Siglent SDS 1202X-E RS-232 decoding

[HwAoRrDk]

I was trying yesterday to decode some RS-232 data transmission on my SDS 1202X-E, but no matter what I tried it just wouldn't decode anything using the 'UART' decode.

Nothing special about the signal: just ±12V RS-232, 1200 baud, 7 bit, no parity, 2 stop bits. Nothing I was able to change in the decode settings seemed to help. All decoded bytes were just showing up as either invalid (in red) or, rarely, incorrect value.

I'm running the latest 1.3.27 firmware. I found an old thread here talking about how there was a regression in the 1.3.27 firmware that broke some aspect of UART decoding, but it sounded like it didn't apply to my situation.

Am I being dumb? Or is the scope UART decoding actually broken?

[tautech]

A picture saves 1000 words. 

2 things to get stable decoding are determining the Idle state and setting the trigger edge correctly then setting the decoding Threshold within the amplitude of the packet.

Here I also use 60ms of trigger Holdoff to prevent retriggering within a packet.
SDS1104X-E with STB-3 demo board for the signal source.

[Sorama]

On what are you triggering ?

[tautech]

On what are you triggering ?

First falling edge of the second packet.....H Pos + Trigger level indicates such.

Decode list is from the first packet, distinguished by the time stamp in the decode list.
Scrolling down that list will reveal the packet triggered on. 

[HwAoRrDk]

I'm pretty sure I have everything set up correctly. See screenshots.

[tautech]

Hmmm I might need to get a NIB 1202X_E out...

Try setting the Threshold higher.
4V might be enuf but I like to set it ~2/3 so ~8V for you.

[adam4521]

My next move looking at it would be to dial down the stop bits, to 1.5 or 1. The signal needs to 'idle on mark' (or low) for at least that length of time for the receiver to resync on the rising edge of successive bytes. The signal presented looks 'tight' on the idle time.

[nctnico]

I was trying yesterday to decode some RS-232 data transmission on my SDS 1202X-E, but no matter what I tried it just wouldn't decode anything using the 'UART' decode.

Nothing special about the signal: just ±12V RS-232, 1200 baud, 7 bit, no parity, 2 stop bits. Nothing I was able to change in the decode settings seemed to help. All decoded bytes were just showing up as either invalid (in red) or, rarely, incorrect value.

I'm running the latest 1.3.27 firmware. I found an old thread here talking about how there was a regression in the 1.3.27 firmware that broke some aspect of UART decoding, but it sounded like it didn't apply to my situation.

Am I being dumb? Or is the scope UART decoding actually broken?

It is broken. Read the thread carefully and you'll see it can't decode UART when the characters are send back-to-back like in your case. You'll need to downgrade to the previous firmware if there isn't a newer version where it got fixed.

[tautech]

I'm pretty sure I have everything set up correctly. See screenshots.

Maybe but as I understand it there are too many bits in your packets for SDS1202X-E to decode. 

If we check the datasheet for the UART spec:
Data Width 5，6，7，8 bits

Pulled a new SDS1202X-E out for PD checks so did another decode like the previous with the exact same result.
FW  V1.3.27

Maybe you should follow the suggestion from member adam4521 ?

[nctnico]

I'm pretty sure I have everything set up correctly. See screenshots.

Maybe but as I understand it there are too many bits in your packets for SDS1202X-E to decode. 

If we check the datasheet for the UART spec:
Data Width 5，6，7，8 bits

Pulled a new SDS1202X-E out for PD checks so did another decode like the previous with the exact same result.

But your demo board isn't sending the characters back-to-back like normal UART transmissions typically do. In cases where 7 bits + 2 stop bits isn't supported, a workaround is to decode using 8 bits + 1 stop bit.

[HwAoRrDk]

After fiddling with the settings some more, I managed to get it to decode.

The decode signal threshold made no difference at all. The only thing that would make it decode is setting it to 7N1; that is, 1 stop bit, but where the signal is actually 2 stop bits. Nothing else worked - not 8N1, 7N1.5, etc. I could have sworn I tried 7N1 before and got nothing, but maybe I didn't.

So it seems adam4521 is correct, and that it is particular about having some idle state in between characters. Which is pretty stupid, because obviously real-world signals do not always work like that. And one would think even given that it would be able to decode the first character.

Supposedly the prior 1.3.26 firmware doesn't have this poor UART decode performance? What is the procedure for downgrading? I might try that.

[tautech]

What is the procedure for downgrading?

https://int.siglent.com/upload_file/zip/firmware/Oscilloscope/SDS1202X-E_1.3.26_EN.zip

Unzip and stick the .ADS file on a USB stick.
Have a quick look at the Revision notes and Install instructions.
Downgrading/upgrading is normally without issues but watch for mention that you cannot in the notes.

Utility/System somewhere there will be an upgrade tab.
Select the file from what the scope can see and let it rip.
Typically we would perform a Self Cal when FW gets changed but the unit needs be running for a bit to be warm and stable.

