# Received emonTx: plugged in; not receiving data via rtl\_433 **URL:** \ **Category:** Getting Started\ **Tags:** emontx\ **Created:** [28 November 2020 04:30 UTC](https://community.openenergymonitor.org/t/received-emontx-plugged-in-not-receiving-data-via-rtl-433/16104 "2020-11-28T04:30:49Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![MaxG](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/maxg/32/10374_2.png) [@MaxG](https://community.openenergymonitor.org/u/MaxG)\ **Post date:** [28 November 2020 04:30 UTC](https://community.openenergymonitor.org/t/received-emontx-plugged-in-not-receiving-data-via-rtl-433/16104/1 "2020-11-28T04:30:49Z")
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 🙂 no data is being received ☹ 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. ---
**Author:** ![borpin](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/borpin/32/193_2.png) [@borpin](https://community.openenergymonitor.org/u/borpin)\ **Post date:** [28 November 2020 09:47 UTC](https://community.openenergymonitor.org/t/received-emontx-plugged-in-not-receiving-data-via-rtl-433/16104/2 "2020-11-28T09:47:34Z")
> [@MaxG](#): > > `trl_433` 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; > ---
**Author:** ![Robert.Wall](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/robert.wall/32/38246_2.png) [@Robert.Wall](https://community.openenergymonitor.org/u/Robert.Wall)\ **Post date:** [28 November 2020 14:52 UTC](https://community.openenergymonitor.org/t/received-emontx-plugged-in-not-receiving-data-via-rtl-433/16104/3 "2020-11-28T14:52:24Z")
> [@borpin](#): > > 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. 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. ```plaintext [[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 ``` ```auto 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. ---
**Author:** ![MaxG](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/maxg/32/10374_2.png) [@MaxG](https://community.openenergymonitor.org/u/MaxG)\ **Post date:** [28 November 2020 23:06 UTC](https://community.openenergymonitor.org/t/received-emontx-plugged-in-not-receiving-data-via-rtl-433/16104/4 "2020-11-28T23:06:59Z")
Thank you for the replies… > [@borpin](#): > > I’m anticipating this is a typo (you can edit the post). Yes, fixed now… (sorry) > [@Robert.Wall](#): > > You only need to look at the sketch to see what the format is. Sure, only 🙂 I had a look at [the code](https://github.com/openenergymonitor/emontx3/blob/master/firmware/src/src.ino) and it lists: ```auto 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? ---
**Author:** ![Robert.Wall](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/robert.wall/32/38246_2.png) [@Robert.Wall](https://community.openenergymonitor.org/u/Robert.Wall)\ **Post date:** [29 November 2020 00:38 UTC](https://community.openenergymonitor.org/t/received-emontx-plugged-in-not-receiving-data-via-rtl-433/16104/5 "2020-11-29T00:38:56Z")
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](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. > [@MaxG](#): > > What do I need to do with rtl\_433 to receive the emonTX signal? 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. ---
**Author:** ![MaxG](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/maxg/32/10374_2.png) [@MaxG](https://community.openenergymonitor.org/u/MaxG)\ **Post date:** [29 November 2020 00:55 UTC](https://community.openenergymonitor.org/t/received-emontx-plugged-in-not-receiving-data-via-rtl-433/16104/6 "2020-11-29T00:55:17Z")
Thank you. Invoice date: Sept 9th, 2020 ![image](https://community.openenergymonitor.org/uploads/default/original/3X/8/5/85163a87b7543462a22b22f952adb7210ff53666.png) 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. 🙂 ---
**Author:** ![Robert.Wall](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/robert.wall/32/38246_2.png) [@Robert.Wall](https://community.openenergymonitor.org/u/Robert.Wall)\ **Post date:** [29 November 2020 01:19 UTC](https://community.openenergymonitor.org/t/received-emontx-plugged-in-not-receiving-data-via-rtl-433/16104/7 "2020-11-29T01:19:39Z")
Then the sketch you have will be the one I thought it was. [openenergymonitor/EmonTxV3CM/blob/master/src/EmonTxV3CM.ino](https://github.com/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: ```plaintext w - 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. > [@MaxG](#): > > rtl\_433 could read the emonTX, considering it is on the rtl\_433 decoder list. 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. ---
**Author:** ![borpin](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/borpin/32/193_2.png) [@borpin](https://community.openenergymonitor.org/u/borpin)\ **Post date:** [29 November 2020 10:03 UTC](https://community.openenergymonitor.org/t/received-emontx-plugged-in-not-receiving-data-via-rtl-433/16104/8 "2020-11-29T10:03:14Z")
> [@Robert.Wall](#): > > If you have the Arduino IDE and a programmer, you can disable whitening by setting “w1” You just need any TTY programme and either a programmer or a spare RPi and connect the Pi via the Serial Port → UART. > [@Robert.Wall](#): > > > [@MaxG](#): > > > > rtl\_433 could read the emonTX, considering it is on the rtl\_433 decoder list. > > 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. 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. > [@MaxG](#): > > I had a look at [the code](https://github.com/openenergymonitor/emontx3/blob/master/firmware/src/src.ino) and it lists: 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) · GitHub](https://github.com/openenergymonitor/EmonTxV3CM/) ---
**Author:** ![MaxG](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/maxg/32/10374_2.png) [@MaxG](https://community.openenergymonitor.org/u/MaxG)\ **Post date:** [29 November 2020 10:36 UTC](https://community.openenergymonitor.org/t/received-emontx-plugged-in-not-receiving-data-via-rtl-433/16104/9 "2020-11-29T10:36:39Z")
> [@borpin](#): > > > [@Robert.Wall](#): > > > > 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. > > I’d agree. Assume nothing is my mantra. That decoder was probably not created by anyone here! 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. ---
**Author:** ![Bill.Thomson](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/bill.thomson/32/1834_2.png) [@Bill.Thomson](https://community.openenergymonitor.org/u/Bill.Thomson)\ **Post date:** [29 November 2020 10:58 UTC](https://community.openenergymonitor.org/t/received-emontx-plugged-in-not-receiving-data-via-rtl-433/16104/10 "2020-11-29T10:58:10Z")
> [@borpin](#): > > 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. 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: > > > \[EmonTxV3\](https://guide.openenergymonitor.org/setup/emontx/), the OpenEnergyMon…itor transmitter, is now shipping with \[a new firmware\](https://github.com/openenergymonitor/EmonTxV3CM) that changes the protocol: > > \_Note: This firmware uses data whitening to improve the reliability of the data transmission. A standard pattern of 1s and 0s is overlayed on the underlying data, this prevents sync issues that result from too many zero values in a packet. When the packet is received it is decoded by emonhub. The 'whitening = 1' is required to tell emonhub to decode the packet correctly.\_ > > #ifdef RF\_WHITENING > byte WHITENING = 0x55; > for (byte i = 0, \*p = (byte \*)&tmp; i \< sizeof tmp; i++, p++) > \*p ^= (byte)WHITENING; > #endif > > Some samples of the new firmware transmissions can be found in \[this Google groups thread\](https://groups.google.com/d/msg/rtl\_433/y6dajQHSbKA/GJN6p\_gtAQAJ). > > Can you please add support for this as well. My SDR decoded _all_ of the other devices I have that operate at 433.92 MHz, with no issues. ---
**Author:** ![Robert.Wall](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/robert.wall/32/38246_2.png) [@Robert.Wall](https://community.openenergymonitor.org/u/Robert.Wall)\ **Post date:** [29 November 2020 13:47 UTC](https://community.openenergymonitor.org/t/received-emontx-plugged-in-not-receiving-data-via-rtl-433/16104/11 "2020-11-29T13:47:06Z")
> [@Bill.Thomson](#): > > 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. @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. ---
**Author:** ![borpin](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/borpin/32/193_2.png) [@borpin](https://community.openenergymonitor.org/u/borpin)\ **Post date:** [29 November 2020 20:31 UTC](https://community.openenergymonitor.org/t/received-emontx-plugged-in-not-receiving-data-via-rtl-433/16104/12 "2020-11-29T20:31:36Z")
@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 ☹. ---
**Author:** ![Robert.Wall](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/robert.wall/32/38246_2.png) [@Robert.Wall](https://community.openenergymonitor.org/u/Robert.Wall)\ **Post date:** [29 November 2020 21:08 UTC](https://community.openenergymonitor.org/t/received-emontx-plugged-in-not-receiving-data-via-rtl-433/16104/13 "2020-11-29T21:08:43Z")
> [@borpin](#): > > would going back to the DS firmware be the simplest, immediate, solution? 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. ---
**Author:** ![pb66](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/pb66/32/27_2.png) [@pb66](https://community.openenergymonitor.org/u/pb66)\ **Post date:** [29 November 2020 21:23 UTC](https://community.openenergymonitor.org/t/received-emontx-plugged-in-not-receiving-data-via-rtl-433/16104/14 "2020-11-29T21:23:48Z")
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? ---
**Author:** ![borpin](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/borpin/32/193_2.png) [@borpin](https://community.openenergymonitor.org/u/borpin)\ **Post date:** [29 November 2020 21:28 UTC](https://community.openenergymonitor.org/t/received-emontx-plugged-in-not-receiving-data-via-rtl-433/16104/15 "2020-11-29T21:28:32Z")
> [@Robert.Wall](#): > > But it’s clear to me that @MaxG has given up, so there’s little point is putting any more effort in. Hardly surprising! ---
**Author:** ![Bill.Thomson](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/bill.thomson/32/1834_2.png) [@Bill.Thomson](https://community.openenergymonitor.org/u/Bill.Thomson)\ **Post date:** [29 November 2020 21:37 UTC](https://community.openenergymonitor.org/t/received-emontx-plugged-in-not-receiving-data-via-rtl-433/16104/16 "2020-11-29T21:37:54Z")
> [@Robert.Wall](#): > > Did you change the “decoding” format that Brian published I was trying a raw capture, using only the rtl\_433 executable itself. Here’s what that looks like ![image](https://community.openenergymonitor.org/uploads/default/original/3X/3/5/35b56f7b72665c8ecd43b70fa6797c1a74e7cdb7.png) 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. ---
**Author:** ![Robert.Wall](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/robert.wall/32/38246_2.png) [@Robert.Wall](https://community.openenergymonitor.org/u/Robert.Wall)\ **Post date:** [29 November 2020 21:44 UTC](https://community.openenergymonitor.org/t/received-emontx-plugged-in-not-receiving-data-via-rtl-433/16104/17 "2020-11-29T21:44:35Z")
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. ---
**Author:** ![Bill.Thomson](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/bill.thomson/32/1834_2.png) [@Bill.Thomson](https://community.openenergymonitor.org/u/Bill.Thomson)\ **Post date:** [29 November 2020 21:49 UTC](https://community.openenergymonitor.org/t/received-emontx-plugged-in-not-receiving-data-via-rtl-433/16104/18 "2020-11-29T21:49:37Z")
Everything I’ve ever seen WRT the UHF ISM freq says it’s at 433.92 MHz. > [@Robert.Wall](#): > > Is within 80 kHz enough? A receiver that far off center freq would be problematic at best, if it worked at all. ---
**Author:** ![Robert.Wall](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/robert.wall/32/38246_2.png) [@Robert.Wall](https://community.openenergymonitor.org/u/Robert.Wall)\ **Post date:** [29 November 2020 22:14 UTC](https://community.openenergymonitor.org/t/received-emontx-plugged-in-not-receiving-data-via-rtl-433/16104/19 "2020-11-29T22:14:29Z")
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 ```auto 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 ```auto writeReg(0x07, 0x6C); // RegFrfMsb: writeReg(0x08, 0x7A); // RegFrfMid writeReg(0x09, 0xE1); // RegFrfLsb ``` ---
**Author:** ![Bill.Thomson](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/bill.thomson/32/1834_2.png) [@Bill.Thomson](https://community.openenergymonitor.org/u/Bill.Thomson)\ **Post date:** [29 November 2020 22:30 UTC](https://community.openenergymonitor.org/t/received-emontx-plugged-in-not-receiving-data-via-rtl-433/16104/20 "2020-11-29T22:30:03Z")
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. [Next page](https://community.openenergymonitor.org/t/received-emontx-plugged-in-not-receiving-data-via-rtl-433/16104.md?page=2)