Siglent's new product- MSO/SDS2000 Series

[rf-loop]

With the Siglent SDS2000's 2 x 2G ADC's...........

tautech corrected some mistake and  after this also my answer can then flush out.

[rf-loop]

(Hopefully there's some hysteresis on the logic channels.)

I do not know comparators without any hysteresis. But what are specifications I do not have any idea and nothing in any datasheets.

But this is problem with nearly all "logic analyzers" (what are more like data stream recorders)
Im mean these MSO's and "soap box" logic "analyzers".

In real circuits dependent of logic families (and even inside families) there is quaranteed level for logic 0 and quaranteed level for logic level 1. Between this area is undefined/illegal range. These kind of "analyzers" do not know anything about this reality. It need two settable reference level and also way to display undefined level if exist.

Also no one have specified exactly these channels timing, true impedance, true analog rise and fall times and how exatly these are between channels and so on...  so for all these this "analyzer" word is some amount overshoot. And this is not alone Siglent but all these in this kind of class.  When work with this kind of "analyzers" it nee keep in mind that logic devive under test may think 1 and 0 different as these kindd of analyzers (and both are right in they own world but only perhaps there)

It means, if need real logic analyzer, it need buy or rent real logic analyzer.

[Mark_O]

Attached is the Datasheet for the MSO probe set.

This looks good too.  It confirms that the protocol decoders work on the digital channels, which the User Manual doesn't (yet).  And there seems to be a Clock input, which may enable synchronous sampling.  Lastly (for tonite), Page2 has some important considerations which are frequently not conveyed to users (usually with unfortunate results).

The Threshold Accuracy looks rather poor, but their reasoning is correct about why (on Page2).  Though it's unclear if they're reporting the accuracy at the head input, or with lead influences included.  Without the leads, accuracy of the threshold setting should be considerably better than +/-400 mV.  This may just be a Spec Sheet thing.

With the Siglent SDS2000's 2 x 2G ADC's that give a total of 4GSa/s divided by the 8 MSO channels results in a rated 500MSa/s Max for each MSO channel.

Ah, I don't think it works that way (all 8 digital channels are sampled simultaneously).  And the 2 ADC's are running in parallel, along with the digital acquisition.  The 500 MSa/s rate is more than reasonable, given the frequency response of the active logic head, and the flying lead influences.

[nctnico]

And this is not alone Siglent but all these in this kind of class.  When work with this kind of "analyzers" it nee keep in mind that logic devive under test may think 1 and 0 different as these kindd of analyzers (and both are right in they own world but only perhaps there)

It means, if need real logic analyzer, it need buy or rent real logic analyzer.

It seems synchronous sampling is also supported which is a big plus. If the bus display features are expanded a little bit you really don't need a seperate logic analyser. I have used the HP/Agilent MSOs in the past (the early models) and the lack of displaying a bus and synchronous sampling made it necessary to use a seperate logic analyser for some tasks. I think I'll give myself one for Christmas this year 

[tautech]

I'm still looking for the SCPI manual for the SDS2000

The Siglent SDS2000 series Programming manual is under development and will feature an increased set of commands over those used in the SDS1000 series.
Hopefully it will be available to download soon and should also be shipped on the product software CD as it is for the SDS1000 series.

[nctnico]

Has anyone tried the CAN decoding on the SDS2000 series? I have a project coming up where I will be using the CAN protocol so it would be nice to have some CAN decoding capabilities. Should I get an SDS2000 ahead of my schedule or just buy a CAN analyser?

[tautech]

@ nctnico
Just checked my sedan for a diagnostics connector and yes, I could do a check for you.
I had a quick study:
http://fabiobaltieri.com/2013/07/23/hacking-into-a-vehicle-can-bus-toyothack-and-socketcan/
About 1/3 down the page there is a socket and pinout diagram that does not exactly match my sedan, but I will check what signals are there.

[nctnico]

It would be great if you could check if CAN works  Depending on the age of your car you might find two CAN busses. One for the engine and one for the less important stuff like doors, lights, electric windows, etc.

[tautech]

I have only 1 obvious connector, below the dashboard.
Nearly set up, will do some probing to see whats there, then hopefully grab an image and post it.   

[tautech]

Now I do not profess to be any expert at bus decoding and I guess with time I could get a much better result. Errors aplenty namely driver error. 
Pics show a Run/Stop of decoding at a slow timebase then timebase adjusted to show smaller fragments of the decoding.

Does this qualify for an early Xmas nctnico ?

Edit
A nice feature is to be able to select the table and scroll through all the captured lines of decode, one at a time.

[nctnico]

I hate to nitpick on your efforts but what worries me is that all the data decodes as zeroes. I think something is wrong with grounding the scope to the vehicle 
Just to clarify: if you scroll through the table with decoded messages the scope shows the waveform for the decoded message? In other words you can skip through the waveform by selecting a different message?

[tautech]

Vehicle was never turned on.
The reference was a connector pin that measured GND but in the data plug. But you are quite right, the mains related ripple was a real problem.
I will set up again with a better reference(jumper to GND) and get some better results for you.
But Lunch first.

Although many errors are shown, observation shows all data successfully decoded at some point.

[Mark_O]

I have only 1 obvious connector, below the dashboard.

That one OBD-II connector can have as many as 4 active busses running on it: High-speed CAN, Low-speed CAN, slow K-Line (ISO-14230, or ISO-9141), and J1850 PWM/VPW.  Generally, only two of those will be active on any one vehicle, but there are numerous exceptions.  Ford even uses another pair (1/8) for a separate Infotainment CAN bus.  Other lines are 'Manufacturer Discretion', and may be additional K-Lines, ALDL, or 1-wire CAN.

Nearly set up, will do some probing to see whats there, then hopefully grab an image and post it.

Make sure you pick the proper lines... you want 6/14 (CAN-Hi/Lo, respectively).  Those are universal.  That will be ISO-15765, running at 250 or 500k.  As mentioned, there are plenty of other active lines there, just to confuse you.   

[Mark_O]

Vehicle was never turned on.
The reference was a connector pin that measured GND but in the data plug. But you are quite right, the mains related ripple was a real problem.

No, it's actually not.  Granted, it looks bad, but this is exactly the type of environment CAN was designed to function in.

a)  CAN is a differential bus.
b)  CAN-Hi and CAN-Lo go in different directions, and thus the polarity on your screen for one channel is wrong (CAN-Lo goes negative)
c)  in the Recessive state, they're both the same (0), and in Dominant, their differential amplitude is doubled
d)  that means the ripple, even of such large amplitude, will get canceled out, when the 2 channels are combined (in-phase noise is eliminated)
*)  to clarify, CAN-Hi is Added to the inverse of CAN-Lo by a bus transceiver  (or the Rigol decoder)
e)  that's how you get the noise immunity required in such an environment, enabling reliable communications

