Trouble decoding ERT messages that rtlamr finds

Ethan T

unread,

Apr 22, 2020, 12:40:09 AM4/22/20

to rtl_433

I'm trying to monitor my neighborhood's water meter to watch for leaks, and as such I'm playing with ERT decoding in both rtlamr (https://github.com/bemasher/rtlamr) and rtl_433. Having set up rtl_433 at home to monitor several weather sensors, I like its interface and low CPU usage. I have been unable to get rtlamr running with sufficient speed on an RPi2, but rtl_433 has no problem on it ... except that it's failing to find ERT packets that I know it can decode.

My first test was at home: I ran rtlamr for a bit, then ran rtl_433 for a bit. rtlamr was consistently able to find more ERT/SCM traffic than rtl_433 in the same place, with the same rtl-sdr dongle and antenna. So I know it can decode the data that rtlamr is seeing, it just seems to be far less sensitive to the good data.

For my main tests, I collected radio data with an rtl-sdr dongle in two places: one spot about 6 feet from the water meter's transmit antenna, and one about 100 meters away near our clubhouse, which is where I'd eventually like to set up the logging station with a directional antenna pointed at the water meter.

This data, fed into rtlamr, shows several packets in both recordings. However, the same file fed into rtl_433, shows no decoded ERT (a.k.a. SCM) packets. In fact, it shows no packets at all. I recorded the files with rtl_sdr using the standard settings that rtlamr uses, in auto gain mode, with frequency 912,600,115 Hz and sample rate 2,359,296 sps. I'm running rtl_433 like so:

rtl_433 -M level -r near_club.iq.cu8 -s 2359296 -f 912600155 -R 149

I tried "-Y classic" and "-Y minmax". I also played with "-Y level=" values. None of them got me any packets.

"-vv" yields "Test mode file issued 13 packets" and "Test mode file issued 10 packets", but "-A" shows no packets at all for one file, and gibberish for the other.

I can upload the IQ files somewhere but they're 377mb and 487mb respectively. I also have the sample files created by rtlamr, which only include the packets it's able to decode, and those are 2-3mb each.

Any ideas?

Paul Harrington

unread,

May 14, 2020, 1:00:05 PM5/14/20

to rtl_433

I modified the ert.c code slightly (diffs against e310efe; see below) to add in more debugging and also to make the output consistent wrt rtlamr (I think the ert-type processing is incorrect in rtl_433)

I ran rtlamr and rtl_433 side by side against rtlmux so they are working on identical bytestreams and I noticed a lot of DECODE_ABORT_LENGTH (I live in a suburb of Boston and there are a lot of meters chirping regularly). Curiously, one a single meter id appears in the rtl_433 output. I will do some further experiments and report back if anything interesting comes up.

regards,

pjjH

phrrngtn@sdrpi:~/work/rtl_433/build $ git diff

diff --git a/src/devices/ert.c b/src/devices/ert.c

index 3d11ffe..fffc0b1 100644

--- a/src/devices/ert.c

+++ b/src/devices/ert.c

@@ -54,18 +54,27 @@ static int ert_decode(r_device *decoder, bitbuffer_t *bitbuffer)

data_t *data;

if (bitbuffer->bits_per_row[0] != 96)

+ {

+ fprintf(stderr, "DECODE_ABORT_LENGTH %d\n", bitbuffer->bits_per_row[0]);

return DECODE_ABORT_LENGTH;

+ }

+

b = bitbuffer->bb[0];

if (crc16(&b[2], 10, 0x6F63, 0))

+ {

+

+ fprintf(stderr, "ERT failed checksum\n");

return DECODE_FAIL_MIC;

+ }

+

/* Instead of detecting the preamble we rely on the

* CRC and extract the parameters from the back */

/* Extract parameters */

physical_tamper = (b[3]&0xC0) >> 6;

- ert_type = (b[3]&0x60) >> 2;

+ ert_type = (b[3]&0x36) >> 2;

encoder_tamper = b[3]&0x03;

consumption_data = (b[4]<<16) | (b[5]<<8) | b[6];

ert_id = ((b[2]&0x06)<<23) | (b[7]<<16) | (b[8]<<8) | b[9];

Christian Zuckschwerdt

unread,

May 14, 2020, 1:31:02 PM5/14/20

to rtl_433

+ fprintf(stderr, "DECODE_ABORT_LENGTH %d\n", bitbuffer->bits_per_row[0]);

Maybe this can help to get more insight what the bitbuffer looks like:

bitbuffer_printf(bitbuffer, "%s: DECODE_ABORT_LENGTH ", __func__);

Paul Harrington

unread,

May 14, 2020, 1:58:43 PM5/14/20

to rtl_433

Thanks for that. I have appended some of the output from rtl_433 and also some redacted output from rtlamr (to comply with the wishes of the author of rtlamr as per github) from in or around the same time (i.e. they are not directly correlated. I just wanted to include some output with timestamps to show how much traffic rtlamr is seeing). I notice in the code a comment that says that it is not using the preamble (F2A60) so I am unsure if these kind of failed decodes might be expected? In any case, I am having a difficult time reproducing the output of rtlamr using LuaRadio but I thought that was 100% due to this being my first SDR project. When I googled for rtl_433 and rtlamr, I found this post so I am going to study the rtlamr implementation more closely and see if I can understand what it is doing that rtl_433 is not.

BTW, rtl_433 is a really cool looking piece of software. I am looking forward to learning more about it as I debug this particular issue.

pjjH

[00] { 7} 06 : 0000011