CC2340R5-Q1: Effect of bus transfer speed on Connection Monitor

Hi, Ti

I saw this piece of code in the Connection Monitor project: （SDK：simplelink_lowpower_f3_sdk_7_40_00_64， project：connection_monitor_LP_EM_CC2340R5_freertos_ticlang）

    // With a 100ms connection interval we will skip 3 channels into the future (in each connection event we can monitor 1 channel)
    // This is mainly done to ensure that even a very slow bus is able to send the connection information in time
    // In time: before the Central/Peripheral already go past the channel that we chose to listen on
    // If Central/Peripheral are already past this point, we will have to wait numChannels*connInterval until we catch the
    // connection once again
    chanSkip = (uint16_t)((BUS_LATENCY_IN_MS/connInterval) + 1);

    // Catch anchor point n+2 connection intervals in the future
    ubCMConnInfo.ArrayOfConnInfo[i].scanDuration = (uint16_t)(connInterval*(chanSkip + 1));

    // DeltaTime is the distance between the current time and time we received the data for the new connection.
    deltaTime = uble_timeDelta(currTime, reqTime);

    // Figure out how many connection events have passed since the last anchor point
    if (deltaTime > connInterval * BLE_TO_RAT)
    {
      chanSkip += (uint16_t) (deltaTime / (connInterval * BLE_TO_RAT) + 1);
    }

    ubCMConnInfo.ArrayOfConnInfo[i].currentChan = setNextDataChan(sessionId, chanSkip); //jump some [ms] channels into the future

Two things are illustrated here.

1.This is mainly done to ensure that even a very slow bus is able to send the connection information in time.

2.If Central/Peripheral are already past this point, we will have to wait numChannels*connInterval until we catch the connection once again.

I'm thinking that if I transmit the connection parameters via LIN (at least 40ms, Split into multiple packets for transmission with 10ms transmission interval), odds are that I've already missed the target channel. But I still have no RSSI events after waiting longer than numChannels*connInterval. Are there any parameters I need to adjust?

Best regards

Preston

Preston,

The key thing that needs to be considered in that situation is the connection interval. It's likely that if you have a connection interval that is very quick, it will put more pressure on your system if you have a slower bus latency such as LIN. For example, with Android devices, it's common to use a 7.5ms connection interval in the beginning of the connection for GATT discovery, etc. During this time, there can also be channel map updates from the phone and so on so the device would need to react fast to that. That said, we have had other situations where similar devices have been in production with connection monitor leveraging LIN. If you set it to expect a larger bus latency, does the system work well? How large are you setting it?

Hi, Evan

I'm not quite sure what you mean by bus latency. Is it the time difference between the master sending and the slave receiving in the bus?

Also, I would like to confirm one thing, after the monitor succeeds in monitoring for the first time, will the monitor find the channel where the monitored object is located by itself, or will it make a fixed jump according to the rules of CSA1#? Is it difficult to continue monitoring if the first monitor fails?

Please help me explain these questions, thanks!

Best regards

Preston