UART decoding

UART decoding, a forum discussion on Cleverscope Mixed Signal USB Oscilloscopes. Join us for more discussions on UART decoding on our Questions forum.

Back to Forum Index : Back to Questions   RSS
ivo@pretech.co.nz

22nd October
Posts: 1

I have a CS328 classic using the latest software: 4.80866. My firmware is up-to-date.
I'm trying to decode a 16MBaud stream (bit width 62.5ns). I am using the digital inputs - in particular IN 1. The analogue probes are not in use.
I have two problems:

1) The decoding doesn't appear on the scope display although, he name given to the signal line (uart TX) appears, but no data is displayed. If I output the decoding to the notes, then the decoded data does appear.
2) Although the decoded data appears in the notes, there is a strange characteristic. If I send a message of length between 1 - 14 bytes, decoding is done correctly. If I send 15 bytes, the last byte is not decoded. If I send 16 - 19 bytes, the data is decoded correctly. If I send 20 bytes, the last byte is not decoded. If I send 25 bytes all bytes are received correctly.
If I use my UART in loop back mode, all bytes are received for all instances above.
If I use another device to receive the data, it receives the correct number of bytes
If I look at the scope trace, the length of the total data frame is roughly what would be expected for the correct number of bytes - hard to identify individual bytes with the decode display working!

Do I have a bug in the software, or am I doing something wrong?

Thanks
Ivo

bartschroder

23rd October
Posts: 453

Hello Ivo,
There is a problem with 480866, and it does not show the decoded values. It is ok in 680865, which we have put back on the website. We will be bringing out a fix for this shortly. As you say, the decoded values do show up in the Notes.

The problem you have with decoding is due to the time quantization - there are only 10ns per sample, but, so 6.25 samples per bit. We estimate the bit rate looking at the message that has been received. The more bits, the more accurate the estimate. We use oversampling to look at the centre three samples of the bit, and use majority to estimate the bit value (there could be noise). Our oversampling is based on 16 or a higher integer which aligns our sample rate with the bit rate.

However, in your case, there are only 6.25 samples per bit, so we cannot oversample enough. Also as the bit rate and the sample rate are not time aligned, the bit edge could be anywhere in the 10ns period, and will be moving in relation to the sample points as the message progresses, so an error in the bit rate estimation will accumulate to being an error in estimating the centre of the bit, meaning we pick the wrong 3 centre bit values. Our decoder was based on the idea that we would have a very accurate estimate of the bit rate, and the location of the start bit, and that we could therefore correctly identify where the centre of the bit was. This is not the case with a 16 Mbaud data stream.

We had thought that UART's would not be used above about 1 Mbaud, but we are wrong! We will have to make the decoder change tack, and do it a different way if the number of samples per bit is low.

So it is a problem in our decoder design.

cheers
Bart

Back to Forum Index : Back to Questions   RSS
You must be logged in to post a reply



You need to Register or Log In before posting on these forums.

×

Your shopping cart is empty.