Siglent SDS2000 new V2 Firmware

[Performa01]

Or so you hope!   Don't forget that this scope is on the market for almost two years now, and still suffers from bugs that make it pretty useless for any real type of work.

What bugs are you talking about, that make it ‘pretty useless for any real type work’?

I have used the SDS2000 to troubleshoot, repair and redesign some older test gear, including some high precision stuff, and as a DSO, it didn’t let me down. I just had to use a separate LA as the digital channels were not working with the initial V2 beta firmware.

Other brands are big companies that have built gear for decades and have a big R&D department with lots of firmware developers. The firmware for a complex piece of gear like a modern MSO isn’t that easy to develop from scratch with just a handful of people.

In short, you pretty much bought a half-finished (ok, 70% finished) scope and agreed to work as a beta tester for free. 

What’s left, if nobody else does?

Siglent claims to aim for making affordable test gear available for everyone. Many private users out there certainly welcome that. Do we reach that goal by just bashing Siglent for some immaturities in their firmware, or is it more likely to achieve something by reporting any bugs we find?

I could understand if people get angry for instance about bugs in a Rigol 4k, as these start approaching the prices of A-brand scopes in the same class, also with the various software options. If we have to pay big money like for an established A-brand, we expect a mature product indeed.

Yes, the WaveAce is shit (guess who made them?) but there are many other alternatives which aren't.

Oh, of course. If you you’re willing to pay 5k or more for the basic scope, plus another 1k for each and every software option, even if it’s a serial decoder for just a single protocol, and still make do with relatively short memories, than I’m sure you’ll find ‘many other alternatives’.

Most of them? The Keysight DSOX2k has a hires mode (10bit), as does the R&S HMO1000 (up to 16bit?). If I remember right even the Rigol DS2k/DS4k have some working hi-res modes.

Maybe. I have the impression that resolution enhancement wasn’t that common until recently.

