Siglent 1202X-E Serial Decoding not working

[Mag748]

Hello,

I have a Siglent SDS 1202X-E. The UART Decode function has stopped working. I recall it had been working in the past, albeit not very well, but it was usable. Now I can no longer successfully decode very basic UART data. I have updated the firmware to the latest version (1.3.27) and reset all settings, and tried every conceivable troubleshooting step. The Oscope functionality is still fine, and the signal is displayed and triggered and all decode setting are correct as far as I’m aware.

I have (2) Arduino sketches. The first repeatedly sends the character "A" to the serial port. The siglent successfully decodes this. The second Arduino sketch sends the character string "AA". The Siglent fails to decode this. It displays a red error for the first character, and then a single apostrophe for the second character. I have attached the sketches and images for your reference. Edit: this forum won’t let me attach the INO files

As a side note, can anyone recommend a decent, and good value for the money logic analyzer capable of UART decode?
Sincerely,
Marcus

[tautech]

With simple decoding (Edge trigger) you often need to set a trigger Holdoff to prevent retriggering within a packet.

Zoom out some to identify a packet length and set trigger holdoff for a little longer than 1 packet.

[Mag748]

Hey tautech,

The baudrate is 9600 and it’s only 2 bytes, so quite a short packet. I did zoom out to capture 3 packets, as well as adjusting the hold off to very long. Unfortunately, no change, and the packets are still not able to be decided.

Sincerely,
Marcus

[tautech]

3ms is all the Holdoff you need: just a little larger than the packet width.

[mwb1100]

Can you show your "Decode/Configure" menu?

If I set the decoder's parity or stop bit setting incorrectly I can get similar problems decoding - all but the last character in a consecutive run shows as an error and the last character in the run may or may not decode correctly.

[Mag748]

Dear mwb1100,

See attached images.

[Mag748]

Here is the “AA” signal with the single “A” overlaid as a reference. Is there something invalid about the serial signal the arduino is sending?

[mwb1100]

Try setting the trigger type to "serial" instead of "edge" (you might need to revisit all the other settings to make sure they are correct - I had to readjust pretty much all of them). 

With a serial trigger instead of edge trigger I got good decode results even when I had mis-configured the parity and stop bits settings (I actually expected some errors, since the waveform wouldn't be meeting those configurations - but that doesn't matter at the moment).

Also, I would hit the "single" trigger mode before looking at the decode, but I don't think that should matter for you since the packets are all the same on your tests.  You might want to give it a try anyway.

[Mag748]

Hey mwb1100,

I gave the Serial trigger a shot. Interestingly, that seem to work fine. I set the trigger to equal 0x41 and it triggers right at the end of the first byte. This works in single shot and normal mode. Unfortunately, nothing changes with the decode functionality.

[Hexley]

Hello,
I have (2) Arduino sketches. The first repeatedly sends the character "A" to the serial port. The siglent successfully decodes this. The second Arduino sketch sends the character string "AA". The Siglent fails to decode this.

It is interesting that the "envelope" of the decoded character in your first image extends past the end of the stop bit. In fact, it seems to stop one full bit time later. That may or may not be significant.

Although the scope is set to 8/N/1, meaning that 1 stop bit should be sufficient, it is suggestive that it can decode a single "A" (when the idle line acts like a long series of additional stop bits) but cannot decode "AA", where there is strictly a single stop bit in the data stream between the two characters.

As a further hint, note that the decoding envelope that the scope displays for the second "A" shows the start of the decoding window happens at the second bit of that second "A". That is, the true start bit seems to have happened while the scope was working on the preceding decode window: look where the red envelope for that first character ends -- it is **after** the start bit for that second "A".

An experiment to try: change the Arduino to send 2 stop bits and see if the scope can decode "AA" then. Or, insert a program delay before sending the second "A", and see how that affects the error.

[mwb1100]

An experiment to try: change the Arduino to send 2 stop bits and see if the scope can decode "AA" then. Or, insert a program delay before sending the second "A", and see how that affects the error.

Beat me to the punch!  I had a long reply queued up to suggest configuring the arduino for 2 stop bits to see if that made decode work.

The second photo in the first post shows that the 10 bits used to send the first 'A' character takes 1.040ms including start & stop bits.  So the arduino has the correct timing.  If having the arduino send 2 stop bits fixes the SDS1202X-E's decode, then that's an indication that there's a problem in the SDS1202X-E decoder that Siglent will likely need to fix (or at least weigh in on a workaround).

[mwb1100]

Also, I'm testing with an SDS1104X-E and don't see the problem unless I deliberately misconfigure the decoder.  I didn't realize it, but the 2 channel SDS1000X-E and the 4 channel SDS1000X-E scopes have very different firmware histories (it makes sense that they'd have different firmware builds, but I expected their releases would closely follow each other in both changes and release timing).

The 2 channel firmware history only mentions one UART decoder related fix: "Fixed the bug of UART decoder with some special settings"

