Baud rate and parity: why 8E1 is the default

Baud rate, parity, data bits and stop bits have to be identical on every device sharing one RS485 bus, because Modbus RTU has no way to negotiate them. Get one of the four wrong and you do not get an error message, you get silence. After this lesson you can read those four settings off a datasheet, calculate the silences that follow from them, and find a device whose settings nobody wrote down.

Four settings that must match everywhere

All four have to match on every device on the line, and the specification says so in as many words: the transmission mode and the serial port parameters must be the same for all devices on a Modbus serial line.

A working client configuration for a three phase energy meter reads 9600, 8, E, 1.

The meter at the other end holds the same four choices in its own registers. On an Eastron SDM630 the parity and stop bit setting sits at datasheet number 40019 (PDU address 0x0012) and the baud rate at datasheet number 40029 (PDU address 0x001C), and both need a restart to take effect. There is no handshake: what you type into the client has to match what somebody once wrote into the device. For the frame that travels over those settings, see Modbus RTU explained.

Why a character always takes 11 bits

Because the specification pins the character frame at 11 bits, and when the parity bit disappears a second stop bit takes its place.

Counted out: 1 start bit, 8 data bits (least significant first), 1 bit for parity completion, 1 stop bit. That is 11. The wording on no parity is explicit: the use of no parity requires 2 stop bits, so the frame is filled out to a full 11 bit asynchronous character.

The consequence matters more than the arithmetic. Because the character length never changes, neither does the timing derived from it.

8E1, 8O1, 8N2 and the odd one out 8N1

Three of these four combinations produce an 11 bit character. One does not.

8N1 is common in the field but it is not spec compliant, and that is worth saying plainly rather than treating it as a fifth legal option. The Eastron SDM630 shows how it spreads: value 0 of its parity register means one stop bit and no parity, so one of the most widely sold Modbus meters ships that way. The cost is concrete. A 10 bit character makes any device that derives its timers from the baud rate work with a shorter character time, and an 8N1 client never talks to an 8E1 server.

Which baud rate to choose, and why not the fastest

9600 and 19200 are the two rates every device must implement, and 19200 is the required default. Everything else, from 1200 up to 115200, is optional.

Practice and specification diverge here, and the specification hints at why: elsewhere it calls 9600 bits per second the typical rate. So the default to meet is 19200 8E1, while the device in front of you is quite likely on 9600. Try both.

Faster is not free. Every implemented baud rate must be held to better than 1 percent when transmitting and tolerate a 2 percent error when receiving, so a device with a cheap clock runs out of margin at high speed first. Length and speed also trade against each other on RS485, which is covered in the lesson on the RS485 physical layer. Pick the lowest rate that meets your cycle time, a sum worked out in the lesson on polling interval and bus load.

How long is one character at your baud rate?

Divide 11 by the baud rate. At 9600 baud that is 11 / 9600 = 0.0011458 s, which is 1.1458 ms per character.

Now put a real request on that clock. An FC03 read request is 8 bytes on the wire: server address, function code, two address bytes, two quantity bytes, two CRC bytes. At 9600 baud that is 8 x 1.1458 = 9.17 ms of transmission, plus the mandatory t3.5 silence before and after it, so 2 x 4.010 = 8.02 ms. That means 17.19 ms passes before the response may even begin. At 19200 baud the same request costs 8.59 ms.

That is why you read registers in blocks. The bytes are cheap, the silences are not.

Why the silence between frames is the message boundary

An RTU frame has no length field and no start character, so the only thing that tells a receiver a message has ended is the line going quiet. Two intervals do that work:

• t3.5, 3.5 character times, is the minimum silence between two frames. Quiet for longer than this means the previous frame is complete and the next character starts a new one.
• t1.5, 1.5 character times, is the largest gap allowed between two characters inside one frame. A longer gap means the frame is declared incomplete and discarded.

