Question about EmonTX firmware. BATTERY_VOLTAGE_PIN


I am trying to understand this line of code in EmonTX firmware.

int battery_voltage=analogRead(battery_voltage_pin) * 0.681322727;                // 6.6V battery = 3.3V input = 1024 ADC

I don’t understand where “0.681322727” cames from.

I understand that the battery pack is connected at the input pin of MCP1702 IC; so ATMEGA is powered by 3.3V source.

EmonTX has a voltage divider (470k x 2) and an input to A7 to read the battery voltage.

So, as I understand, … battery_voltage wil be: analog_read(A7) * 3.3 / 1023 * 2 = analog_read * 0.0064516129

And 0.0064516129 * 100 to generate a integer: 0.64516129

But where does 0.681322727 come from ???

I am use that 0.681322727 will be the correct one, but I wish understand where it cames from.


I don’t know the answer to your question, so hopefully someone who does will chime in. Your maths seems sound to me. With regards:

I think you’re unlikely to get a sensible reading with a source impedance that high. Have a look at the scope trace in the second last post in this thread:

Maybe the larger than expected multiplier is an attempt to compensate for that, but I’d hope not, as the reading you get with such a high source impedance may well depend on what you last read with the ADC. A better solution might be to call analogRead() several times in quick succession.

Those resistor values are indeed correct according to the emonTx schematic, and the reason for choosing values as high as that is clear: battery drain. But as you say, it’s unlikely to properly charge the S&H capacitor in the ADC. I can’t provide any enlightenment regarding the derivation of the constant, it may even have been obtained empirically.

Hi again both of you.

the 470k values are taken from emontx v3.4 schematic, but my question is about the firmware. I don’t know if this “getting started” category is the rigth place to ask this question. Where does 0.681322727 come from ???


The short answer is: we don’t know. @glyn.hudson might be able to tell you.

Tbh I can’t remember! I believe it was a result of calculating the value as you have done above then multiplied by a calibration factor after empirical measurement with a calibrated multimeter. This was many years ago, I would have to revisit. Let me know if you think the calibration could be improved.

I think @dBC’s suggestion is the one to follow up: Set the calibration to the correct number as calculated, then do several measurements in succession until the value stabilises. Then compare that with your meter reading. Expect up to 2% uncertainty due to the resistor tolerances, plus some uncertainty due to tolerances in the 3.3 V regulators - another 1% if your emonTx is a.c. powered, or up to 1.75% (worst case) if it is powered from the USB connector or programmer. Then of course there’s the accuracy of your meter to consider.


After reading all of you I think the solution is to have a little cap as jeelab sugest here:

And about firmware, I think ATMEGA is powered by 3.3V, so 1023 anaog value is 3.3V. As voltage divider is a x2 factor, so I think that it will have to be:

int battery_voltage = analogRead(battery_voltage_pin) / 1024 * 3.3 * 2 * 100; //1023 or 1024 (there is always discussion about this). (x100 is to save 2 decimales in the int battery_voltage value

int battery_voltage = analogRead(battery_voltage_pin) * 0.64453125; //1023 or 1024 (there is always discussion about this)

Max value for the battery is 6.6V.

As @glyn.hudson says, the diference between 0.681322727 and 0.64453125 is about 5.7% so may be he check several times with a multimeter. But 5.7% is big.

Conclusion: I understand that 0.681322727 is an empirical value. I will add a 0.1uF cap.


1 Like