Somehow, you've just got 2 copies of the same CAN signal, and that doesn't do you much good.  Though you can decode CAN with only one-side, as long as there is no noise.  I've done it, but wouldn't recommend it, since "Seeing" even just 1 error (corrupted packet) in 1000 messages, that isn't really there, doesn't enhance productivity.

Although many errors are shown, observation shows all data successfully decoded at some point.

I hate to have to say this, being as you're such a good guy and all, but you haven't decoded any CAN data yet.    Like the last time you tried this, and wound up "decoding" the gaps between the packets, and unsurprisingly got all 00 "data".

I'd offer to set up the scope for you, but I don't have one here so I could walk you through the settings.  Maybe if you email me airfare, I can hop a plane to NZ and show you how to do it.     Yeah, that's the ticket!  (apologies to J.Lovitz, SNL)

"A" for effort, though.     Not everyone would be willing to explore unknown territory, as you have been.

[Mark_O]

For some examples of CAN data being properly decoded, you can look at what Teneyes has done with his Rigol...

https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg439487/#msg439487

[tautech]

Thanks Mark for the advice.

Only 2 active lines that seem identical with engine running or not.
Of course much more data when running.
Best result was @ 50 KHz bus speed setting.

Aussie Holden Commodore V6 by GM

Will do some more attempts in due course

