# Received emonTx: plugged in; not receiving data via rtl\_433

**URL:** <https://community.openenergymonitor.org/t/received-emontx-plugged-in-not-receiving-data-via-rtl-433/16104>\
**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:** 16\
**Page:** 2

<div class="post-metadata">

**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/21 "2020-11-29T22:30:28Z")

</div>

> [@Robert.Wall](#):
>
> If you have a sketch that uses rfmTxLib, in the .cpp file, this is what to change

I’ll give that a shot…

---

<div class="post-metadata">

**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:36 UTC](https://community.openenergymonitor.org/t/received-emontx-plugged-in-not-receiving-data-via-rtl-433/16104/22 "2020-11-29T22:36:10Z")

</div>

I’m fairly sure the frequency hasn’t changed since I’ve been around - unless JeeLib changed before I cribbed it.

I wonder why JCW chose 434.000 MHz, rather than the band centre. Or maybe he went off-centre to minimise co-channel interference from everyone using the centre. I’ve not noticed anything in the literature about it.

---

<div class="post-metadata">

**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:45 UTC](https://community.openenergymonitor.org/t/received-emontx-plugged-in-not-receiving-data-via-rtl-433/16104/23 "2020-11-29T22:45:31Z")

</div>

This _might_ be the sketch that fits the decoder Brian listed:  
emonTxV3\_4\_DiscreteSamplingPolledPulse

[emonTxV3\_4\_DiscreteSamplingPolledPulse.ino.zip](https://community.openenergymonitor.org/uploads/short-url/ts9pchHIdMKn8Y5J9P8p6SH5rTE.zip) (7.2 KB)

I’ve no idea where that might be on Github.

---

<div class="post-metadata">

**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:51 UTC](https://community.openenergymonitor.org/t/received-emontx-plugged-in-not-receiving-data-via-rtl-433/16104/24 "2020-11-29T22:51:33Z")

</div>

I tried changing the SDR freq to 434.0 MHz, and it still receives the data from my Oregon Scientific  
weather devices, but no cigar WRT the emonTx data. That’s not saying much though as the SDRs  
have a fairly broad front end. They’re original purpose was to receive TV signals, so the fact they  
still work tuned so far off center freq is understandable.

---

<div class="post-metadata">

**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:55 UTC](https://community.openenergymonitor.org/t/received-emontx-plugged-in-not-receiving-data-via-rtl-433/16104/25 "2020-11-29T22:55:07Z")

</div>

Is that with a “new” sketch or the old (July 2016) “polled pulse”?

---

<div class="post-metadata">

**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 23:33 UTC](https://community.openenergymonitor.org/t/received-emontx-plugged-in-not-receiving-data-via-rtl-433/16104/26 "2020-11-29T23:33:21Z")

</div>

> [@borpin](#):
>
> > [@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!

Well, this techo thing is way beyond my skill 🙂 so, what else could be expected from me other than putting this project aside or seek alternative solutions?

“putting more effort in” could lead to a solution, which may help a future audience wanting to take the same route; that is using rtl\_433 to receive the emonTX data.

> [@Bill.Thomson](#):
>
> I was trying a raw capture, using only the rtl\_433 executable itself.

Isn’t the sample rate 2,500,000 for the emonTX, rather than 250,000 s-1?  
I tried both to no avail, but the outcome seems to be related to a change in data format, as this discussion implies?!

---

<div class="post-metadata">

**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:** [30 November 2020 01:42 UTC](https://community.openenergymonitor.org/t/received-emontx-plugged-in-not-receiving-data-via-rtl-433/16104/27 "2020-11-30T01:42:54Z")

</div>

> [@Robert.Wall](#):
>
> Is that with a “new” sketch or the old (July 2016) “polled pulse”?

The first try was with an ancient (v2.6.0) version of firmware.

This is the output in “analysis” mode:

 ![image](https://community.openenergymonitor.org/uploads/default/original/3X/9/b/9bff20cbe1dcd4666e0e111b687f84386245cd13.png)

So it’s apparently receiving the signal, just not decoding it. ☹

---

<div class="post-metadata">

**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:** [30 November 2020 01:47 UTC](https://community.openenergymonitor.org/t/received-emontx-plugged-in-not-receiving-data-via-rtl-433/16104/28 "2020-11-30T01:47:52Z")

</div>

> [@MaxG](#):
>
> Isn’t the sample rate 2,500,000 for the emonTX,

I haven’t (yet!) seen anything that indicates a sample rate of 2.5 Msps for emonTx.  
When I set it to 2.5 Msps, none of the signals were decoded. Resetting it to 250 ksps  
enabled decoding of the Oregon Sci instruments as before.

---

<div class="post-metadata">

**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:** [30 November 2020 02:02 UTC](https://community.openenergymonitor.org/t/received-emontx-plugged-in-not-receiving-data-via-rtl-433/16104/29 "2020-11-30T02:02:56Z")

</div>

🙂 I have read so much stuff in recent days, I can’t recall where I saw this, otherwise I would share the link; sorry.

---

<div class="post-metadata">

**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:** [30 November 2020 02:20 UTC](https://community.openenergymonitor.org/t/received-emontx-plugged-in-not-receiving-data-via-rtl-433/16104/30 "2020-11-30T02:20:14Z")

</div>

NOT a problem. Been there and done that when it comes to _info overload._ 😉

---

<div class="post-metadata">

**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:** [30 November 2020 07:41 UTC](https://community.openenergymonitor.org/t/received-emontx-plugged-in-not-receiving-data-via-rtl-433/16104/31 "2020-11-30T07:41:20Z")

</div>

> [@MaxG](#):
>
> seek alternative solutions?

I suggest that to achieve what you want (EmonTX measure data and send via MQTT) you hook up a PiZero (or any Pi Clone) and use emonhub.

---

<div class="post-metadata">

**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:** [30 November 2020 07:43 UTC](https://community.openenergymonitor.org/t/received-emontx-plugged-in-not-receiving-data-via-rtl-433/16104/32 "2020-11-30T07:43:55Z")

</div>

> [@Bill.Thomson](#):
>
> This is the output in “analysis” mode:

Is than with the V2.6.0 firmware or the CM firmware?

---

<div class="post-metadata">

**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:** [30 November 2020 12:58 UTC](https://community.openenergymonitor.org/t/received-emontx-plugged-in-not-receiving-data-via-rtl-433/16104/33 "2020-11-30T12:58:50Z")

</div>

> [@borpin](#):
>
> Is than with the V2.6.0 firmware or the CM firmware?

The sketch Robert linked to in post 22.

---

<div class="post-metadata">

**Author:** ![TrystanLea](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/trystanlea/32/31_2.png) [@TrystanLea](https://community.openenergymonitor.org/u/TrystanLea)\
**Post date:** [30 November 2020 13:00 UTC](https://community.openenergymonitor.org/t/received-emontx-plugged-in-not-receiving-data-via-rtl-433/16104/34 "2020-11-30T13:00:24Z")

</div>

@MaxG as your order is relatively recent, if you do not wish to pursue this option, feel free to contact shop support if you wish to return the EmonTx for a refund: [support@openenergymonitor.zendesk.com](mailto:support@openenergymonitor.zendesk.com)

Alternatively I think @borpin’s suggestion to use a pizero with emonhub may be the easiest route.

---

<div class="post-metadata">

**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:** [30 November 2020 22:36 UTC](https://community.openenergymonitor.org/t/received-emontx-plugged-in-not-receiving-data-via-rtl-433/16104/35 "2020-11-30T22:36:26Z")

</div>

> [@borpin](#):
>
> I suggest that to achieve what you want (EmonTX measure data and send via MQTT) you hook up a PiZero (or any Pi Clone) and use emonhub.

Appreciate the idea…  
However, thinking this through, I need a Pi a power supply, a case, etc. which easily adds up to some 180 AUD. MY use case requires three CTs, equating to ~60 AUD per CT… and presents quite a level of complexity.

Further thinking led to the conclusion, I am better off getting a [Sonoff Pow R2](https://www.itead.cc/sonoff-pow-r2.html) for 17 AUD; it is self-contained (as in, has its own case, no extra bits required).

> [@TrystanLea](#):
>
> feel free to contact shop support if you wish to return the EmonTx

I truly appreciate this offer… and may well take it up.

* * *

Thank you all for your support in this matter.

---

<div class="post-metadata">

**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:** [1 December 2020 07:31 UTC](https://community.openenergymonitor.org/t/received-emontx-plugged-in-not-receiving-data-via-rtl-433/16104/36 "2020-12-01T07:31:54Z")

</div>

> [@MaxG](#):
>
> I need a Pi a power supply, a case, etc. which easily adds up to some 180 AUD.

I think you are way over egging that.

First, it will use the same PS as the EmonTX (one powers the other).

A PiZero is plenty enough oomph.

> **[Raspberry Pi Zero W (Wireless)](https://core-electronics.com.au/raspberry-pi-zero-w-wireless.html)**
>
> The smallest Raspberry Pi just got a whole lot cooler. The Raspberry Pi Zero W carries the same form factor and specifications as the original Pi Zero and provides built-in WiFi and Bluetooth 4.1!

Case, any local 3D printers or an Aliexpress

> [@EmonTX to Rpi - Direct Serial Connection](https://community.openenergymonitor.org/t/emontx-to-rpi-direct-serial-connection/13114/38):
>
> By way of an update, I bought some dupont connectors, a crimping tool and made up a cable. I had the case lying around and the Pi already had the header soldered on. Currently running a full emonScript install. The improvement would be to use right-angle headers and [this case](https://www.thingiverse.com/thing:2270702) - it would be really neat then! [Link to wiring diagram](https://community.openenergymonitor.org/t/4-ct-emonbase-using-emontx-and-pi-zero-w/6580/17)

> [@EmonTX to Rpi - Direct Serial Connection](https://community.openenergymonitor.org/t/emontx-to-rpi-direct-serial-connection/13114/61):
>
> So the final step on my odyssey (possibly) 3D printed case (link above), a right angle header and a short cable made up with a crimp tool makes for a very clean setup. Pi is then powered off the 5V DC to the emonTX (it works the other way as well). End cost is slightly more than the emonESP, but far more flexible, can update firmware and no need for emoncms on a second machine/Pi. My aim is to install this at a friend’s house for a month and see if Agile will save him m…

Add an SD card, a header (or solder the wires direct) and a few wires and you will be done.

YMMV

[Previous page](https://community.openenergymonitor.org/t/received-emontx-plugged-in-not-receiving-data-via-rtl-433/16104.md?page=1)
