Determining CRC always fails

[caiser01]

I'm following the instructions in the wiki to determine the CRC for my meter but reveng always fails with "no models found".

My meter is the Gen 5 shown at the bottom of this page: https://wiki.recessim.com/view/Landis%2BGyr_Residential_Meter

I'm using an RTL-SDR for listening to the meter. The antenna and SDR are placed next to an inside wall at the point nearest to the meter's location on the outside. All the software is running on a Raspberry Pi 4 running Bookworm.

Some raw sample data:

80FF2A55002330EFFFFFFFFFFFFE902482A0001A006D1E05A40B112C82E001001935060C7B7C7031A6
80FF2A55002330FFFFFFFFFFFFFE9024178C001200892C7AA40B9024178C01001635050A5F7E709EC1
80FF2A55002330FFFFFFFFFFFFFE90247AF800EC0087CC06A40B90247AF8010016350503437E704642
80FF2A55002330FFFFFFFFFFFFFE90241B200006008AC0F6A40B90241B20010015350513657E7084C8
80FF2A55002330FFFFFFFFFFFFFE90241B0700D40089654BA40B90241B07010015350506457E70E732
80FF2A55002330FFFFFFFFFFFFFE90241CE500C400896B5CA40B90241CE5010015350506D17E702B87
80FF2A55002330FFFFFFFFFFFFFE90241CE500CC00896B67A40B90241CE501001535050B317E70935F
80FF2A55002330FFFFFFFFFFFFFE9023FA7100520086AA48A40B9023FA710100153505117B7E7087D6

Stripping the first 6 bytes yields:

30EFFFFFFFFFFFFE902482A0001A006D1E05A40B112C82E001001935060C7B7C7031A6
30FFFFFFFFFFFFFE9024178C001200892C7AA40B9024178C01001635050A5F7E709EC1
30FFFFFFFFFFFFFE90247AF800EC0087CC06A40B90247AF8010016350503437E704642
30FFFFFFFFFFFFFE90241B200006008AC0F6A40B90241B20010015350513657E7084C8
30FFFFFFFFFFFFFE90241B0700D40089654BA40B90241B07010015350506457E70E732
30FFFFFFFFFFFFFE90241CE500C400896B5CA40B90241CE5010015350506D17E702B87
30FFFFFFFFFFFFFE90241CE500CC00896B67A40B90241CE501001535050B317E70935F
30FFFFFFFFFFFFFE9023FA7100520086AA48A40B9023FA710100153505117B7E7087D6

My reveng command:
reveng -w 16 -s 30EFFFFFFFFFFFFE902482A0001A006D1E05A40B112C82E001001935060C7B7C7031A6 30FFFFFFFFFFFFFE9024178C001200892C7AA40B9024178C01001635050A5F7E709EC1 30FFFFFFFFFFFFFE90247AF800EC0087CC06A40B90247AF8010016350503437E704642 30FFFFFFFFFFFFFE90241B200006008AC0F6A40B90241B20010015350513657E7084C8 30FFFFFFFFFFFFFE90241B0700D40089654BA40B90241B07010015350506457E70E732 30FFFFFFFFFFFFFE90241CE500C400896B5CA40B90241CE5010015350506D17E702B87 30FFFFFFFFFFFFFE90241CE500CC00896B67A40B90241CE501001535050B317E70935F 30FFFFFFFFFFFFFE9023FA7100520086AA48A40B9023FA710100153505117B7E7087D6

and the result:
reveng: no models found

Am I doing something wrong? Or is there something different about the way my meter is sending data?

[BitBangingBytes]

Sorry for the delayed response, did you ever make any progress on this or still stuck? You seem to be doing everything correct from what I can tell.

[caiser01]

Nope, never made any further progress. I'm still stuck trying to find the CRC with reveng with the same error message.

I've read through the reveng README but this type of reverse engineering is pretty far outside my expertise. I may just have to wait until the tools mature a bit more and "just work".

Besides until/unless the GridStream protocol is reverse-engineered enough to see usage data, it doesn't really help with what I was trying to do (track usage in Home Assistant).

[BitBangingBytes]

For reveng I would only try 3 or 4 packets with it. It’s trying to find a CRC that works for all packets provided, so if one packet has a bit error, it’ll fail to find a CRC that works for all of them. Try picking 3 packets and if you get no result try mixing up by removing one and adding in a different one.

As for power readings, working on sharing instructions more publicly on how to extract and reverse engineer the firmware. So perhaps soonish there will be a breakthrough.

[caiser01]

Thank you for the advice.

It looks as though there was indeed an bit error in one of the packets. After swapping some things around, the following combination got me what looks like a valid result:

reveng -w 16 -s 30FFFFFFFFFFFFFE90241B0700D40089654BA40B90241B07010015350506457E70E732 30FFFFFFFFFFFFFE90241CE500C400896B5CA40B90241CE5010015350506D17E702B87 30FFFFFFFFFFFFFE90241CE500CC00896B67A40B90241CE501001535050B317E70935F 30FFFFFFFFFFFFFE9023FA7100520086AA48A40B9023FA710100153505117B7E7087D6

The output was:
width=16 poly=0x1021 init=0x70a0 refin=false refout=false xorout=0x0000 check=0x1cf1 residue=0x0000 name=(none)

I need to set my RPi and SDR back up now to capture some more packets and test the CRC.

[caiser01]

I put 0x70A0 into the GNU Radio script and turned on 'Validate Checksum' and then ran it. Packets started coming in. I took four random packets out of those and ran reveng on them and got the same result as before. I think I have the correct CRC for my utility company now.

Louisville, KY | LG&E | CRC = 0x70A0

I do however have a new problem. If I try to run:

python SmartMeterGPSDecoder-v1.py 127.0.0.1 52001

I get:

Connected to remote SDR flowgraph

MeterID, upTime(secs), upTime(days rounded), GPSlat, GPSlon, epoch
Connection closed

And it dumps me back to the shell prompt immediately. The GNU Radio script is still running in the background and packets are still coming in when this happens.

Any thoughts on that behavior?

[BitBangingBytes]

Your smart meter network does not incorporate GPS coordinates as part of the WAN address. The telltale sign is the WAN address starting with FE means it's not using GPS coordinates.

30FFFFFFFFFFFF FE90241CE500 C400896B5CA40B 90241CE5 010015350506D17E702B87

You can see the WAN address is FE90241CE500 which contains your LAN address 90241CE5 within it. If you look at the packets for the Oncor network in Dallas you will see the WAN address is completely different from the LAN address.

[caiser01]

Your smart meter network does not incorporate GPS coordinates as part of the WAN address. The telltale sign is the WAN address starting with FE means it's not using GPS coordinates.

Ah, okay. In that case, I guess everything is working as expected.