Archived Forum

What voltage is your RFM12B low voltage detector set to?  I believe the default is 3.1 V. See the RFM12B data sheet for details.

If the RFM12B is detecting low battery, that could explain why the emonTx is locking up, which is your starting point.

Thanks for the hint. I'll check that. I'm guessing that isn't the issue but I'll use a cord and power adapter for a while to try it. My other emonTx is currently using 2 AA batteries and it works fine, often down to under 2.8 volts. Any idea why this one would be different? Is it worth changing the low voltage detector on the RFM12B? Have others done it? The documentation for the emonTX seems to suggest 2 AA batteries so I am assuming others aren't having that problem? 

You are correct in that the fuses were set to 3.3 volts not lower. Perhaps this should be added in the build notes or some where since it really needs to be corrected for people using batteries to power their emontx. Hopefully that will fix my freezing problems. Thanks.

Assuming that Low Battery was enabled, of course!  If not, it's back to the drawing board.

The next step would be to not transmit (OK, I know that defeats the purpose, but....) and see if it still locks up. If not, it looks like the RFM12B, if it still does, it might be the RFM12B and/or something else (and I'd start looking for dry joints that get disturbed when you check the batteries).

You do have the latest libraries, don't you? There were problems some months ago that were traced to a bug in the JeeLib library - see http://openenergymonitor.org/emon/node/1051
It doesn't sound like the same problem but worth updating the library used on both systems even so.

Okay, I'm still have major freeze up problems. I am trying to use the CurrentOnly version of the emonTxV3. Is that the latest version?

When I comment out the line with the call to send_rf_data(); then it seems to run. When I leave it in there, my emonTx freezes pretty much instantly. If I try and add a debugging comment to the function, I get a garballed character and it freezes like it's get a memory issue. If I try tracing it further, it's something in the sendNow command. 

I am using Arduino 1.5.2, Mac, and the latest RFu_JeeLib.h library. Any suggestions?

Or, I am debugging using a second emonTx and the same problem occurs. 

Wait a moment! What hardware do you have? emonTxV3 is for the new 4-ct emonTx that uses the RFµ module, not the Atmel328P.  I didn't think there were any emonTxV3's available yet.

(I see what you've done - mistaken the emonTx V2.3 for emonTx3 ! ! !)

If you have the 3 current, 1 voltage, pulse and temperature input emonTx (this one) then you should be using one of the emonTx_CT123.... sketches and the original JeeLib library.

(For what it's worth, my emonTx locks up instantly with the RFµ library, and the standard JeeLib library puts the RFµ's bootloader into an infinite loop and effectively 'bricks' it, so Glyn tells me).

Hi.. Thanks a lot. I didn't realize that a new hardware version of the emonTx is out. That was indeed was that problem. 

My initial problem seems to have been solved by changing the low voltage cut-off and dealing with the issue related to the sendNow function in the rfm library. Thanks a lot for solving that one. Read that whole thread and was very impressed how that turned out. 

Thanks again. 

Is there any problem setting the low voltage down to 2.7 volts or so? I basically don't want it to come on, since I'll receive a notice to change the battery well before that. 

The RFM12B is specified to work down to 2.2 V, and the AVR down to 1.8 V.

Bear in mind your battery voltage is measured relative to the internal reference, which has a 9.1% tolerance (1.0 - 1.2 V), so you need to measure the actual battery voltage and scale the voltage you are reading to match.

Okay, good point. But even with the 9.1% tolerance, I should be good down to well below 2.7 volts before I have problems. Likely, I should be able to hit 2.5 with no issues. Perhaps even 2.3 or 2.4 volts. Thanks.

Sorry, going through the code on the emonTx examples, I see that the emonTxV3 uses the new sendNow function while the emonTx uses the sendStart function. For those of us still using v1.3 and v1.4 hardware, should the emonTx code on Github be changed to use the sendNow? 

Or is this only important in the emonGLCD sketch which has already been changed? 

The problem was only seen with the GLCD. I suggest using the GLCD code throughout. You can find the thread about the problem with the GLCD locking up, you can read all about it.

Also, don't forget that transmitting uses a quite high current and as the battery becomes exhausted, the internal resistance rises and so the voltage you measure might not reflect the actual voltage whilst transmitting.