That's nonsense, sorry. FFT does not need 12bit vertical resolution to "make sense", and is a pretty useful facility even on 8bit scopes, assuming of course the implementation isn't crap (like Rigol's limit of a few thousand points only) and works correctly (which it does on other scopes).

For spectrum analysis, I personally just cannot think of too many use cases, where I would want to have less than at least 70dB of dynamic range.

Reliability is certainly an issue, but frankly what accuracy do you expect from a scope with a timebase that is spec'd with +25ppm? Without an external clock reference (i.e. GPSDO) the accuracy will be limited by nature.

I don’t think I expect something unreasonable. Every single quartz crystal oscillator I’ve used so far was pretty much spot on within a couple ppm of its nominal value at room temperature, despite the specs that usually say +/- 100ppm. So it is somewhat strange if an oscillator in a scope is close to the limits of its accuracy spec. right from the start.

The much bigger problem is the lack of resolution anyway, due to its not implemented as a reciprocal counter, which is all the more incomprehensible, given all the computing power in such a scope.

Reliability is certainly an issue, but frankly what accuracy do you expect from a scope with a timebase that is spec'd with +25ppm? Without an external clock reference (i.e. GPSDO) the accuracy will be limited by nature.

I don’t think I expect something unreasonable. Every single quartz crystal oscillator I’ve used so far was pretty much spot on within a couple ppm of its nominal value at room temperature, despite the specs that usually say +/- 100ppm. So it is somewhat strange if an oscillator in a scope is close to the limits of its accuracy spec. right from the start.

The much bigger problem is the lack of resolution anyway, due to its not implemented as a reciprocal counter, which is all the more incomprehensible, given all the computing power in such a scope.

Y out was pretty much only available in a few specific Tek scope models and was also bandwidth limited, so it was only really useful for very specific cases.

To put it in your own words: that’s nonsense, sorry.

But on this topic I discovered something interesting:

http://blog.hameg.com/?p=622

So while I thought Y-out has gone with the introduction of digital scopes, apparently Hameg/R&S provide a Y-output (again) at least for their HMO series. That’s great news, and makes these scopes attractive for people who want an accurate trigger frequency display. And it is exactly like it used to be with the analogue scopes – the y-output follows the triggered channel. And no, it was NOT bandwidth limited at all.

I have no doubt though, that the built in frequency counter of an HMO has true 6 digits of resolution and would be fairly accurate (like even on the ancient Rigol 1054E), so there is much less need for an y-out just to feed a proper external frequency counter anyway.

[nctnico]

Maybe. I have the impression that resolution enhancement wasn’t that common until recently.

That depends on your definition of recently. The Tektronix TDS500/700 series which was introduced around 1990 has high-resolution mode as standard.

[Performa01]

The V2 firmware doesn't look like it is much better than the V1 firmware. Just more things plastered over. If you want to use an oscilloscope's FFT function to check the spectral waveform purity of the signal generator than you are clearly using the wrong tool.

Oh? I’m a bit confused right now. What do we use in order to check the spectral purity of a signal? A spectrum analysis tool, don’t we? And what is an FFT analyser then?

So you probably meant to say I should have used a _proper_ spectrum analyser instead, right? You’re absolutely correct about that – I just don’t have one here at the moment (and the one I have in my second lab only starts at 500kHz, so there would have been a gap anyway).

So you’re basically suggesting that FFT on an 8 bit scope is not the right tool to do a proper spectral analysis. That’s certainly correct, mainly because of the severely limited dynamic range.
 And that’s exactly what I said all the time.

Either way the value for money the SDS2000 offers just isn't good because a lot is severely limited at best. You can buy a used DSO for the same amount of money which has proper FFT and works as advertised.

Is it really that limited? Just because average and Eres modes aren’t very useful right now? And just because of the FFT? Why do we need FFT on a scope anyway, when you yourself stated it’s not the proper tool for doing spectrum analysis?

The added value of the SDS2000 is in the MSO, protocol decoding and advanced features but it is those that cause most of the headaches. If I didn't need protocol decoding I'd never bought the SDS2000 to begin with!

That’s fine, but not everyone is like you.

There are also folks like me, who want a scope with reasonably high bandwidth, high signal fidelity and a reliably working, jitter-free trigger system. And deep memory of course, so we don’t run into aliasing troubles when looking at signals that contain LF and HF components at the same time.
Ah – yes, we also want a reasonable high waveform update rate, so that we can see what’s going on with a dynamic signal.

All the additional bells and whistles are nice, but it’s not the world if there are still some flaws in them.
Particularly for protocol decoding I have no problems to stick with my LA if needed. The nice thing of an MSO is that it’s so easy to correlate analogue and digital signals, where digital in my case mostly means control signals and not a serial bus, even though this would certainly also be very useful for some cases, e.g. troubleshooting A/D or D/A converters with a serial interface.

Also your remarks about averaging and high res being OK with a short memory is nonsense.

Thank you. Where and when did I ever say it is ok?

The best thing I’ve ever said about average mode is that it’s kinda usable, but would be much more useful if only we had more memory available. What I said is that we should be able to live with the slow wavefrom update rate, as there is no hardware support available in this mode.

For Eres mode, I’ve even stated that the way it is implemented now I cannot think of any useful application. But on this one I was not quite right, because it can still serve as a noise reduction tool for non-repetitive waveforms. But having said that, please don’t argue sometimes in the future that I’ve made a remark that Eres is ok, ok?

What I finally said is that there are still scopes in the same price range that do not have long memory in the first place.

They are very handy to clean a signal up so you can make accurate cursor measurements. I made good use of that in one of my recent projects on a trace which was several seconds long.

Yes, as it is now you couldn’t use it for that, except when the signal frequency stays below some 250Hz.

Still I'd like to see how the protocol decoding works in the V2 firmware and whether you can zoom (using the s/div knob) into the bits of a message without losing the decoding. And does zoom mode work together with decoding in the V2 firmware?

I’ll certainly do that, but I have to set up something that generates a serial data stream first. Unfortunately I don’t have anything ready to use at my hands at the moment.

[nctnico]

The V2 firmware doesn't look like it is much better than the V1 firmware. Just more things plastered over. If you want to use an oscilloscope's FFT function to check the spectral waveform purity of the signal generator than you are clearly using the wrong tool.

Oh? I’m a bit confused right now. What do we use in order to check the spectral purity of a signal? A spectrum analysis tool, don’t we? And what is an FFT analyser then?

So you probably meant to say I should have used a _proper_ spectrum analyser instead, right? You’re absolutely correct about that – I just don’t have one here at the moment (and the one I have in my second lab only starts at 500kHz, so there would have been a gap anyway).

So you’re basically suggesting that FFT on an 8 bit scope is not the right tool to do a proper spectral analysis. That’s certainly correct, mainly because of the severely limited dynamic range.

Stop moving goal posts / twisting what I wrote! A good LF sine wave generator will have a harmonics well below 40dB so it rather is obvious that an 8 bit FFT isn't going to cut it but an 8 bit FFT is still perfectly useful for checking filters, system bandwidth, distortion, EMC issues, etc. Your claim FFT is on an 8 bit scope is useless is just nonsense.

The added value of the SDS2000 is in the MSO, protocol decoding and advanced features but it is those that cause most of the headaches. If I didn't need protocol decoding I'd never bought the SDS2000 to begin with!

That’s fine, but not everyone is like you.

There are also folks like me, who want a scope with reasonably high bandwidth, high signal fidelity and a reliably working, jitter-free trigger system. And deep memory of course, so we don’t run into aliasing troubles when looking at signals that contain LF and HF components at the same time.
Ah – yes, we also want a reasonable high waveform update rate, so that we can see what’s going on with a dynamic signal.

With those requirements the SDS2000 simply is the wrong choice; a second hand DSO from an A-brand would be a much wiser choice! How many hours did you waste doing tests on your SDS2000? If you would have put those hours to better use you may have made enough money to cover the price difference between the SDS2000 and a scope which works.

[smarteebit]

... Same goes for Eres and averaging. Without long memory they are utterly useless because at some point you will want to zoom in on a long signal. ...

For Eres I agree with you, but for averaging why is long memory so important? It must be a periodic signal to apply the averaging, a single peroid contains all the information you need. I think in most of cases kpts memory and >60 wfm/s update rate are enough for average mode.

[nctnico]

A frequency sweep is also periodic!

[smarteebit]

A frequency sweep is also periodic!

I don't think it is wise to use averaging to observe a frequency sweep signal. Have a try.

[nctnico]

A frequency sweep is also periodic!

I don't think it is wise to use averaging to observe a frequency sweep signal. Have a try.

Use the sync output of the generator as a trigger and you'll be able to average a frequency sweep on a long trace without problems.

[Performa01]

Horizontal Position

Just want to point out something that regularly ticks me off – it’s the horizontal position adjustment on many DSOs – not just Siglent.

Let’s have a look at the vertical position first.

I set it 3 divisions down the centre, which corresponds to -60V in the 20V/div vertical gain setting (V_Pos_20V)




Now when I ‘zoom’ into the waveform vertically, by increasing the vertical gain to 2V/div, everything works as expected. The vertical position remains unchanged and corresponds now to -6V, as it should be (V_Pos_2V)




Now let’s do something similar with the horizontal position.

I set the position 2 divisions left of the centre, which corresponds to -1ms at a 500µs/div horizontal timebase setting (H_Pos_500us)




When I ‘zoom’ into the waveform horizontally, by lowering the timebase to 200µs/div, the result is quite different to the vertical settings: now the trigger point moves to the left and is now 5 divisions left the centre (H_Pos_200us)



Of course, making the timebase even faster would move the trigger point out of view.

This behaviour is rather annoying and inconsistent with the vertical position.
Both, x and y position knobs are labelled ‘Position’.
For both, the screen display doesn’t show a position, but an electrical quantity, volts for vertical and seconds for horizontal. But in the case of vertical, the position remains constant and the displayed volts offset changes according to the vertical gain setting, whereas for horizontal, the position changes and the displayed time offset (called ‘Delay’ here) remains constant.

We often want to zoom into a waveform horizontally, but at the same time we don’t want to change the position of the trigger point on the screen.

I know, many scopes (but not all!) do it like the Siglent, but that doesn’t make it right in my book.

Maybe we could get a compromise in one of the next firmware releases: the horizontal menu is pretty empty anyway. Why not include a menu item to chose between constant screen position (as I think it should be anyway) and constant delay (as it is now)?

[nctnico]

On many (higher end) DSOs you can adjust the horizontal position. In my case I often have the trigger point set somewhere in the left part of the graticule because in 90% of the cases you are not interested in what is before the trigger point.

[tautech]

Funny isn't it how what some of us accept as normal behaviour drives others to despair.

As you say most of us have experienced this, I have many times and the normal workaround is to return the H position to zero and readjust to suit the job at hand.

It could well be a handy feature you ask for, just as you say closer examination of one part of a waveform with a H offset WILL have the waveform off the display at faster timebase settings.

Yes, there's heaps of room in the Horizontal menu to incorporate such a feature.

Which other brands have a user definable horizontal position?

Anyway I'll vote for it, who else?

On many (higher end) DSOs you can adjust the horizontal position. In my case I often have the trigger point set somewhere in the left part of the graticule because in 90% of the cases you are not interested in what is before the trigger point.

Brands? Models?

[rf-loop]

Setting delay and setting horizontal position is bit different. Because setting delay from center line moves horizontally. But this is based to time, not based to distance in divisions or millimeters etc. You set TIME position related to center line.

Now if we change time scale of course horizontal position moves because we have set how far in time we want be from center line.

There need be one setting more. Lock trigger position to the current user adjusted position on the screen independent of t/div scale  and then same function need include swap between delayed time position and this trigger position....it need just one button... or there can even use long push and short push or ... this need carefully design for good useability.   

Also more wishes.  Add one feature. When zoomed and trig position is horizontally where ever is... one button: set zoomed window center to trigger position. My fingers are tired to turn these adjustments... 


....also many adjustments are frustrating slow and I hope they develop FW better also for these small things (but honestly it can also tell that overall Siglent have developed themselves lot of... but always..developing road is endless.). Try turn example trigger holdoff adjust from minimum to example 500ms..  Do Siglent think I will employ one secretary who turn this knob so that I can go to coffee for this waiting time.  These kind of adjustments need be flash speed if people do work for earn money with using instruments.  Why they do not think themselves how instruments UI need build. Peoples who have only sit in school whole life and without any real knowledge and enough experience how to use test and measurements equipments in practice for real working can not design UI. Period.  And Siglent is not in this club alone and not at all poorest member!

Lets money talk... What ever scope, Rigol, Siglent or xxxx If I need every work day use extra time for nothing, just loosing time for  turning some slow adjustments extra 10 minutes when this can do in 15 seconds if functionality is designed right. Every year I loose more than one these kind of oscilloscopes price just alone for this one thing. If these kind of things are many...  and my working power decrease say 20% due to instruments poor useability...   hobbyist is different. He can think and talk with his wife...oh well...hobies take time..

[nctnico]

Funny isn't it how what some of us accept as normal behaviour drives others to despair.

As you say most of us have experienced this, I have many times and the normal workaround is to return the H position to zero and readjust to suit the job at hand.

It could well be a handy feature you ask for, just as you say closer examination of one part of a waveform with a H offset WILL have the waveform off the display at faster timebase settings.

Yes, there's heaps of room in the Horizontal menu to incorporate such a feature.

Which other brands have a user definable horizontal position?

Anyway I'll vote for it, who else?

On many (higher end) DSOs you can adjust the horizontal position. In my case I often have the trigger point set somewhere in the left part of the graticule because in 90% of the cases you are not interested in what is before the trigger point.

Brands? Models?

AFAIK on all Tektronix and Yokogawa scopes the trigger position can be adjusted freely. My Agilent DSO7000 allows to select left, centre or right but I would expect the lower end models to also have this feature.

[Performa01]

Serial Decoding (DSO) - UART

As the heading suggests, this is about serial protocol decoding with the analogue channels.

I will not be able to test all the decoders, but will review the UART protocol for a start. It’s not only the oldest standard, but also still a very common one – almost every microcontroller comes with UART  hardware built in.

Historically, there is a number of possible configurations, regarding the number of bits (5-9), frame format (1, 1.5 and 2 stop bits), parity (even, odd, none) and handshake. For my test, I’ll stick with the simplest (and most common) setup:

8 data bits, one stop bit, no parity, no handshake (which is irrelevant for decoding anyway).
Idle level is always high, unless we have to deal with an inverted UART signal.

The industry standard speed setting is still 9k6 baud, but I wanted to go a little faster than that - and by that, I already found some serious bug…

The microcontroller used for generating the serial data stream has a rather primitive baud rate generator that would not be able to generate more than 38k4 baud with decent accuracy (at 20MHz clock).

Initially, I wanted to use 115k2, where the micro would actually generate 113636 baud, that’s an error of -1.36%.
In order to make sure my test isn’t flawed by any major timing inaccuracies, I wanted to set the scope to exactly that baud rate, but it turned out to be pretty much impossible (UART_Custom_Baud)




Bug Alert: The custom trigger setting is unusable. I tried to set 113636 baud for several minutes before I finally had to give up. Adjustment seems to work initially, but because of the poor responsiveness of the select knob it would take some time to get there anyway. But at a certain point, it starts making big jumps and the values go all over the place. For instance, at about 80000, it suddenly jumped down to 70000, than back up to 90000 and then to 140000 with one big leap. When I tried to get back down, it would eventually jump back from 122000 to 300. I tried again to go up to 113000, but to no avail – after approaching 80000, values start to jump randomly and go all over the place.

After that experience, I decided to stick with 38k4, which my little micro can generate with just 0.16% error. This is a standard baud rate, consequently one of the predefined settings on the scope (even though not visible in the screenshot, these are available down to 600 and also 300 isn’t a problem, as this is the lowest custom setting).

The signal setup is Ch. 1 for RX and CH. 4 for TX. Since I don’t actually have any valid RX signal, it would be nice if I could disable decoding for RX in the channel selection menu. But then again, in any real application we would hardly have an UART communication in just one direction (UART_Signal_Setting)




For the initial test, I’ve set a standard trigger on the falling edge of the TX signal (Ch. 4). After switching ‘Display’ on, we get the decoded values at the bottom and in a list overlay on the top half of the screen (UART_Decode_full_14)



At the bottom of the screen we have two lines of decoded values. Since Ch.1 carries just a random signal, we can’t get any meaningful values and the decoder doesn’t even detect anything before the trigger position (which sits at 50% of the screen width).


With serial decoders active, we have a memory limitation once again – we cannot have more than 1.4/2.8 Mpts of memory (UART_Decode_Memory)



Why this limitation?

But I guess I know the answer – it’s probably all about processing power, as the waveform update rate drops to just ~1/s when decoding is active. This would certainly get worse with more memory…


Switching Ch. 1 off makes the unwanted line of decoded RX values disappear (UART_Decode_full_4)



Now we only have the TX decoding left, but of course we cannot see anything, as there is a total of some 1000 values on the screen.

But we also have the list on the top half of the screen, which shows the values for RX/TX together with individual timestamps and error information. The list size can be configured from 1 to 7 lines and I’ve set it to the maximum right from the start.

Complaint: There is so much space in that list – why on earth do we only get hex and cannot have decimal and ASCII decoding as well? This would make it s much more useful.

To verify the validity of the decoded data, my test data is configured as a stream of packets, 16 bytes each, which just contain a counter running from 0 to 0xFF. So the first packet contains the numbers 0 to 15, the second one 16 to 31 and so on. After the last packet (240 – 255) it starts over again at 0 – 15.

As we can see in the list, the first four decoded values aren’t correct, quite obviously the decoder just starts with the first captured data and doesn’t seek for a proper start condition first. But at least it gets in sync eventually, so everything looks fine after the 4th decoded value.

Now we can scroll through the list to inspect the other values, which can be a tedious task for that many values as there is no acceleration for the select knob – but at least it doesn’t do funny things like jumping around. Instead it has something else to offer (UART_Decode_Full_Scroll)




Instead of moving through the list, as we’d expect, it highlights any line we’ve ever selected, plus showing some funny artefacts in the RX and TX ERR columns.

Bug1: The selection knob really is a pain to use. It either does funny things in a failed attempt to respond to the speed of turning it, or it doesn’t change it’s behaviour at all, making it almost impossible to get through a longer list or a larger number of selections.
Quite obviously there is not one central driver for the rotary encoder with working parameters for base sensitivity and acceleration, that hopefully would be tested to be fool proof in operation, but each part of the scope seems to use its own encoding routine and so we don’t get a consistent behaviour throughout the instrument. This problem certainly has to be addressed.

Bug2: The list navigation basically works, but it clearly shouldn’t look like this. The arrow in the leftmost column should only be in the line currently selected, and all the shading and funny artefacts shouldn’t be there, should they?

After a while of twiddling with aching fingers I got to the point where my counter overflow occurs. We can see this happen between decoded values #212 and #213 (UART_Decode_Full_Rollover)



After even more twiddling and a serious amount of time, I finally managed to reach the trigger position, where the timestamp changes sign (UART_Decode_Full_Trigpos)




Now instead of just looking at the decoded values in the list, we want to see them correlated to the actual waveform. We can do this by lowering the timebase setting and then use the horizontal position control to navigate through the data (UART_Decode_Detail_0us, UART_Decode_Detail_200us)






The list display only shows what’s on the screen, which is a good thing given the poor response of the select knob. The problem with this is that the correlation to the total captured data is lost, as the list now starts with number one again and we cannot know how this relates to the numbers in the full list.

An alternative (and probably better) approach would be to always have the full list and we could select a value in it and the corresponding waveform gets automatically centred on the screen. This way we wouldn’t need the horizontal position control at all.

Another way to look at the details is using the Zoom function (UART_Decode_Zoom)



This works beautifully now. The list starts at 1 again, hence still doesn’t correlate to the total data, but other than that everything works as expected. We can use the horizontal timebase and position controls to navigate through the data.

There’s a lot more to serial decoding (and triggering!), but this review is already long enough so I’ll stop it here in order to draw a first conclusion.


Conclusion:

Serial decoding certainly works – at least for the UART, that has been tested here – and is already quite usable, but still has a number of bugs and flaws that need to be addressed.

• In general, the Select knob is a pain to handle and it behaves quit differently for different applications within the scope. This really needs a central encoder driver with proper sensitivity/acceleration parameters, properly tested to be effectively and reliably working. It’s these little things that can completely spoil the usability experience with any instrument.
  
• The list display navigation needs to be fixed. Multiple arrows, highlighting like a multi-selection plus some artefacts look weird and lead to confusion.
  
• The list display should contain decimal and ASCII representation of the data together with the hex value that we already have.
  
• It would be nice if the numbers in the list of decoded values would always stick with the decoded value, i.e. the list would not start with 1 again in zoom modes, but keep the numbers of the total capture for the decoded values shown.
  

EDIT: Configurable decoder list size corrected to 1 - 7.

[Performa01]

Which other brands have a user definable horizontal position?

It certainly needs not be a high end scope.

PicoScope for instance, who is a reputable UK manufacturer of USB scopes up to the >10k price range, have this for all their scopes. You don't set a horizontal position, but a pre-trigger range expressed in 0 ~ 100% of the horizontal screen width. That's the logical and intuitive way to do this and is in accordance with our experience with analogue scopes, where the trigger position doesn't change with timebase, no matter what we've set the horizontal position).

