CC2745R10-Q1: [BLE 6.0 CS DKC]Long-duration ranging issue in Channel Sounding

Hello,

It seems that could be an overflow error related to the python script. I will assign this to a member of my team and they should get back to you next week.

Best,

Nima Behmanesh

Hello Preston, 

Is the test environment the same as the previous E2E thread? The environment communicated was 1-10m, with initiator within the vehicle. Testing LOS and NLOS situations? Is this still the case? 

When you say consistently report, is the invalid result (0xFFFF FFFF, or 429496795) always reported, or are you getting some valid results, but mostly invalid results? 

Is it possible to capture a sniffer log when the issue occurs? 

Additionally, a 9.11.01 release will be public by the end of this week. This SDK will include a large amount of CS problems. 9.12 was released to provide the initial SDK for our new MCUs coming to market. 9.11.01 will contain more CS related fixes. I would recommend switching to this SDK when released. 

In the meantime, please provide a response to the questions above, and let me know if a sniffer log is possible! 

Thanks,
Isaac

Hi, Isaac

We have only tested this issue in NLOS situations, with the test range remaining at 1-10 meters. By "consistently reporting invalid data," we mean the system always report invalid results (0xFFFFFFFF or 4294967295).

The tool for capturing sniffer logs requires an application process, which may take one to two days to arrange. However, if the new SDK is updated this week, I would prefer to prioritize validating the new version first. Thank you.

Best regards!

Preston

Hello Preston, 

I am going to run channel sounding tests on the 9.11.00.18 SDK, to see if I can reproduce on my side. Can you let me know what antenna configuration you are using, and the TX power being used? 

Understood that the sniffer takes some time to arrange. If possible, please provide a sniffer log of the error. Also, I recommend trying the 9.11.01 SDK when it is released today or tomorrow. 

As mentioned, I am working on testing this in the next few days and capturing a sniffer log as well. 

Thanks, 

Isaac

Hi, Isaac

I have configured the dual-antenna setup according to the documentation specifications, with both CC2340 and CC2745 following this configuration. The TX power is set to the default value of 0x80.

Best regards!

Preston

Hi, Isaac

I have received instructions to prioritize validating the new SDK. Would you mind informing me when the new SDK will be released?

We currently need to conduct a functional demonstration at the customer's site and hope to use the SDK with optimized Channel Sounding capabilities. Thank you.

Best regards!

Preston

Hello Preston, 

The newest SDK can be found here. The newest SDK version is 9.11.01.19. 

Let me know if you have any questions on the new SDK.

Additionally, the CC2745R10-Q1 has a max TX Power of 10 dBm, where the CC2340R5-Q1 has a max TX Power of 8 dBm. If you are using max TX power for each device, be sure to adjust the tx_power_delta accordingly (0x02 for CC2745R10-Q1 max TX Power to CC2340R5-Q1 max TX Power). 

Thanks,
Isaac

Hi, Isaac

I'm using the new SDK and have switched to the MUSIC algorithm following the previous approach, but found all reported distance values are invalid (When configured with the adaptive algorithm, only invalid values are produced; however, when configured with NN, valid range values can be obtained). Does the new SDK require additional configuration options?

The configuration method is as follows:

uint16_t CSProcess_OpenSession( void )
{
    uint16_t handle = CS_PROCESS_INVALID_SESSION;

    // Find an available slot
    for (uint16_t i = 0; i < CS_PROCESS_MAX_SESSIONS; i++)
    {
        if (gCsProcessDb.sessionsDb[i].isInitiated == FALSE)
        {
            handle = i;
            break;
        }
    }

    if (handle != CS_PROCESS_INVALID_SESSION)
    {
        // Mark the session as active
        gCsProcessDb.sessionsDb[handle].isInitiated = TRUE;

        // Clear filtering DB
        memset(&(gCsProcessDb.sessionsDb[handle].filteringDb), 0, sizeof(CSProcessFiltersDb_t));

        // Mark filtering as not initialized
        gCsProcessDb.sessionsDb[handle].filteringDb.initDone = FALSE;

        // Initialize BleCsRanging module configuration.
        // Note that numAntPath parameter is still unknown at this point
        // TODO: Make these values configurable from outside of the module
        BleCsRanging_initConfig(&gCsProcessDb.config);

        // Use adaptive algorithm
        gCsProcessDb.config.algorithm = BleCsRanging_Algorithm_Music;
        gCsProcessDb.config.distFusion = BleCsRanging_DistanceFusion_Min;

        gCsProcessDb.config.sumAntPath = BleCsRanging_MAP_Individual;

    }

    return handle;
}

Modify the algorithm to BleCsRanging_Algorithm_Music in the CSProcess_OpenSession() API.

Best regards!

Preston

The invalid value is 4294967295.Attached is the runtime log.

music_py.txt

Hello Preston, 

The MUSIC and Adaptive algorithm options are no longer available. We have switched the CS distance processing to a fully NN based system. Selecting the MUSIC and Adaptive algorithm options will yield invalid data results. 

Let me know if you have any other questions. 

Thanks,

Isaac

Hi, Isaac

Does this mean that the newly released SDKs will no longer support the MUSIC algorithm? Our previous testing was all based on the MUSIC algorithm. If we switch to the NN algorithm, we will need to reanalyze the channel sounding ranging data. We would like to confirm this with you.

Best regards!

Preston

Hi, Isaac

I will close this issue. Regarding the new SDK-related matters, I will track them in a new issue. Link:e2e.ti.com/.../cc2745r10-q1-channel-sounding-fixed-point-ranging-test-shows-abnormal-fluctuations-in-distance-values

Best regards!

Preston