AradMsMeter-Dialog3G: ~98% of packets decode as all zeros and 2% perfectly (US Master Meter 3G AMR) #3459
Description
Hi guys,
I'm trying to receive US Master Meter 3G AMR water meters at 916 MHz using an RTL-SDR Blog V4. These seem very similar (or possibly identical?) to the Arad Dialog3G that @avicarmeli worked on in #1992 — huge thanks for that work.
I have 3 meters in range with known serial numbers and counter readings, so I can verify when a decode is correct. Each meter transmits roughly every 11 seconds, but only about 1 out of 40–50 packets actually decodes with the correct serial and counter. All the other packets do find the preamble and go through the decoder, but come out as serial=00000000 and volume=0.0 — the payload is all zeros. This is the main issue I'm trying to solve.
Curious observation: proximity / drift behavior
When a meter first enters the range of my antenna (e.g. I bring it from my car garage closer to the RTL-SDR dongle), the first few packets seem to have a much higher probability of decoding correctly. After that it goes back to outputting mostly zeros until a rare correct decode. This makes me wonder if there's some kind of drift happening — either on the meter side or the SDR side — that degrades decoding over time. But I really don't know.
Questions
I've been trying to understand what's going on and would love some help:
-
Preamble false match? Could the all-zero payloads be caused by the preamble matching at the wrong position in the bitstream? I noticed that
bitbuffer_searchmight returnrow_bitswhen it doesn't truly find the preamble, and then the unsigned subtraction in the length check could wrap around and pass — extracting bits past the end of the buffer. But I might be misreading the code. -
Preamble not strict enough? Could these payloads just be noise, with the 48-bit preamble not being selective enough, leading to false triggers? I really hope this isn't the case — an 11-second burst interval seems way more realistic than a 5-minute one for a drive-by AMR application.
-
FSK / Manchester drift? Is there some sort of drift issue, or could something be off with the Manchester encoding / FSK demodulation that causes the decoder to lose sync after a while?
Side observation: volume mismatch on one meter
This is not my main concern, but it might be a useful data point: out of my 3 meters, 2 decode the volume correctly on every successful packet. The third one, however, consistently reports a wrong reading — the meter face reads 136,984 gallons but the decoder outputs 7310.3. The serial number on that meter is always correct, so the byte alignment seems fine — it's just the volume field that's off. It's possible this particular meter has a defect or that it helps us figure out the bigger decode problem. Mentioning it here in case it helps paint a fuller picture.
Setup
- Hardware: RTL-SDR Blog V4
- Software: rtl_433 v25.12
- Command:
rtl_433 -R 260 -f 916M -F json - Meters: 3× Master Meter Dialog3G (US, gallon units), on a bench ~1m from antenna
Since the decoder works about 1 in 40–50 packets, it seems like we are very close to something that works reliably — the preamble and packet structure seem to match. I'd really appreciate any pointers from anyone who's seen similar behavior.
Happy to share IQ captures (.cu8 files) or any other data that would help. Thanks!