EmonTH battery measurement accuracy

ksmster · 19 August 2016 20:34

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.

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.
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?

glyn.hudson · 19 August 2016 21:54

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:

ksmster · 20 August 2016 14:41

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?

glyn.hudson · 20 August 2016 15:21

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

github.com

openenergymonitor/emonhub/blob/emon-pi/conf/emonpi.default.emonhub.conf#L167

    
      
                 datacodes = h,h,h,h,h,h,h,h,h,h,h,L
                 scales = 1,1,1,1,0.01,0.01,0.01,0.01,0.01,0.01,0.01,1
                 units = W,W,W,W,V,C,C,C,C,C,C,p
          
          
[[15]]
              nodename = emontx3cm15
              [[[rx]]]
                 names = MSG, Vrms, P1, P2, P3, P4, E1, E2, E3, E4, T1, T2, T3, pulse
                 datacodes = L,h,h,h,h,h,L,L,L,L,h,h,h,L
                 scales = 1,0.01,1,1,1,1,1,1,1,1,0.01,0.01,0.01,1
                 units = n,V,W,W,W,W,Wh,Wh,Wh,Wh,C,C,C,p
                 whitening = 1
          
          
[[16]]
              nodename = emontx3cm16
              [[[rx]]]
                 names = MSG, Vrms, P1, P2, P3, P4, E1, E2, E3, E4, T1, T2, T3, pulse
                 datacodes = L,h,h,h,h,h,L,L,L,L,h,h,h,L
                 scales = 1,0.01,1,1,1,1,1,1,1,1,0.01,0.01,0.01,1
                 units = n,V,W,W,W,W,Wh,Wh,Wh,Wh,C,C,C,p
                 whitening = 1

e.g

[[23]]
    nodename = emonth5
    [[[rx]]]
       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)

ksmster · 22 August 2016 06:19

Ok. Do I need to create PR for this file
https://github.com/openenergymonitor/emonTH/blob/master/emonTH_DHT22_DS18B20_RFM69CW_Pulse/emonTH_DHT22_DS18B20_RFM69CW_Pulse.ino
Or may be this too
https://github.com/openenergymonitor/emonTH/blob/master/emonTH_DHT22_DS18B20_RFM69CW_Pulse/emonTH_DS18B20_in_DHT22_socket_Pulse/emonTH_DS18B20_in_DHT22_socket/emonTH_DS18B20_in_DHT22_socket.ino
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.

emjay · 22 August 2016 14:33

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.

glyn.hudson · 23 August 2016 00:33

Just this file, this is the main emonTH firmware

https://github.com/openenergymonitor/emonTH/blob/master/emonTH_DHT22_DS18B20_RFM69CW_Pulse/emonTH_DHT22_DS18B20_RFM69CW_Pulse.ino

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.

ksmster · 25 August 2016 10:32

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

glyn.hudson · 25 August 2016 18:35

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

ksmster · 25 August 2016 18:37

take a look on example

glyn.hudson · 26 August 2016 15:18

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.

glyn.hudson · 1 September 2016 04:36

Merged! Thanks

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.