Landis+Gyr GridStream Protocol

Protocol Analysis

Analysis and decoding of the packets used on the Landis+Gyr GridStream mesh network.

Packet Structure

Sync and Header

---

The sync word that the Landis+Gyr smart meters send is shown below, this can be used in GNU Radio or other tools to receive only packets transmitted by the meters. Note that at the start of the header we begin using start and stop bits. These must be stripped off of the rest of the data packet during processing.

Sync and Header

Sync						Header
0xAA	0xAA	0xAA	0xAA	0xAA	0xA	0x00	0xFF	0x2A
10101010	10101010	10101010	10101010	10101010	1010	0 00000000 1	0 11111111 1	0 00101010 1

Using GNU Radio it was found that shortening the Sync requirements a bit and incorporating part of the header leads to the cleanest data for further downstream processing. The modified sync shown in 8 bit chunks is shown below.

Sync Word used with GNURadio

0xAA	0xAA	0xAA	0xAA	0xA0	0x05	0xFF
10101010	10101010	10101010	10101010	10100000	00000101	11111111

The final byte of the sync (0x2A) along with it's start and stop bits are discarded as part of the processing.

---

Type, Length and Sub Type

---

So far only two types of packets have been observed, a 0x55 and a 0xD5 packet. Multiple lengths and SubTypes of these are listed below.

	Type	Length	SubType	Packets Purpose
1	0x55	0x0023	0x30	Report up-time and other unknown data
2	0x55	0x0028	0x30
3	0xD5	0x0011	0x21
4	0xD5	0x0011	0x22
5	0xD5	0x0011	0x29
6	0xD5	0x0016	0x21
8	0xD5	0x0016	0x29
7	0xD5	0x0017	0x21
9	0xD5	0x0017	0x29
10	0xD5	0x001C	0x21
11	0xD5	0x001C	0x29
12	0xD5	0x001D	0x29
13	0xD5	0x0047	0x51
14	0xD5	0x00FD	0xC0

---

Data

---

Data varies per packet type but a common theme is the 0x55 packets appear to be broadcasts from the meters with only their own ID. 0xD5 packets usually contain two ID's and appear to be how data is routed across the network. Sometimes one of the meter ID's in a 0xD5 packet is FFFFFFFF which may be a broadcast packet. This was observed when packets were sent that appear to be updating the system time of the meters.

---

Checksum

---

C++ source code below used to calculate the CRC, different energy providers use a different initial CRC value. Assume this is to segment traffic, unsure if Routers/Collectors are shared by different providers to return traffic or not.

uint16_t Landis_crc16 (uint16_t crc, const std::vector<uint8_t> &data, size_t size) { 
// CoServ CRC = 0x45F8 
// Oncor CRC = 0x5FD6 
// Hard coded Poly 0x1021
    uint16_t i = 0;
    while (size--) {
        crc ^= data[i] << 8; 
        i++; 
        for (unsigned k = 0; k < 8; k++) 
            crc = crc & 0x8000 ? (crc << 1) ^ 0x1021 : crc << 1;
    }
    return crc; 
}

---

Captured Meter Data

There have been two packet types observed thus far, a 0x55 and a 0xD5 packet.

• 0x55 appears to be broadcasts from the meters and happen frequently. They have been observed multiple times per minute from a single meter.

• 0xD5 appears to be a packet for transporting data across the mesh network. Each D5 packet will contain two meter ID's, Meter ID #1 and Meter ID #2. There are many 0xD5 packet length and types that have been observed, some are shown below.

---

0x55 Meter Data

The data below was captured from the same meter (F0EE36DB) and shows some of the values that can change with each transmission. Different meters have different fixed data and some of the data changes less frequently as well.

0x55 Captured packets from Meter F0EE36DB (Oncor)

Pkt	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18
	Not part of CRC calc			Data
	Header	Type	Length	SubType	Unknown	Unknown	Identifier or Meter ID	Unknown	Counter	Uptime	Unknown	Meter ID	Unknown	Unknown	Unknown	Unknown	Checksum	Trailing