[don]

Moving discussion over here (start of topic at https://www.eevblog.com/forum/testgear/siglent-technical-support-join-in-eevblog/225/)

------------old post ----------
"For example, I'm at 1.4Mpts and 20MSa/s (5ms/div).  It decodes data fine and I see 12 messages but too small to read.  As soon as I change the time base to zoom in, the decoded messages go off screen but the signaling of all 12 packets stays on screen.  Further scrolling of horizontal or changing time base does not help bring back decoded messages.  Unless I change timebase back to 20MSa/s.  It's very odd. "

"When I have some time I will investigate more.
What Protocol are you decoding?
Please start with reply in this thread:
https://www.eevblog.com/forum/testgear/siglent's-new-product-msosds2000-series/  "

------------------New post--------------
I'm decoding I2C. I'm also using an I2C trigger on 7bit address & data.  Trigger works fine.  My goal is to decode measurements using as much memory as I can and zoom in on a specific event.  What I've noticed:

Memory must be 1.4Mpts or less to decode.  It will try to decode but just gives a flat blue line if 7Mpts or 14Mpts.  Once I get it to decode correctly with 1.4Mpts my goal is to zoom in.  The zoom feature is not functional during decode or roll mode.  I'm hoping this gets fixed.   So next step is to adjust time base and move horizontal position.  This occasionally works but rarely.  This would be an okay work around to zoom if fixed.   I suspect if I capture at just the right memory and sample rate it will let me change the time base and keep decoded messages in sync with waveform.  But usually as soon as I change the scale the decoded messages move off screen.  The decoded messages behave in a similar fashion compared to roll mode.  In roll mode the center of the screen moves off screen as soon as I change the time base, and in decode mode the messages move off screen as soon as I change the time base (but happily the signals zoom son center of display as expected -- just need to implement that in roll mode).

So I'm not sure what is going on with decode.  It sort of works.  It definitely seems okay as long as you have waveform filling the screen.  But once a zoom is required it starts misbehaving. 

The list function works well except you cannot correlate the messages in the list to the waveforms which would be great.  Meaning would be great if you could scroll though decoded messages, click on one, and have waveform reflecting message jump to the center of screen.

I just received scope today so am putting it through the paces with latest firmware.  I thought I had zooming in roll mode figured out.  I found that time base changes center on the right side of screen (should obviously be center).  But as soon as you zoom in such that memory decreases along with time base you lose the waveform.  So if I'm in roll mode at 200ms/div for example, I can change time base trying to zoom in on the whatever I have on the right edge of screen.  As soon as I see the memory drop because of the sample rate increase (zoom mode does not work here remember), I lose the waveform.  I find I can only zoom to about 1ms when in reality I should be able to get to 500ns/div or so.

Ironically I purchased this scope specifically for long memory and zooming in on roll mode plus the I2C decode.  But I understand firmware is not mature so we will see what improvements can be made. 

[don]

Sorry for the long post before.  Just found a common thread with odd I2C decode behavior.  All my prior I2C decode acquisitions were with single triggers.  If I set to normal trigger followed by pressing the run/stop button to stop,  decode & timebase changes  generally works even to full memory depth of 14Mpt.  So that's good news and should be an easy firmware fix.  When I press run/stop I see the image repaint as it does some house cleaning. 

Now we need proper zoom mode working here and in roll mode, or at least fix the time base changes in roll mode. 

[don]

Okay, Roll mode update:

If memory is set to 1.4Mpts or less, I can run roll mode, stop acquisition and change time base & horizontal position.  The catch is that it zooms on the right side of screen and not the center for some reason.  Zoom button still does not work but this function is becoming a close equivalent.

As soon as I increase sample size to 7Mpts, I can change time base about the right edge of the screen as well.  As I decrease timebase / zoom in, the memory eventually drops from 7Mpts to 2.8Mpts then hits 1.4Mpts.  At 1.4Mpts the waveforms jumps off screen. At 14Mpts I see the misbehavior begin when it drops from 7Mpts to 2.8Mpts.  So it's okay until it decreases the it's sample size by two steps.

 

[don]

Hi All,

Does someone report these bugs to Siglent or do they monitor directly?

Summary of issues  I found on my first day with  SDS2074 (with updated firmware):

1) zoom does not work in roll mode
2) zoom does not work when decoding
3) cursors do not work in zoom mode
4) changing timebase in roll mode is centered on right edge of screen instead of center of screen (works correctly in YT mode)
5) changing time base in roll mode (centered on right edge of screen ) works for sample size up to 1.4Mpts.  At 7Mpts and 14Mpts waveform focal points shifts off screen when time base reduction causes sample size to decrease  two steps (is 7Mpts ->2.8Mpt->1.4Mpts= fail)
6) i2C decode only works reliably if normal trigger is used and acquisition is stopped with run/stop.  If single trigger is used, the decoded mesages and waveforms lose alignment when time base is changed.
7) pressing stop from normal trigger sometimes causes captured waveform to disappear.
8 ) Is it possible to add cursor gating to measurements??
9) During normal triggering screen updates are not fully cleared before updated waveform is displayed (new waveform + old waveform are shown at the same time).  Need to press stop to repaint the screen with last waveform.  Observed with I2C decoding, may or may not be related to decoding.

