One of the most confusing things about Modbus is that the very same register can be called two different numbers depending on who is counting, and a value that reads perfectly in one master can come out one register off in another for exactly this reason. The cause is that Modbus has a zero-based protocol address that goes on the wire and a one-based data model number that appears in documentation and tools, and the two differ by one. This page explains the difference between zero-based and one-based addressing, why it produces the classic off-by-one, and how a driver's per-device base setting ends the guessing for good.
Modbus zero-based vs one-based addressing in one line: Modbus zero-based versus one-based addressing is the gap between the address actually placed on the wire, which is zero-based and runs from 0 to 65535, and the way documentation and tools often number the same registers starting from 1. Because they differ by one, a register described as number 1 in a manual is protocol address 0 on the wire, so a driver that assumes the wrong base reads one register off from what you intended. Setting a driver's base, zero-based or one-based, to match how a given device is documented resolves the off-by-one.
Modbus separates the address that travels on the wire from the way people refer to registers. In the actual protocol frame, the address field is zero-based: the first register in a table is protocol address 0, the next is 1, and so on, up to a maximum of 65535. This is the number the master literally puts into the request and the slave uses to look up the register. It is a pure offset into the table, starting from zero, with no gaps and no assumptions about which table you mean beyond the function code you sent.
The trouble is that humans and many tools count from one. Documentation, configuration screens, and casual conversation frequently number registers starting at 1, so the first register is called register 1, the second register 2, and so on. This one-based numbering is a data-model convenience, easier to read and to talk about, but it is offset by one from the zero-based address on the wire. So the register a manual calls number 1 is protocol address 0, number 2 is address 1, and the entire numbering is shifted by one relative to what actually goes into the Modbus request.
That single-register shift is the whole problem in a nutshell. When you read a value, you and the device have to agree on which counting scheme the number you typed represents. If you enter a one-based register number into a field that expects a zero-based wire address, or the reverse, every register you touch lands one position away from the one you meant. Because the shift is consistent, the symptom is neat and repeatable: everything is off by exactly one register, which is the fingerprint of a base mismatch rather than a random wiring or data fault.
This is why a configuration that works perfectly in one master can be off by one when you rebuild it in another. Different Modbus masters, drivers, and tools make different assumptions about what the address you type means. One tool may expect you to enter the zero-based wire address directly, so you type 0 for the first register. Another may expect the one-based data-model number and quietly subtract one before putting it on the wire, so you type 1 for that same first register. If you carry the same typed numbers from one tool to the other without accounting for their differing assumptions, you shift the whole map by one and read the neighbouring register everywhere.
The confusion is worse because both readings often look plausible. Reading one register off does not usually throw an error; it just returns the value of the adjacent register, which may be another real measurement, so you get a believable but wrong number rather than an obvious failure. The tell is that a value you can independently verify, from the device's own display or a known state, appears exactly one register away from where you asked. When a whole set of tags is consistently one register out and the data otherwise looks sensible, a base mismatch between how the two masters count is almost always the cause.
It is worth being clear that this is a different problem from the register-type prefix in numbers like 40001. That prefix, the leading 4, tells you the register table, and stripping it is a separate step covered by the register-addressing offset topic. Zero-based versus one-based is purely about whether the counting within a table starts at 0 or at 1, independent of which table you are in. A given configuration can get the table right and still be off by one purely because the base does not match, which is why the two issues are worth keeping distinct when you troubleshoot.
The practical cure is to stop guessing and set the base explicitly. Good Modbus drivers let you choose, often per device, whether the addresses you enter are zero-based or one-based, so once you know how a particular device's documentation numbers its registers you configure the driver to match and enter addresses exactly as the manual gives them. That per-device base setting is what ends the off-by-one, because it makes the translation between what you type and what goes on the wire explicit and consistent rather than dependent on an assumption you have to remember for each tool.
Setting it per device matters because a single SCADA system often talks to equipment from many vendors, and those vendors do not all document their registers the same way. One device's manual may list one-based numbers while another lists raw zero-based offsets, and a base setting that is correct for one can be wrong for another. Configuring the base alongside each device, and verifying it against a known reference value at commissioning, means every device is read with the counting scheme its own documentation uses, so a fleet of mixed equipment all lines up correctly.
For cloud SCADA this is a commissioning discipline that pays off permanently, because a base mismatch is deterministic: it affects every read of every tag on that device in exactly the same way, forever, until fixed. A cloud SCADA platform such as Merobix will faithfully return whatever the configured base produces, so the safeguard is to confirm each device's base against a value you can check independently before the site goes live. Get the base right once per device and the off-by-one never appears again for that device, which is far cheaper than chasing consistently-wrong readings after operators have started to rely on them.
Zero-based addressing is the address actually placed on the wire, where the first register in a table is protocol address 0 and the range runs to 65535. One-based numbering is how documentation and tools often refer to the same registers, starting the count at 1. Because they differ by one, the register a manual calls number 1 is protocol address 0, so the two schemes describe the same register with numbers that are offset by one.
Different masters assume different things about the address you type. One may expect the zero-based wire address directly, while another expects the one-based data-model number and subtracts one before putting it on the wire. Carrying the same typed numbers between them without accounting for that assumption shifts the whole map by one, so every tag reads the neighbouring register, giving a believable but wrong value.
Good drivers let you choose, often per device, whether the addresses you enter are zero-based or one-based. Once you know how a device's own documentation numbers its registers, you set the driver's base to match and enter addresses exactly as the manual gives them, making the translation to the wire address explicit and consistent. Verify the base against a known reference value at commissioning, and the off-by-one disappears for that device.
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.