SDS1104X-E UART/Serial Decode for 9 bit multidrop/multiprocessor protocol

[Raoul Duke]

I've just started using my new (to me) SDS1104X-E scope to reverse engineer an EIA/TIA-485 (aka RS485) serial bus.  Alas, the serial bus is using 9 bit multidrop/multiprocessor protocol.  Briefly, this protocol uses the parity bit to signal and address/command versus data: if the parity is high/mark then the 8 data bits are an address (or command), and if parity is low/space, the bits are data.  Some UARTs can handle this directly in hardware, and other UARTs need to set parity to always mark/space and take the interrupt to check the incoming parity to determine address or data.

This is a common 485 protocol in the embedded market.  And I have not yet tried to get the Linux ftdi_sio driver to implement this - one headache at a time please.

Alas, Siglent UART decode functionality only includes ODD/EVEN/NONE parity.  The standard additional parity options of MARK/SPACE have not been included for some reason, which makes decode a pain because I need to walk through every waveform to figure out the parity.  And it often seems to throw its hands up and fail to decode if it thinks there's a parity error.

Can anyone tell me how the serial decode is implemented?  Is it application code run by the host processor?  Can it be replaced?  Is there any chance that Siglent will update the serial decode to add at least "always mark/space" parity option? I know that it is too much to ask for a 9-bit mode that decodes like I2C, but at least fixed mark/space would make my life significantly easier.

As an aside, I've only had the scope for 2 days now, so I haven't figured out the details.  I've tried the "Wave Form Save" button on the web interface, but it is not quite what I had in mind.  I have about 3 seconds of serial data, sampled at 5MSa/s in 14Mpts of memory - if I have to write my own serial decoder for the 9 bit protocol, I'd like to be able to dump all 14Mpts.  Would that be done with SCPI commands?

Pushing my luck here, but because EIA/TIA485 is a differential signal, I run A to channel 1 and B to channel 3, and use Math to generate A-B superimposed on the channel 1 & 3 traces.  It would be nice to use the math trace for the Decoder.  This analog signal easily shows when the drivers are switched on, pulling the bus a few hundred millivolts from the resistor pull up/pull down and termination one bit time before the start bit.  And then the drivers are turned off one bit time after the stop bit.  Different devices on the bus have different mark & space voltages, allowing me to sort them out.

Thanks for any help.

[Rerouter]

I wont be in the lab until saturday. But I can atleast help out with some if it. The decoders are baked into either the fpga bitstream or the application on the scope, dont yet know enough to say which. But the system app would be the easier one to patch if it was the case.

For dumping the contents. The only current way to do it that I am aware of is "C1:WF? ALL" swapping out c1 for c1-c4 for an analog channel. Or d0-d15 for a digital. Its unscaled. And I really hope either siglent or one of us can patch in a way to dump over network in the same formats that you can to a USB. And yes its 1 channel at a time.

When I get back I can look at the rest

[tautech]

Please check you have the latest  6.1.26 firmware installed.
Download link:
https://www.siglentamerica.com/download/7232/

[Raoul Duke]

Thanks.

I upgraded from 6.1.25R2 to 6.1.26.  It works a little better decoding but it still does not like 0x00 without parity.  Still no option for MARK/SPACE parity.

[rf-loop]

Thanks.

I upgraded from 6.1.25R2 to 6.1.26.  It works a little better decoding but it still does not like 0x00 without parity. 

Do you mean Serial trigger or serial decode. I have never meet problem where decoder do not decode 0x00  with what ever parity setting.  (I have not tested all trigger variations so this I do not know - yet and now busy days, so hobby things queue is in waiting state) But what I have seen is UART speed is perhaps bit off (or what ever is real reason)  and some times using custom speed setting give better result. But, now it need note that I do not also have perfect speed source. So...
Parity setting have been and is E, O or N.  No forced 1 or  0  (until Siglent add this feature in some future if they want do it)

[Raoul Duke]

I mean serial decode.  The serial trigger is a level of complexity that I have not gotten to work properly yet, so I just trigger on the first start bit of the first character from power on.

The new firmware is demonstrably worse than the previous version.  It fails to decode 75% to 80% of the bytes.  Yes, it's a custom bit rate.  Yes, I've tried jiggling it.  No it didn't work any better.  The List window is also much worse because it is all jittery and jumpy, trying to remain on a successfully decoded byte while I scroll in time through all the bytes it missed.

Update: I got the decoder to work much better by taking the bit rate WAY high - over 10% - until everything failed.  Then I took it lower than target by a few percent, and it started decoding everything.  And then I rolled it back up to the target bit rate - 1.6%, and it still decoded properly.  The actual correct bit rate is still busted though.  1.6% should not be significant, as I have 48 samples per bit - it's less than 1 sample.  The list is still jittery when scrolling horizontally in time.

Here are some screen shots.

[Rerouter]

Just as a silly question, you have set up your RX and TX thresholds to reasonable values? Could you show pages 1 and 2 of the decoder menu?

I will be able to double check this on Saturday, but the more info I have, the better I will be able to replicate it.

[tautech]

Here are some screen shots.

Ditch Maths, set probes and inputs to 10x, set Hor Position to zero (press the knob), use lower V/div and separate traces. Assign traces to RX/TX and check thresholds are appropriate.

