ADE9000 xWATTHR register not reset

I'm seeing the same. Applying a constant test signal, will return a value that is twice the expected value. This happens completely randomly but with what looks like a ~1:50000 chance. It totally feels like a race condition or read-modify-write bug in the ADE9000 firmware. Would be great if one of the devs could have a look at the code.

I would suggest you use line cycle or sample based accumulation and read on irq or using the status register. 

What is the benefit of read with reset in your application as apposed to reading at a fixed period  based on line cycle or sample based? 

Dave

In my case the reading of the registers is synchronized to the wall clock down to a resolution of 100ms. It would maybe be possible to find a solution that does not need reading the WATTHR register with reset, but it would complicate our firmware and make it less accurate (in relation to the measurement timestamps). What I would probably do, if this is indeed a confirmed bug in the ADE9000.

If it's a bug, it should be documented at least, if not fixed in the ROM mask.

What may be helpful to you is sync your read to dready 

wait for time clock period then 

wait for dready using  irq or status

read registers

see if this helps.

As far as debugging this how often are you reading the registers? You mention 100 ms above is that the fastest you read. 

Dave

yes, I'm reading every 100ms.

yes, I'm reading every 100ms.

So far the only time I have had an issue is if the micro is servicing an IRQ. Can you add a time stamp when you read the energy registers?

I did my test without any inputs and only 1 channel for my test

epconfig = 0x21

1 write xIGAIN and xVGAIN registers to 0xF8000000 this will set gain to 0 and force datapath to 0 

ADE_SPI_WRITE(ADDR_AIGAIN,0xF8000000,0x4);

2 write Xwattos to any value. This is just  number to accumulate at the sample rate. I used 0x228BA2

 ADE_SPI_WRITE(ADDR_AWATTOS,0x228BA2,0x4);

in my loop 

void loop(void){
if (millis() - period_ms > 100)
{
period_ms = millis();
energy = ADE_SPI_READ(ADDR_AWATTHR_HI,0x04);
if(energy < 212000 | energy > 283000)
Serial.println(energy);
}

These are the values I read at 100ms and used this data to set if(energy < 212000 | energy > 283000)  

If I get any failures I will post later

thx for investigating, we will do such a test here as well.

It took a long time but I did see it  I started at 3:47pm I will try to sync to dready to see if this helps. This will take some time to understand what is going on hopefully syncing to dready is an option and it works. 

OK. good to know, I guess.

Interesting, that it took so long for the first wrong value to appear. after that, the error rate is pretty much what we see here.

good work!

You might want to try sample based accumulation which is crystal based

set samples count to 0

wait for 100ms to pass using rtc. 

set sample count to 800. You should get a new value every .1ms 

use egyrdy to determine if samples are ready

Dave

Ok I think I found  something. You are using read with reset so you should be able to do this. Set EGY_TIME to 1. This should have no impact but it seems to. I still need to figure out why. Let me know if this works for you. 

ADE_SPI_WRITE(ADDR_EGY_TIME, 1, 0x2);

We will test this, and I will let you know. Would be great if it worked, this would be an easy fix then. :) thanks for your tests!

My only concern is it may still happen but what the rate is I don't know still working on the why. 

sample based in still an option I tested with 800 using sample base accumulation and it work fine so does linecyc .

EGY_TIME 0x0 is also an option