-
-
Notifications
You must be signed in to change notification settings - Fork 122
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Can rtl_433_ESP be used/adapted to read smart meters at center frequency ~912MHz (902-928MHz industrail band) similar to rtlamr project #131
Comments
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. |
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. |
These are already in the list of supported protocols in the README:
and 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) |
Cool stuff... and great work figuring this out... 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? |
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. |
That's cool and amazing work! 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!!! |
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?
The text was updated successfully, but these errors were encountered: