Received emonTx: plugged in; not receiving data via rtl_433

Getting Started
1

I bought an emonTX (assembled PCB, no enclosure), plugged into 9V AC, blinks red every so often (~10sec); one CT connected to CT1. It has 433MHz marked at the back; antenna connected.

I then loaded rtl_433 with (was typo: trl) rtl_433 -s 2500000 -R45 expecting to see some data… but nada – it rhymes :slight_smile: no data is being received :frowning:

Without limiting the protocol to -R 45, and choosing a sample rate of 250,000 I get all my other 433MHz nodes, but nothing from the emonTx.

Any hints on how to proceed appreciated.

2

I’m anticipating this is a typo (you can edit the post).

I see you have used the builtin decode in rtl_433 (R45). That was written a while ago and may no longer work as I expect it was written for the old EmonTX firmware. @Robert.Wall, I don’t know if the actual data format sent via the RFM has changed with the new firmware, but I have a feeling it has.

@MaxG, if you just do a raw receive, do you get anything?

[edit]
The data decode code;

3

You only need to look at the sketch to see what the format is. Most sketches now include the “emonhub.conf” description of the data format transmitted, in addition to looking at the variables themselves in the data structure.

[[15]]
  nodename = emontx3cm15
  [[[rx]]]
    names = MSG, Vrms, P1, P2, P3, P4, E1, E2, E3, E4, T1, T2, T3, pulse
    datacodes = L,h,h,h,h,h,l,l,l,l,h,h,h,L
    scales = 1,0.01,1,1,1,1,1,1,1,1,0.01,0.01,0.01,1
    units = n,V,W,W,W,W,Wh,Wh,Wh,Wh,C,C,C,p
    whitening = 1

struct {
    unsigned long Msg;
    int Vrms,P1,P2,P3,P4; 
    long E1,E2,E3,E4; 
    int T1,T2,T3;
    unsigned long pulse;
}

L - unsigned long integer (4 bytes)
l - signed long
h - signed integer (2 bytes)
“whitening” means each byte is XOR’d with 0x55 before transmission to remove long strings of null bytes, which were causing the receiver to lose lock. You need to XOR with 0x55 again to recover the data.

4

Thank you for the replies…

Yes, fixed now… (sorry)

Sure, only :slight_smile:

I had a look at the code and it lists:

emonhub.conf node decoder (nodeid is 8 when switch is off, 7 when switch is on)
See: https://github.com/openenergymonitor/emonhub/blob/emon-pi/configuration.md
[[8]]
    nodename = emonTx_3
    firmware =V2_3_emonTxV3_4_DiscreteSampling
    hardware = emonTx_(NodeID_DIP_Switch1:OFF)
    [[[rx]]]
       names = power1, power2, power3, power4, Vrms, temp1, temp2, temp3, temp4, temp5, temp6, pulse
       datacodes = h,h,h,h,h,h,h,h,h,h,h,L
       scales = 1,1,1,1,0.01,0.1,0.1, 0.1,0.1,0.1,0.1,1
       units =W,W,W,W,V,C,C,C,C,C,C,p

[update1] I checked the link in the config, and it points to the emonhub which I do not have.

My idea was to get this board, read four inputs, send the data with the built-in RF module; intercept it with rtl_433, form a MQTT msg and receive it in openHAB.

What do I need to do with rtl_433 to receive the emonTX signal?

5

When did you buy your emonTx?
If it’s an emonTx V3.4 bought since 18/8/20, your sketch will be V2.0.0 of this one:
https://github.com/openenergymonitor/EmonTxV3CM/blob/master/src/EmonTxV3CM.ino
If you got it before that date, tell me when and I’ll try to guess which version you have. The sketch you quoted above was the default until 18/10/2019. That is when emonLibCM became the default and I think whitening was introduced either with that, or at the most 1 - 2 months before.

I don’t have one of those, so I cannot tell you. We only write for and test with the Hope RFM69CW and we try to maintain backwards compatibility with the RFM12B wherever possible.

The complete data relating to the transmission is
Frequency: 434.000 MHz
The bit rate is 49.23 kb/s, deviation 90 kHz
The complete message is:
3 bytes pre-amble 0xAA 0xAA 0xAA
1 byte 0x2D
1 byte Group (210 = 0xD2)
1 byte header, of which the low 5 bits are the NodeID
1 byte message length
message
2 bytes CRC-16 checksum

The message bytes are as you see in the sketch, sent low byte first.

6

Thank you.
Invoice date: Sept 9th, 2020

image
image782×161 7.45 KB

Well, my assumptions were (as assumptions often are) wrong, that rtl_433 could read the emonTX, considering it is on the rtl_433 decoder list.

Since, I have not much of a clue on how to make this work; and (as mentioned elsewhere bought the wrong board), I most like bin the thing for good.

In any case, I am grateful for the support I have received. :slight_smile:

7

Then the sketch you have will be the one I thought it was. openenergymonitor/EmonTxV3CM/blob/master/src/EmonTxV3CM.ino

If you have the Arduino IDE and a programmer, you can disable whitening by setting “w1” in the on-line configuration - and you see that if you connect your programmer and restart the sketch. It’s in the list near the top:

  w<x>      - turn RFM Wireless data on or off:
            - x = 0 for OFF, x = 1 for ON, x = 2 for ON with whitening

You should then have “raw” data arriving in your rtl_433 that will easily decode. I gave you the structure of the data in post no.3.

So following the byte containing the NodeID you have
length: 40 (decimal)
4 bytes - message number (uint32_t)
2 bytes - voltage (int16_t)
4 × 2 bytes - power (int16_t)
4 × 4 bytes - accumulated energy (int32_t)
3 × 2 bytes - temperature (int16_t)
4 bytes - pulse count (uint32_t)
2 bytes - CRC-16 checksum

As I have said, I have no knowledge of your radio. If you study the list you gave in post no.2 and compare that with the sketch you found and the one I think you have, it should be easy enough edit that file to decode your new sketch. You have the format up to and including “power”, that is the same. You need to add “accumulated energy” and reduce the number of temperatures.

Don’t you think it is a little unkind to blame us at OEM for someone else’s list? They surely are responsible for publishing it and for its accuracy.

8

You just need any TTY programme and either a programmer or a spare RPi and connect the Pi via the Serial Port → UART.

I’d agree. Assume nothing is my mantra. That decoder was probably not created by anyone here!

However, I do have an RTL stick so I’ll try and find some time to help if you get stuck. If we get it to work it can be added to the RTL codebase.

So this is one of the confusions. Although that code is in the EmonTX repo, it is not the current code (@TrystanLea could this be sorted out please?). The right repo for the default CM (continuous Monitoring) sketch is GitHub - openenergymonitor/EmonTxV3CM: EmonTxV3 Continuous Monitoring Firmware (Default shipped EmonTxV3 firmware)

9

Interesting perception… and interesting where this is going… very defensive.

All I said, verbatim, “I assumed”… read again “I”… not sure how one can derive “blame” or blaming someone else from this phrase.

I read the docs, bought an emonTX, the rtl_433 I have; it lists an emonTX; not sure how any new user to emonTX would pick up that the emonTX listed in rtl_433 is not the one I bought with the same name.
Reading the docs is all I can do upfront; now I have the physical hardware, and realise it is not working… then I ask questions… then my (entirely my) assumption, meaning: I thought this should work, but it turned out it doesn’t.

Turning this around that I would blame others is simply ridiculous and immature.

I wish you all the best.

10

I’ve an RTL-SDR v2.0 so I gave it a try with data whitening turned off. No joy.
Looks like this has been an open issue since March.

From the author’s github page:

My SDR decoded all of the other devices I have that operate at 433.92 MHz, with no issues.

11

@Bill.Thomson Did you change the “decoding” format that Brian published 111. data = data_make( ... ) to suit the latest data packet structure?

It’s going to be an even bigger issue when we move to using Hope’s “Packet Mode”. That does data whitening ‘properly’ and uses a pseudo-random string XOR’d with the data.

12

@Robert.Wall - would going back to the DS firmware be the simplest, immediate, solution?

@Bill.Thomson - Doh! Never though to check for an Issue relating to it :frowning:.

13

If we knew which version the decoder is written for, possibly. But it’s clear to me that @MaxG has given up, so there’s little point is putting any more effort in. If he changes his mind, I’m prepared to help again.

A long-term “solution” would be for the rtl_433 designers/maintainers to co-operate with OEM, I’ve not noticed any evidence of that happening.

14

Try searching this forum for RTL-SDR for more info, the emon decoder was developed by someone who was discussing it on this forum IIRC. I can’t recall if he wrote the code or was just assisting but I do recall a discussion about making this device work with emontx. Maybe that person is contactable either via github or this forum’s pm for some pointers?

15

Hardly surprising!

16

I was trying a raw capture, using only the rtl_433 executable itself.
Here’s what that looks like

image
image828×699 24.6 KB

My Anemometer/WindVane and ThermoHygrometer data are coming through,
but no emonTx data shows up. The last time I tried it, (~4 years ago) the emonTx data
was decoded with no issues.

17

Our exact frequency (crystal-dependent of course) is alleged to be 434.000 MHz. Is within 80 kHz enough? - We’re doing FSK with 90 kHz deviation, the bit rate is 49.23 kb/s.

18

Everything I’ve ever seen WRT the UHF ISM freq says it’s at 433.92 MHz.

A receiver that far off center freq would be problematic at best, if it worked at all.

19

According to the data sheet (Hope’s), the oscillator is 32 MHz.

FSTEP = FXOSC ÷ 219
and
FRF = FSTEP × Frf(23,0)

FDEV = FSTEP × Fdev(13,0).

The values we use are JeeLib’s and are:

Fdev is 0x05C3

Frf is 0x6C8000

Whenever I’ve done the sums, it’s come out as 434.000000 on my calculator.

For the centre frequency of 433.92 MHz, our Tx registers need to be 0x6C7AE1.

If you have a sketch that uses rfmTxLib, in the .cpp file, this is what to change

    writeReg(0x07, 0x6C); // RegFrfMsb: Frf = Rf Freq / 61.03515625 Hz = 0x6C8000 = 434.00 MHz as used JeeLib 
    writeReg(0x08, 0x80); // RegFrfMid
    writeReg(0x09, 0x00); // RegFrfLsb

to

    writeReg(0x07, 0x6C); // RegFrfMsb:
    writeReg(0x08, 0x7A); // RegFrfMid
    writeReg(0x09, 0xE1); // RegFrfLsb
20

434.0 would not be outside the UHF ISM band, as the allocation there is 1.74 MHz wide.
(433.05 to 434.79 MHz)

433.92 is midway between those two limits which might explain why it sees so much use.
(as that freq is as far away from either band edge as possible)

The one thing I remember for sure is that when I tested it four years ago, I didn’t have to
anything other than run the rtl_433 decoder. I let the decoder app take all its defaults and
it worked OK.