PicoScope 7 Software
Available on Windows, Mac and Linux
Serial decode issue
Serial decode issue
Hi,
I've an odd one here...
I'm decoding an RS485 data stream at 9600, n, 8, 1 and the master device always decodes ok but I get bad decodes on the response data.
The master device has a nice symmetric signal on the lengths of the 1s and 0s but the response data wave forms are slightly different. At 9600 the bit length is just over 104us. If you get a single 1 bit with a 0 either side the bit width is about 119us and a single 0 bit with a 1 either side is about 89us. If you have a 1 and a 0 together the total is the expected 208us so basically the isolated 0 bit on the wire is asymmetric but it is padded to always keep the proper bit time.
The basic idea with asynch comms is you are supposed to make your value decision in the middle of a bit cell and so it should not matter if an isolated 0 is "shorter" as long as it is positioned correctly in the time slot.
The serial decode works fine with this for the most part unless the first two bits in the start of a byte are 1 followed by a 0 and the bytes are back to back. In this case the serial decoder seems to look at the slightly short 0 start bit and decides it is not the start of the byte and gets out of synch until either the next "valid" start bit or the first pair of 0s which it then assumes is a start bit.
Has anyone come across this issue before?
Regards,
Peter
I've an odd one here...
I'm decoding an RS485 data stream at 9600, n, 8, 1 and the master device always decodes ok but I get bad decodes on the response data.
The master device has a nice symmetric signal on the lengths of the 1s and 0s but the response data wave forms are slightly different. At 9600 the bit length is just over 104us. If you get a single 1 bit with a 0 either side the bit width is about 119us and a single 0 bit with a 1 either side is about 89us. If you have a 1 and a 0 together the total is the expected 208us so basically the isolated 0 bit on the wire is asymmetric but it is padded to always keep the proper bit time.
The basic idea with asynch comms is you are supposed to make your value decision in the middle of a bit cell and so it should not matter if an isolated 0 is "shorter" as long as it is positioned correctly in the time slot.
The serial decode works fine with this for the most part unless the first two bits in the start of a byte are 1 followed by a 0 and the bytes are back to back. In this case the serial decoder seems to look at the slightly short 0 start bit and decides it is not the start of the byte and gets out of synch until either the next "valid" start bit or the first pair of 0s which it then assumes is a start bit.
Has anyone come across this issue before?
Regards,
Peter
Re: Serial decode issue
The file I have is very large at 77MB so I can't upload it. Is there a way to save a section of a captured waveform as I'm not on site anymore and it requires a plane trip to get there!
Re: Serial decode issue
I noticed that the master packet had decode errors too one one capture but far fewer. When I looked at these, the differences in time were less than a us. I had the threshold set to 2V and there is a bit of a noticible rise and fall time on the signals due to cable lengths etc so I adjusted the threshold to 1 v to make the pulse slightly larger which worked in that instance. We are talking going from 103.4us at the 2V point to maybe 104.5 at the 1V point here.
It looks like the timing window for the start bit is set very tight...
It looks like the timing window for the start bit is set very tight...
Re: Serial decode issue
Best I can do is a couple of screen captures showing one of the failures with the measurements for the start bit and following 1 bit - waveform is reversed as I was capturing from an RS485 line and picked the wrong polarity when connecting my probe...
- Attachments
-
-
Re: Serial decode issue
looks like your baud-rate is a bit off.
Hard to tell without a .psdata file.
you can try using a wetransfer link for the .psdata because it is far to big for the forum to post.
Benno
Hard to tell without a .psdata file.
you can try using a wetransfer link for the .psdata because it is far to big for the forum to post.
Benno
Re: Serial decode issue
I think the baud rate is ok but the start bit detection in the asynch serial decode is just a bit too sensitive. It gets confused with relatively small changes in the timing as you can see from the above images and is completely thrown by the non symmetric 0/1 bit timing for the responses.
Peter
Peter
Re: Serial decode issue
Here's the file in drop box:
https://www.dropbox.com/scl/fi/c72lu94f ... 3eqyh&dl=0
https://www.dropbox.com/scl/fi/c72lu94f ... 3eqyh&dl=0
Last edited by petermcs on Thu Dec 21, 2023 1:51 pm, edited 1 time in total.
Re: Serial decode issue
If you select decode between time rulers and then place the cursors as shown, the framing errors disappear.
When you enable serial decoding it downsamples data to process, as you have plenty of trace with no data with your settings this results in around 5 samples per bit of the serial data which is too low, hence the sample rate too low message
If you select between cursors it downsamples the selected region, has many more samples per bit, and can process the data.
You could just move the trigger to 10% and change the timebase to 5S/div , but this would depend upon other data you need to collect.
Hope this helps.
- SampleRateTooLow.png (9.98 KiB) Viewed 128415 times
You could just move the trigger to 10% and change the timebase to 5S/div , but this would depend upon other data you need to collect.
Hope this helps.
Martyn
Technical Support Manager
Technical Support Manager
Re: Serial decode issue
He is sampling at 500kS / sec so it is 50 samples per bit
This should be enough.
P.S. I misunderstood the downsampling. why is that ?
is this also true for CAN bus ?
Benno
This should be enough.
P.S. I misunderstood the downsampling. why is that ?
is this also true for CAN bus ?
Benno
Last edited by bennog on Fri Dec 22, 2023 10:20 am, edited 1 time in total.
Re: Serial decode issue
It looks like the problem is the pulses are not symmetric High = 102us = 9800 Hz Low = 106us = 9400 Hz
I don't have the RS232/485 specs in my head what the variation is allowed in these timings.
But somehow the picoscope software is very picky about the bit timing and missing te start bits.
Benno
I don't have the RS232/485 specs in my head what the variation is allowed in these timings.
But somehow the picoscope software is very picky about the bit timing and missing te start bits.
Benno
Re: Serial decode issue
The Serial Decoder only pulls down 20MSamples for decoding, the data is downsampled on the device, so even though the device is sampling at 500kSamples/second you won't get that for decoding.
The full buffer contains 250MSamples so 20MSamples for decoding means you are getting less than 5 samples per bit not the 50 samples.
If you decoder between rulers, and set the rulers as I have shown, you are getting 20MSamples across a tenth of the overall time which is why it can then decode correctly.
We are currently investigating this limit to see what impact it will have on performance if we increase it.
The full buffer contains 250MSamples so 20MSamples for decoding means you are getting less than 5 samples per bit not the 50 samples.
If you decoder between rulers, and set the rulers as I have shown, you are getting 20MSamples across a tenth of the overall time which is why it can then decode correctly.
We are currently investigating this limit to see what impact it will have on performance if we increase it.
Martyn
Technical Support Manager
Technical Support Manager
Re: Serial decode issue
Excellent Martyn! That's sorted it perfectly.
I can see what you mean in terms of the buffer used for analysis and the down sampling which means the slight changes in the timing for the bits can be come large if they are at a sample boundary...
Thanks for your help with this.
Peter
I can see what you mean in terms of the buffer used for analysis and the down sampling which means the slight changes in the timing for the bits can be come large if they are at a sample boundary...
Thanks for your help with this.
Peter