rtl_433
rtl_433 copied to clipboard
merbanan
Add support for Landis+Gyr G5 Integrated FOCUS AXe Power Meter
The power company installed new power meters recently so I decided to embark on yet another rtl_433 project. I've been going it alone for more than a week and decided to have the experts take a stab at it. I've not been able to come up with anything resembling useful data.
FCC ID: R7PEG1R1S6 https://fccid.io/R7PEG1R1S6
I believe mine is using mode 1 (see page 3 of the test report) at 9.6 kbps (104.17 uS per pulse).
Test report: https://fccid.io/R7PEG1R1S6/Test-Report/Test-Report-2789309
If this unit is sending the LAN ID, this should be 0x900F418E as printed on the meter sticker. This has been what I have been searching for to no avail.
Sample: g024_916.15M_250k.cu8.zip
Close (within about 10 seconds) to the time this sample was recorded, my meter was reading 182 kW delivered, 00000 recorded, "KW" 6.336 kW, 245.031 volts, and "IKW" 0.897 kW. I can't get all of the readings at the time of transmission because I have to wait for the meter to scroll through.
Throwing this into bit bench, I've gotten close to the classic sync word of 0xD391 but found 0xD351 and 0xD371 at times. I've been using PCM and short and long = 104 uS in pdv.
GFSK or FSK may be in use according to the information found in the links above.
Bit bench for the above sample: here
There may be two or more packets in one transmission. The above transmission was recorded without an antenna connected. Let me know if different sample rates are needed. I have recorded samples at 1M with worse results. Thanks.
Hi @MidwestTechnologies
Can you try more messages with :
rtl_433 -f 916M -X "n=landis,m=FSK_PCM,s=104,l=104,r=20000" -s 1024k
Progress has been slow these last couple of months. I have analyzed the data and I'm not getting anywhere with it. These meters work in a mesh network and repeat transmissions from other meters. Most of the meters that I have observed have LAN addresses printed on their stickers that begin with 0x900F but I have observed one meter that began with 0x90EE. I believe what I am seeing with some of these packets is the identifier of the origin of the data with the identifier of the repeating station.
All that to say I have not seen any identifiers in the data that come close to looking like something that I have seen on the stickers. If I plug the data into BitBench, shift -2, and reflect, I get a lot of 0x90 but nothing that looks promising.
I am attaching the data that I have been analyzing and hoping that some fresh eyes on it will help. I have sorted these decodes by RSSI and into shorter messages, medium messages, and longer messages. My intention in sorting them by RSSI was trying to pinpoint messages that originate from the same location. You will see common sequences of characters from different transmissions.
Landis Gridstream Sample Decodes.zip
Have you seen this project?https://github.com/BitBangingBytes/gr-smart_meters They seem to have got further with dissecting and decoding the packets for the Gridstream Rf protocol using gnuradio. I'm not sure how easily that would translate into rtl_433.
At a minimum, I would think that the syncwords referenced may be helpful.
https://wiki.recessim.com/view/Landis%2BGyr_GridStream_Protocol
I did look that over a couple of months ago when I got into this. There is a lot of good information there and I was able to take that sync word (or much of it) and apply it to rtl_433. Currently, I am using sync 0xaaaaaaaaaaaaa007ff. I could probably add 0x952a to that sync word because all messages have that in common.
The trouble is, I don't see the LAN IDs for the two meters on my property in any of the data. I even tried the GPS algorithm found on Recessim and could not get a solution that contained my coordinates or coordinates that are even close to me. The rest of the data in my decodes don't really match up well to the Recessim formats.
I expect at least some of these packets to contain the ID and power consumption at a minimum. Some likely contain repeated data with the ID of the station that is being repeated and its consumption since this is a mesh network.
I would much rather use rtl_433 to do this because it allows me to decode many different sensors on one SDR. I will need to run rtl_433 with one radio and the Recessim package with another radio otherwise.
Thanks for your help.
I would also rather use rtl_433 instead of gnuradio, but I'm still trying to work out parity between the recessim package and the output from rtl_433. Can you share what are using as a flex decoder?
@MidwestTechnologies can we get access to more signal recordings? And try with some other sample rates also. From the spreadsheet file it looks like the demodulation is unstable because the amount of bits are varying (209-213).
One more thing, the signal is slightly clipped. Adjusting the gain should result in a more clear demodulated signal. Maybe that will be enough to recover the bits properly.
@krvmk certainly...here is the complete command I used including the flex...
rtl_433 -d 1 -f 914.915M -s 1024k -M level -Y minmax -F csv:log_landis.csv -X "name=landis,m=FSK_PCM,s=104,l=104,r=20000,tolerance=4,preamble={72}0xaaaaaaaaaaaaa007ff" -R -149 -F kv
Again, I should have added 0x952a to the end of sync above. LAN IDs in my neighborhood all so far begin with 0x90 and should be 4 bytes long (i.e. 90xxxxxx) according to the meter sticker. There is a second nine digit ID, specific to the power company, on the sticker. None of my decodes match these numbers, either.
@merbanan I can get you more samples but, in addition to 1024k, I have tried 250k, 1000k, and 1200k. I still saw the variance that you mentioned. I tried 1400k and 2400k as well and rtl_433 was no longer able to decode. If you have any suggested sample rates, please let me know.
Thank you all for your guidance.
@merbanan Just now saw you comment on gain. I tried without any antenna hooked up as one of these Landis meters is only 20 feet from my radio. I also tried a 10 dB attenuator in line with my outdoor antenna. With the attenuator, I still got variance in the decodes. Without the antenna connected, I got no decodes in a couple of hours. I think one thing I could have done differently is let rtl_433 run longer without the antenna. I'm not sure how often these meters transmit and it could take time to hear my meter on the frequency I'm monitoring. Any suggestions are appreciated.
Since the Landis meters use FHSS, I use the max sample rate for the rtl-sdr of 2560k. I've had good luck seeing signals around 904M instead of 915M for my personal meter, since the rate is relatively narrow compared to the 902-928 frequency range of the meter. You would need a 13000k sample rate to cover the whole spectrum.
The bandwidth and sample rate is 1to1ish on the rtl-sdr. So too high sample rate and the band is so wide that we get in disturbances. Anyway @MidwestTechnologies I guess that you could try with 1000k and 1200k then. Regarding FHSS we should eventually see some signals around the observed band. The demodulator can not handle to too many strong signals at the same time.
Anyway if you run the following: rtl_433 -Y minmax -s 1024k -r signals/LFG/g002_916M_1024k.cu8 -W test.sr we can see that the signal is almost completely framed. It looks like we are loosing like 5 bits at the end.
But the pulse recovery is riddled with short pulses (lets call them tiny pulses).
If we add -vvvv we get the pulse table output that is used for bit recovery.
Pulse data: 185 pulses [ 0] Pulse: 0, Gap: 6, Period: 6 [ 1] Pulse: 1, Gap: 1, Period: 2 [ 2] Pulse: 2, Gap: 1, Period: 3 [ 3] Pulse: 1, Gap: 1, Period: 2 [ 4] Pulse: 2, Gap: 1, Period: 3 [ 5] Pulse: 2, Gap: 1, Period: 3 [ 6] Pulse: 1, Gap: 2, Period: 3 [ 7] Pulse: 1, Gap: 1, Period: 2 [ 8] Pulse: 2, Gap: 4, Period: 6 [ 9] Pulse: 1, Gap: 2, Period: 3 [ 10] Pulse: 1, Gap: 1, Period: 2 [ 11] Pulse: 1, Gap: 1, Period: 2 [ 12] Pulse: 2, Gap: 6, Period: 8 [ 13] Pulse: 2, Gap: 1, Period: 3 [ 14] Pulse: 2, Gap: 3, Period: 5 [ 15] Pulse: 2, Gap: 2, Period: 4 [ 16] Pulse: 1, Gap: 1, Period: 2 [ 17] Pulse: 1, Gap: 1, Period: 2 [ 18] Pulse: 2, Gap: 1, Period: 3 [ 19] Pulse: 2, Gap: 1, Period: 3 [ 20] Pulse: 1, Gap: 1, Period: 2 [ 21] Pulse: 2, Gap: 1, Period: 3 [ 22] Pulse: 2, Gap: 4, Period: 6 [ 23] Pulse: 1, Gap: 1, Period: 2 [ 24] Pulse: 2, Gap: 3, Period: 5 [ 25] Pulse: 2, Gap: 1, Period: 3 [ 26] Pulse: 4, Gap: 2, Period: 6 [ 27] Pulse: 1, Gap: 4, Period: 5 [ 28] Pulse: 1, Gap: 2, Period: 3 [ 29] Pulse: 1, Gap: 1, Period: 2 [ 30] Pulse: 4, Gap: 1, Period: 5 [ 31] Pulse: 218, Gap: 105, Period: 323 [ 32] Pulse: 1, Gap: 1, Period: 2 [ 33] Pulse: 107, Gap: 104, Period: 211 [ 34] Pulse: 108, Gap: 1, Period: 109 [ 35] Pulse: 1, Gap: 103, Period: 104 [ 36] Pulse: 1, Gap: 1, Period: 2 [ 37] Pulse: 108, Gap: 103, Period: 211 [ 38] Pulse: 1, Gap: 1, Period: 2 [ 39] Pulse: 108, Gap: 107, Period: 215 [ 40] Pulse: 106, Gap: 105, Period: 211 [ 41] Pulse: 1, Gap: 1, Period: 2 [ 42] Pulse: 106, Gap: 39, Period: 145 [ 43] Pulse: 1, Gap: 65, Period: 66 [ 44] Pulse: 108, Gap: 107, Period: 215 [ 45] Pulse: 106, Gap: 107, Period: 213 [ 46] Pulse: 106, Gap: 108, Period: 214 [ 47] Pulse: 105, Gap: 108, Period: 213 [ 48] Pulse: 85, Gap: 1, Period: 86 [ 49] Pulse: 19, Gap: 108, Period: 127 [ 50] Pulse: 107, Gap: 107, Period: 214 [ 51] Pulse: 106, Gap: 107, Period: 213 [ 52] Pulse: 106, Gap: 107, Period: 213 [ 53] Pulse: 106, Gap: 107, Period: 213 [ 54] Pulse: 106, Gap: 105, Period: 211 [ 55] Pulse: 1, Gap: 1, Period: 2 [ 56] Pulse: 108, Gap: 105, Period: 213 [ 57] Pulse: 108, Gap: 105, Period: 213 [ 58] Pulse: 106, Gap: 108, Period: 214 [ 59] Pulse: 107, Gap: 106, Period: 213 [ 60] Pulse: 107, Gap: 106, Period: 213 [ 61] Pulse: 107, Gap: 109, Period: 216 [ 62] Pulse: 104, Gap: 1, Period: 105 [ 63] Pulse: 2, Gap: 104, Period: 106 [ 64] Pulse: 106, Gap: 1, Period: 107 [ 65] Pulse: 2, Gap: 104, Period: 106 [ 66] Pulse: 2, Gap: 1, Period: 3 [ 67] Pulse: 106, Gap: 414, Period: 520 [ 68] Pulse: 1, Gap: 650, Period: 651 [ 69] Pulse: 1280, Gap: 213, Period: 1493 [ 70] Pulse: 2, Gap: 1, Period: 3 [ 71] Pulse: 103, Gap: 1, Period: 104 [ 72] Pulse: 1, Gap: 108, Period: 109 [ 73] Pulse: 103, Gap: 109, Period: 212 [ 74] Pulse: 107, Gap: 213, Period: 320 [ 75] Pulse: 106, Gap: 107, Period: 213 [ 76] Pulse: 106, Gap: 107, Period: 213 [ 77] Pulse: 106, Gap: 2, Period: 108 [ 78] Pulse: 1, Gap: 104, Period: 105 [ 79] Pulse: 106, Gap: 1, Period: 107 [ 80] Pulse: 2, Gap: 104, Period: 106 [ 81] Pulse: 106, Gap: 1, Period: 107 [ 82] Pulse: 2, Gap: 105, Period: 107 [ 83] Pulse: 107, Gap: 745, Period: 852 [ 84] Pulse: 1, Gap: 212, Period: 213 [ 85] Pulse: 110, Gap: 103, Period: 213 [ 86] Pulse: 1, Gap: 1, Period: 2 [ 87] Pulse: 214, Gap: 319, Period: 533 [ 88] Pulse: 107, Gap: 212, Period: 319 [ 89] Pulse: 1, Gap: 1, Period: 2 [ 90] Pulse: 107, Gap: 530, Period: 637 [ 91] Pulse: 1, Gap: 2, Period: 3 [ 92] Pulse: 213, Gap: 214, Period: 427 [ 93] Pulse: 103, Gap: 2, Period: 105 [ 94] Pulse: 1, Gap: 107, Period: 108 [ 95] Pulse: 958, Gap: 108, Period: 1066 [ 96] Pulse: 424, Gap: 1, Period: 425 [ 97] Pulse: 536, Gap: 106, Period: 642 [ 98] Pulse: 959, Gap: 106, Period: 1065 [ 99] Pulse: 962, Gap: 105, Period: 1067 [100] Pulse: 1, Gap: 1, Period: 2 [101] Pulse: 960, Gap: 106, Period: 1066 [102] Pulse: 959, Gap: 79, Period: 1038 [103] Pulse: 1, Gap: 63, Period: 64 [104] Pulse: 1, Gap: 70, Period: 71 [105] Pulse: 853, Gap: 534, Period: 1387 [106] Pulse: 105, Gap: 215, Period: 320 [107] Pulse: 211, Gap: 1, Period: 212 [108] Pulse: 2, Gap: 105, Period: 107 [109] Pulse: 427, Gap: 427, Period: 854 [110] Pulse: 108, Gap: 211, Period: 319 [111] Pulse: 109, Gap: 426, Period: 535 [112] Pulse: 106, Gap: 107, Period: 213 [113] Pulse: 107, Gap: 319, Period: 426 [114] Pulse: 107, Gap: 428, Period: 535 [115] Pulse: 69, Gap: 1, Period: 70 [116] Pulse: 142, Gap: 175, Period: 317 [117] Pulse: 1, Gap: 784, Period: 785 [118] Pulse: 105, Gap: 1, Period: 106 [119] Pulse: 1, Gap: 319, Period: 320 [120] Pulse: 323, Gap: 10, Period: 333 [121] Pulse: 1, Gap: 305, Period: 306 [122] Pulse: 1, Gap: 1, Period: 2 [123] Pulse: 105, Gap: 960, Period: 1065 [124] Pulse: 109, Gap: 212, Period: 321 [125] Pulse: 319, Gap: 1, Period: 320 [126] Pulse: 2, Gap: 422, Period: 424 [127] Pulse: 1, Gap: 2, Period: 3 [128] Pulse: 107, Gap: 148, Period: 255 [129] Pulse: 1, Gap: 63, Period: 64 [130] Pulse: 107, Gap: 106, Period: 213 [131] Pulse: 109, Gap: 106, Period: 215 [132] Pulse: 213, Gap: 106, Period: 319 [133] Pulse: 108, Gap: 105, Period: 213 [134] Pulse: 215, Gap: 213, Period: 428 [135] Pulse: 106, Gap: 321, Period: 427 [136] Pulse: 105, Gap: 320, Period: 425 [137] Pulse: 108, Gap: 214, Period: 322 [138] Pulse: 106, Gap: 107, Period: 213 [139] Pulse: 212, Gap: 2, Period: 214 [140] Pulse: 1, Gap: 105, Period: 106 [141] Pulse: 213, Gap: 106, Period: 319 [142] Pulse: 107, Gap: 195, Period: 302 [143] Pulse: 1, Gap: 230, Period: 231 [144] Pulse: 109, Gap: 532, Period: 641 [145] Pulse: 107, Gap: 212, Period: 319 [146] Pulse: 215, Gap: 106, Period: 321 [147] Pulse: 426, Gap: 427, Period: 853 [148] Pulse: 106, Gap: 214, Period: 320 [149] Pulse: 108, Gap: 425, Period: 533 [150] Pulse: 106, Gap: 109, Period: 215 [151] Pulse: 105, Gap: 321, Period: 426 [152] Pulse: 1, Gap: 1, Period: 2 [153] Pulse: 103, Gap: 428, Period: 531 [154] Pulse: 214, Gap: 105, Period: 319 [155] Pulse: 108, Gap: 746, Period: 854 [156] Pulse: 108, Gap: 959, Period: 1067 [157] Pulse: 107, Gap: 104, Period: 211 [158] Pulse: 1, Gap: 1, Period: 2 [159] Pulse: 108, Gap: 318, Period: 426 [160] Pulse: 108, Gap: 319, Period: 427 [161] Pulse: 107, Gap: 18, Period: 125 [162] Pulse: 1, Gap: 406, Period: 407 [163] Pulse: 1, Gap: 1, Period: 2 [164] Pulse: 107, Gap: 168, Period: 275 [165] Pulse: 1, Gap: 256, Period: 257 [166] Pulse: 107, Gap: 320, Period: 427 [167] Pulse: 106, Gap: 535, Period: 641 [168] Pulse: 1, Gap: 1, Period: 2 [169] Pulse: 103, Gap: 2, Period: 105 [170] Pulse: 1, Gap: 533, Period: 534 [171] Pulse: 105, Gap: 321, Period: 426 [172] Pulse: 106, Gap: 108, Period: 214 [173] Pulse: 107, Gap: 211, Period: 318 [174] Pulse: 108, Gap: 105, Period: 213 [175] Pulse: 108, Gap: 106, Period: 214 [176] Pulse: 214, Gap: 212, Period: 426 [177] Pulse: 642, Gap: 105, Period: 747 [178] Pulse: 108, Gap: 533, Period: 641 [179] Pulse: 320, Gap: 106, Period: 426 [180] Pulse: 108, Gap: 425, Period: 533 [181] Pulse: 321, Gap: 214, Period: 535 [182] Pulse: 104, Gap: 109, Period: 213 [183] Pulse: 105, Gap: 108, Period: 213 [184] Pulse: 213, Gap: 215, Period: 428
Here we can see pulses and gaps with a low length. These will trip up bit recovery.
Either we get a cleaner signal or we manipulate the pulse table and do a pulse merge when we get the tiny pulses. Maybe @zuckschwerdt can elaborate if it would be feasible to dynamically per r_device merge pulses and gaps shorter then lets say 10% of device->short_width. That should help with noisy signals and signals with a low bandwidth.
I have a capture of a good signal from rtl_433 and using the gnuradio package, I know what the output should be. However I captured it at the higher sample rate and can see the signal on triq. Above and below about 600k I can see what I would assume is harmonics. Is there a decimate feature that I can give it to isolate 2560k down to 1000k if I give it the frequency?
We don't have such a tool (shift, decimate). But perhaps you could build it with gnuradio?
I wasn't able to get far with gnuradio as I'm not that familiar. I could decimate them, but they ended up looking really noisy after, so obviously I was missing something in the config.
I was able to get some new clean samples at 250k sample rate, and getting a little closer to matching what gnuradio is able to decode. There are 3 in the zip, and the txt files are the output from the decoder in gnuradio. I was able to get the first part to match up in pdv, but it seemed to get out of sync. When I used the same settings in rtl_433, it wasn't matching up for some reason.
This sample is clean and we can use the flex decoder to pick up the sync words.
build/src/rtl_433 -Y minmax -s 250k -r g00*_904.4M_250k.cu8 -X "name=landis,m=FSK_PCM,s=104,l=104,r=20000,tolerance=10,preamble={28}0xaaaa005"
{278}ff2a557005d14a403374575c4037f48956d0104cc10047b055b7224516d45100d45084
{279}ff2a55005d14a403375431ec037f48956dc704cc10044705543725517d571054bb494
{278}ff2a557005d14a403375852f4037f48956dd104cc10050705581364a1784b10050f594
I checked the bits and at least one file matched up. This does not match gr-smart meters though. There is a code block called deframer: https://github.com/BitBangingBytes/gr-smart_meters/blob/maint-3.10/lib/Deframer_impl.cc#L100 and the wiki mentions start and stop bits.
If we take ff2a557005d14a40337 we get the following bits:
111 1111 1
0 0101 0100 1 [54] bit reverse [2A]
0 1010 1011 1 [AB] ~ [D5]
0 0000 0000 1 [00] ~ [00]
0 1110 1000 1 [E8] ~ [17]
0 1001 0100 1 [94]
0 0000 0001 1 [01]
0 0110 111
The starting 0 bit and ending 1 bit holds for this section and probably the rest. And matching against the wiki we start with 2A and then D5. After that we have the length in 2 bytes. 0x17 is 23 and 23*10 + CRC and some headers could be around 278 bits.
So this info should now be implemented into a decoder.
I can confirm @merbanan that using the 0 start bit and 1 stop bit, I am now able to decode one of my meter's IDs. I used one of my saved decodes and manually deleted the start and stop bits then reflected the 8 bits in between. I need to see if I can pull more data out.
I was hoping that decode_uart would handle the 8N1 decoding with the flex decoder, but it doesn't seem to work like I thought it would.
Works for me:
rtl_433 -Y minmax -s 250k -r signals/LFG/g00*_904.4M_250k.cu8 -X "name=landis,m=FSK_PCM,s=104,l=104,r=20000,tolerance=10,decode_uart,preamble={36}0xaaaa005ff"
And the decoded data matches the supplied files.
Mine is working off the radio with the following: rtl_433 -d 1 -f 904.4M -R -149 -Y minmax -s 1000k -M level -F csv:log_landis_new.csv -F kv -X "name=landis,m=FSK_PCM,s=104,l=104,r=20000,tolerance=10,decode_uart,preamble={72}0x555555555555400fff"
Mine is working live now. I think I had messed up the preamble. It doesn't seem like it is picking up the signal as easily as gnuradio.
I have a similar, but not the same meter. My meter label says Focus RXR. However the FCC ID: R7PEG1R1S2 says Landis+Gyr Technology, Inc. Gridstream RF Enhanced Integrated Focus AX Meter EG1R1S2 - https://fccid.io/R7PEG1R1S2.
The FCC ID of your meter is ..S6 rather than ...S2. My utility is PSEGLINY. I'm in Long Island, NY, USA.
I haven't tried to receive anything from it yet because I wasn't sure where to start. Also I was hoping some day the utility would have a way to get the built in Zigbee radio enabled.
If it helps, I can capture and contribute signals. Any recommendations for capturing signals welcome. How often does it transmit? How long does it take to frequency hop through it's range and come back to the same frequency?
I believe the Gridstream protocol is fairly standard across the Landis+Gyr meter line, with some variations with v4 vs v5. Based on what I have captured thus far, the meters will often broadcast updates simultaneously on multiple frequencies in the 902-928 MHz range, so tuning anywhere in that range for long enough should be sufficient.
While rtl_433 is able to convert the bits into a datastream, I've not seen any indicators of how to decode the power usage that it is sending up to the provider.
Well we need a proper decoder based on the information from here: https://wiki.recessim.com/view/Landis%2BGyr_GridStream_Protocol and then we need to analyse the unknown fields.
Before that happens it would be of interest to test some sample rates to see what settings give more received messages.
If people can supply flex rows and create a bitbench that would be good also.
The hardest part I had in getting it initially decoding with gnuradio was finding the right value for the CRC check, since it seems like bad signal is fairly common with a frequency hopping mesh network like they use. Each provider uses their own code, and I used this https://wiki.recessim.com/view/Gr-smart_meters_Setup_Guide#Determining_your_power_providers_CRC to find mine. I had several dozen codes initially captured that apparently had bad data, as the tool was not able to find a match. Once I got enough good packets and found the CRC init value, I could at least validate the data was not corrupted.
Since that value will vary, can that be passed to a proper decoder somehow? Or would it be a matter that it would have to figure it out on its own after seeing X amount of packets captured?
I believe the Gridstream protocol is fairly standard across the Landis+Gyr meter line, with some variations with v4 vs v5.
On the face, my meter says Model 40-1565 Series IV so maybe v4?
Based on what I have captured thus far, the meters will often broadcast updates simultaneously on multiple frequencies in the 902-928 MHz range, so tuning anywhere in that range for long enough should be sufficient.
So how long is "long enough" -- do I need to wait some number of minutes or hours before deciding to try something else?
Thanks
I usually get something after 5-10 minutes or so, but it is hard to tell for certain how much is coming from my meter vs the neighborhood. Since it is a mesh, all the meters will relay traffic between each other to get back to the company.
I've been sitting on 904.4 MHz for some time now. My meter IDs show up about once every half hour average. That may not be typical of every situation. However, I am getting my neighbors' meters about once every 5 minutes or so. I had to turn my gain down quite a lot to get good decodes at 1000k sample rate.