Watt-hour rollover in "ASCII with Wh" Packet

Ask questions about the GEM here.
Post Reply
lwe
Posts: 9
Joined: Thu Dec 23, 2021 2:53 pm

Watt-hour rollover in "ASCII with Wh" Packet

Post by lwe » Thu Jan 06, 2022 10:08 am

I configured my GEM system and reset all counters about a week ago, and have been logging output every 5 seconds using the "ASCII with Wh" packet. I noticed this morning that the watt-hour counter on one of my mains SPLIT-200 CTs rolled over, which seems very quick. I see a value of 167771 before it wraps around to 4.75. I also noticed that this rollover hasn't occurred on any other channel.

I'm trying to confirm what the mechanism for this rollover is so I know how to correct it.

I noticed in the docs that the internal seconds counter rolls over at 16777216, and that it uses a 24-bit counter. It looks like the Wh values are also tracked in a 24-bit counter, with the final 2 digits representing the hundredths decimal? So the fix in that case would be to detect when the new Wh is much lower than the previous, then add 167772.16 to it? I suppose I would need to track the cumulative number of rollovers as well.
ben
Site Admin
Posts: 4262
Joined: Fri Jun 04, 2010 9:39 am

Re: Watt-hour rollover in "ASCII with Wh" Packet

Post by ben » Thu Jan 06, 2022 3:15 pm

lwe wrote:
Thu Jan 06, 2022 10:08 am
I configured my GEM system and reset all counters about a week ago, and have been logging output every 5 seconds using the "ASCII with Wh" packet. I noticed this morning that the watt-hour counter on one of my mains SPLIT-200 CTs rolled over, which seems very quick. I see a value of 167771 before it wraps around to 4.75. I also noticed that this rollover hasn't occurred on any other channel.

I'm trying to confirm what the mechanism for this rollover is so I know how to correct it.

I noticed in the docs that the internal seconds counter rolls over at 16777216, and that it uses a 24-bit counter. It looks like the Wh values are also tracked in a 24-bit counter, with the final 2 digits representing the hundredths decimal? So the fix in that case would be to detect when the new Wh is much lower than the previous, then add 167772.16 to it? I suppose I would need to track the cumulative number of rollovers as well.
I'm currently out of the office due to COVID (feeling fine, just out of caution at this point). I'll check with Paul on Monday about that format.
Ben
Brultech Research Inc.
E: ben(at)brultech.com
Post Reply