[nctnico]

The list display only shows what’s on the screen, which is a good thing given the poor response of the select knob. The problem with this is that the correlation to the total captured data is lost, as the list now starts with number one again and we cannot know how this relates to the numbers in the full
list.

An alternative (and probably better) approach would be to always have the full list and we could select a value in it and the corresponding waveform gets automatically centred on the screen. This way we wouldn’t need the horizontal position control at all.

The Agilent DSO7000 works this way which is a real blessing when looking for a malformed packet. The waveform tracks the selected message from the list (which shows all the messages in the memory and not just what is on screen).

All in all the decoding on the SDS2000 is still crappy (as I feared). How on earth are you going to find a missing/malformed bit or message? BTW I have pointed Siglent to Youtube videos on how decoding should work early in 2015 but appearantly they are not willing to learn!

[Performa01]

There need be one setting more. Lock trigger position to the current user adjusted position on the screen independent of t/div scale  and then same function need include swap between delayed time position and this trigger position....it need just one button... or there can even use long push and short push or ... this need carefully design for good useability.   

I totally agree.

The PicoScope I've mentioned before certainly has both settings at the same time - pre-trigger range (trigger position) and trigger delay. The latter I've never used so far, because thankfully I was always able to set up a trigger condition closely related to the signal I wanted to see. So I thought trigger delay would generally not see much use (except maybe analogue video signals when no dedicated video line/field triggers are available, but that should be a real niche application nowadays), hence I could make do with just having to switch between the two in the horizontal menu.