1	00FF2A	55	0023	30	FFFFFFFFFFFF	50	CF8DD9E2	C0	0C	0001ECBF	A483	F0EE36DB	0100	213204	384F	7E80	0896	04
2	00FF2A	55	0023	30	FFFFFFFFFFFF	50	CF8DD9E2	C0	16	0001ECC6	A483	F0EE36DB	0100	213204	3AC5	7E80	F47E	04
3	00FF2A	55	0023	30	FFFFFFFFFFFF	50	CF8DD9E2	C0	2A	0001ED05	A483	F0EE36DB	0100	213204	1207	7E80	A412	04
4	00FF2A	55	0023	30	FFFFFFFFFFFF	50	CF8DD9E2	C0	34	0001ED29	A483	F0EE36DB	0100	213204	1FF9	7E80	D9C4	04
5	00FF2A	55	0023	30	FFFFFFFFFFFF	50	CF8DD9E2	C0	38	0001ED37	A483	F0EE36DB	0100	213204	2571	7E80	963C	04
6	00FF2A	55	0023	30	FFFFFFFFFFFF	50	CF8DD9E2	C0	42	0001ED5C	A483	F0EE36DB	0100	213204	33A9	7E80	8384	04
7	00FF2A	55	0023	30	FFFFFFFFFFFF	50	CF8DD9E2	C0	4C	0001ED60	A483	F0EE36DB	0100	213204	354D	7E80	2CB6	04
8	00FF2A	55	0023	30	FFFFFFFFFFFF	50	CF8DD9E2	C0	4E	0001ED79	A483	F0EE36DB	0100	213204	3F25	7E80	871A	04
9	00FF2A	55	0023	30	FFFFFFFFFFFF	50	CF8DD9E2	C0	60	0001EDA6	A483	F0EE36DB	0100	213204	0F05	7E80	25C9	04
10	00FF2A	55	0023	30	FFFFFFFFFFFF	50	CF8DD9E2	C0	6A	0001EDCD	A483	F0EE36DB	0100	213204	1E55	7E80	F33F	04

Commentary on the data fields above, they have been grouped based on sample analysis but this could be wrong. If you see a new pattern not noticed before you may be correct.

• Field 5 - Never observed a packet with this length and subtype that wasn't all FF's

• Field 6 - Have only seen this change when comparing data from different energy providers

• Field 7 - Appears to either be location identifier (Oncor) or duplicate meter ID (Coserv)

• Field 9 - Increments some amount with each transmission and rolls over at 0xFF

• Field 10 - Value in seconds since meter powered on, easy way to see last time the meter experienced a power outage.

• Field 15 - This value counts from near 0 to around 3FFF and rolls over, not sure what it is. Have not been able to correlate the counting value or speed vs time to any sort of power utilization.

0x55 Captured packets from Meter 5021D005 (Coserv)

Pkt	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18
	Not part of CRC calc			Data
	Header	Type	Length	SubType	Unknown	Unknown	Meter ID	Unknown	Counter	Uptime	Unknown	Meter ID	Unknown	Unknown	Unknown	Unknown	Checksum	Trailing
1	00FF2A	55	0023	30	FFFFFFFFFFFF	FE	5021D005	00	7C	0003FB20	A403	5021D005	0100	072001	1E56	7E00	9032	04
2	00FF2A	55	0023	30	FFFFFFFFFFFF	FE	5021D005	00	AE	0003FB9E	A403	5021D005	0100	072001	0DA8	7E00	83E8	04
3	00FF2A	55	0023	30	FFFFFFFFFFFF	FE	5021D005	00	B8	0003FBC1	A403	5021D005	0100	072001	1B54	7E00	2924	04
4	00FF2A	55	0023	30	FFFFFFFFFFFF	FE	5021D005	00	C0	0003FC30	A403	5021D005	0100	072001	052E	7E00	09FC	04
5	00FF2A	55	0023	30	FFFFFFFFFFFF	FE	5021D005	00	EA	0003FC9F	A403	5021D005	0100	072001	3062	7E00	C69A	04
Power restored after an outage
6	00FF2A	55	0023	30	FFFFFFFFFFFF	FE	5021D005	00	06	0000000F	A403	5021D005	01EA	6000FE	26DA	7E30	90CE	04
7	00FF2A	55	0023	30	FFFFFFFFFFFF	FE	5021D005	00	0E	0000000F	A403	5021D005	01EA	6000FE	26EF	7E10	2740	04
8	00FF2A	55	0023	30	FFFFFFFFFFFF	FE	5021D005	00	20	00000011	A403	5021D005	01EA	6000FE	2801	7E90	8B23	04
9	00FF2A	55	0023	30	FFFFFFFFFFFF	FE	5021D005	00	2C	00000013	A403	5021D005	01EA	6000FE	2883	7E60	1A1A	04
10	00FF2A	55	0023	30	FFFFFFFFFFFF	FE	5021D005	00	54	00000017	A403	5021D005	01EA	6000FE	2A72	7E80	E3CD	04

---

0xD5 Meter Data

There appear to be multiple packet lengths and styles for the 0xD5 packet. Some samples shown below.

0xD5 Captured packet

