EmonTH battery measurement accuracy

EmonTH battery measurement accuracy.

Before I’ve started investigation. I’ve setup EmoTH with
fully charged pack of batteries. After about two weeks
it was clear to see a discharging trend. But it’s very
difficult to see this trend during day. So I made small
experiment. I multiplied battery value not for 10 but for
1000. And result you can see here.

Approval math.
Atmega 328 have 10bit analog read with 3.3V reference voltage
This is about 0,00322265625 per tick. It should be enough to
have more or less accurate x.yz values instead of only x.y
In the same time we use int to send battery data so its should
be enough to send values multiply by 1000.

I think multiplication by 1000 is the last reasonable value
by two reasons.

  1. If we extend even more we can have some complex logic with
    integer during data transmitting. To ensure that we will not extend the range.
  2. As you can see on pictures measurement have some fluctuation. I assume that’s
    because of working DC-DC voltage regulator and battery inertia.

Thoughts? Is it worth of Github PR?

Nice idea, although is it really necessary since when monitoring battery voltage we’re more interested in long terms trends, e.g here’s a 6-month discharge cycle:

Fix in EmonTh firmware is quite easy. I can do PR very quickly.
But what about EmonCMS do we need to change multiplier there too?

Yes, the scales factor in the emonhub node decoder entry for the emonTH will need to be updated


    nodename = emonth5
       names = temperature, external temperature, humidity, battery, pulsecount
       datacodes = h,h,h,h,L
       scales = 0.1,0.1,0.1,0.1,1
       units = C,C,%,V,p

My concern with merged a PR for this is that users who do not update their emonhub config will have incorrect readings. I think it’s best if this is inserted in the code as a comment that a technically capable user who wants the extra resolution can uncomment, if required.

There is also the issue of battery life, transmitting more bits via RF will cause shorter battery life (although probably negligible)

Ok. Do I need to create PR for this file
Or may be this too
BTW what is it?

I don’t see any issue here. We are sending now 16-bit (2-byte) int, and we will continue to send int.

Hmm, wouldn’t it make sense to send the raw 10bit value (a 16bit slot is used anyway), then do all the scaling at the receiver side?
This avoids the overheads (especially size) of double precision float operations hidden in the map() routine.


Just this file, this is the main emonTH firmware


Yup, that’s another option. This would result in slightly increased battery life since the AVR would be doing less computation and spending less time awake. The same issue of users having to manually update emonhub config with new scale factor is still present. The question is, is the confusion, inconvenience and support issues that will arise due to the non-technical user getting incorrect Vbatt readings worth in increase accuracy? IMHO I don’t think so, In my mind, the battery voltage is just an indicator to alert the user when it’s time to change the batteries. The accuracy at present is sufficient for this.

1 Like

@glyn.hudson Quick question. Can I use map function or constant multiplier is better?

Please elaborate, with an example. Sorry I don’t quite understand.

take a look on example

Ah, I see. I think a constant multiplier would be better (less come computational intensive?). As I mentioned earlier I only intend to merge these changes as comments since changing the order of magnitude the battery voltage reading is transmitted via rf packets will result in existing users having incorrect reading unless they update emonhub.conf which is beyond some users.

Merged! Thanks :thumbsup:

Added example how to increase better battery measurement accuracy by skabashnyuk · Pull Request #10 · openenergymonitor/emonTH · GitHub

Example is added as a comment for reasons I mentioned earlier. User will have to enable manually by uncomment.