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.

CC2745R10-Q1: Inquiry About BLE Channel Sounding Distance Measurement Drift

Part Number: CC2745R10-Q1

Hello, TI support team

I am currently testing the Bluetooth Channel Sounding feature for distance measurement and have encountered an issue for which I would like to request technical support.

My current development environment is as follows:

  • SDK: SimpleLink Low Power F3 SDK v9.14.02.16

  • car_node:

    • CC2745 LaunchPad

    • Dual antenna configuration

  • key_node:

    • CC2340R53 LaunchPad

    • or a custom CC2340R53 hardware board

The observed behavior is described below:

  1. When the key_node remains stationary, the continuously measured distance values are relatively stable with only small fluctuations.

    For example:

    • The initial measured distance is around 160

    • Subsequent readings remain stable around this value

  2. However, if the key_node is slightly moved and then placed back to the original position, the measured distance changes significantly, even though the physical position is nearly unchanged.

    For example:

    • The initial stable value is around 160

    • After moving and placing it back, the stable value may become around 100

    • The new readings are also stable, but with a noticeable offset from the previous value

Currently observed characteristics:

  • The readings are stable over short periods when stationary

  • After repositioning, the measurement settles to a different stable value

  • Even after returning the device to the original location, the measured distance does not recover to the previous value

I would like to ask the following questions:

  1. Is this behavior considered normal for the current Channel Sounding implementation?

  2. Are there any possible solutions or recommended debugging methods for this issue?

Thank you for your support.

Best regards,

Jiahao Fan.

  • Hey Jiahao,

    Thanks for reaching out! 

    Is this behavior considered normal for the current Channel Sounding implementation?

    This is not the normal behavior. We expect some fluctuations in the distance measurements, however the results should stabilize fairly quickly. 

    Are there any possible solutions or recommended debugging methods for this issue?

    I would recommend modifying the size of the memory buffer that stores the values of previous measurements

    Best Regards,

    Tarek D

  • Hi Tarek,

    Thanks for your recommendation. I have a bit of confusion - how is the size of the cache area changed implemented in the car_node routine? Is it a change to a certain macro definition, or a change to the window size of the moving average filter?

                if (currSession->filteringDb.initDone == FALSE)
                {
                    // Init filters DB
                    currSession->filteringDb.initDone = TRUE;
                    currSession->filteringDb.lastTimeTicks = currTime;
                    deltaTime = ((float) currTime) / ((float) RAT_TICKS_IN_1S);

                    BleCsRanging_initSlewRateLimiterFilter(&currSession->filteringDb.srlfFilter, 3.0f,  gCsProcessDb.config.iirCoeff, BleCsRanging_SlewRateLimiterFilter_MA2);// Configure here, like MA4 or MA8.
                }
  • Hey Jiahao,

    I'm currently looking into the "best practice" for implementing this. In the mean time, modifying the size of the moving average filter is worth checking.

    Best Regards,

    Tarek D