Above 19200 baud, meaning greater than 19200 rather than from 19200 upwards, the standard recommends fixed timers instead: 750 us for t1.5 and 1.750 ms for t3.5, because servicing those interrupts at speed loads the processor. Two details get retold wrong. At exactly 19200 baud you still calculate. And the fixed 1.750 ms is shorter than the 2.005 ms the formula gives at 19200, so it is a pragmatic floor, not a continuation of the curve.

Finding an unknown device without guessing

Change one variable at a time and start with the most likely combination, not the top of the dropdown.

A workable order is 9600 8N1, then 9600 8E1, then 19200 8E1, and only then the rest. Combine that with an address sweep over the valid range of 1 to 247, remembering that address 0 is the broadcast address and never answers and that 248 to 255 are reserved. Hold the serial parameters still while you walk the addresses, then move to the next set.

The moment something answers, write down all four values plus the address. For tooling that automates the walk, see scanning a Modbus network.

Common mistakes

Assuming no parity is the standard. The specification prescribes 19200 8E1, while plenty of inexpensive devices leave the factory on 9600 8N1. Both assumptions are wrong often enough to cost you an afternoon. Read it from the datasheet, or sweep for it.

Changing two things at once. Adjusting baud rate and parity in the same step makes the result useless: a hit tells you nothing about which change caused it, and a miss rules out nothing. Change one thing, test, then move on.

Picking the highest baud rate because the dropdown allows it. Higher speed means a shorter maximum cable run and less margin against noise, and the wiring rules behind that are in the RS485 wiring guide.

Expecting a wrong parity to produce an error message. The device receives a mangled frame, discards it and stays quiet. You get a timeout, and a timeout looks exactly like a broken wire, a wrong address or a dead device. Telling silence, a CRC error and an exception apart is the subject of the lesson on RTU troubleshooting.

Try it yourself

1. 1

   Calculate your character time

   Divide 11 by your baud rate. At 9600 baud that is 1.1458 ms. Write it down, because everything else here is a multiple of it.

2. 2

   Calculate t3.5

   Multiply the character time by 3.5. At 9600 baud that gives 4.010 ms of mandatory silence between two frames.

3. 3

   Repeat for 19200 baud

   Do the same sum for 19200 and confirm that both numbers halve: 0.573 ms per character and 2.005 ms of silence.

4. 4

   Read a register with the correct parameters

   With mbpoll (free to use, including commercially) read two holding registers from a device on address 1, because -t 4 selects the holding register block. The adapter, the port name and the switches are walked through in the lesson on reading your first device:

   mbpoll -m rtu -a 1 -b 9600 -P none -t 4 -r 1 -c 2 -1 /dev/ttyUSB0
   

5. 5

   Break the parity on purpose

   Run the same command with -P even while the device is still set to no parity. Note what you get: no answer, no complaint from the device, just a timeout.

6. 6

   Break the baud rate on purpose

   Now run it with -b 19200 while the device is still on 9600. Same picture. A wrong serial parameter produces silence, never a tidy error message.

No hardware? Run the pymodbus simulator (free to use, including commercially) over TCP and confirm that baud rate and parity play no role there, because TCP carries no serial parameters. On Linux or macOS you can do the full exercise with a virtual serial pair:

socat -d -d PTY,link=/tmp/ptyp0,raw,echo=0,ispeed=9600 PTY,link=/tmp/ttyp0,raw,echo=0,ospeed=9600

Expected result: two calculated times, and two failed attempts that produce exactly the same symptom.

Summary

• Baud rate, data bits, parity and stop bits must be identical on every device on one Modbus serial line, because RTU cannot negotiate them.
• An RTU character is always 11 bits, because switching parity off adds a second stop bit in its place, so timing never depends on parity.
• The specification requires even parity and 19200 baud as defaults, while many field devices ship on 9600 8N1, which is 10 bits and not spec compliant.
• Character time is 11 divided by the baud rate, so 1.1458 ms at 9600 baud, which puts t3.5 at 4.010 ms.
• A wrong baud rate or parity produces a timeout, not an error message, so change one setting at a time.