Add support for Badger ORION water meter

[nickovs]

This PR provides support for the Badger ORION series of remotely readable water meters. According to the FCC certification there are two variants, one with a fixed 916.45MHz frequency and one frequency hopping; this code has only been tested with the single frequency version (since that's all they have around me) but it should work with the other version if given the correct list of hop frequencies.

The encoding is similar to M-Bus mode T, using the same 4:6 DC-balanced encoding and the same CRC16 polynomial, but with a totally different payload format. This is documented in a comment in the code.

This is my first PR to this project; I've tried to follow all of the contributing guidelines but if there are any changes required then I'm more than happy to squash them in.

[zuckschwerdt]

Looks very good, thanks!

[nickovs]

@zuckschwerdt Thanks for the feedback. I have made the changes that you suggested.

[CFSworks]

I also have a Badger water meter with fixed (916.45 MHz) carrier and tested this on my own meter with:
rtl_433 -d rtl_tcp://... -R 219 -f 916450000 -s 1200000

I can confirm that it displays the correct volume (so the offset of the volume field is correct) but cannot attest to the accuracy of the other fields. I do know that some meters have bits set in the "Flags-2" byte, though in my own meter -- the only one in range, sadly -- this byte is always zero. The first 4 bytes for me are constant (for as long as I have been capturing signals from that meter; my first sample was a little over 4 years ago), so I have no way of knowing where the Flags-1 field ends and ID field begins. The ID field also does not match the number on the label on the meter, but should work to identify it nonetheless.

Note that this PR closes #1779.

Note also that this PR is based partially on my own analysis of the protocol (in which I made some mistakes, believing that there was only a 32-bit sender followed by a 32-bit volume) so please don't give my confirmation as much weight as someone testing this truly independently. :)

[nickovs]

@CFSworks Thanks for testing this and for your pervious analysis which set me on the right path. Thanks also for your pointing me to the rtl_433 project in the first place, since otherwise I wouldn't have done this PR!

Regarding the ID field, can you check if the extracted ID field matches the number stamped on your meter mod 2^24? This is the case for my meter and the meters on the adjacent houses to mine. I've documented this assumption in the comment on line 36 but it would be good to get further validation.

Regarding the flags, my guess (based on far too few observations) is that the byte at offset 3 has flags about the device hardware itself and the byte at offset 7 has status flags for the "Premise Leak Detection", "Cut-Wire Indication", "Reverse Flow Indication", "No Usage Indication" and "Encoder Error" conditions described in the documentation. In my neighbourhood most devices have data[3] == 0 but one device (which looks noticeably different and seems more modern) has one of these bits set. There is more variation in the bits in byte 7. Unfortunately without deliberately triggering a variety of fault conditions it is a little hard to accurately identify which flag is which.

[CFSworks]

Regarding the ID field, can you check if the extracted ID field matches the number stamped on your meter mod 2^24? This is the case for my meter and the meters on the adjacent houses to mine. I've documented this assumption in the comment on line 36 but it would be good to get further validation.

Hmm... I'm comparing the binary representations of these, and found a possible match:

The number stamped on my meter is an 8-digit number; if I drop the highest digit, then the low 19(?!?) bits of the 7-digit number do match the low 19 bits of your ID field. This suggests a few more bits of flags (at least 5, but possibly more if the highest of those 19 bits are matching only coincidentally for me) and correspondingly fewer bits belonging to ID.

Regarding the flags, my guess (based on far too few observations) is that the byte at offset 3 has flags about the device hardware itself and the byte at offset 7 has status flags for the "Premise Leak Detection", "Cut-Wire Indication", "Reverse Flow Indication", "No Usage Indication" and "Encoder Error" conditions described in the documentation. In my neighbourhood most devices have data[3] == 0 but one device (which looks noticeably different and seems more modern) has one of these bits set. There is more variation in the bits in byte 7. Unfortunately without deliberately triggering a variety of fault conditions it is a little hard to accurately identify which flag is which.

Hah, I might be able to trigger the "premise leak detection" intentionally, but I don't want to commit to doing that. :)

[nickovs]

@CFSworks You might want to try your tests on the device ID field again now that I've fixed a very dumb bug in my code!

[CFSworks]

@CFSworks You might want to try your tests on the device ID field again now that I've fixed a very dumb bug in my code!

Much better now! The ID field matches the low 7 digits of the serial on the label (so, not mod 2^24, but mod 10^7)

[nickovs]

Much better now! The ID field matches the low 7 digits of the serial on the label (so, not mod 2^24, but mod 10^7)

@CFSworks That is interesting. My guess is that the allocation of meter IDs is performed by the utility company that deploys them rather than by Badger, and the utility choose how these get programmed into the meter. I guess that some companies truncate the decimal value to fit it in and some truncate the binary value. I will update the comment in the code to reflect this variation.

[Adminiuga]

My guess is that the allocation of meter IDs is performed by the utility company that deploys them rather than by Badger

Seems so, my meter ID, the one which is indicated on the wire is ReportedMeterID | 0x4000000

Thanks for the PR! Finally can monitor the water usage

[nickovs]

@merbanan @zuckschwerdt Any update on if this could be merged?

[caliKev]

I think I have the frequency hopping version I can’t seem to receive any readings from my badger meter on the 916.45 frequency. Do you have any suggested next steps to pin down the frequency? I’m in an urban area so there is a lot of background.

[mumixam]

@caliKev what's the fccid of yours?

[timelf123]

I have a Badger 100WRD - FCC ID ewq100wd. I'm new to radio - does this spectrum grant mean that the 100WRD could possibly be listening on the same 916.45 freq, or is it more likely that it stayed on 908? I'm not at the location with this meter right now to test

Edit: appears it supports multi-freq. I'll do some more digging later

FCC-1300-mpeWD
ITRON CONFIDENTIAL REV a
Test Data Summary
FCC 15.247 / IC RSS‐210; Frequency Hopping Transmitter;
100W+ – Residential, 903 MHz – 926.85 MHz for EUT

[merbanan]

You can add frequency hopping parameters to rtl_433 command line. You can then add the option to output the frequency in the decoded output and then just let rtl_433 scan the frequency band for a while.

[timelf123]

For later readers, The Badger 100WRD is actually using an Itron radio and is supported already with SCM+. Example:

rtlamr -msgtype=scm+

{"FrameSync": 5795, "ProtocolID": 30, "EndpointType": 171, "EndpointID": FOOBAR, "Consumption": 121964, "Tamper": 18432, "PacketCRC": 53135}

[segdy]

My water company recently installed a new meter. It's a "BadgerMeter Recordall Model 25". I have no idea if this is a smart meter or not (I know previously water company would read the meters manually). Unfortunately water meter is out on the street so I can't easily use a pulse counter or similar.

Any chance this is supported as well?

I have tried

rtl_433 -f 916.45M -s 1200k -R 223

but I don't get any output. Any advice for debug?

[nickovs]

Does the metal cover for the meter have a plastic insert, and if so, does it have an FCC ID stamped into it (or can you find such an ID anywhere else in the meter housing)? If so it's possible to look up the FCC certification and get quite a bit of detail about the transmissions.

[segdy]

Hi Nick, thanks for the reply. No FCC indicator or anything else. Looks like this:

Maybe still not a smart meter?
(I’d be really surprised if they replace the meter but still don’t put a state of the art solution there …)

[mumixam]

@segdy the meter itself does not need to be "smart". they can attach a device to the pipe that is able to calculate flow using ultrasonic 'waves'. that being said it doesn't look like you have one installed unless its outside of the photo. most of the time you'll see a wire that connects to a antenna on the "lid" of the meter enclosure lid

[segdy]

Thanks, so probably no smart meter the …
There is definitely nothing else outside and no cables / antenna. Lid is simply plastic.

One question, slightly OT: I know many meters have a pulse counter. Do you know from how far this can be read out? Does it have to be immediately on top of the meter? Or could it be “hidden” a few centimeters on the side of the meter?

[nickovs]

@segdy That doesn't look like a meter that is remotely readable. For most models of Badger water meter the radio interface that allows remote reading is a separate unit that is attached by a wire and is fitted into the lid that covers the hole where the mechanical water meter is mounted to the pipe.

To answer your later question, at least for Badger, the pulse recorder is connected to the flow meter by a cable, but the radio signal from the recorder can be picked tens of meters away; with a tuned directional antenna pointing straight at it you could probably do even better. The receiver that I have picks up some signal from each of the meters on my block, although with a small, cheap, omnidirectional antenna the more distant ones tend to have rather weak signals. In my town the water company reads the all the meters just by driving slowly down the street in a car with an antenna on the roof.

[caliKev]

Sorry for the long delay. I don’t see an fcc ID. I’m guessing this is lte modem. Is there any way to read it?

[nijhawank]

Any chance to read meter with this? I would also need help on what arguments to run rtl433 with?

https://fccid.io/GIF2014W-OSE
FCC ID GIF2014W-OSE
BADCER METER, INC.
MODEL: ORION ENDPOINT
IC; 1046A-2014VOSE

Thanks in advance.

[jschwalbe]

Greetings! It appears my device (FCC ID GIF2006B) also uses frequency hopping. Hoping to find a way to utilize it. Any ideas?

[nickovs]

@jschwalbe First off, it should be noted that meters with FCC ID GIF2006B can operate in either fixed frequency or hopping mode. It can run continuously on 911.65MHz, 916.45MHz and 921.25MHz, or it can hop on the 25 channels at 400kHz spacing starting with the lowest fixed frequency and running up to the highest fixed frequency (i.e. hops are at 911.65 + n * 0.4 MHz for n in the range 0 to 24). So, before you go down the rabbit hole of trying to deal with frequency hopping you should try listing on each of those frequencies and see if you can pick anything up.

If that fails, you have two option: try to work out the order in which the hops are made, or ignore the issue and only collect 1 in 25 packets. The later option is much simpler, but the unit transmits ever 4 seconds so you'll only have the chance to pick up a reading every 100 seconds, and if you have interference then you'd need to wait another 100 seconds for the next one.

Working out the hopping sequence is not horribly hard, but it's sort of time consuming. The way I'd do it is to write a script that runs the rtl_433 for a while (-T 1000) on each of the 25 channels, only listening for the Badger Orion (-R 223) with the output set to some machine readable format like JSON (-F json) and with the metadata set to include a high resolution time stamp (-M time:unix:usec). You could then analyse the timestamps for the transmissions on each frequency; records on a single frequency will show up with an interval that is a multiple of the total cycle time but the records on the different frequencies will have a different phase. A short Python script of similar should be able to work out the correct order for you.

I hope this helps!

[nijhawank]

Hi @nickovs any help on this meter https://fccid.io/GIF2014W-OSE

I couldn’t find what frequencies I should try listen on

[jschwalbe]

@nickovs Thank you so much for the detailed reply!

I have two units in the basement. One for inside water, and one for outside water.

rtl_433 -f 911.65M -R 223 yielded nothing
rtl_433 -f 916.45M -R 223 yielded two Badgers; updating at 4 sec intervals! (one is certainly mine as the Volumes match, but the other is off: 105323 vs 105238 and not changing despite changing on the physical readout)
rtl_433 -f 921.25M -R 223 yielded nothing

For each time, I gave it a good 3 minutes (and much longer on the middle one). Didn't pick up any others, so that makes me wonder if the update interval is slower than the transmit interval. I'll report back on my findings as I take more readings over time! Thanks again!!

@nijhawank try this command rtl_433 -f 904.9M -R 223. I honestly have no idea if that's going to work, but the FCC page says it transmits 904.9 - 924.5 MHz, so it's a start. Also try replacing 904.9M with 924.5M.

Edit to add: seems like those are the ones; still trying to figure out how long it takes to update. Will keep track over a day or so.

Edit to add again: can confirm that the values only update once an hour. Pretty cool to see! Thanks for the help and hard work!

[mgorbach]

@nickovs I have a badger meter labeled "Orion Cellular LTE" but FCC ID GIF20170CEV5D0M. I am able to see transmissions when running rtl_433 -v -f 916.45M -s 1000000 -X 'n=badger,m=FSK_PWM,short=10,long=10,reset=1000' every couple seconds. However, when I set the preamble as in your script, I no longer get any information decoded. Any idea how I can figure out how to decode this?

[nickovs]

@mgorbach Firstly, given that the device as a cellular interface, do you know if it is going to also transmit in the 915MHz band. Finding a certification number on the device and looking up FCC certification documents would tell you this, even if the rest of the documentation is somewhat opaque.

The way I decoded the data in the first place was to read this [wiki page (https://github.com/merbanan/rtl_433/wiki/Decipher-a-new-device-and-write-a-decoder) and the FCC certification documents and then write some Python code to first visualise the data, followed by some trial and error. I can't really recommend a better option. Given that you seem to already be seeing some data, just printing it as binary and eyeballing it is not a bad place to start.

Looking at your test command line, I note that you didn't disable the other decoders. Just to check, are you seeing output packets that are tagged as badger? Are you seeing any other packets coming in on a similar cadence? If you are getting badger packets and nothing else with a similar timing then you are probably on the right track and it's just going to be a matter of figuring out the preamble.

[Michael55123]

I'm in the same boat @mgorbach did you ever fin da solution? I get this kind of data when I run you above command.
root@notlinux:# rtl_433 -v -f 916.45M -s 1000000 -X 'n=badger,m=FSK_PWM,short=10,long=10,reset=1000'
bash: /usr/bin/rtl_433: No such file or directory
root@notlinux:# /usr/local/bin/rtl_433 -v -f 916.45M -s 1000000 -X 'n=badger,m=FSK_PWM,short=10,long=10,reset=1000'
rtl_433 version 23.11-161-g71bcb5b7 branch master at 202409100934 inputs file rtl_tcp RTL-SDR

New defaults active, use "-Y classic -s 250k" if you need the old defaults

[Protocols] Registered 228 out of 263 device decoding protocols [ 1-4 8 10-12 15-17 19-23 25-26 29-36 38-47 49-60 63 67-71 73-85 87-100 102-105 108-116 119-122 124-128 130-149 151-161 163-168 170-175 177-197 199 201-215 217-232 234-241 243-244 246-247 249-259 261-263
[Input] The internals of input handling changed, read about and report problems on PR #1978
[SDR] Found 1 device(s)
[SDR] trying device 0: Realtek, RTL2838UHIDIR, SN: 00000001
Found Rafael Micro R820T tuner
[SDR] Using device 0: Realtek, RTL2838UHIDIR, SN: 00000001, "Generic RTL2832U OEM"
Exact sample rate is: 1000000.026491 Hz
[R82XX] PLL not locked!
[SDR] Sample rate set to 1000000 S/s.
[Input] Bit detection level set to 0.0 (Auto).
[SDR] Tuner gain set to Auto.
[Input] Reading samples in async mode...
[SDR] Tuned to 916.450MHz.
Allocating 15 zero-copy buffers
[Baseband] low pass filter for 1000000 Hz at cutoff 200000 Hz, 5.0 us

---

time : 2024-09-11 17:01:44
model : badger count : 1 num_rows : 1 rows :
len : 68 data : fffffffffffffffff
codes : {68}fffffffffffffffff

---

time : 2024-09-11 17:01:51
model : badger count : 1 num_rows : 1 rows :
len : 188 data : c0000000000000000000000000000000000000000000000
codes : {188}c0000000000000000000000000000000000000000000000

---

time : 2024-09-11 17:02:01
model : badger count : 1 num_rows : 1 rows :
len : 78 data : fffffffffffffffffffc
codes : {78}fffffffffffffffffffc

---

time : 2024-09-11 17:02:17
model : badger count : 1 num_rows : 1 rows :
len : 64 data : fffffffffffffffe
codes : {64}fffffffffffffffe

---

time : 2024-09-11 17:02:32
model : badger count : 1 num_rows : 1 rows :
len : 805 data : 802080000a0408000000005250242080020012091108802080804204a04044060050a4808122204008a42a1540cd0010002800c402103440400902242020456418402a11488a208820a09a12092800414481580a0a805248100a8841006010801011084088
codes : {805}802080000a0408000000005250242080020012091108802080804204a04044060050a4808122204008a42a1540cd0010002800c402103440400902242020456418402a11488a208820a09a12092800414481580a0a805248100a8841006010801011084088

---

time : 2024-09-11 17:02:34
model : badger count : 1 num_rows : 1 rows :
len : 67 data : ffffffffffffffffe
codes : {67}ffffffffffffffffe

---

time : 2024-09-11 17:02:46
model : badger count : 1 num_rows : 1 rows :
len : 37 data : e000000008
codes : {37}e000000008

---

time : 2024-09-11 17:02:46
model : badger count : 1 num_rows : 1 rows :
len : 401 data : fffffffed5511169cd6bd79f101216858058b5ec31bed080969c0d73aa1f847c59a9942cf2d739c7625aeaaddeb4878e4ed00
codes : {401}fffffffed5511169cd6bd79f101216858058b5ec31bed080969c0d73aa1f847c59a9942cf2d739c7625aeaaddeb4878e4ed00

---

time : 2024-09-11 17:02:46
model : badger count : 1 num_rows : 1 rows :
len : 93 data : fffffff696a3e966c5f7a9c0
codes : {93}fffffff696a3e966c5f7a9c0

---

time : 2024-09-11 17:02:50
model : badger count : 1 num_rows : 1 rows :
len : 79 data : fffffffffffffffffffe
codes : {79}fffffffffffffffffffe

---

time : 2024-09-11 17:03:06
model : badger count : 1 num_rows : 1 rows :
len : 38 data : fffffffffc
codes : {38}fffffffffc

---

time : 2024-09-11 17:03:06
model : badger count : 1 num_rows : 1 rows :
len : 24 data : 7fffff
codes : {24}7fffff

---

time : 2024-09-11 17:03:22
model : badger count : 1 num_rows : 1 rows :
len : 74 data : ffffffffffffffffffc
codes : {74}ffffffffffffffffffc

[baf]

@nijhawank @Michael55123 - just had my meter replaced with a similar model to what you seem to have. Both the old one and new one are Badger branded, but the old one worked fine with the -R 223 decoder whereas the new one (FCC ID GIF2018OCELMDOM) does not. I also see plenty of transmissions on 916.45MHz, but I don’t have the experience to create my own decoder. Did either of you have any luck? @nickovs, would be happy to provide some sample output if you could help update your decoder.