Serial Decoding (DSO) - UARTAs 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)
![](https://www.eevblog.com/forum/testgear/siglent-sds2000-new-v2-firmware/?action=dlattach;attach=190624)
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)
![](https://www.eevblog.com/forum/testgear/siglent-sds2000-new-v2-firmware/?action=dlattach;attach=190626)
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)
![](https://www.eevblog.com/forum/testgear/siglent-sds2000-new-v2-firmware/?action=dlattach;attach=190628)
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)
![](https://www.eevblog.com/forum/testgear/siglent-sds2000-new-v2-firmware/?action=dlattach;attach=190630)
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)
![](https://www.eevblog.com/forum/testgear/siglent-sds2000-new-v2-firmware/?action=dlattach;attach=190632)
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)
![](https://www.eevblog.com/forum/testgear/siglent-sds2000-new-v2-firmware/?action=dlattach;attach=190634)
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)
![](https://www.eevblog.com/forum/testgear/siglent-sds2000-new-v2-firmware/?action=dlattach;attach=190636)
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)
![](https://www.eevblog.com/forum/testgear/siglent-sds2000-new-v2-firmware/?action=dlattach;attach=190638)
![](https://www.eevblog.com/forum/testgear/siglent-sds2000-new-v2-firmware/?action=dlattach;attach=190640)
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)
![](https://www.eevblog.com/forum/testgear/siglent-sds2000-new-v2-firmware/?action=dlattach;attach=190642)
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.