I would even be happy with a soft button in the horizontal menu, where we could set the trigger delay by means of a (hopefully properly working by then) select knob, just like the holdoff value in the trigger menu. But the main use of the horizontal position control should be to set the screen position of the trigger point, that would not change with the timebase.

[Performa01]

Serial Trigger (DSO) - UART

I’ve still used a conventional edge trigger for the review of the serial UART protocol decoding. Now let’s see how well the serial UART trigger works.

The setup appears to be independent of the serial decoding, so we need to repeat all the settings here, such as channels, trigger levels, idle level, bit order, plus the specific UART protocol settings (number of bits, stop bits, parity, baudrate).

We can trigger on several conditions, for instance on the start of a frame (UART_trig_start)



Of course this will trigger on the start of any frame, so we get just a random portion of our data stream. We can also trigger on the stop condition (UART_trig_stop)



That doesn’t make much of a difference, other than the trigger fires just one bit clock earlier, i.e. on the stop bit, that is immediately followed by the start bit within one packet.

Apropos packets: in the previous screenshot we can see the transition between two packets, as I deliberately programmed a little break between them. It is the signal staying idle for some 240µs on the transition from 0xef to 0xf0.


We can trigger on specific data as well, unfortunately a single data item only, not a complete message. The following screenshots demonstrate this by triggering on