The 4 channel firmware history mentions that fix and 3 others (none of those other 3 seem like they'd be related to this problem).

[Mag748]

Good observation! The decode does work when a large enough delay is added between bytes. And I did configure the serial port to use 2 stop bits, and decode works as well.

The settings for stop bits does make a difference to the envelope. It’s as if the stop bits setting is internally being doubled or something.

The photos attached are with the arduino sending 2 stop bits and different decode stop bit settings applied.

[mwb1100]

Seems like you will need Siglent's help.  I wonder if the problem got introduced by the "Fixed the bug of UART decoder with some special settings" in firmware 1.3.27?

I don't know if Siglent lets you easily downgrade firmware.  If so it might be worth trying 1.3.26 to see if the problem goes away.

As for your question about

As a side note, can anyone recommend a decent, and good value for the money logic analyzer capable of UART decode?

You can get good results with a $10 Saleae Logic clone and the sigrok software - I haven't actually used one of these, but from all the reviews and tutorials out there it's clear that they work.  An example review/tutorials on youtube is this (cued up to where he starts talking about UART decoding):

  - https://youtu.be/7x4h7Zq2NNU?t=730

One thing about the cheap logic analyzers - they generally can't handle the voltage levels of RS232 signals (which are often +/-5V or more in magnitude).  UART levels are fine (0 to 3.3V or 5V).  If you need the RS232 levels supported, you'll need to move up to something a bit more expensive (but can still be less than $100) such as a Kingst or DreamsourceLab DSLogic logic analyzer.  Or run the RS232 through a level shifter.

I have a DSLogic U2Basic 100Msps with 8MB hardware buffer RAM on board (a knockoff, I'm sure, from eBay) and it works well with UART decoding.  They seem to run around $60-80 on eBay right now.

[Mag748]

See attached response from Siglent. It would seem they feel it’s functioning as designed. Interesting…

[nctnico]

So they are basically saying their decoder can't decode UART with characters send back-to-back as is being done in many UART protocols? 

[Manul]

Just noticed the problem today when I needed decoding. I can confirm that 1.3.27 has f*ucked up decoding. For example, with 8 data bits, no parity and 1 stop bit it somehow expects 11 bits, with parity 12. Nothing decodes correctly. Tried resetting the scope to defaults and some other things, but nothing helped, also I did not feel like wasting any more time. Did a rollback to 1.3.26 - everything works perfectly as it always did.

[CharlotteSwiss]

I won't go into decode, but I think this latest FW 1.3.27 has several problems. For example, I had some occasional problems with the USB stick with 1.3.26, but with this latest FW it often crashes and the stick always has problems when I then insert it into the PC (it doesn't even recognize it). In the FW notes they said they had fixed this problem, for me they made it worse. I'm almost willing to go back to 1.3.26. Tautech could perhaps inform those of Siglent (in my opinion the changes made for the USB have only done damage).

[tautech]

I won't go into decode, but I think this latest FW 1.3.27 has several problems. For example, I had some occasional problems with the USB stick with 1.3.26, but with this latest FW it often crashes and the stick always has problems when I then insert it into the PC (it doesn't even recognize it). In the FW notes they said they had fixed this problem, for me they made it worse. I'm almost willing to go back to 1.3.26. Tautech could perhaps inform those of Siglent (in my opinion the changes made for the USB have only done damage).

Don’t worry I already have !

[sonpul]

It's a pity, but I feel unfair and deliberate bias on the part of the developers towards the owners of the SDS 1202X-E. For their sympathy and support of Siglent, for choosing a two-channel model, they were deprived of the Internet and Wi-Fi. 1202X-E owners are not worthy of the -V2 Operating System, markers and FFT tables; for them there is no need to check the functionality of the firmware. But for that, the owners of the SDS 1104X-E are not deprived of attention. I wonder why that is?

[CharlotteSwiss]

I won't go into decode, but I think this latest FW 1.3.27 has several problems. For example, I had some occasional problems with the USB stick with 1.3.26, but with this latest FW it often crashes and the stick always has problems when I then insert it into the PC (it doesn't even recognize it). In the FW notes they said they had fixed this problem, for me they made it worse. I'm almost willing to go back to 1.3.26. Tautech could perhaps inform those of Siglent (in my opinion the changes made for the USB have only done damage).

Don’t worry I already have !

You should report that with 1.3.26 the situation with the USB stick was better. They should leave the other changes made, but for the USB leave everything as before. If you have any news, give a shout. Thank you

[ebastler]

It's a pity, but I feel unfair and deliberate bias on the part of the developers towards the owners of the SDS 1202X-E. [...] But for that, the owners of the SDS 1104X-E are not deprived of attention. I wonder why that is?

I am pretty sure it's because Siglent have sold many more units of the 1104 than the 1202, so they are giving that model more attention. Four channels are nice, and the upgrade to 200 MHz is free.

What I find surprising is that the two models use different firmware at all. I would assume that they are based on essentially the same platform. Hence would expect that they either use the exact same firmware and determine the model configuration at runtime, or at least use firmware built from the same codebase, with just a compile-time switch to select the model. In the latter case the firmware releases and features could easily stay in sync.

[sonpul]

