I need to review my aging OeM system (approx. 5 years old now) its all working fine, but its still running on a Rasp Pi 2B with an RFM69Pi V3 board.
I’m slowly moving all my Raspberry Pi projects over to a single virtual environment (ProxMox) rather than have several Pi’s scattered over the place.
I wish to maintain the RFM69 receiver comms to both a very old emonTX (original, running for 5+ years) along with an emonTH. Both of these run old code using RFM12 modules.
As I can’t get the SPI pins or a direct serial interface when using a virtual environment, I’ve created a USBSERIAL version of the RFM daughter board - this is using a USB serial interface, Attiny1624 and an RFM69CW chip.
This is my new board.
So to get to the crux of the matter… Software.
I’ve re-compiled the “emonBase_rfm69pi” code for the attiny1624, using the RFM69_JEELIB_NATIVE radio format, which is running/compiling, however I never receive a message over the RFM chip.
I can tell that the RFM chip is receiving a message by debugging the RFM library - REG_IRQFLAGS1 goes “true” when a message is received, but the IRQ2_PAYLOADREADY flag is never set, so no data packet is processed.
So my question: is the emonBase_rfm69pi code in RFM69_JEELIB_NATIVE mode supposed to be compatible with the radio packet format in rfm69pi_v3 code (from several years ago) ?
It looks like the rfm69pi_v3 processes raw packets of data in code, whilst the emonBase_rfm69pi code expects the RFM69 chip to do the decoding and CRC checks etc.
The RFM12 and RFM69 chips are all 434Mhz versions on both new and old devices.
The ‘old’ JeeLib code is what’s now called “JeeLib Classic”. This uses a slightly different message format to Hope’s RFM69 built-in message handling code, which probably explains why you get nowt out. To add to the complication, the RFM69 can also encrypt and decrypt on-chip, which is probably impossible (memory constraints, but I’d like to prove it one day) in most of out emonTx/emonTH legacy sketches.
It should be very simple to take my JeeLib-compatible transmit-only library to send with the LPL message format and r.f. parameters, but it wouldn’t do encryption, acknowledgements or transmitter power control.
It might help to look at the release post for the CM version of the emonPi
I’m committed for the next two days, I should be able to give you a bit more time later in the week.
That likely explains the issue I’m seeing, thanks @Robert.Wall
I think, I’m using a continuous monitoring sketch on the emonTX (Arduino style 328p), although knowing me, its likely to be modified! The hardware is in a waterproof case outside, so not easy to check the actual version.
If you can point me at your JeeLib-compatible library, that would be great - I don’t need encryption or the extras.