0x00  = the start of the first packet
0x1f = the end of the 2nd packet
0x20 = the start of the 3rd packet

(UART_trig_data_0x00, UART_trig_data_0x1f, UART_trig_data_0x20)








There is also a parity error trigger, and of course it never fired in my test setup, since parity isn’t even enabled. I didn’t test this any further as I couldn’t be bothered to program the UART in my micro ina way that it would generate parity errors sporadically – I’m just willing to believe that this trigger condition works, provided parity checking works in the first place. This I’ve also not tested yet, but then again, most UART connections only run over short distances nowadays and so we don’t usually configure them with parity – just like for SPI busses, where parity checking isn’t even an option.


Conclusion

The serial UART trigger works just fine, though it would be nice to be able to trigger on more than just one single data item. Setting up a list of, say, up to 8 data items that have to occur in the data stream in sequence in order to fire the trigger would certainly be helpful in finding a particular message on a busy data connection.

[Performa01]

Serial Decode (DSO) - SPI

SPI is a synchronous serial transmission standard, so we would expect decoding to be a fair bit easier than the asynchronous ones, like UART, where the bit clock has to be recovered from the data stream in order to decode it.

There are 4 SPI modes for data setup and sample at any combination of clock polarity (which determines the idle level) and clock phase (leading or trailing edge).