Pkt	1	2	3	4	5	6	7	8	9	10	11	12
	Not part of CRC calc			Data
	Header	Type	Length	SubType	Meter ID #1	Meter ID #2	Unknown	Unknown	Unknown	Unknown	Checksum	Trailing
1	00FF2A	D5	0016	21	F05FCB84	F0FC4DB1	E288	0100	273205	00781930	CB72	00

0xD5 Packets where actual time along with uptime is observed

Pkt	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18
	Not part of CRC calc			Data (Oncor Meter)
	Header	Type	Length	SubType	Meter ID1	Meter ID2	Counter	Epoch Time	Unknown Reading?	Uptime	Unknown	Unknown	OptionalID Meter ID2		Meter ID2	Unknown Data	Checksum	Trailing
1	00FF2A	D5	0047	51	F0C00020	F03B9FFB	18	60378AB1	00033D56	0006C31A	A483	010150	CFB5D9E4	00	F03B9FFB	000103240602030705070704000000 04C2 C000 204C 0401 FA 2030208180 2163 1900	75F3	00
2	00FF2A	D5	0047	51	F10679DE	F03B9FFB	1E	60378C72	00023F96	0006C4DB	A483	010150	CFB5D9E4	00	F03B9FFB	000103240602030705070704000000 0718 6800 204C 0401 FA 2030208180 0BF7 1D30	CDB4	00
3	00FF2A	D5	0047	51	F159CD44	F03B9FFB	B4	603A627C	00028F50	00099AE5	A483	010150	CFB5D9E4	00	F03B9FFB	000103240602020705070805000000 02A3 C800 1E6C 0401 D9 2030208180 226A 1A10	7330	00
Data (CoServ Meter)
4	00FF2A	D5	0047	51	F143250D	5021D005	1A	603AD051	000130D8	000D10ED	A403	0101FE	5021D005	00	5021D005	000103200000000000000000000000 02C3 0800 0E20 0200 E3 20301F8180 22F0 1C40	4FEB	00
5	00FF2A	D5	0047	51	F143248A	5021D005	64	603AD09C	000133C6	000D1138	A403	0101FE	5021D005	00	5021D005	000103200000000000000000000000 0BA0 9000 0E20 0200 E3 20301F8180 4076 1150	73A7	00
6	00FF2A	D5	0047	51	500F0DD6	5021D005	80	603AD0D3	000135EC	000D116F	A403	0101FE	5021D005	00	5021D005	000103200000000000000000000000 01D8 A800 0E20 0200 E3 20301F8180 1412 2E40	ADC1	00

• Epoch time calculator and explanation can be found here, first convert time from hex to decimal then input into converter.

00FF2A D5 0016 21 F073B577 F062363D FA88 0100 1F6C04 14E93E70 CF80 04

00FF2A D5 0017 29 8073AEAC F0F28D56 1288 0100 1F3204 041CBB1930 2D2A 04

00FF2A D5 001B 21 F10679E2 8073CE7D F498 0100 106C02 0A15F9055F06571A80 37C5 00

00FF2A D5 001C 29 8073ADB3 8073CE7D 9088 0100 106C02 040A99CF055F3A4B1170 A696 04

00FF2A D5 0021 22 F05A1A60 8073CE7D D8010100106C020520301D81800A99CF055F3ADD1410 A560 04

00FF2A D5 0047 51 F05A4BCC F03D4CD7 5A6032F37F0001DA2E00022BE9 A483 010150D075D9E2E0 F03D4CD7 000103240403030806080801000000036EE8001F6C0401E9203020818018C22930 9294 00

Data captures

*Note: This file does not contain the trailing bytes shown in the captures above, it stops at the 16 bit Checksum.

Oncor Meter - F03B9FFB - 48 hours capture

Data Requests from SmartMeterTexas (F03B9FFB)

Date	Time	Meter Read	On Demand Energy Usage
03/01/2021	14:31:08	37641.426	79.415
03/01/2021	16:44:40	37648.598	37.441
03/01/2021	22:14:01	37658.906	47.749
03/02/2021	21:17:07	37705.09	44.071
03/02/2021	21:22:58	37705.234	44.215

This table lists Real-time data requests from SmartMeterTexas.com which allows customers to request current meter readings. You will see 0xD5 packets in the data file closely linked to the times above. When the request is made on the website the meter generally responds within 10-15 seconds meaning the system can send a message to the mesh network, traverse across the meters and return fairly quickly.

GPS Tagged Wardrive Files

Format will likely change for the files as more is learned, currently the format is:

Meter_ID, Uptime(seconds), Uptime(days), GPS_Data($GPGGA)

Wardrive-NTX_to_Highland-Park-03-09-2021.csv