R900BCD — the same reading, encoded as digits
A variant of R900 that encodes consumption as decimal digits rather than a binary integer. Easy to mistake for the plain version, with results that look fine and are not.
R900BCD is a variant of R900 in which the consumption value is carried as binary-coded decimal rather than as a plain binary integer.
BCD stores each decimal digit in its own group of four bits. The number 1234 is
held as the four nibbles 0001 0010 0011 0100, rather than as the binary value
0100 1101 0010. It is a slightly wasteful encoding that persists because it maps
directly onto the mechanical digit wheels of a register and onto seven-segment
displays — no conversion arithmetic needed in a device with a very small budget for
either power or silicon.
Properties
| Property | Value |
|---|---|
| Band | 902–928 MHz |
| Utilities | Water |
| Payload | Cumulative consumption, BCD-encoded |
| Payload style | Odometer — cumulative |
| Encryption | None |
| Decoders | rtlamr |
rtlamr -msgtype=r900bcd -filterid=YOUR_METER_ID
Why this variant deserves its own page
If you decode a BCD payload as plain binary, you do not get a checksum failure or an obvious garbage value. You get a number. It is in a believable range, it increases over time in a believable way, and nothing in the output suggests anything is wrong. It is simply the wrong number.
This is the failure mode worth knowing about, because every other problem on this site announces itself as silence. This one announces itself as data.
The tell is arithmetic. In BCD, no nibble can exceed 9 — the values A through F
are unused. So a payload misread as binary produces a reading that advances
unevenly, jumping over the ranges the encoding cannot represent. If your
consumption series climbs steadily and then makes an implausible leap, then climbs
steadily again, suspect the encoding before you suspect the meter.
The definitive check is the same one as everywhere else: the number on the broadcast must match the number on the register. Not approximately, not in the same ballpark — the same digits. If it does not match, you have either the wrong meter or the wrong decoder, and BCD is the reason the second is more likely than it sounds.
Practical approach
Do not try to determine the variant in advance. Ask for both and let the decoder sort it out:
rtlamr -msgtype=r900,r900bcd -filterid=
Then verify against your physical register before you build anything on top of the number. Try plain R900 first — it is the more common of the two, and it is the one that carries the leak flag, which is the field actually worth having.
Next
Where this leads.