[martin1959]

I had similar UART decode problems using FW V1.3.27 which forced me to downgrade to V1.3.26.

Now Siglent has published a new firmware version V1.3.28 (2026/4/25) with the following changes.
Fixed some bugs:

• SCPI instruction configuration exception when inactive
  channel is set as trigger source.
• Under the interpolation time base, CSV files need to save the
  original sampling points, not the interpolated points.
• After recalling the settings file, sometimes the cursor settings
  are incorrect.
• In tracking mode, using the SCPI command to change the
  source of an X cursor will cause the sources of X1 and X2 to
  change simultaneously.
• After setting the reference level for FFT, power down and
  restart to restore the reference level error.
• In the average sampling mode, when the time base is
  modified under a large time base, the waveform does not
  clear the old sampling points.
• SCPI instruction reads FFT cursor, returns incorrect unit.
• Sometimes UART decoding stop bit judgment error.
• When the unit is mHz, the frequency value read by SCPI is in
  MHz units, which confuses uppercase and lowercase.

I have installed this new version V1.3.28 yesterday on my SDS1202X-E and was able to decode UART data with 115200 bps, 8N1 format and data sent back-to-back.
I have not tested different serial variants, but for my case the UART decode problem has been resolved (see point 8 in above changelog).

[CharlotteSwiss]

https://www.siglenteu.com/service-and-support/firmware-software/digital-oscilloscopes/#sds1000x-e-series

 

Normally, on my 1202X-E, the firmware was called sds1202X-E, while version 1.3.28 is called sds1002X-E.
Is this a transcription error?

[tautech]

https://www.siglenteu.com/service-and-support/firmware-software/digital-oscilloscopes/#sds1000x-e-series

 

Normally, on my 1202X-E, the firmware was called sds1202X-E, while version 1.3.28 is called sds1002X-E.
Is this a transcription error?

No.

2ch X-E were only released to the west as 200 MHz models but there is also a 100 MHz version in the east that we don't see but we may have had these in the west too if Mr Dave Jones didn't show the boot log of his SDS1102X-E prerelease unit. 
Siglent responded by only releasing the SDS1202X-E to the west.

[CharlotteSwiss]

No.

2ch X-E were only released to the west as 200 MHz models but there is also a 100 MHz version in the east that we don't see but we may have had these in the west too if Mr Dave Jones didn't show the boot log of his SDS1102X-E prerelease unit. 
Siglent responded by only releasing the SDS1202X-E to the west.

Thanks Tautech, but Mr Martin said:
<<I have installed this new version V1.3.28 yesterday on my SDS1202X-E...>>

So this would mean that his sds1202x-e is a 100mhz version?
 

[tautech]

No.

2ch X-E were only released to the west as 200 MHz models but there is also a 100 MHz version in the east that we don't see but we may have had these in the west too if Mr Dave Jones didn't show the boot log of his SDS1102X-E prerelease unit. 
Siglent responded by only releasing the SDS1202X-E to the west.

Thanks Tautech, but Mr Martin said:
<<I have installed this new version V1.3.28 yesterday on my SDS1202X-E...>>

So this would mean that his sds1202x-e is a 100mhz version?
 

No, the 100 MHz model is a SDS1102X-E.....the only one in the west is owned by Mr Dave Jones. 

This latest X-E update is easily missed when looking here and it only shows at the bottom of the page:
https://int.siglent.com/download/firmwares/?ProId=12
 

[CharlotteSwiss]

No, the 100 MHz model is a SDS1102X-E.....the only one in the west is owned by Mr Dave Jones. 

This latest X-E update is easily missed when looking here and it only shows at the bottom of the page:
https://int.siglent.com/download/firmwares/?ProId=12
 

But who is this Mr Dave Jhons? 

So this 1.3.28 is not suitable for my sds1202x-e 

[tautech]

No, the 100 MHz model is a SDS1102X-E.....the only one in the west is owned by Mr Dave Jones. 

This latest X-E update is easily missed when looking here and it only shows at the bottom of the page:
https://int.siglent.com/download/firmwares/?ProId=12
 

But who is this Mr Dave Jhons Jones ? 

Mr EEVblog !

So this 1.3.28 is not suitable for my sds1202x-e

100% it is !
Download link:
https://int.siglent.com/upload_file/zip/firmware/Oscilloscope/SDS1002X-E_V1.3.28_EN.zip

[CharlotteSwiss]

No, the 100 MHz model is a SDS1102X-E.....the only one in the west is owned by Mr Dave Jones. 

This latest X-E update is easily missed when looking here and it only shows at the bottom of the page:
https://int.siglent.com/download/firmwares/?ProId=12
 

Then I install it, very good 


But who is this Mr Dave Jhons Jones ? 

Mr EEVblog !

So this 1.3.28 is not suitable for my sds1202x-e

100% it is !
Download link:
https://int.siglent.com/upload_file/zip/firmware/Oscilloscope/SDS1002X-E_V1.3.28_EN.zip