How did I get 20213 bps? Well, to determine where I was at, I had looked at the Saleae and o’scope signal, and roughed out I was getting about 20000. I hadn’t noticed the pop up when I hovered (see the linked article for details).
How did I generate 20213 bps, and why? Well, I’m running on an MC9S08PA60 using the internal clock, set to run as fast as it goes, and requested 19200. It thinks the closest it can get is 19230.795. I have not set up the FLL trim registers, I only need “ball park” clocking for most of the work done.
I’m talking to a PC via a USB to EIA485 device, and that is running at 19204 according to the Saleae (sampling digital only at 125MS/s). It seems that the async analyzer is forgiving enough that I don’t can decode both with the 20013 setting. That’s all great for me.
Now for the question. How much forgiveness does the analyzer have +/-%? I had tried setting at my rough estimate of 20000 and couldn’t decode the faster signal. What tips/recommendations are there for setting baud on a bi-directional bus like RS485?
I ran some tests using our software to generate 19200 bps simulation Async Serial data using the process documented below.
To give a quick explanation of how our Async Serial analyzer decodes data:
After the beginning of the start bit is detected (falling edge in our test case), our Async Serial analyzer essentially reads the first bit right in the middle of where it expects the first bit to reside (with the Async Serial analyzer set to 19200 bps, this will be at approximately 78.14 us after the start bit falling edge to be precise, given each bit is 52.09 us wide). Afterwards, each subsequent bit is read every 52.09 us. The analyzer prints dots where the decoding occurs, which indicates the timing at which the analyzer decodes data based on its bit rate setting (image below).
Updating the analyzer settings to 20,000 bps on the same waveform still decodes the data correctly in this test case, but you will notice the sample dots start to drift towards the end.
Below is the analyzer set to 22,000 bps on the same waveform. At this point, the sample points have drifted enough to the point where the decoded data becomes incorrect.
And it depends on how much tolerance and practical margin (robustness) you want to have in your answer, as well as some other factors.
For typical serial bus bit rates that are significantly slower than the analyzer’s sample rate, as well as when the rising/falling edges are ‘sufficiently fast’ relative to the bit periods – you can probably discount the more pedantic timing details and focus on the more dominating factors: the configured analyzer decoder bit rate vs. observed serial bus TX/RX bit rate(s) and where the ‘sample point’ is within the bit period.
The decoder’s sampling bit rate / clock needs to be accurate enough to actually ‘hit’ (sample) close enough within the middle of each bit, and the decoders usually synchronize to the leading (falling) edge of the first (start) bit. If you are sampling ‘too quickly’ then you’ll sample within the end of the wrong (earlier) bit, and if you are sampling ‘too slowly’ then you’ll sample within the beginning of the wrong (later) bit. Since the RS-485 bus encoding uses an NRZ encoding scheme w/o any resyncs in between bits, the bit errors (e.g., framing errors) will more likely be in the later or last / stop bit (10th bit for an 8N1 configuration) of each ‘frame’ on the serial bus. This is why other serial encoding schemes use more edges vs. pure NRZ – so they can resync more often than just the starting edge (e.g., ‘bit stuffing’ on CAN bus protocol, or Manchester encoding for every bit). Unfortunately, those edges can result in more EMI noise, too.
@BitBob, thank you, some good thoughts there. Ill also follow up that link.
For some reason I thought the analyzer had an auto baud sampler, but i was using my first Saleae with the old Logic SW, and I had a new MSO on my desk, and might have mudled which did what.
I can set my baud rate and capture reliably, but only for the originator, or the responder as my 485 nodes are differently clocked.
One thing i forgot, the analyzers are SW, and i can have multiple instances running. When i get back to my desk ill try running two analyzers on the same channel, one at each speed