#4,5,6,7 make it very difficult to use scope. I was pulling my hair out until I saw a pattern that I could work around.  Hoping to get confirmation that these will be resolved before my 30 day return option is up.   I can work with Siglent directly if they are not represented here.

Unit is pretty nice otherwise. Unless other issues come up I'm pleased with performance so far.

Thanks,
Don

[nctnico]

About 9:
Many Tektronix scopes do this as well. Sometimes this is handy to get a feel about how wide a pulse varies and sometimes it is outright annoying.

[Mark_O]

Sorry for the long post before.

Hey, don't apologize.  This is good stuff.  Both for potential buyers, to know what to expect.  And for Siglent, so they know what they need to fix.

Just found a common thread with odd I2C decode behavior.  All my prior I2C decode acquisitions were with single triggers.  If I set to normal trigger followed by pressing the run/stop button to stop,  decode & timebase changes  generally works even to full memory depth of 14Mpt.  So that's good news and should be an easy firmware fix.

Agreed.  It does sound like a mode-specific glitch, and the underlying functionality is OK.

Now we need proper zoom mode working here and in roll mode, or at least fix the time base changes in roll mode.

I'd say both are required.  Thanks again for your test reports.

[tautech]

Pointed Siglent to post:
https://www.eevblog.com/forum/testgear/siglent's-new-product-msosds2000-series/msg493484/#msg493484
Thanks for the "heads up" don

[marmad]

1) zoom does not work in roll mode

Hmm... does Zoom work on any DSO while using Roll Mode? It certainly doesn't work on the Rigol DS2000 series - and I'm not so certain it could.

Roll mode is a completely different kind of acquisition - sampling and doing decimation bit by bit - as opposed to a screen at a time. Zoom mode suggests that the DSO go back to the original sampled data and re-decimate for a different time base. This seems like an impossibility to me in Roll mode due simply to the method of acquisition. But perhaps I'm wrong about this.

[don]

About 9:
Many Tektronix scopes do this as well. Sometimes this is handy to get a feel about how wide a pulse varies and sometimes it is outright annoying.

I've observed many Tek scopes doing this as well, but I don't think it's an intentional feature but instead an artifact of architecture.   You can take two TDS754D's (different vintages & options) and one will show remnants of last waveform, and one will not.  The newer one does not.  Both high end scopes in the day and both worked this way out of box and useable.

I use newer tek, agilents  and lecory and don't recall any of them doing this.   Behavior of Siglent jumped out at me.  Might be common at this price point though.