Post Go back to editing

ADE9000 xWATTHR register not reset

Category: Hardware
Product Number: ADE9000

Hello everyone.

We are building an energy meter with the ADE9000 and came across an issue with the xWATTHR register.

The ADE is set up to reset the register after every read, but every other hour we see a value twice the expected one.

This lets us think, that the register was not reset after the last read.

We are already reading the register twice to force a reset and decrease the probability of a skipped reset.

Is this an know issue?

Is there another way to ensure the register reset?

Thanks in advance!

Parents
  • 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.

Reply
  • 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.

Children
  • 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

  • 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

    212247
    212247
    212248
    282996
    212247
    212247
    212247
    212248
    212247
    282996
    212247
    212247
    212248
    212247
    212247
    212247
    282996
    212248
    212247
    212247
    212247
    212247
    282997
    212247
    212247
    212247
    212247
    212248
    282996
    212247
    212247
    212247
    212248
    212247
    212247
    282996
    212247
    212248
    212247
    212247
    212247
    282996
    212248
  • 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. 

    21:59:57.700 -> 495243
    00:01:40.673 -> 495243
    00:55:41.399 -> 495243
    01:33:47.036 -> 495244
    04:19:10.610 -> 495243
    06:03:50.603 -> 495243
    06:57:10.135 -> 495243
    07:58:29.972 -> 495243
  • 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