I’ve set up the most common SPI mode 0, which means clock idle level is low, hence positive clock polarity and data is set up on the falling (trailing) edge and sampled on the rising (leading) edge of the clock signal.

The data length can be set to anything from 4 to 96 bits, but 8 bits is the most common configuration, and I’ve used this one too.

Interestingly, the SPI decoder of the SDS2000 doesn’t provide a configuration for the clock polarity (or idle level), which might make it a bit more difficult for the decoder to get in sync at the start of a packet. At least there is a toggle for selecting the clock edge for sampling, which just distinguishes between SPI modes 0/4 (rising) and 1/2 (falling). So I chose the rising edge (SPI_Decode_Setup_CLK)




As my little micro provides almost no hardware support for SPI, I stick with a clock of only 100kHz, but I also have no doubt that speed doesn’t matter for this test as long as the sample rate is kept about an order of magnitude higher than the SPI clock.

In contrast to UART, data channels can be disabled in the SPI decoder menu, even though the menu item says ‘CLOSE’ whereas I would think ‘Disable’ would be more descriptive (SPI_Decode_Setup_MISO)




For the initial tests I use negative edge triggering on the slave select signal, which is labeled ‘CS’ in the SDS2000 decoder menu and the ‘~’ (C language notation for bit-wise inversion) is used in the menu to describe an inverted signal (SPI_Decode_Setup_CS)




Complaint: While the SDS2000 keeps most settings after a restart, it does not preserve the threshold levels for the various signals. In my setup, threshold levels reverted back to 16V after every restart and I had to set them again to 2.5V for each individual signal (SCK, MOSI, CS).

At a timebase setting of 100µs/div we can see a complete packet with 16 data items. Decoding appears to work and only the MOSI line of decoded values is displayed at the bottom of the screen, just as expected. The data look correct, just the first value (0x50) is already a little too wide to fit the available space and the incomplete display is indicated by a red dot

I’ve set the trigger point to about 7% of the screen width, so the 2nd list entry corresponds to the first data after the trigger point, with timestamp 0.00µs (SPI_Decode_100us_7%)



The first decoded data item at -98.00µs is faulty (should be 0x4f), as is to be expected, since the packet is truncated. But why on earth is it displayed in the first place? The decoder knows that we are looking for 8 bit data, so why display something what looks like a valid decoding instead of something like ‘6 error bits’, as other protocol decoders would? Even displaying nothing at all would be better than filling the list with invalid data without any hint that they aren’t valid.


What happens if I run the test at 5ms/div in order to capture some 50 packets (800 data bytes) at once? With the trigger point set just 200µs apart from the left screen edge, we get the following picture (SPI_Decode_5ms_0%_1)



The first data item after the trigger is now the 4th item in the list and data appear to be correct here, but everything else? Oh boy, what a disaster!

First look at the timestamps in the list.

We have two entries with each -100.00µs and 0.00µs respectively, which might be a hint that the actual resolution of the timestamp is worse than 100µs, even though the display suggests a resolution of 10ns and the current sample rate of 20MSa/s allows 50ns after all.

Then what happens after the 4th entry? Timestamp suddenly jumps up to the maximum value and says 69.8ms for all the 860 remaining entries in the list!

And what about the decoded data line at the bottom of the screen? It says just ‘0xe0’ for a total of 864 bytes on the screen!

Scrolling thorugh the list, data is basically correct, but shows an unjustified 0x00 decoding between packets, except for the transition where the data counter rolls over from 0xFF to 0x00. So it seems it doesn’t happen if the following value after the short break is actually zero. To illustrate this, I show screen shot examples for two transitions (SPI_Decode_5ms_0%_17, SPI_Decode_5ms_0%_34)






Just for completeness I also show the end of the list, that contains a total of 864 entries. The last complete packet ends at line 859 and the data is 0x2F, then comes the already familiar extra 0x00 decoding, followed by 4 items that are just garbage. It almost looks like the decoder keeps working a little beyond the end of the acquisition buffer on some data, that have not actually been captured (SPI_Decode_5ms_0%_858)




