EmonTH battery measurement accuracy

ksmster · 2016-08-19T20:34:17.790Z

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.

Знімок екрана 2016-08-19 23.07.04.png2880×1800 718 KB

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.

Знімок екрана 2016-08-19 23.13.35.png1982×946 134 KB

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 · 2016-08-19T21:54:37.405Z

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:

emonTH_batterylife.png1185×557 37.4 KB

ksmster · 2016-08-20T14:41:03.316Z

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 · 2016-08-20T15:21:25.632Z

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 · 2016-08-22T06:19:18.014Z

glyn.hudson:

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.

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?

glyn.hudson:

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

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

emjay · 2016-08-22T14:33:39.596Z

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 · 2016-08-23T00:33:39.826Z

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

emjay:

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.

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 · 2016-08-25T10:32:09.007Z

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

glyn.hudson · 2016-08-25T18:35:19.038Z

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

ksmster · 2016-08-25T18:37:40.851Z

take a look on example

aa9a86a1a45f9c36f667f66fe803e062447516b2.png1982×946 134 KB

glyn.hudson · 2016-08-26T15:18:01.877Z

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 · 2016-09-01T04:36:02.749Z

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.