CAN Bus Analyzer

It sounds like you are making good progress! If your analyzer is intended to work with certain baud rates, then you could design it to sweep through each one and see if the controller is able to lock on to the data (not register errors). Or, you could just have the user select their baud rate (since this is typically known in a system). If you need to support a continuous range of different baud rates, though, you would need some kind of baud rate detection circuit; that would be much more difficult.

Best regards,
Max

Binu,

Yes, it is certainly possible to measure baud rate using an oscilloscope. You would just directly measure the width (in time) of a single bit. The baud rate would then be 1/t(bit).

If you have a system that needs to cycle through different baud rates in order to find the correct one, it can be useful to use a transceiver with an "autobaud loopback" like the SN65HVD235. This mode disables the external output driver while still internally looping back the TX data to the RX data through the transceiver. This allows a local controller to cycle through different rates and synchronize to the CAN bus without disrupting communication.

Regards,
Max

Binu,

Yes - a baud rate of 125 kbps means that there are 125,000 bits in each second. So, the time taken for each bit would be (1 second) / (125,000 bits). This gives you a bit time of 8 us. If you are measuring 8.8 us, it means that your bus is running slightly slower (at 113.636 kbps).

You may want to first double-check the oscilloscope time measurement to make sure it is correct. One thing to note is that you can usually measure bit timing more accurately if you set the time scale so that the screen only displays two or three bits in total at a time. This gives more resolution to the timing measurements. Another thing to check is that you are measuring the bits during a transmission period in which only one CAN driver is active (for example, the data field of the CAN packet). Other periods (like arbitration or acknowledgement) may involve multiple transceivers driving simultaneously, and some delay between the different drivers (due to bus cabling) would cause the dominant bits to be extended in time.

If the bit timing measurement is valid, then you could also check your system's reference oscillator (e.g., crystal) to make sure it is giving a clock frequency within its expected range.

Regards,
Max