search

merbanan / rtl_433

Program to decode radio transmissions from devices on the ISM bands (and other frequencies)
GNU General Public License v2.0
6.04k stars 1.31k forks source link

Elster Power Meter #1196

Open gcormier opened 4 years ago

gcormier commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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)

image

image

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 commented 4 years ago

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 commented 4 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

Looks like i might have a couple of interesting captures.

abstractvector commented 1 year ago

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:

gdt commented 11 months ago

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

ther3zz commented 1 month ago

Just wondering if anyone has been able to get rtl_433 to work with QZC-REXUANZ device. I just got solar installed and am monitoring generation there. It would be great to also monitor total consumption without having to install any additional hardware!

zuckschwerdt commented 1 month ago

Elster FCC docs for QZC-REXUANZ (https://fcc.report/FCC-ID/QZC-REXUANZ) seem to indicate the same Frequency Hopping Spread Spectrum at 902.4 - 927.6 MHz. You should be able to catch and investigate transmissions.

velaar commented 1 week ago

Elster FCC docs for QZC-REXUANZ (https://fcc.report/FCC-ID/QZC-REXUANZ) seem to indicate the same Frequency Hopping Spread Spectrum at 902.4 - 927.6 MHz. You should be able to catch and investigate transmissions.

Same can be said for QZC-GNIC that just got installed by Enmax in Calgary / Alberta / Canada.

As per Honeywell's roadmap all A4RES meters are using what they call REXU protocol Source. The only mention of REXU I found was here and it clearly suggests that it is the same protocol that is used by elster.