First it's imperative you get rock solid stable triggering, the packets with just ordinary trigger settings should be completely stable and no jumping around. The secret to do this is with trigger Holdoff.
For the UART signal from Siglents demo board STB-3 I've set a holdoff of 55ms so the trigger is disarmed for a complete packet.
When you have a stable Decode in Run mode, then you can piss around with fancy pants Decode trigger to get only the data you want/need to see.

If you choose to use the Zoom you can then see just where you are in relation to the data stream and with the Hor Position (in Zoom) walk the zoomed portion to anywhere you want.

Here we have 74 lines in the Decode list with the trigger position packet (#37) at 0s and the pre and post trigger packets all listed and time stamped.



Study the various settings visible in this screenshot.

[rf-loop]

Thanks.

I upgraded from 6.1.25R2 to 6.1.26.  It works a little better decoding but it still does not like 0x00 without parity. 

Not 9 bit multidrop because it can not do it but other ways about decode...
Here tested using 115kb
Two decoders simultaneously
Decoder 1 8bit, Odd, 1 stop  (data 0x54,58,31,00,41,31)
Decoder 2 8bit, Even, 1 stop  (data 0x54,58,32,00,42,32)

Included also 0x00

(there can see also that decoder 2 input signal have bit idle time between bytes because same tiny slow controller send simultaneously both transmissions and this is reason also why it start bit late)





It decode rock solid without errors etc.  (attached images and just saved "on the fly")
Just set all parameters as they need be and without any problem immediately decode and really rock solid.

then your other message with images

"Here are some screen shots."

With my eyes it looks that there must be some really weird settings. Like something is totally "out of order".

[Raoul Duke]

Thank you everyone for the help.  I had moved the trigger level up & down without success.  The big issue seems to have been sensitivity to exact timing; once I dropped the baud rate down 1.6%, the decoder has been much more stable.  I still wish for a "MARK/SPACE" parity option so that at least I can highlight the address/command words.

From what I can tell, it seems that the decoder is running in S/W after the data capture.  Which is nice because it allows for the timing & level changes to be performed on captured data, rather than recapturing it all.

I will now attempt to try the data triggering function, and learn how to make segments work.  My current limitation is the 3000 character decode limit.  Here's a screenshot of the limit, showing how the analog data identifies two devices by their different driver voltages.

 

[tautech]

Thank you everyone for the help.  I had moved the trigger level up & down without success.  The big issue seems to have been sensitivity to exact timing; once I dropped the baud rate down 1.6%, the decoder has been much more stable.  I still wish for a "MARK/SPACE" parity option so that at least I can highlight the address/command words.

From what I can tell, it seems that the decoder is running in S/W after the data capture.  Which is nice because it allows for the timing & level changes to be performed on captured data, rather than recapturing it all.

I will now attempt to try the data triggering function, and learn how to make segments work.  My current limitation is the 3000 character decode limit.  Here's a screenshot of the limit, showing how the analog data identifies two devices by their different driver voltages.

It decode rock solid without errors etc.  (attached images and just saved "on the fly")
Just set all parameters as they need be and without any problem immediately decode and really rock solid.

then your other message with images

"Here are some screen shots."

With my eyes it looks that there must be some really weird settings. Like something is totally "out of order".

I agree, Raoul Duke is still learning to use the X-E to its potential. 

@Raoul Duke
For you to have to STOP the scope to get stable Decode you still have some settings to optimize.
All previous screenshots are with the scope in RUN mode and with stable triggering.
Please read previous posts carefully again.

Note, Red boxes in the Decode line indicate errors, you still have some settings to correct.
All we can do if offer screenshots showing correct decoding....unfortunately we do not have your scope in front of us to make the correct settings.

Sometimes it can help to start again after pressing Default to clear any settings that might be corrupting your results.......and yes I was caught by just this showing Decode to member Dubbie one day when he visited. 

[Raoul Duke]

The errors are parity errors because I can only pick ODD/EVEN, and the parity bit is being used to identify command/address bytes (mark) from data bytes (space).

The scope is stopped after I fill all 14M of memory with data from power on - 7 seconds of data.  I have zero control nor insight into the devices on this bus.  They perform auto-discovery after power on and boot.  Again, I have zero control over this, because I'm reverse engineering the protocol, not developing the firmware or hardware.

Now that I understand the protocol to some extent, my next project is to make the ftdi_sio driver speak 9-bit multidrop at the oddball bit rate.

Thanks again for the help.

[tautech]

Respectfully, without rock solid stable triggering it's hard to get meaningful results.
Your screen captures with a STOPped display indicate the packets are jumping around and trigger settings are not optimum. Trigger holdoff gets it stable for further adjustments to the Decode settings to get a result.
When achieved all the packet boxes all turn blue.
Using Zoom also shows where you are within the data stream.

[nctnico]

Respectfully, without rock solid stable triggering it's hard to get meaningful results.
Your screen captures with a STOPped display indicate the packets are jumping around and trigger settings are not optimum. Trigger holdoff gets it stable for

Read what Raoul wrote: 9 bits is often used in multi-drop protocols using the parity bit as a 9th bit. However the oscilloscope simply doesn't support it and hence the decoding errors when the parity doesn't work out. Now what would be nice is to have a feature which would color the byte based on the 9th bit.