Maybe the 1104X-E sold more than the 1202X-E. But. I see 1202X-E in people's workplaces very often, maybe even much more often than 1104X-E. And it seems to me that it was the two-channel model that greatly increased its popularity and attracted many people to Siglent. And for this, owners of the 1202 are teased with periodic improvements to the 1104. This issue needs to be raised in the topic of new models. Because I might want to switch to the dual-channel HD800. And in this line, it turns out, owners of two-channel devices can also be left in the very last place of attention. And show how Siglent can treat its fans.

[larrybud]

I have the 1104 and a google search brought me here. I'd like to let you know what I did that suddenly "worked" after reading through this thread. Note that I'm also on the latest 1.3.27 firmware.

I was simply trying to decode the arduino Serial.print with a "hello world" and getting the same kind of decoding output that the OP had. Checked all the settings, everything looked good.

Then I tried the 2 stop bits and that did NOT work, then I noticed something. My "idle level" was set to LOW, not HIGH. Once I flipped it to HIGH I was able to decode a full string, EVEN WITH 1 stop bit.

So I'm wondering if their 1.3.27 update messed something up with the Idle High display setting, and even though yours says it's set to high, maybe it's in some weird limbo value. Try just toggling it back to low then back to high to "reset" the value. Definitely worth a shot.

[Performa01]

It's a pity, but I feel unfair and deliberate bias on the part of the developers towards the owners of the SDS 1202X-E. For their sympathy and support of Siglent, for choosing a two-channel model, they were deprived of the Internet and Wi-Fi. 1202X-E owners are not worthy of the -V2 Operating System, markers and FFT tables; for them there is no need to check the functionality of the firmware. But for that, the owners of the SDS 1104X-E are not deprived of attention. I wonder why that is?

You should consider the history: the SDS1202X-E was the first member of a (back then) new platform (Xilinx Zynq), introduced in late 2016. It already had many improvements compared to the older Blackfin platform, such as long FFT, deep measurements, long memory also for ERES and Average acquisition modes, just to name the most important ones.

The SDS1104X-E on the other hand was released about one year later and the platform has developed further. There are limited resources and a different front panel, so the SDS1202X-E cannot run an adapted version of the SDS1204X-E firmware.

The SDS1202X-E is the bottom of the barrel model of the contemporary product line. It still gives you a lot for the money, like 200 MHz bandwidth and free serial decoders even back then, when no other manufacturer was willing to provide such. From my point of view, Siglent makes this offer just to serve hobbyists on a budget, but certainly don't make much of a profit from that part of their business.

[tv84]

The SDS1202X-E is the bottom of the barrel model of the contemporary product line. It still gives you a lot for the money, like 200 MHz bandwidth and free serial decoders even back then, when no other manufacturer was willing to provide such. From my point of view, Siglent makes this offer just to serve hobbyists on a budget, but certainly don't make much of a profit from that part of their business.

All true, but ruining something that was working in a previous FW version, and let it stay like that, is not the way to do things. Even for the programmer's curriculum...

[nctnico]

It's a pity, but I feel unfair and deliberate bias on the part of the developers towards the owners of the SDS 1202X-E. For their sympathy and support of Siglent, for choosing a two-channel model, they were deprived of the Internet and Wi-Fi. 1202X-E owners are not worthy of the -V2 Operating System, markers and FFT tables; for them there is no need to check the functionality of the firmware. But for that, the owners of the SDS 1104X-E are not deprived of attention. I wonder why that is?

The SDS1202X-E is the bottom of the barrel model of the contemporary product line. It still gives you a lot for the money, like 200 MHz bandwidth and free serial decoders even back then, when no other manufacturer was willing to provide such. From my point of view, Siglent makes this offer just to serve hobbyists on a budget, but certainly don't make much of a profit from that part of their business.

If this where actually true, the tech support would have replied that the serial decoding is crippled/not working instead of suggesting to put dead time between the characters. The latter just shows the tech support (and maybe some people in R&D as well) knows too little about what is required for protocol decoding (and more specifically: how serial / UART protocols work as these typically send data back-to-back).

[vorosj]

I am pretty sure the the V1.3.27_EN firmware UART decoder is simply wrong. It must be a bug, the frame in the decoder line is longer then the actual UART frame, and it fails decoding.

I downgraded to 1.3.26_EN, don't even touched the input signal or settings, and it's working.
(test: 19200, 8bit, 1 start, 1 stop, no parity)

[Mike54]

Hello Marcus and the others,

recently I bought a new SDS1202X-E oszilloscope and was really astonished about the price/feature-relationship of that model...
...until I investigated the UART-decoding feature: I found same problems when decoding UART-signals with 1 stopp-bit (commonly used).
My new oszilloscope was delivered with FW 1.3.27 and I despeately searched for my mistake in wrong settings etc. ...
I tested with Arduinos, Raspberry-pico and serial-signals from my PC - no success.
Shortly before claiming to resend the set, I found this discussion here and successfully downgraded to FW 1.3.26 - now my decoding- problems disappeared.

Thank you very much for this article and discussion! I think, there seems to be a real bug in the actual FW - and not only when decoding ascii "AA".

Generally I am awaiting a new and improved FW-version and hope, that Siglent will care for that!

Greetings from Hamburg/Germany
Mike