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.
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.
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
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.
I’ll give that a shot…
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.
This might be the sketch that fits the decoder Brian listed:
emonTxV3_4_DiscreteSamplingPolledPulse
emonTxV3_4_DiscreteSamplingPolledPulse.ino.zip (7.2 KB)
I’ve no idea where that might be on Github.
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.
Is that with a “new” sketch or the old (July 2016) “polled pulse”?
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.
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?!
The first try was with an ancient (v2.6.0) version of firmware.
This is the output in “analysis” mode:
So it’s apparently receiving the signal, just not decoding it. 
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.
I have read so much stuff in recent days, I can’t recall where I saw this, otherwise I would share the link; sorry.
NOT a problem. Been there and done that when it comes to info overload. 
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.
1 Like
Is than with the V2.6.0 firmware or the CM firmware?
The sketch Robert linked to in post 22.
@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: [email protected]
Alternatively I think @borpin’s suggestion to use a pizero with emonhub may be the easiest route.
2 Likes
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 for 17 AUD; it is self-contained (as in, has its own case, no extra bits required).
I truly appreciate this offer… and may well take it up.
Thank you all for your support in this matter.
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.
Case, any local 3D printers or an Aliexpress
Add an SD card, a header (or solder the wires direct) and a few wires and you will be done.
YMMV