Serial parity and framing are the rules that wrap each byte on an asynchronous serial line so the receiver knows where a character starts, where it ends, and whether it arrived intact. They are the settings behind the cryptic 8N1 or 8E1 shorthand printed on device manuals and dialed into terminal software. Getting them wrong is one of the most common reasons a Modbus RTU link or serial radio connects electrically yet exchanges nothing but errors, so field techs need to read the shorthand fluently.
Serial Parity & Framing in one line: Serial framing is the structure of start bit, data bits, optional parity bit, and stop bits that surrounds each byte on an asynchronous link, commonly written as 8N1 for eight data bits, no parity, one stop bit. Parity is an error-check bit that helps the receiver detect a corrupted character, and every device on the link must use identical framing and parity or communication fails.
The three-part code such as 8N1 packs the entire character frame into a compact notation. The first number is the count of data bits, almost always 8 in industrial work, though 7 appears on some legacy ASCII links. The middle letter is the parity mode: N for none, E for even, O for odd, and occasionally M or S for mark and space. The final number is the count of stop bits, normally 1 but sometimes 2 to give the receiver extra settling time.
So 8N1 means eight data bits, no parity, and one stop bit, which is the default across the vast majority of Modbus RTU and general serial devices. 8E1 means eight data bits, even parity, one stop bit, and is common on installations that want the extra per-character error check. When two devices disagree, for example one set to 8N1 and the other to 8E1, the receiver either flags parity errors on every byte or misreads the frame boundaries entirely, and the link appears dead even though the wiring and baud rate are correct.
Because the shorthand is terse, it is worth writing the full setting on panel drawings and commissioning sheets rather than assuming a default. A device that ships from the factory at 8E1 dropped onto a bus documented as 8N1 will refuse to communicate until every node is reconciled to one framing, and chasing that mismatch in the field wastes hours if nobody recorded the intended configuration.
The start bit is a single transition that tells the receiver a character is beginning, letting it synchronize its bit sampling clock to the incoming data even though the two devices share no clock wire. After the data bits, one or two stop bits return the line to its idle state and guarantee a minimum gap before the next start bit. If the receiver does not see a valid stop bit where it expects one, it raises a framing error, which usually signals a baud mismatch, severe noise, or a floating line.
Parity adds a simple integrity check. With even parity the transmitter sets the parity bit so the total number of ones in the data plus parity is even; the receiver recomputes it and flags any character where the count no longer matches. This catches single-bit flips caused by noise, though it cannot catch an even number of simultaneous errors and cannot correct anything, only detect. That is why parity is a first line of defense rather than a guarantee of data integrity.
Protocols layered on top add their own stronger checks, which is why many Modbus RTU installations run 8N1 with no parity and rely on the message-level CRC to catch corruption across the whole frame. The choice between 8N1 and 8E1 is therefore partly about whether you want a per-character check in addition to the protocol's own checksum. Either can be correct, but consistency across the bus is what actually matters.
In a cloud SCADA rollout, the serial framing lives on the edge link between a field gateway or serial device server and the instrument it polls. The gateway must be configured with the exact data bits, parity, and stop bits of the target device, and a single wrong letter in that setting turns every poll into a framing or parity error that surfaces upstream as a device timeout. Before blaming the radio or the cloud, an experienced technician confirms baud, parity, and stop bits agree on both ends.
These settings are static and invisible once a site runs, which makes them a classic source of intermittent-looking trouble that is actually a hard configuration mismatch. A tech swapping a failed RTU for a spare that boots at a different parity default can knock a whole segment offline, and without good records the fix is trial and error across a handful of combinations. Documenting the intended framing per device is cheap insurance against exactly this scenario.
A cloud platform that reports per-device communication statistics, including framing and CRC error counts, turns an otherwise opaque serial problem into something diagnosable from a browser. Instead of driving to the pad with a laptop and a breakout box, an operator can see that a device is answering but throwing parity errors, narrow the cause to a framing mismatch, and direct the field fix precisely. Clean framing is the quiet prerequisite that lets the rest of the telemetry chain work.
8N1 means each character is sent with eight data bits, no parity bit, and one stop bit, preceded by a start bit. It is the most common framing for Modbus RTU and general industrial serial links. Both devices on the link must use the same framing, so if one is set to 8N1 the other must be too.
Modbus RTU already protects each message with a CRC, so many installations run 8N1 with no parity and rely on that checksum. Using 8E1 with even parity adds a per-character check on top, which some sites prefer. Either is acceptable, but every device on the same bus must be configured identically or the link will not work.
A framing error means the receiver did not find a valid stop bit where it expected one, which most often points to a baud-rate mismatch between the two devices. Severe electrical noise, a floating or unterminated line, or a wrong stop-bit setting can also cause it. Confirming that baud, data bits, parity, and stop bits match on both ends usually clears it.
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
Last reviewed: July 27, 2026. Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.