All displays show just some random number for the bottom line decoding.

Can we try to find the problem? Let’s just lower the timebase (in stop mode, as I’ve moved over to single shot capture already) to 100µs/div in order to see a complete packet, just as we did before – but all the errors we’ve seen so far are there again (SPI_Decode_5ms_100us_D600us_1)



The timestamps now jump to just 1.30ms, but the data is correct except for the extra zero byte, that clearly isn’t there when looking at the data traces on the screen. There are double lines because of the peak detect mode, but even though it might not look pretty, it has absolutely no impact on the decoding. Just to make sure, I’ve tried it in normal acquisition mode as well, without any different results. The bottom display line keeps saying ‘0xe0’ and of course the multi selection, shading and artefacts in the list are there, just as already mentioned in the UART review.

Just for completeness I’ll also show the end of the list where we see another extra zero decoding, once again not warranted by the signal traces as they appear on the screen. Neither at the start nor at the end of the packet is the MOSI line low at all, let alone for full 8 clock periods (SPI_Decode_5ms_100us_D600us_13)




Even though no further tests would be necessary in this situation, I still tried zoom mode. Even though I’ve already seen this kinda working sometimes, it is a complete mess right now. The decoding line at the bottom of the screen shows ‘0x00’ and the list is in accordance with that for a change (SPI_Decode_5ms_Zoom_100us)




It’s the same for serial SPI triggering, which also doesn’t work.

I could not be bothered to post a dedicated review on this, so I just want to point out that serial SPI trigger on 8 bit data only works for the upper 4 bits, whereas the lower nibble always is treated as zero, no matter what the actual setting is. And for the entire trigger word, the don’t care setting (‘X’) is ignored and treated as zero. So this is completely unusable as well.


Apart from the fact, that the scope should never behave like this, no matter what signals are thrown at it, there still remains the question if there’s something wrong with my signal? I think the fact that the list display is basically correct, but the timestamps and the decoding line at the bottom of the screen are not, already is a strong indication that there’s nothing wrong with the signals after all.

Just to be sure, I have hooked up an LA with serial protocol decoder in order to verify that everything is fine with the signal. And the results indicate that it is indeed! All the data is correct and there are no extra zero data items between packets. And this is with a sample rate of just 1MHz!

This decoder also displays the first (truncated) packet that is not in sync, but it clearly indicates that there were 2 bits missing on the last data item, so we can know that the entire packet is invalid (SPI_Data_Verification)




Conclusion:

SPI decoding is totally unusable and I cannot even begin to list all the bugs I’ve found during my tests. Well, it’s more than just bugs, it simply doesn’t work. SPI trigger doesn’t work either.
This is clearly a case where nobody could claim this part of the scope has ever been tested, other than maybe one single message at one fixed timebase setting, just like my very first scenario.

It is very bad practice, to include totally untested pieces of firmware with an official release.

[nctnico]

return return return return

[Fagear]

Setting delay and setting horizontal position is bit different. Because setting delay from center line moves horizontally. But this is based to time, not based to distance in divisions or millimeters etc. You set TIME position related to center line.
Now if we change time scale of course horizontal position moves because we have set how far in time we want be from center line.
There need be one setting more. Lock trigger position to the current user adjusted position on the screen independent of t/div scale  and then same function need include swap between delayed time position and this trigger position....

May I add a little to this topic?
As owner of Rigol DS2072A I can confirm that it can fix trigger position on whatever place on the screen. Just set "HorRef" as "Trig Pos" in Horizontal menu to lock it.
Or you can also set it as "User" to set "zoom point" independently at any point on the screen (not locking to the center of the screen or trigger position). DS1000Z cannot do it though.

[Mark_O]

Thanks for the extensive breakdown.  One error I did want to point out though...

Serial Decoding (DSO) - UART

As we can see in the list, the first four decoded values aren’t correct, quite obviously the decoder just starts with the first captured data and doesn’t seek for a proper start condition first. But at least it gets in sync eventually, so everything looks fine after the 4th decoded value.

This isn't the fault of the scope OR it's decoders.  It is the (expected) result from your setting the triggering on an arbitrary edge.  I believe if you adjust the triggering to UART mode, that your results will fall into alignment properly.

[Don't feel bad... I made the same mistake initially, when I started testing the decoders on the SDS1000X.  If it never managed to 'sync up' properly, and we had nothing but garbage, then the operator error would be obvious.  Since it eventually does sync, we overlook the fact that we didn't set it up properly in the first place.]

[Mark_O]

Serial Decode (DSO) - SPI

...The first data item after the trigger is now the 4th item in the list and data appear to be correct here, but everything else? Oh boy, what a disaster!  First look at the timestamps in the list.  We have two entries with each -100.00µs and 0.00µs respectively, which might be a hint that the actual resolution of the timestamp is worse than 100µs, even though the display suggests a resolution of 10ns and the current sample rate of 20MSa/s allows 50ns after all.  Then what happens after the 4th entry? Timestamp suddenly jumps up to the maximum value and says 69.8ms for all the 860 remaining entries in the list!

Believe me, I feel your pain on this.  I've been running a 1000X through a battery of tests for some time now, and SPI was one of the first things I looked at.  And many of the same glitches and anomalies were present there as well (with edge-triggering).  That would tend to confirm the hypothesis that the two scopes share much the same core code-base.  As would the fact that most (not all) of the other problems you've reported from your extensive testing also appear in my list for the 1000X too.

