I do see a drop in voltage during really cold weather but it isn't much. To be honest I am measuring the voltage using the moteinos built in voltmeter that others have referenced, so I don't think method truly reflects the actual voltage drop. I have not tried to set up a proper voltage divider circuit to measure the actual battery voltage yet.Do you mean that you are using measuring the 1.1V reference voltage and extrapolating the VCC from that? If so, that's fairly accurate, even over temperature.
Tom, that is what I am doing. If that is correct, I am seeing voltage drops on the order of 100ths of volts on days where the temp is below zero F.WOW, that's pretty outstanding! Makes me want to switch to these! But wait... they don't spec these to work below 0 degrees C! What's up? I sure wish they'd spec what these are 'supposed' to do in 'normal' outdoor cold conditions. -15F spec would be very useful.
<...snip>Wish I had a CNC router! ;DBuild one! That's what I did. Check out http://www.solsylva.com/
http://www.panasonic-eneloop.eu/home/whats-eneloop.htmlThanks. ::)
Hi There. Here is my first eneloop crash. Was fairly liner down to 3.6v (mid jan) then fall sharply to 3.3v Interesting is what happened when it reach 3.3v Node is still running fine. Thoughts ?3.6 volts is where 3 ENELOOPs in series would hit the knee - 1.2V each. While it may have taken a temporary slow down (maybe due to reduced current) at 3.3V, I'd expect the battery to continue to decay until the mote stops operating.
Yes end of summer, In the last week Max = 28, down to 19 degrees C at night. Will see how much longer it lasts and report back latter.
You're currently in your Summer months, right? What's the ambient temperature?
Tom
Your latest curve is intriguing - that it's totally flat once it reached 3.3V. What circuit and what code are you using to measure the voltage?I have 2 x 1Mohm as a voltage divider with a 0.1uf capacitor as per the following post.
Tom
#define VOLTAGE 3.3 // Motes run on DC 3.3V
/**
* Main Publish Battery Function
*/
void publishBattery() {
// the pin is defined based on configuration.
static byte pin = A0 + configuration.batteryAPin;
// what is the voltage. "batteryFactor" is configured as 0.5 (i.e. resistor divider), 1000 reports in miliVolts
batteryVoltage = readVoltage( pin ) / configuration.batteryFactor * 1000.0f;
// sent the battery voltage, this packages and sends a RFM69 packet.
sendPublishMessage( MEASURE_BATT_MV, batteryVoltage );
}
/**
* the analog volatge from an analog input pin
*/
float readVoltage( int sensorPin ) {
// make sure iys an input pin
pinMode( sensorPin, INPUT);
// read and discard once
analogRead(sensorPin);
// Volatage = Reading / 1023 {magnitude of reading} * 3.3 {volts that the reading represents}
return VOLTAGE * ( analogRead(sensorPin) + analogRead(sensorPin) ) / 2 / 1023;
}That's what I suspected. This will ALWAYS read around 3.3V even if the battery is 2.5 volts. Why? Because your voltage reference, VDD, is tracking the measured voltage. The measuredVoltage will always read 0.5 of VDD... You need a correction factor that measures VDD compared to the internal 1.1V reference such that BatteryVoltage = (MeasuredVDDmV/3300)*(calculatedBatteryVoltage)...Your latest curve is intriguing - that it's totally flat once it reached 3.3V. What circuit and what code are you using to measure the voltage?I have 2 x 1Mohm as a voltage divider with a 0.1uf capacitor as per the following post.
Tom
http://jeelabs.org/2013/05/16/measuring-the-battery-without-draining-it/
The code (except) is below, basically it just does and analogRead() and computes and publishes a voltage, this is called once a minute. I haven't posted this on GitHub - yet.
KiwiCode: [Select]#define VOLTAGE 3.3 // Motes run on DC 3.3V
/**
* Main Publish Battery Function
*/
void publishBattery() {
// the pin is defined based on configuration.
static byte pin = A0 + configuration.batteryAPin;
// what is the voltage. "batteryFactor" is configured as 0.5 (i.e. resistor divider), 1000 reports in miliVolts
batteryVoltage = readVoltage( pin ) / configuration.batteryFactor * 1000.0f;
// sent the battery voltage, this packages and sends a RFM69 packet.
sendPublishMessage( MEASURE_BATT_MV, batteryVoltage );
}
/**
* the analog volatge from an analog input pin
*/
float readVoltage( int sensorPin ) {
// make sure iys an input pin
pinMode( sensorPin, INPUT);
// read and discard once
analogRead(sensorPin);
// Volatage = Reading / 1023 {magnitude of reading} * 3.3 {volts that the reading represents}
return VOLTAGE * ( analogRead(sensorPin) + analogRead(sensorPin) ) / 2 / 1023;
}
Tom thanks, I understand your point, but am happy with the solution I have at the moment, basically I just need pre warning when a node is about to die. And BtW the node did die in the last day.I think your indication that it's about to die is when it flatlines to 3.3V :)
Kiwi
I think your indication that it's about to die is when it flatlines to 3.3V :)Correct, <3.6V is advance notice, <3.4v expect it to die soon.
So, now that you've successfully used up your charge on the Eneloops, how do you like them?
Tom
Correct, <3.6V is advance notice, <3.4v expect it to die soon.It would be a pretty simple software mod to know, exactly, what you're battery voltage is. If you compensate with the VDD reading, then, as long as VDD is 3.3V (ie, the batteries are supplying enough voltage for the regulator to be operating within its control range) then your direct reading will be accurate, but once your VDD reading starts dropping off, then the scaled reading will still give you an accurate reflection of battery state.
I think I choose them because of ease of maintenance. I have an apple charger which you just plug these into. A Lipo (my reading) needs a special charger circuit, and I have read numerous report of them being affect by low temperatures. Sydney does drop down to a few degrees above zero at night in winter months, so I saw this as a more reliable option.
Getting 1-2 years off a single charge is perfectly adequate solution, and could very easily extended by reducing the frequency of sampling and transmitting data.