Elster Power Meter

[gcormier]

trafficstars

Someone has done quite a bit of work in GNU Radio to decode the packets from Elster power meters I'm no GNU Radio expert, but if I provide the sample captures would anyone be willing to write the decoder?

[zuckschwerdt]

I don't expect the actual coding to be a problem. Can we get information on the protocol? There is something about frequency-hopping in there? Is that part of the protocol or just "alternative settings" to reduce device overlap?

[zuckschwerdt]

I take it that https://github.com/argilo/gr-elster/blob/master/python/packetize.py has the main logic part. Doesn't look to involved.

[gcormier]

Ok great. I picked up a LimeSDR mini, so I will do some wide band captures to see if it's actually hopping, or if it just repeats it across a few.

[gcormier]

I looked up the FCC information on this one. It looks like the device is dumb, and it meets compliance merely by rotating through the 25 channels (https://fccid.io/QZC-R2EA/Test-Report/Test-Report-880526)

If I'm reading this correct the channels are ~397kHz apart. With 25 channels that's only one half of 902-928MHz. Pages 22-24 of the FCC doc talk about channels 0 through 63. So I'm not clear on what's going on.

I'll run a capture overnight on 902.40MHz. rtl_433 -f 902.4M -d "" -g "" -s 1M -S unknown

[gcormier]

Found this tidbit on reddit as well,

.. they are FSK modulated, 400khz channel spacing over 25 channels at either 35.5kbps or 142.2kbps data rate.

[gcormier]

I got around 900 packets overnight.

If we assume the above note is accurate on rates, we're looking for 28us or 7us pulses, which I don't see (except for three with a single 28us packet) from running rtl_433 -r * and grep'ing the output.

I could use some help on how to proceed.

(One of three useless single count 28us..)

Detected FSK package	@0.131516s
Analyzing pulses...
Total count:   30,  width: 5.27 ms		( 1318 S)
Pulse width distribution:
 [ 0] count:   24,  width:   40 us [40;48]	(  10 S)
 [ 1] count:    1,  width:  244 us [244;244]	(  61 S)
 [ 2] count:    2,  width:   84 us [80;88]	(  21 S)
 [ 3] count:    2,  width:  168 us [168;172]	(  42 S)
 [ 4] count:    1,  width:   28 us [28;28]	(   7 S)
Gap width distribution:
 [ 0] count:    2,  width:  660 us [616;704]	( 165 S)
 [ 1] count:   15,  width:   40 us [40;44]	(  10 S)
 [ 2] count:    4,  width:   76 us [76;88]	(  19 S)
 [ 3] count:    5,  width:  120 us [120;132]	(  30 S)
 [ 4] count:    2,  width:  204 us [204;204]	(  51 S)
 [ 5] count:    1,  width:  160 us [160;160]	(  40 S)
Pulse period distribution:
 [ 0] count:    2,  width:  704 us [664;748]	( 176 S)
 [ 1] count:   15,  width:   80 us [80;84]	(  20 S)
 [ 2] count:    3,  width:  332 us [292;376]	(  83 S)
 [ 3] count:    4,  width:  220 us [208;252]	(  55 S)
 [ 4] count:    3,  width:  120 us [120;124]	(  30 S)
 [ 5] count:    2,  width:  168 us [168;168]	(  42 S)
Level estimates [high, low]:   2050,    181
RSSI: -18.1 dB SNR: 21.1 dB Noise: -39.1 dB
Frequency offsets [F1, F2]:   -5282, -14762	(-20.1 kHz, -56.3 kHz)
Guessing modulation: No clue...

[georgejung]

I'm interested in this. I just got my RTL-SDR yesterday and have found my water meter. Next is my electric meter which is an Elster R2S. Any updates?

[argilo]

I'm guessing that rtl_433 might not be a great way to receive these signals due to the frequency hopping; my understanding is that rtl_433 receives a single frequency, and so it would only catch 1 out of every 25 Elster packets. (Please correct me if that's not the case!)

https://github.com/argilo/gr-elster should be able to receive R2S meters. You can receive 6 channels with an RTL-SDR, or the full 25 channels with a HackRF (or other wide-band SDR). Please note that packet disassembly is incomplete, since I've only reverse engineered part of the protocol.

