MSP430FR6047: Processing issue with msp430fr6047 at specific sampling frequencies during flow conversion

Hi,

This behavior seems weird. Does the VFR calibration function in your project use the USS_calibrateVFRFlow() function provided in the USS library? Or you have a custom calibration function on your side. 

Best regards,

Cash Hao

Hi Cash,

You asked if I was using the library's USS_calibrateVFRFlow() function or a custom one. The direct answer is that I am not calling USS_calibrateVFRFlow() explicitly. However, after investigating, I've found that my method configures the library to apply the same logic internally.

Allow me to explain my implementation and compare it with the code you mentioned.

## My Current Implementation
My system works in two phases:

• Calibration Calculation (one-time setup): I have a module (calibration_logic.c) that calculates a linear piecewise correction curve. This module computes the slope and offset for each range and saves them into a table in RAM (miTablaCalibracionRuntime). The crucial step is that, at the end, I configure the TI library to use this table, as shown in this snippet from my apply_new_calibration_curve() function:
  

// --- Snippet from: calibration_logic.c ---

void apply_new_calibration_curve(void)
{
    // ... (calculation of new_slope and new_offset for each range i) ...

    // Update the calibration table in RAM
    miTablaCalibracionRuntime[i].iq16Slope  = _IQ16(new_slope);
    miTablaCalibracionRuntime[i].iq16Offset = _IQ16(new_offset);

    // ... (loop for all ranges) ...


    // --- THIS IS THE KEY CONFIGURATION PART ---
    // 1. Link the table and the number of points to the calibration object
    miObjetoCalibracionRuntime.pMeterConfiguration = &miTablaCalibracionRuntime[0];
    miObjetoCalibracionRuntime.numOfRanges = NUM_RANGOS_CALIBRACION;

    // 2. Select the flow calibration mode
    gUssSWConfig.algorithmsConfig->volumeCalibrationOption = USS_Alg_volume_flow_Calibration_Option_flow;

    // 3. Link my calibration object to the global algorithms configuration
    gUssSWConfig.algorithmsConfig->calibObject.flowCalibObject = &miObjetoCalibracionRuntime;
}

• Normal Measurement (in the main loop): During normal operation, my main loop only calls USS_runAlgorithms(). There are no subsequent calls to USS_calibrateVFRFlow() or USS_calibrateVolumeFlowRate().
  

// --- Snippet from: main.c ---

while(1)
{
    // ...
    code = USS_runAlgorithms(&gUssSWConfig, &algResults);
    // ...

    if (code == USS_message_code_valid_results)
    {
        // I directly use the results from the library.
        // algResults.volumeFlowRate already arrives CALIBRATED.
        // algResults.volumeFlowRateNoCalib arrives UNCALIBRATED.
        double rawVolumeFlowRate = algResults.volumeFlowRate; 

        // I pass the calibrated flow rate to my moving average filter
        ma_update(&ma_filter, rawVolumeFlowRate, &flowResults);

        // ... rest of the logic ...
    }
    // ...
}

The fact that USS_runAlgorithms() returns both volumeFlowRate (calibrated) and volumeFlowRateNoCalib (uncalibrated) indicates to me that the library is applying the calibration table internally, thanks to the configuration I provided.

## Comparison with the USS_calibrateVFRFlow code
I have analyzed the ussSwLibVFRCalibFlow.c file you hinted at, and indeed, the logic it contains is what I expect to be applied.

// --- Source code from TI library: ussSwLibVFRCalibFlow.c ---

USS_message_code USS_calibrateVFRFlow(
        USS_SW_Library_configuration *config,
        USS_Algorithms_Results_fixed_point *results)
{
    // ...

    // Save the uncalibrated flow rate
    results->iq16VolumeFlowRateNoCalib = results->iq16VolumeFlowRate;

    // Find the corresponding calibration range
    calibIdx = USS_findMeterConstantRange(
            config->algorithmsConfig->calibObject.flowCalibObject->pMeterConfiguration, 0,
            config->algorithmsConfig->calibObject.flowCalibObject->numOfRanges-1, iq16Volume);

    // ...

    // Apply the linear correction (y = mx + b)
    iq16TempMpy = _IQ16mpy(iq16Volume, flowCalibObj->pMeterConfiguration[calibIdx].iq16Slope);
    iq16Volume = iq16TempMpy + flowCalibObj->pMeterConfiguration[calibIdx].iq16Offset;

    results->iq16VolumeFlowRate = iq16Volume;

    return USS_message_code_valid_results;
}

The conclusion I've reached is that the mathematical operation is identical. My code prepares the calibration table and configuration, and the library, when executing USS_runAlgorithms(), applies that same table. The only difference is when and how the logic is invoked: in my case, it's implicit; in the flow you suggested, it's explicit after the measurement.

## Conclusion and Reframing the Problem
This confirms that the calibration logic I'm using is functionally correct and equivalent to the library's. Therefore, the error I observe at 8Hz and higher frequencies does not seem to be related to a flaw in the calibration method.

My main hypothesis returns to being that this is a computational bottleneck. The units that fail could be marginally slower, and at 8Hz and above, the cycle time (125 ms) is not enough to complete USS_runAlgorithms() and all my additional logic (mainly the moving average filter with outlier detection, which uses double arithmetic).

Thanks again for your help. It has been very useful in confirming that my calibration approach is sound.

Best regards.

Hi,

You calibration approach looks good to me. As you are saying the cycle time 125ms is not enough to complete the algorithm. I would suggest you can toggle a GPIO in the code before and after the calculation, then you will get exactly how long it takes to run those codes. 

Best regards,

Cash Hao