RS485 Baud Rate Errors - Mixing HWSerial Devices Can Cause Problems
Carywin last edited by Carywin
This is more of a troubleshooting report than a request for help. I thought I'd report my findings here in hopes of saving someone else the headaches I've had recently.
What it boils down to is: the default clocks used on the common 3V3 and 5V Arduino boards cause small errors in actual baud rate on the hardware USART serial ports, and at certain rates the error difference between the two variants is opposite and results in no communications being possible between them.
I have a small but growing RS485 MySensors network incorporated into my OpenHAB-based home automation system. It started out with just a MQTT gateway and a single node, being a weather station mounted up on the roof about 5 metres away. RS485 was chosen because getting RF signals through the metal roof was problematic, and I was sick of climbing up there to change batteries. Both the gateway and the WXS were built with 3V3 8MHz 32u4 based Arduinos, because then I could use the hardware USART port for RS485 comms while still having the USB port for debugging. Cat-6 cable was used, with one pair for the RS485 comms and a pair each for +12V and GND. The baud rate was set at 115200 bps and this setup worked flawlessly for about a year.
So pleased was I with the reliability, that I decided all sensor nodes on my upper storey that had easy access for a cable would be wired nodes on the RS485 network going forward.
The second node to be deployed on the network was a light/heat/fan controller for the bathroom. This node used a 5V 16MHz 32u4 Arduino. When built and tested on the bench, this node worked perfectly; but when deployed into the roof space and connected to mains power it flatly refused to work, spitting FPAR:NOREPLY errors forever. I spent a lot of time trying to troubleshoot the comms issues by investigating ground loops or other noise, termination, or power supply issues. I pulled the AC/DC supply off it and used the central +12V one. I changed the baud rates around and got some intermittent success. At one point I even fried both the Arduino and my laptop when some stray high-power-switching surges tried to find their way to ground through the USB cable. Nothing seemed to work in the roof, everything worked fine on the bench.
After much longer scratching my head than I feel comfortable admitting I examined the differences between the MQTT gateway and my test setup, investigated how the oscillator clock is divided down to determine the baud rate, and stumbled upon the answer:
at fosc = 8 MHz (3V3 parts), 115.2kbps, Error = -3.5%
at fosc = 16 MHz (5V parts), 115.2kbps, Error = 2.1%
Total error: 5.6%, somewhat outside the tolerable window of ~5% for baud rate error.
In the end the solution was as simple as lowering the baud rate on the 5V 16MHz part by ~4% to 110600 bps. The new node then instantly connected and has been reliable ever since.
Guillermo Schimmel last edited by
This post is deleted!