Hi all
For some reason after about 7 years of constant use, my emonTH’s, emonTX’s and more, stopped being updated in my Raspberry Pi, which I assumed was caused by the RFM2Pi 868Mhz module attached to the Pi was faulty.
I was maybe a little hasty here, but my first attempt at a repair was to replace the firmware on the RFM2Pi, which didn’t help, but at least loaded successfully.
My next step was to replace the RFM69CW radio module (would not suggest trying this at home ), but again didn’t help.
If I now load minicom sudo minicom -D /dev/ttyAMA0 -b38400 I can see data arriving every 5 seconds (one of my self build emonTX energy monitor updates every 5 seconds), but not sure what exactly should be printed - here’s a screenshot.
Before I order a new RFM2Pi, anyone any ideas of how to confirm it’s actually faulty.
It’s anybody’s guess what this data is - the place to look is your emonTx, or whatever is sending the data.
If it’s like the software for the ‘standard’ emonTx (of whatever vintage), the code you’re looking for is like this
struct
{ // RFM RF payload datastructure
int temp;
int temp_external[NUM_EXTERNAL_TEMP_SENSORS];
int humidity;
int battery;
unsigned long pulsecount;
} emonth;
What this does is bundle an armful of integers (long and short, mostly signed) into a stream of bytes representing the numbers. As you know, to send a decimal as an integer, we cheat and multiply by 10 or 100, so the first 2 bytes - given the temperature outside here is 22.2°C would be 0x00, 0xDE - but they appear in reverse order, so DE, 00. Quite how they are represented as text characters - which is what you’re doing is open to interpretation, only bytes representing printable ASCII characters will make sense.
What you need to do is turn on a HEX representation - and Minicom help says it is -H, --displayhex
Then you pick apart the message pairs (or quads) of bytes at a time and decode it. The pseudo-code algorithm for a signed integer (they are - unless it says not) is:
x= ([1st byte] + ( [2nd byte] * 2^8) )
if x > (2^15)
x = (x - (2^16))
return x
or
x= ([byte 1] + ( [byte 2] * 2^8) + ( [byte 3] * 2^16) + ( [byte 4] * 2^24) )
if x > (2^31)
x = (x - (2^32))
return x
If the numbers make sense, your RFM69CW is working but not encrypted. If it’s encrypted, give up before you start.
Thanks Robert, it’s good to hear from you too.
I’m going to throw in the towel and order a new RFM2Pi (without RF) from OEM, as your post above has fried my simple brain
If it does not fix it, at least I’ll have a spare…
Sorry about that. I’m not surprised it doesn’t make sense. My brain tripped out on over-temperature 4 days ago.
What you’re seeing could well be OK, I don’t have enough information to be able to tell. Did you recompile the software with RFM69_JEELIB_NATIVE defined?
The usual reason for gobbledygook is a wrong baud rate?
Another may be incorrect firmware upload, does your board have the atmega328 or attiny84?
I assume we are expecting that standard serialised byte value packet format here, E.g:?
Yes it is before being decoded by emonHub but emonhub only decodes the above semi human readable byte value packet format. The RFM2Pi converts the raw binary from the radio packet into the space separated byte values first, so we should still be seeing an output that looks like:
OK 5 0 0 0 0 (-0)
I know you are familiar with this as you have written the code for this before
Early this morning I de-soldered the RFM69CW radio module in anticipation of the new RFM2Pi arriving, so can’t check any further at the moment.
Yes, correct. It’s what was reported in minicom.
In retrospect, I’ve dealt with this issue badly from the start. I should have paid more attention to diagnosing the problem instead of jumping to conclusions, and making wholesale changes.
@TrystanLea thanks for a speedy delivery of the RFM2Pi board, I’ve fitted a RFM69CW but unfortunately I’m not getting any output to /dev/ttyAMA0, there’s nothing at all via minicom.
Can you confirm that the firmware is pre-loaded (the shop ad suggests it is)?
The only brief sign of life is the small red led on the RFM2Pi lights momentarily upon power-up.
The RFM69CW is a new one (I decided to use it in preference to the one that I removed earlier from the old board).
Hello @Paul, thanks to @Gwil for the speedy delivery
Gwil confirmed that he uploaded the firmware by attaching the board to an emonBase and that the upload did complete successfully, but it’s not easy to test beyond that as the radio module is of course not connected.
Is your baud rate back to 38400?
Could you try stopping emonHub and go to Admin > Serial monitor and check the serial output from the device that way?
Yes, 38400, and it has remained so for the past 7 years.
I’m not using emonHub, I have used node-RED to format the data, store it in Influx, and display it in Grafana.
Node-RED has a serial in node to monitor specific serial ports, and nothing is being picked up (also nothing is being detected in minicom)
I’m still not convinced that the problem lay with the RFM2Pi, but I don’t know where else to look. It’s worked reliably for the past 7 years, and it just suddenly stopped in the middle of the night.
Thanks Brian, I was thinking the same, as the new RFM2Pi is displaying the same symptoms as the original RFM2Pi - just a blink of the onboard LED, and no output on /dev/ttyAMA0, so yesterday I rooted in my junk drawer (we all have one ) and found an old RFM12B module (that I didn’t know I had).
Although it works on a different baud rate, and the output format is slightly different, it worked OK, and I began receiving data on /dev/ttyAMA0 from two of my sensors (channels 10 & 18), but did not deliver data from EmonTH’s & EmonTX’s whose channels were in the 20’s ??
There is some dropout however, despite being in the same room as one of the sensors, and not getting consistent 5 second updates.
I did think it may of been a 434MHz module but according to Robert’s write up, I believe it’s a 868MHz (like my system)
I don’t understand this - even the old emonTx V2 went up to 29 or 30 (31 is reserved). JeeLib uses some bits in the integer that holds the Node ID for flags. Bits 7 - 5 are the flags, bits 4 - 0 the (source) Node ID. Radio Packet Formats.pdf (14.9 KB)
Even placing an EmonTH next to the RFM12B makes no difference, yet a temperature sensor 10mts away and through 2 walls using channel 18 reports reliably.
It just won’t handle signals from channels 20+
I’m sure I’ve read about this before, but despite googling I cannot find anything.
Maybe I’m mistaken.
), but again didn’t help.