However, unlike with your 2000(X), the SPI situation improved quite a bit when I changed from an edge-triggered mode to SPI-triggering.  I was surprised to hear your report that it made no difference.  So it's possible that some improvements on the 1000X side simply haven't made it over to the 2000X yet.

As my little micro provides almost no hardware support for SPI, I stick with a clock of only 100kHz, but I also have no doubt that speed doesn’t matter for this test as long as the sample rate is kept about an order of magnitude higher than the SPI clock.

I believe that is correct.  I ran SPI tests from 10kHz to 14 MHz (using an embedded comms channel on an NXP chip), with both 8-bit and 16-bit message "words", and as long as the sample rate remained at least 4x the bit-clock, the 1000X handled it as well (or as badly).

...I just want to point out that serial SPI trigger on 8 bit data only works for the upper 4 bits, whereas the lower nibble always is treated as zero, no matter what the actual setting is. And for the entire trigger word, the don’t care setting (‘X’) is ignored and treated as zero. So this is completely unusable as well.

This wasn't true on the 1000X, even on the earliest of the 3 Releases I have been working with.  I set up match patterns spanning 4, 8, and 16 bits, and all were observed properly.  And X was never treated as matching just "0".  And never did I observe a situation where multiple Cursor pointers in the List view were lit up simultaneously.

I mention this mainly to give you some hope, because the code appears to still be going through some significant transformations.  Which hopefully should eventually appear for you on the 2000(X) platform.

Conclusion:
SPI decoding is totally unusable and I cannot even begin to list all the bugs I’ve found during my tests. Well, it’s more than just bugs, it simply doesn’t work. SPI trigger doesn’t work either.  This is clearly a case where nobody could claim this part of the scope has ever been tested, other than maybe one single message at one fixed timebase setting, just like my very first scenario.

While I don't think that SPI decode is unusable on the 1000X, I do have to agree that there are too many quirks, anomalies, and glitches to accept it as a reliable debug-platform, at the moment.  And the number of problems, which as you commented strongly suggest an inadequate level of in-house testing, makes the job of evaluating or reviewing the product far more difficult than anyone might anticipate, for a released product.

So I have a lot of respect for the amount of time you have invested in your exploration of the V2 software releases for the SDS2000(X).  I'm not sure where you've found the time to perform all the tests and write them up!     I'm having trouble just keeping up with reading them all!    But I am sure it is providing Siglent with a wealth of extremely valuable information, which should enable them to quickly focus on correcting the issues.


[NB:  you mentioned about the List size for Serial decodes... "The list size can be configured from 4 to 7 lines and I’ve set it to the maximum right from the start."  Are you sure that isn't from 1-7?  The 1000X lets you drop it as low as 1 line (saves space), and the User Manual for the 2000X indicates 1-7 as well.]

[Performa01]

Thanks for the extensive breakdown.  One error I did want to point out though...

Serial Decoding (DSO) - UART

As we can see in the list, the first four decoded values aren’t correct, quite obviously the decoder just starts with the first captured data and doesn’t seek for a proper start condition first. But at least it gets in sync eventually, so everything looks fine after the 4th decoded value.

This isn't the fault of the scope OR it's decoders.  It is the (expected) result from your setting the triggering on an arbitrary edge.  I believe if you adjust the triggering to UART mode, that your results will fall into alignment properly.

Thanks a lot for your replies – it is nice to see another user care for the topic and makes me feel not so alone now

Regarding edge triggering on an UART signal, you’re perfectly right and it’s probably just the way I put it was a bit misleading. I certainly didn’t expect the decoder to get in sync properly in the middle of a packet – that’s why I’ve set up this test with a series of packets (with small periods of idle level between them) instead of just one endless stream of data in the first place.

I personally cannot think of a way to reliably detect the start of a frame when decoding starts in the middle of a stream.

When using the UART trigger, there are no invalid packet fragments (as can be seen in the screenshots of my review of the UART trigger) – most of the time, that is. I have to make a reservation here, as it is obvious that the trigger would still fire if the incorrect decoding from any initial out-of-sync packet matches the trigger condition by accident.

[Performa01]

However, unlike with your 2000(X), the SPI situation improved quite a bit when I changed from an edge-triggered mode to SPI-triggering.  I was surprised to hear your report that it made no difference.  So it's possible that some improvements on the 1000X side simply haven't made it over to the 2000X yet.

Well, for my tests it cannot make a difference, since I didn’t trigger on a random edge of the clock or data, but on the falling edge of the slave select signal, which is always related to the start of a packet. Consequently, data after the trigger point have always been correct (apart from the extra 0x00 decoding between packets) and I did not complain about invalid data before the trigger point other than that it wasn’t marked invalid in some way (no error bit indication as e.g. the SPI decoder on my LA does).

[NB:  you mentioned about the List size for Serial decodes... "The list size can be configured from 4 to 7 lines and I’ve set it to the maximum right from the start."  Are you sure that isn't from 1-7?  The 1000X lets you drop it as low as 1 line (saves space), and the User Manual for the 2000X indicates 1-7 as well.]

You’re right of course. Four lines is just the default setting, but I can wind it down to one if required. Tanks for the hint - I’ve corrected that statement in my review post.