I’m troubleshooting rf interference causing data drop outs, from a position of zero background knowledge of rf or the OEM hardware/firmware. So far, I have determined by rtl-sdr dongle that there is interference with emonTH and emonTX3/4 transmissions by a small, variable noise source at exactly 433MHz. The individual OEM kit transmissions appear to show rf energy across variable bandwidths from 433 to 435MHz and dropouts occur when the noise source is high (there are other reasons too: collisions and apparent non-transmissions).
I wondered whether it might be possible to “tune” the frequency of the OEM kit to avoid this. The RFM69CW appears to allow for loads of configuration so I looked at the emonTH2 firmware sketch to see how it configures the rf. The key line is #249
rf12_initialize(nodeID, RF_freq, networkGroup)
but looking at the function declaration in the includes, this call is not passing a forth parameter (f) required:
f is passed to local variable “frequency” and used to set the central frequency in the function:
rf12_xfer(0xA000 + frequency); // 96-3960 freq range of values within band
To cut to the chase, I don’t understand why the sketch compiles without error given this parameter mismatch. However, I know nothing about c++ compilers!
Without understanding this, I can’t work out exactly how the RFM69 is initialised. Any help would be appreciated.
I assume you’re using the JeeLib library for your emonTH2. That’s a minefield to find your way through. A long time ago, I picked it apart and simplified it into a ‘transmit-only’ version, calling it “rfmTxLib”, and you might find that easier to understand. rfmTxLib is totally compatible with the JeeeLib format.
Your reference documents are of course the Hope manuals for the RFM12B (if you have one) and the RFM69CW.
If you’re going to move the frequency around in the band, bear in mind that all your network needs to move.
Also bear in mind that the emonTx V4 has dropped the JeeLib radio packet format and now uses Low Power Labs library, so for forwards compatibility, you might consider moving to that. I looked briefly at it when I released the CM version on the emonPi, but rejected it as at the time OEM philosophy was that sensor nodes didn’t receive, plus the data rate chosen was a lot slower (that’s since changed). Other than that, I know very little about it. I might well be wrong, but I think LPL won’t work with the REFM12B.
I’m just reading through the published source code on the EmonTH2 github page and following through the includes in the Jeelib github repositories. Then I reference to the Hope manuals and the control commands and bit settings.
Sounds very useful. Is this available anywhere? Google couldn’t find the library.
To show the issue, the image below shows a waterfall of 11 seconds height taken from AirSpy software, with the receiver gain set to 30dB. I’ve labelled the EmonTx4 and EmonTx3 transmissions, which are wideband. The longer but narrowband transmissions are probably OOK Oregon weatherstation sensors or the alarm system (which should be 866MHz). Today, the noise peak is shifted from 433MHz to 434.2MHz, so may be a function of the receiver.
I looked further into compiler handling of function parameters in C++ and I gather that most would throw exceptions if too few parameters are passed. I may have to get a compiler running to check how the EmonTH2 source actually compiles.
Did you search here? - I’ve published it here in the forum many times.
Unsurprising given the data rate.
My advice would be to use the Arduino IDE. Platformio screwed my system up when I tried it - it took an evening to recover from the damage it did.
If you swap to LPL, you’ll need to compile and upload new sketches anyway.
