Can rtl_433_ESP be used/adapted to read smart meters at center frequency ~912MHz (902-928MHz industrail band) similar to rtlamr project

[puterboy]

Current Situation

Will rtl_433_ESP work (or can it be adapted) to decode smart meter messages on the ~912MHz frequency range?
This can be done on Windows/Linux using rlt_sdr dongles with the rtlamr software https://github.com/bemasher/rtlamr.
It would be great to do this on an esp32 rather than having to use a "bigger" separate PC/RPi device.

Proposed Change

Add rltamr support to rtl_433_ESP

Additional Context

Assuming it is possible, do you think the LilyGo LoRa32 V2.1_1.6 dev board with 915MHz crystal [Q211 or maybe Q212] would work?

[NorthernMan54]

This from my 915Mhz Lilygo board ( I'm not sure if its a Q211 or Q212, but I don't think it makes a difference, as the difference appears to be just the prepackaged firmware ). So 912Mhz should be supported

The challenging part here would be the signal decoder, as rtlamr is written in GO and it would need to rewritten in C to support the ESP32 chip. Which is a massive task. With the rtl_433 port it was pretty straightforward as it is written in C already. Personally I think you should just get a RPI 4/5 with the rtl_sdr dongle and use that.

[puterboy]

The challenging part here would be the signal decoder, as rtlamr is written in GO and it would need to rewritten in C to support the ESP32 chip. Which is a massive task. With the rtl_433 port it was pretty straightforward as it is written in C already. Personally I think you should just get a RPI 4/5 with the rtl_sdr dongle and use that.

This is how I am doing it now but I was hoping to streamline things and reduce size/power consumption/complexity by just using an esp32 board.
BTW, I now have the rtl_433 working great on my lilygo board and it's awesome so far...

[Entropy512]

These are already in the list of supported protocols in the README:

Registering protocol [44] "ERT Interval Data Message (IDM)"
Registering protocol [45] "ERT Interval Data Message (IDM) for Net Meters"
Registering protocol [46] "ERT Standard Consumption Message (SCM)"

and
Registering protocol [92] "Neptune R900 flow meters"

Edit: The challenge here might be that the various AMR meters are spread spectrum systems that hop channels - while the author hasn't confirmed it, rtlamr appears to rely on a very high sampling rate not just to have many samples per symbol, but also to be able to capture multiple channels at once. Since the modulation is OOK, all rtlamr appears to do is decide "was there energy anywhere in my sampling bandwidth" to allow simultaneously monitoring a pile of channels at once.

per https://fccid.io/P2SNTGECDR900D/Test-Report/TEST-REPORT-897476.pdf the channel spacing was measured at 131.6 kHz - I suspect it's really 131.072 as that's exactly 4x the data rate. Looks like one of the channels is almost exactly 911.1 MHz

Edit: After running rtl_433 a bit with the -M level command and the sample rate cranked up to match what rtlamr uses, it's 125 kHz channel spacing, and approximately 11 minutes 40 seconds for a complete hop cycle (e.g. after 11m40s it'll return to a frequency and the sequence of frequencies starts repeating)

[puterboy]

Cool stuff... and great work figuring this out...
Are you saying that you were able to read an AMR meter using rlt_433_ESP?
Were you restricted to just a single frequency vs. the ability of rtl_tcp + rtlamr to capture about a 2MHz band of channels?

So, in the end do you think it's possible to use rtl_433_ESP to read my meters or will I get better reliability an update frequency just using an rtl-sdr dongle with rtlamr software?

[Entropy512]

Yup. I've successfully read a Neptune R900 water meter. My electric meter is one of the super-new encrypted mesh network unfortunately. I've got some ugly proof-of-concept code at https://github.com/Entropy512/r900_esphome that has horrible documentation and relies on some patches to this codebase. At some point in the next month or two I'll clean things up and submit PRs here to remove some hardcoded stuff and replace it with configurable items.

In my case, even when dwelling on a single channel, the R900 repeats its hop cycle every 11 minutes 40 seconds. It only updates its actual data every 15 minutes - so receiving more often by trying to follow the hopping has no benefit in my case. I've reverse engineered my meter's hop sequence, but other meters may hop differently - their documentation implies that they do.

[puterboy]

That's cool and amazing work!
Looking forward to trying out your cleaned up code when it is ready.
In my case, I am concerned that I may lose some "resolution" in the time series consumption data since currently using an rtl-sdr and rtlamr, I get the R900 data pretty much as soon as it changes. Using rtl_433 while I might not lose any of the new data since it's only published once every 15 minutes, the time resolution for when that data is recorded would not be uniform. Plus, given reception issues, it's not infrequent that even with an rtl_sdr, I miss an occasional broadcast so if it repeats only every 11min40sec, missing one or two broadcasts could cause one to miss an entire 15 min update.
And since I am trying to correlate consumption with usage (e.g., showers, laundry, dishwasher, lawn watering), I want every bit of resolution that I can get.

Also, I would be concerned about my electric meter where due to interference, I miss a lot of broadcasts.

Still really cool and worth playing with!!!
Thanks.