Changes

8,652 bytes added , 14:08, 3 April 2023

→‎00FF 2A 55 Meter Data: Changed data tags based on discovery using IWR

====Sync and Header====

----The ~~sync word that the~~ Landis+Gyr Gridstream smart meters ~~send is~~ use a 52 bit sync shown below~~, this~~ regardless of Gridstream version. This can be used in GNU Radio ~~or other tools~~ along with the header to ~~receive only~~ uniquely identify 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.

{| class="wikitable"

|+Sync ~~and Header~~52 bits long! colspan="67" |Sync~~! colspan="3" |Header~~

|-

!0xAA

!0xA

~~!0x00~~

~~!0xFF~~

~~!0x2A~~

|-

|10101010

|1010

|}

----Of particular note is the difference between versions 1-4 and version 5. In version 5 there are two bits [11] that do not respect the start/stop bit checks of the prior versions. The older protocol expects a 0 start bit, 8 data bits and a 1 stop bit. By violating two consecutive start bits the older versions of GridStream ignore version 5 even if they have the same CRC Adder! This appears to be a way to add backwards compatibility to newer versions of GridStream.

{| class="wikitable"

|+Header for Gridstream

! colspan="2" |Header v1 - v4

! rowspan="3" |

! colspan="2" |Header v5

|-

!0x00

!0xFF (10 bit)

!0x00

!0xFF (11 bit)

|-

|0 '''00000000''' 1

|0 '''11111111''' 1

|0 '''~~00101010~~00000000''' 1|[11] '''11111111''' 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. These two sync's are both loaded into the '''PDU Align''' block and if either one is matched the full packet is passed downstream.

{| class="wikitable"

|+Sync Word used with GNURadiofor v4

!0xAA

!0x00

!0x5F

!0xF

|-

|10101010

|00000000

|01011111

|1111

|}

{| class="wikitable"

|+Sync Word used with GNURadio for v5

!0xAA

!~~0xA0~~0x00!~~0x05~~0x7F!~~0xFF~~0x1F

|-

|10101010

|~~10101010~~00000000|~~10101010~~01111111|~~10100000|00000101|11111111~~11111

|}

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

----<br />

====~~Type, Length~~ Packet Types and ~~Sub Type~~Structures====----Data is shown in Hexadecimal unless stated otherwise So far only two types of packets have been observed, a 0x55 and a 0xD5 packet. Multiple lengths and SubTypes of these exist, a few are listed below.

{| class="wikitable"

|+

!

!Start of

Frame

!Type

!Sub Type

!Sequence

! colspan="2" |Packets Purpose

|-

!

|00FF

|00

|81 or 85

|1 Byte

| colspan="2" |Report Power Usage (Device Control Word DCW)

|-

!

|00FF

|01

|81 or 85

|1 Byte

| colspan="2" |Report Power Usage (Device Control Word DCW)

|-

!

|00FF

|02

|81 or 85

|1 Byte

| colspan="2" |Report Power Usage (Device Control Word DCW)

|-

!

|00FF

|03

|81 or 85

|1 Byte

| colspan="2" |Report Power Usage (Device Control Word DCW)

|-

!

!Start of

Frame

!Type

!Sub Type

!Length

!~~SubType~~Unknown

!Packets Purpose

|-

!1

|~~0x55~~00FF|~~0x0023~~2A|~~0x30~~55|0023|30

|Report up-time and other unknown data

|-

!2

|~~0x55~~00FF|~~0x0028~~2A|~~0x30~~D5|0047|51|Includes Epoch and Uptime

|-

!3

|~~0xD5~~00FF|~~0x0011~~2A|~~0x21~~D5|00FD|-!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~~C0

|

|}

----

====~~0x55~~ 00FF 2A 55 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.

{| class="wikitable"

0x55 Captured packets from Meter F0EE36DB (Oncor)

! rowspan="3" |Pkt

!0

!1

!2

!15

!16

~~!17~~

~~!18~~

|-

! colspan="34" |Not part of CRC calc! colspan="139" |DataPacket! colspan="23" |Trailing 6 Bytes!

|-

!~~Header~~Start of Frame

!Type

!SubType

!Length

~~!SubType~~

~~!Unknown~~

!Unknown

~~!Identifier or~~

~~Meter ID~~

!Unknown

!WAN Address

!Counter

!Uptime

!Unknown

!~~Meter ID!Unknown~~LAN Address

!Unknown

!Timing

(0.01 increments)

!Unknown

!Checksum

|-

!1

|~~00FF2A~~00FF|2A

|55

|0023

|30

|FFFFFFFFFFFF

|50~~|CF8DD9E2|C0~~50CF8DD9E2C0

|'''0C'''

|'''0001ECBF'''

|-

!2

|~~00FF2A~~00FF|2A

|55

|0023

|30

|FFFFFFFFFFFF

|50~~|CF8DD9E2|C0~~50CF8DD9E2C0

|'''16'''

|'''0001ECC6'''

|-

!3

|~~00FF2A~~00FF|2A

|55

|0023

|30

|FFFFFFFFFFFF

|50~~|CF8DD9E2|C0~~50CF8DD9E2C0

|'''2A'''

|'''0001ED05'''

|-

!4

|~~00FF2A~~00FF|2A

|55

|0023

|30

|FFFFFFFFFFFF

|50~~|CF8DD9E2|C0~~50CF8DD9E2C0

|'''34'''

|'''0001ED29'''

|-

!5

|~~00FF2A~~00FF|2A

|55

|0023

|30

|FFFFFFFFFFFF

|50~~|CF8DD9E2|C0~~50CF8DD9E2C0

|'''38'''

|'''0001ED37'''

|-

!6

|~~00FF2A~~00FF|2A

|55

|0023

|30

|FFFFFFFFFFFF

|50~~|CF8DD9E2|C0~~50CF8DD9E2C0

|'''42'''

|'''0001ED5C'''

|-

!7

|~~00FF2A~~00FF|2A

|55

|0023

|30

|FFFFFFFFFFFF

|50~~|CF8DD9E2|C0~~50CF8DD9E2C0

|'''4C'''

|'''0001ED60'''

|-

!8

|~~00FF2A~~00FF|2A

|55

|0023

|30

|FFFFFFFFFFFF

|50~~|CF8DD9E2|C0~~50CF8DD9E2C0

|'''4E'''

|'''0001ED79'''

|-

!9

|~~00FF2A~~00FF|2A

|55

|0023

|30

|FFFFFFFFFFFF

|50~~|CF8DD9E2|C0~~50CF8DD9E2C0

|'''60'''

|'''0001EDA6'''

|-

!10

|~~00FF2A~~00FF|2A

|55

|0023

|30

|FFFFFFFFFFFF

|50~~|CF8DD9E2|C0~~50CF8DD9E2C0

|'''6A'''

|'''0001EDCD'''

|04

|}

[[File:55 Packet Timing Analysis.png|thumb|600x600px|Field 15 Timing Analysis -Anonymous]]

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 WAN Address - ~~Appears~~ Oncor uses GPS coordinates, CoServ uses LAN with padding of some kind. The open source [https://github.com/beroset/gpsdecode gpsdecode] library shows one way to ~~either be location identifier (Oncor) or duplicate meter ID (Coserv)~~translate between WAN Address and GPS coordinates.

*Field 9 7 - Increments some amount with each transmission and rolls over at 0xFF, always an even hex value

*Field 10 8 - Value in seconds since meter powered on, '''easy way to see last time the meter experienced a power outage.'''*Field 10 - LAN Address, Meter ID that's listed on the sticker on the front

'''*~~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.~~* NEW **'''

'''Field 13''' - Timing in hundredths of a second, counts from 0 to 167.99 (0x419F) seconds then rolls over to 0 again. Credit for this discovery goes to an anonymous reader who examined the dataset at the bottom of the page!!

{| class="wikitable"

|+0x55 Captured packets from Meter 5021D005 (Coserv)

! rowspan="3" |Pkt

!0

!1

!2

!15

!16

~~!17~~

~~!18~~

|-

! colspan="34" |Not part of CRC calc! colspan="139" |DataPacket! colspan="23" |Trailing 6 Bytes!

|-

!~~Header~~Start of Frame

!Type

!SubType

!Length

~~!SubType~~

~~!Unknown~~

!Unknown

~~!Meter ID~~

!Unknown

!WAN Address

!Counter

!Uptime

!Unknown

!~~Meter ID!Unknown~~LAN Address

!Unknown

!Timing

(0.01 increments)

!Unknown

!Checksum

|-

!1

|~~00FF2A~~00FF|2A

|55

|0023

|30

|FFFFFFFFFFFF

|FE~~|5021D005|00~~FE5021D00500

|7C

|'''0003FB20'''

|-

!2

|~~00FF2A~~00FF|2A

|55

|0023

|30

|FFFFFFFFFFFF

|FE~~|5021D005|00~~FE5021D00500

|AE

|'''0003FB9E'''

|-

!3

|~~00FF2A~~00FF|2A

|55

|0023

|30

|FFFFFFFFFFFF

|FE~~|5021D005|00~~FE5021D00500

|B8

|'''0003FBC1'''

|-

!4

|~~00FF2A~~00FF|2A

|55

|0023

|30

|FFFFFFFFFFFF

|FE~~|5021D005|00~~FE5021D00500

|C0

|'''0003FC30'''

|-

!5

|~~00FF2A~~00FF|2A

|55

|0023

|30

|FFFFFFFFFFFF

|FE~~|5021D005|00~~FE5021D00500

|EA

|'''0003FC9F'''

|04

|-

! colspan="1918" |Power restored after an outage

|-

!6

|~~00FF2A~~00FF|2A

|55

|0023

|30

|FFFFFFFFFFFF

|FE~~|5021D005|00~~FE5021D00500

|06

|'''0000000F'''

|-

!7

|~~00FF2A~~00FF|2A

|55

|0023

|30

|FFFFFFFFFFFF

|FE~~|5021D005|00~~FE5021D00500

|0E

|'''0000000F'''

|-

!8

|~~00FF2A~~00FF|2A

|55

|0023

|30

|FFFFFFFFFFFF

|FE~~|5021D005|00~~FE5021D00500

|20

|'''00000011'''

|-

!9

|~~00FF2A~~00FF|2A

|55

|0023

|30

|FFFFFFFFFFFF

|FE~~|5021D005|00~~FE5021D00500

|2C

|'''00000013'''

|-

!10

|~~00FF2A~~00FF|2A

|55

|0023

|30

|FFFFFFFFFFFF

|FE~~|5021D005|00~~FE5021D00500

|54

|'''00000017'''

----

====~~0xD5~~ 00FF 2A D5 Meter Data====There appear to be multiple packet lengths and styles for the 0xD5 packet. Some samples shown below, [https://wiki.recessim.com/w/images/9/9e/D5-Packets-Table-F03B9FFB.txt download as a txt file].

{| class="wikitable"

|+0xD5 Captured ~~packet~~packets

! rowspan="3" |Pkt

!1

!

!2

!3

!6

!7

!colspan="3" |8!9

!10

!

!11

!12colspan="2" |

|-

! colspan="34" |Not part of CRC calc! colspan="79" |CRC'd Data!CRC

! colspan="2" |

|-

!~~Header~~Start of Frame

!Type

!SubType

!Length

~~!SubType~~

~~!Meter ID #1~~

~~!Meter ID #2~~

~~!Unknown~~

!Unknown

!DST Meter

!SRC Meter

!Packet

Counter

! colspan="3" |'''Payload'''

!Timing

(0.01 increments)

!Unknown

!Checksum

!~~Trailing~~colspan="2" |Timestamp

|-

|1

|21

|}

<br />

{| class="wikitable"

|+0xD5 Packets where actual time along with uptime is observed

! rowspan="3" |Pkt

!1

!

!2

!3

!14

!15

!

!16

!17

~~!18~~

|-

! colspan="34" |Not part of CRC calc! colspan="1312" |Data Packet (Oncor Meter)! colspan="23" |Trailing 6 Bytes!

|-

!~~Header~~Start ofFrame

!Type

!SubType

!Length

!~~SubType~~Unknown

!Meter ID1

!Meter ID2

!Unknown

!~~OptionalID~~WAN Address

Meter ID2

!

!Meter ID2

!Unknown Data

!Timing

(0.01 increments)

!Unknown

!Checksum

!Trailing

|-

!1

|~~00FF2A~~00FF|2A

|D5

|0047

|0006C31A

|A483

|~~010150~~0101|~~CFB5D9E4|00~~50CFB5D9E400

|F03B9FFB

|000103240602030705070704000000 04C2 C000 204C 0401 FA 2030208180 |2163 |1900

|75F3

|00

|-

!2

|~~00FF2A~~00FF|2A

|D5

|0047

|0006C4DB

|A483

|~~010150~~0101|~~CFB5D9E4|00~~50CFB5D9E400

|F03B9FFB

|000103240602030705070704000000 0718 6800 204C 0401 FA 2030208180 |0BF7 |1D30

|CDB4

|00

|-

!3

|~~00FF2A~~00FF|2A

|D5

|0047

|00099AE5

|A483

|~~010150~~0101|~~CFB5D9E4|00~~50CFB5D9E400

|F03B9FFB

|000103240602020705070805000000 02A3 C800 1E6C 0401 D9 2030208180 |226A |1A10

|7330

|00

|-

! colspan="185" |~~Data~~ ! colspan="14" |Payload (CoServ Meter)!colspan="2" |

|-

!4

|~~00FF2A~~00FF|2A

|D5

|0047

|000D10ED

|A403

|~~0101FE~~0101|~~5021D005|00~~FE5021D00500

|5021D005

|000103200000000000000000000000 02C3 0800 0E20 0200 E3 20301F8180 |22F0 |1C40

|4FEB

|00

|-

!5

|~~00FF2A~~00FF|2A

|D5

|0047

|000D1138

|A403

|~~0101FE~~0101|~~5021D005|00~~FE5021D00500

|5021D005

|000103200000000000000000000000 0BA0 9000 0E20 0200 E3 20301F8180 |4076 |1150

|73A7

|00

|-

!6

|~~00FF2A~~00FF|2A

|D5

|0047

|000D116F

|A403

|~~0101FE~~0101|FE5021D00500

|5021D005

~~|00|5021D005~~|000103200000000000000000000000 01D8 A800 0E20 0200 E3 20301F8180 |1412 |2E40

|ADC1

|00

===Data captures===

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

====Dallas====[https://wiki.recessim.com/w/images/d9/d39b/~~F03B9FFB~~Oncor_Capture_01-07-2023_30hrs.~~txt~~ zip Oncor ~~Meter~~ Capture 01- ~~F03B9FFB~~ 07- ~~48 hours capture]{| class="wikitable"|+Data Requests from SmartMeterTexas~~ 2023 30hrs (~~F03B9FFB~~CONTAINS NEW PACKETS)]~~!Date!Time~~====Austin====~~!Meter Read!On Demand Energy Usage~~|-~~|03/01/2021|14~~[[:31File:08~~|37641~~Austin energy.~~426~~txt|~~79.415~~Austin energy (Two Meters)]]|-~~|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~~90C3717A is PV~~|37705.09|44.071~~|-~~|03/02/2021|21:22:58|37705.234|44.215~~|}This table lists Real-time data requests from [https://www.smartmetertexas.com/home 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 90C1FD1A is ~~made on the website the~~ Net 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)

[https://wiki.recessim.com/w/images/a/a6/Wardrive-NTX_to_Highland-Park-03-09-2021.csv Wardrive-NTX_to_Highland-Park-03-09-2021.csv] [https://wiki.recessim.com/w/images/2/2b/Dallas-Wardrive-GPS_uptime.zip KML File] used in YouTube [https://youtu.be/Y_sh605Q7oA GPS Decoding video] ===Capture files from various regions===[https://wiki.recessim.com/w/images/7/76/RAW_Capture_NJ.txt.txt Raw capture from New Jersey]<br />[https://wiki.recessim.com/w/images/8/85/Seattle-WA-SCL.txt Raw capture for Seattle City Light (SCL) from Seattle, Washington, USA] <br />

Hash

Bureaucrats, Check users, Interface administrators, Administrators, Writers

1,386

edits

Changes

Landis+Gyr GridStream Protocol (view source)

Revision as of 14:08, 3 April 2023

Navigation menu

Personal tools

Namespaces

Variants

Views

More

Search

Navigation

Categories

Reversing Tools

Resources

Tools