Kinetis-M Two-Phase Power Meter using Filter Based Metering Algorithm

Showing results for 
Show  only  | Search instead for 
Did you mean: 

Kinetis-M Two-Phase Power Meter using Filter Based Metering Algorithm

No ratings

Kinetis-M Two-Phase Power Meter using Filter Based Metering Algorithm

Hello Kinetis community,

High accuracy metering is an essential feature of an electronic power meter application. Metering accuracy is a most important attribute because inaccurate metering can result in substantial amounts of lost revenue. Moreover, inaccurate metering can also undesirably result in overcharging to customers.

 The common sources of metering inaccuracies, or error sources in a meter, include the sensor devices, the sensor conditioning circuitry, the Analog FrontEnd (AFE), and the metering algorithm executed either in a digital processing engine or a microcontroller

In this post you will find the description of the implementation of a Two Phase Power Meter firmware featuring Kinetis KM34 device using a metering algorithm known as Filter Based Algorithm. The showed firmware was implemented on the hardware design described in the Reference Manual DRM149 (the software implementation shown in the DRM149 is using a more complex metering algorithm called Fast Fourier Transform).

Firmware Design

The firmware implements the basic functions for an e-meter application such as:

  • Power meter calibration: Performs power meter calibration and stores calibration parameters.
  • Data processing: Read digital values form the AFE and performs scaling.
  • Calculation of quantities: Calculates billing and non-billing quantities
  • HMI control: Updates LCD with the new values and transitions to new LCD screen.

Powe Meter Calibration

The calibration task runs whenever a non-calibrated power meter is connected to the mains. First it checks if the calibration flag is already stored in the microcontroller flash, if not, then it runs the calibration. More detail about the calibration process can be found in the DRM143 document.

The function:

int16 CONFIG_CalcCalibData (tCONFIG_FLASH_DATA *ptr)‍‍

is in charge of calculating the calibration data and store the calibration flag in the flash.

You can refer to the next code section for the complete usage and definition.

  /* if calibration data were collected then calibration parameters are       */
  /* calculated and saved to flash                                            */
  if (CONFIG_CalcCalibData ((tCONFIG_FLASH_DATA *)&ramcfg) == TRUE)
    CONFIG_SaveFlash ((tCONFIG_FLASH_DATA *)&ramcfg, ramcfg.flag);

The calibration task terminates by storing calibration gains, offsets and phase shift into the flash and by resetting the microcontroller device.

Data Processing

Reading the phase voltage and phase current samples from the analog front-end (AFE) occurs periodically every 166.6 μs. This task runs on the highest priority level (Level 0) and is triggered asynchronously when the AFE result registers receive new samples. The task reads the phase voltage and phase current samples from the AFE result registers, scales the samples to the full fractional range, and writes the values to the temporary variables for use by the calculation task.

While kWh values is being calculated every 6000 Hz the remaining quantities: kVARh, QAVG, PAVG, URMS and IRMS are being calculates every 1500 Hz (666.6 μs). This is according to the decimation factor and to reduce the CPU usage since those values are not needed every AFE sample.

The meter definition used for this application can be found in the meterlib2ph_cfg.h files, this file was generated using the Filter-Based Metering Algorithms Configuration Tool, for more information on how to use the tool you can refer to the AN4265 document.

This is the Meter configuration:


Here you can see the expected error behavior against Frequency:


The configuration of the AFE module and channels is the following:

  /* Current Phase 1                                                          */ 
  AFE_ChInit (CH0, 
  /* Current Phase 2                                                          */ 
  AFE_ChInit (CH1, 
  /* Voltage Phase 1                                                          */ 
  AFE_ChInit (CH2, 
  /* Voltage Phase 2                                                          */   
  AFE_ChInit (CH3, 
  /* AFE Initialization @ 6 KHz                                               */

As you can see only the CH3, which is measuring the Voltage phase 2, is configured with interrupt. During the CH3 callback the remaining channels are sampled to get the 4 values at the same time and performs scaling:

/* measurements callback @ 6000 Hz                                            */
static void afech3_callback (AFE_CH_CALLBACK_TYPE type, int32 result)
  static int cnt_1 = 0;
  if (type == COC_CALLBACK) 

    /* Current and Voltage reading                                            */
    u24_sample[0] = AFE_ChRead (CH2) << U_SCALE;            /* Voltage 1 reading ... */
    i24_sample[0] = AFE_ChRead (CH0) << I_SCALE;            /* Current 1 reading ... */
    u24_sample[1] = AFE_ChRead (CH3) << U_SCALE;            /* Voltage 2 reading ... */ 
    i24_sample[1] = AFE_ChRead (CH1) << I_SCALE;            /* Current 2 reading ... */

Calculation of Quantities

Within the CH3 interrupt the metering algorithm functions are called to process the data of the active energy, the calculation task scales the samples using calibration offsets and calibration gains obtained during the calibration phase:

  1. METERLIB2PH_ProcSamples removes DC bias from phase voltage and phase current samples together with performing an optional sensor phase shift correction.
  2. METERLIB2PH_CalcWattHours recalculates active energy using new voltage and current samples.
  3. CONFIG_UpdateOffsets updates offset of the phase voltage and current measurements conditionally.

The CH3 calls the next software interrupt, auxcalc_callback where non-billing quantities are calculated:

  1. METERLIB2PH_CalcVarHours recalculates reactive energy.
  2. METERLIB2PH_CalcAuxiliary recalculates URMS, IRMS, PAVG, QAVG and S auxiliary quantities.

You can find more information about the Filter-Based Algorithm function in the AN4265 document.


HMI Control

The display_callback task is called every 3 Hz by the auxcalc_callback and is executed on the lowest priority. For this application it update the clock data structure, refresh the watchdog timer and call some metering algorithm functions to read the values of the billing and non-billing quantities:

  1. METERLIB2PH_ReadResultsPh1 reads URMS, IRMS, PAVG, QAVG and S auxiliary quantities from phase 1.
  2. METERLIB2PH_ReadResultsPh2 reads URMS, IRMS, PAVG, QAVG and S auxiliary quantities from phase 2.

A timer interrupt is used to update the the LCD content every 1500 ms.

static void lptmr_callback (void)
  /* update menu index                                                    */
  if ((++menu_idx) >= DIM(menu_fcn)) 
    menu_idx = 0; 


The two-phase hardware has been calibrated using the test equipment ELMA8303. During accuracy calibration and testing, the power meter measured electrical quantities generated by the test bench, calculated active and reactive energies, and generated pulses on the output LEDs; each generated pulse was equal to the active and reactive energy amount kWh (kVARh)/imp3. The deviations between pulses generated by the power meter and reference pulses generated by test equipment defined the measurement accuracy.



The next figure shows the calibration protocol of the power meter. The protocol indicates the results of the power meter calibration performed at 25 °C. The accuracy and repeatability of the measurement for various phase currents and angles between phase current and phase voltage are shown in these graphs.

The first graph indicates the accuracy of the active and reactive energy measurement after calibration. The x-axis shows variation of the phase current, and the y-axis denotes the average accuracy of the power meter computed from five successive measurements


The second graph (on the bottom) shows the measurement repeatability; i.e. standard deviation of error of the measurements at a specific load point. 


You will find attached a ZIP file containing the IAR source code of the application and a PDF file showing the complete results of the protocol.

I hope the information helps.


Adrian Cano

Labels (1)
Version history
Last update:
‎09-10-2020 02:37 AM
Updated by: