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.

CC2642R-Q1: [Connection Monitor] MicroCmApp_monitorCompleteEvt returns pCompleteEvt->status = 0x2

Part Number: CC2642R-Q1
Other Parts Discussed in Thread: CC2340R5

Tool/software:

My customer is using the connection monitor example on CC2642R-Q1 for PEPS application, and found the connection monitor lost track of the connection when the cell phone moves away about 10 meters from the central node. When the issue happened, pCompleteEvt->status was read to be 0x2 in MicroCmApp_monitorCompleteEvt.

SDK: simplelink_cc13xx_cc26xx_sdk_7_41_00_17(implemented the changes from CC2340 CM)

Test environment: on vehicle, CC2642 as anchor nodes, monitoring the connection between a cell phone and the central node on the vehicle.

Detailed description of the issue:

1. Start the connection monitor close to the central node(<4 meters), the connection monitor works fine, pCompleteEvt->status = 0x0 for most of the times, occasionally pCompleteEvt->status = 0x2 happens:

2. Moving the cell phone away from the central node, pCompleteEvt->status = 0x2 becaomes more frequent:

3. When the cell phone is 8 to 9 meters away, most events returns pCompleteEvt->status = 0x2:

4. Keep moving the cell phone away, the CM node lost track of the connection:

5. After the connection is lost, connection monitor requests for CM information and start a session again, while pCompleteEvt->status still returns 0x2:

When CM node lost track of the connection, the cell phone was actually still connected to the central node, and the RSSI was not very low. The target range is 50 meters, so the tested range has a quite large gap from the design target.

From the connection monitor code, we found 2 sets of macros related to this status value:

#define MONITOR_SUCCESS 0
#define MONITOR_CONTINUE 1
#define MONITOR_UNSTABLE 2
#define MONITOR_INVALID 3

and

#define CM_SUCCESS 0
#define CM_FAILED_TO_START 1
#define CM_FAILED_NOT_FOUND 2
#define CM_FAILED_NOT_ACTIVE 3
#define CM_FAILED_OUT_OF_RANGE 4

The connection monitor code seems to use both of the macros so I am not sure which one does it use when pCompleteEvt->status = 0x2.

The questions are:

1. Which macro does pCompleteEvt->status use and what does the 0x2 value represent?

2. What is the possible cause of pCompleteEvt->status = 0x2?

3. Why does the status not recovered with a new session?

4. Any suggestion to improve the performance?

Best regards,

Shuyang

  • Hello Shuyang, 

    Apologies for the delay, but I will provide a response by Wednesday (10/02). 

    In the meantime, what changes is the customer using from the CC2340R5 connection monitor project? 

    Thanks, 

    Isaac

  • Hello Shuyang, 

    1. I believe the 0x2 value represents the CM_FAILED_NOT_FOUND. 

    2. The cause of this event is that a Connection Monitor session was not found. Because of this the CM session will not stop, since a session is not found. 

    3. Can the customer log the sessionId and verify that it does not reach 0, or 8? In function ubCM_isSessionActive, an if statement checks the sessionId to see if it is set to 0, or greater than 8 (CM_MAX_SESSIONS). If this is the case, then it will return CM_FAILED_NOT_FOUND. 

    4. I am still looking into possible causes for the CM terminated after moving the phone away past 10 meters. If you could provide more information into what exactly the customer is implementing within the Connection Monitor example project, that would be helpful. Additionally, taking a sniffer log would be helpful in determining what is happening over the air while the Connection Monitor is showing this behavior. 

    Some additional questions: 

    Is there CAN/UART data being processed in between CM events in this implementation? What was added from the CC2340R5 Connection Monitor example? What is the setting for the test? It is strange that CM is failing with an RSSI read of ~-75 dBm. 

    Thanks, 
    Isaac

  • Hi Isaac,

    Thanks for the reply. The customer did find a few missing connection events are observed from a sniffer close to the cetnral side at the distance of 10 meters. Therefore the issue was probably caused by these missing connection events. There is a counter for the missing connection events in customer's application code, and it is possibly too small so the limit was reached at this distance.

    The customer will increase the limit of their counter and see if it fixes the issue, I will let you know if there are following questions, thanks.

    Best regards,

    Shuyang

  • Hello Shuyang, 

    Let me know if increasing the limit of the missed connections counter helps. Let me know if you have any additional questions!

    Thanks, 
    Isaac