I take it that https://github.com/argilo/gr-elster/blob/master/python/packetize.py has the main logic part. Doesn't look to involved.

It does, but the packet dissection in that file is very incomplete (it only attempts to dissect packets that contain meter readings, and the way it detects them is incorrect). A more complete dissector can be found in https://github.com/argilo/gr-elster/blob/master/apps/decode_pcap.py, which analyzes packets captured by packetize.py. But decode_pcap.py still just represents my best guesses at things, so a lot of parts are missing and there are almost certainly bugs.

[merbanan]

We need signal recordings for this type of transmitter. The ones we got are of unknown quality.

@argilo the demod in rtl_433 is generic so it will be able to handle different frequency offsets in the tuned range. I do guess that it would only be able to handle 2-3 frequencies compared to the 6 that gr-elster can handle.

rtl_433 -f 902.4M -s 1M -S unknown should be able to record some signals. If you don't get anything of interest try adjusting the frequency and/or increase the sample rate.

[cliv]

If there's any interest in continuing this work - I have about 12 hours of captured data and at least 3 meters within 50m of my antenna. There should be some decent data in there.

Let me know the best way to share the captures and if i can do anything to help analyze it.

[zuckschwerdt]

Is that single capture? Can you run rtl_433 -A thefile.cu8 on that and check if there are clean FSK packages (like above but with only pulse width as multiples of 28us or 7us). If so, maybe split the file with -S all then sort through the samples for some good ones?

[rexbron]

I would also like to contribute to this. Has anyone looked at https://github.com/shaunhey/ea_receiver

I seem to be able to use it to get the packets but the system doesn't decode them.

[abstractvector]

We've just had a brand new meter installed and would like to help. Our meter is a Honeywell meter, but uses an Elster PCB I believe. At least, it's labeled as TYPE R2SD and says it contains FCC ID: QZC-RX2EA4F which is the Elster PCB: https://fccid.io/QZC-RX2EA4F

Where we're located we shouldn't have much, if any, interference on the 900MHz band and I have an antenna just a few feet from the meter so should be able to get clean signals.

[cliv]

Looks like i might have a couple of interesting captures.

• [g007_902.4M_1000k.cu8 (256K)] #1 #2
• [g034_902.4M_1000k.cu8 (384K)] #1
• [g042_902.4M_1000k.cu8 (384K)] #1 #2
• [g043_902.4M_1000k.cu8 (384K)] #1 #2
• [g045_902.4M_1000k.cu8 (384K)] #1
• [g065_902.4M_1000k.cu8 (128K)] #1
• [g075_902.4M_1000k.cu8 (384K)] #1
• [g076_902.4M_1000k.cu8 (384K)] #1
• [g082_902.4M_1000k.cu8 (384K)] #1
• [g123_902.4M_1000k.cu8 (384K)] #1
• [g124_902.4M_1000k.cu8 (128K)] #1
• [g126_902.4M_1000k.cu8 (384K)] #1
• [g134_902.4M_1000k.cu8 (256K)] #1
• [g144_902.4M_1000k.cu8 (128K)] #1
• [g150_902.4M_1000k.cu8 (384K)] #1
• [g179_902.4M_1000k.cu8 (256K)] #1
• [g187_902.4M_1000k.cu8 (384K)] #1
• [g209_902.4M_1000k.cu8 (640K)] #1
• [g216_902.4M_1000k.cu8 (384K)] #1
• [g251_902.4M_1000k.cu8 (384K)] #1
• [g252_902.4M_1000k.cu8 (384K)] #1
• [g263_902.4M_1000k.cu8 (256K)] #1
• [g281_902.4M_1000k.cu8 (128K)] #1
• [g288_902.4M_1000k.cu8 (256K)] #1 #2
• [g291_902.4M_1000k.cu8 (384K)] #1 #2
• [g299_902.4M_1000k.cu8 (256K)] #1

[abstractvector]

I've been capturing this morning with rtl_433 -f 902.4M -s 1M -S unknown and the only interesting one so far is this:

• [g074_902.4M_1000k.cu8 (133585 samples, 393216 bytes)] #1

[gdt]

What's the status and path forward? It looks like a fair bit of progress -- a PR would be a helpful step.