Community
OpenEnergyMonitor

OpenEnergyMonitor Community

Emontx (Oct 2014) not working with continuous monitoring firmware

Hardware emonTx
#1

I jumped through all the necessary hoops (installing Atom and platformio, resolving dependencies, etc) and uploaded the continuous monitoring firmware found here to my emontx:
GitHub - openenergymonitor/EmonTxV3CM: EmonTxV3 Continuous Monitoring Firmware (Default shipped EmonTxV3 firmware). This caused my emontx to reset itself over and over again.
Since this is my first foray into the world of MCU firmware it took quite a bit of digging on these forums and in the code to discover that this version of the firmware does not support the rfm12b module supplied with my emontx (silk-screened Oct 2014).

Is rfm12b no longer supported? May I suggest a note at GitHub - openenergymonitor/EmonTxV3CM: EmonTxV3 Continuous Monitoring Firmware (Default shipped EmonTxV3 firmware) to warn people not to try what I tried!?
Trying to unbrick my emontx I uploaded the compiled .hex file found here to my emontx:
emontx3/firmware/compiled at master · openenergymonitor/emontx3 · GitHub
but that didn’t work either since it apparently was compiled with “#define RF69_COMPAT 1” forcing compilation to support the newer rfm69w module instead of the older rfm12b module. Again, if the rfm12b is supported I suggest that the appropriate .hex file should be supplied along side the one that supports the rfm69w…or at least provide an appropriate comment.

I see elsewhere here that @Robert.Wall has some code “in beta” to support the RFM12B with Continuous Monitoring. I would be willing to test this code. Is it accessible on the web somewhere?

Best
Chris

#2

Unfortunately, the RFM12B radio module does not have a usable internal buffer like the RFM69CW has, and when running emonLibCM there is insufficient processor capacity to be able to feed the radio data to the RFM12B one character at a time, on time, as the module needs. The result is, the data stream is interrupted and the message is corrupted.

If the radio transmission is important to you, then unfortunately you must, assuming of course that by “bricked” you do not in fact mean that you have permanently damaged your emonTx, reload the appropriate sketch that uses emonLib - the “discrete sample” version.

If you require continuous monitoring, then my best suggestion would be to use the serial output to feed the data to an ESP8266 or, as recommended by a colleague here, a Raspberry Pi Zero W, but the viability of that does depend on the rest of your system. Alternatively, if you have the necessary skills and access to a professional rework station, you could remove the RFM12B module and replace it with an RFM69CW. I don’t advise this course of action without those two things.

#3

Hmmm…I admit I am out of my depth here but why not turn off interrupts while radio transmission is occurring and turn them back on when done? See
https://www.arduino.cc/reference/en/language/functions/interrupts/interrupts/
As stated here:
https://jeelabs.org/2011/06/09/rf12-packet-format-and-design/index.html
the transmit speed is about 50 kbits/s
Assuming a payload of 14 bytes with jeelib packet overhead of 7 bytes. That make 168 bits which should take less than 4 ms to transmit.

#4

And then you lose samples, so it can no longer be claimed to be truly continuous monitoring. Accuracy will suffer, probably not significantly, and so if it’s ‘good enough’ for what you need, then that’s fine. emonLibCM was never intended to work with the RFM12B, which is why that wasn’t considered. But it’s not so simple, because JeeLib uses interrupts, so in fact it would be necessary to stop and restart the ADC.

#5

But you are already turning off interrupts in your code. Each call to writeReg (which is called multiple times in the rfm_send function) does this. And (again out of my depth) the sample code for the rfm12b (which can still be found here: https://www.sparkfun.com/datasheets/Wireless/General/RF12B_code.pdf) does not use interrupts as far as I can tell.
Also turning off interrupts for 4ms out of 10000ms (as you said) is not a significant loss of accuracy but perhaps I’m missing something. So perhaps it is a matter of degree… a few microseconds (not sure how to calculate this) without interrupts in the inner loop of rfm_send is ok but a few milliseconds is not???

#6

The main problem is the CM library and the transmitter library are separate. It would be very easy to link them in a dedicated sketch, but to maintain both libraries as general purpose libraries would introduce yet further complexity, for what I perceive to be an isolated use case. You’re welcome to adapt the published code however you wish - that’s the principle behind Open Source. I’m afraid I don’t have the time to take that on.