This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

UCD3138A: EMETER library - numerical errors at very light load

Part Number: UCD3138A
Other Parts Discussed in Thread: UCD3138

Hello, 

I am having a problem with the emeter library outputs.

At very light load I get numbers that have no realistic meaning, like if a variable was overflowing. I understand that at light load I cannot expect precision, but the results I am getting are not acceptable (it alternates between for example 10W and thousands of watts).

Initially the problem would start below 20W and after doing several rounds of calibration (and changing the emi_capacitance, see below comments) it improved significantly and now the problem surfaces below 6W.

Except for the no load problem, the measurements are fairly precise, so I think right now I have a good set of calibration coefficients. Do you have any advice on this?

Thank you

FIY: there is inconsistency between the spreadsheet file for the calibration and the app note SLUA744 (April 2015) for the E-metering solution regarding the value of emi_capacitance:

  • the app note states that this is the total capacitance of EMI filter + PFC input cap after the bridge
  • the spreadsheet says to include only the PFC input cap

Based on my results, it should be the PFC input cap only. Using the total capacitance (also EMI filter X-caps) would give me the numerical errors below at 20W load

Thank you

  • Hello,

    we will have an application engineer answer your question.

    Thanks ,
    Sanatan
  •  Hi Marco,

    Thanks for choosing UCD3138 and its emeter function.

    When you saw the abnormal input power report, what about Vin and Iin? Are they also abnormal? What is your pin_slope and pin_offset after calibration?

    You are right that  emi_capacitance should include only the PFC input cap before bridge rectifier. The application note was released before the 4-point calibration, we will update it.

    Regards,

    Bosheng

  • Hi Bosheng,

    thank you for your reply.

    pin_slope = 0  (this was the result after many calibration iterations, so the results where already ok I believe vs load)

    pin_offset = -17

    Vin_rms is very accurate and stable.

    Iin_rms measurement has a nonlinearity toward lighter load. It keeps decreasing as the loads gets lighter but then it increases again below 4W. 

    For example at 10W it is measuring about 100mA, but if I reduce the load it increases to 200mA. The power measurements instead does not have any meaning anymore.

    I am also monitoring pin_slow_filtered, whose filtering I have slowed down more compared to what originally in the EVM, but it is not enough. Before the calculation of pin_slow_filtered, I have also added a condition that ignores values of pin above 1kW. Still pin_slow_filtered indicates values that are completely off.

    The PFC at these power level is not switching continuously, that is why I understand that a precise measurement is not realistic, but I need somehow to avoid the values that are not meaningful at all.

    I tried to lower emi_capacitance below the nominal value of the capacitor I am using, hoping it was a matter of tolerance on that. After all, the measurement improved a lot using the correct amount of capacitance, but this did not help

    Thank you

    Marco

  • Hi Marco,

    The pin abnormal reporting is caused by the pin_offset = -17, you can change it to be 0. The pin_slope and pin_offset are trying to compensate the pin measurement error, assuming that the error is consistent across the entire load range. Since the emeter library uses unassigned variables for calculation, the -17 may cause the calculation overflow at light load. In your case, you can just ignore this function by setting both pin_slope and pin_offset to be 0.

    We do not use pin_slow_filtered in emeter calculation. Also, please read section 11 in app note SLUA744, "DO NOT ADD ANY NEW VARIABLES ABOVE THIS LINE".

    Regards,
    Bosheng
  • Thank you Bosheng.

    Thank you for the reminder about not adding anything above that line in variables.h, you had already helped me some time ago about this.

    I was using pin_slow_filtered to detect if pin had very high values that I was simply missing while refreshing in the memory debugger

    Setting pin_offset = 0 helped tremendously, but did not fixed the issue completely.

    I have setup a variable to detect the max value of iin_rms
    Whenever the PFC is not switching continuously (no load), the max value of iin_rms reaches often the value of 32767. After resetting it to 0 in the memory debugger, shortly after (1-2 sec) it is back to 32767. I was never able to catch this before as I did not have this kind of debugging active. This does NOT happen when the PFC is switching continuously (about 10-15W load) and the max value of iin_rms is the expected one.

    What can I do about iin_rms?
    My calibration values are
    iin_slope = 3128
    iin_slope_shift = 2
    iin_offset = 3
    iin_offset_shift = 5

    Thank you

  • Hi Marco,

    It may cause by iin_slope too big and cause calculation overflow. Can you change

    iin_slope = 3128
    iin_slope_shift = 2

    to

    iin_slope = 782
    iin_slope_shift = 0

    Regards,

    Bosheng

  • Hi Bosheng,

    somehow I gave you wrong info, I apologize. These are the settings that cause the overflow

    iin_slope = 2201;

    iin_slope_shift = 9;

    iin_offset = 3128;

    iin_offset_shift = 2;

    I have changed them to the following and it is still happening. Now also pin is overflowing again I think and I record 42,949,672 as max pin (resetting it to 0 goes back to this value shortly after)

    iin_slope = 137;

    iin_slope_shift = 5;

    iin_offset = 782;

    iin_offset_shift = 0;

    Thank you

  • Hi Marco,

    Are you using TI PFC code version 1.2?

    Regards,

    Bosheng

  • Hi Bosheng,

    yes, I started from version 1.2, and modified it based on my needs

    AC voltage is being sensed at AD00 and AD04, AC current at AD02. Dual sampling is enabled

    Thank you

  • Hi Marco,

    Please try the attached library.

    Regards,

    Bosheng

    ipm.lib

  • Bosheng,

    the PFC does not start when I use this library. I see the voltage loop increasing to maximum, but the current loop is clamped at minimum and so the duty cycle is 0

    Thank you
  • Hi Marco,

    How many ADC channels are you using? Did you use iv.adc_raw[3] to store the input current ADC measurement?

     

    Regards,

    Bosheng

     

  • Hi Bosheng,

    I am reading 4 channels. Correct, I am using adc_raw[3] for the current.

    When I re-compile with the new library you provided, the PFC duty cycle stays at zero

    Thank you

    Marco

  • Hi Marco,

    Please try the attached new library.

    Regards,

    Bosheng

    7571.ipm.lib

  • Hi Bosheng,

    the power measurement looks correct and it never records unreasonable numbers, but emeter_output.iin_rms is fixed at 783 (78.3mA) regarless of the load

    Thank you

    Marco