Hi Guys,
I have two emonTX and 2 x emonTH in my system. The EmonPi should receive updates every 10seconds for the EmonTX. I can see the emonTX transmit OK on my SDR capture, however I get updates every 2 minutes if im lucky.
I have some noise at 433.922mHz (right where the emonTX transmits?) which I believe isn’t anything to do with my equipment. Ive been around the house and turned everything off apart from the laptop running the SDR software.
Can I move the TX frequency somehow?
Don’t you mean 433.922 MHz? 433 mHz is way below any usable radio frequency.
The noise is still there with all your transmitters switched off - including Bluetooth? It’s not an artifact of the SDR by any chance?
You can change the frequency, but you’ll need to do the same to the emonPi, the emonTx’s and the emonTH’s.
Which radio module does each use? The software for the RFM12B and the RFM 69CW is totally different, and are they all using JeeLib or are the emonTx’s using a different library (which they might be if they are recent purchases or they’re not using the standard sketch)? Because of that, there may well be different changes needed depending on the software in each.
Have you tried another antenna maybe higher up in the air for EmonTx or EmonPi ?
As you know 433.92MHz is a very common frequency for home automation from car keys to EmonPi. E.g. I have 7 temperature devices and closer to 20 radio controlled plugs at my country house as far as 30 meters away from control unit. Operating very well regardless of occasional collision when two transmissions happens at same time. Only time when there has been an issue was when a temperature sensor had bad batteries and went into a constant transmit mode. The emontx + emonbase and emonth work in parallel to the above setup without problems with 20 meters between EmonBase and EmonTH.
I had similar issues in the beginning with my home automation that you are facing until I upgraded the antenna in the control unit (not OEM based at least yet). After trialling with a couple of different desings the one linked here proved to be the best one (for my purpose).
ps. RFM69 is fully programmable through the library its using, if thats the route then I would start playing with AGC before touching the frequency.
https://cdn.sparkfun.com/datasheets/Wireless/General/RFM69HCW-V1.1.pdf
The SDR is showing a lot about the problem, but could you tweak the scan to show more please?
In brief, the emonTX is sending packets fine, centered around 434.00x MHz as expected. There are replayable captures at 00:21*, 00:26, 00:36, 1:16 plus 5 packets still shown in the history (* does not fit the 10 second spacing of the others).
Why are packets not seen every 10 seconds? Remember the duration of a packet at a fraction of a second is commensurate with the SDR left to right scan time. With a wide scan setting, packet events are easily missed.
If you freeze frame on say the 1:16 event, you can see the typical high modulation index FSK pattern with two peaks centred around the nominal carrier frequency of 434.0 MHz. The modulation information is mostly in those peaks (and curiously there is little at the carrier frequency). At decode time, one peak corresponds to the 1’s and the other to the 0’s
Now here is the problem - the narrow band interferer is dumping energy into the “left-hand” peak. This will skew the decode towards that value, flipping bits. Best case, the packet length value is not corrupted and the packet reception will terminate normally with a bad CRC - then rejected at a higher level.
Tweaking thresholds and gains can’t solve this, that will only adjust the vertical scale of your picture. Either the interferer needs to be removed from the reception passband or move the passband elsewhere.
Can you rerun the monitoring with a reduced scan width? 433.750 - 434.250 MHz will easily capture the packet activity and should confirm the 10 second heartbeat (and perhaps shed some light on the 00:21 anomaly).
Then narrow the scan even further to concentrate on just the 433.9xx activity. So far it is showing almost no modulation spread. It may be a slow OOK signal - its signature may offer some clues to its origin (e.g. weatherstation).
At least as far as the current scan shows, the interferer seems to be continuous - this breaks the ISM rules which insist on maximum duty cycles exactly to allow a primitive time sharing of the bandwidth.
One quick cross check is to run the SDR without an antenna, all signals should flatline to the noise floor. Then connecting a more directional antenna (e.g. a simple loop) you can null out the interferer to give a rough bearing and potentially triangulate the offender.
