CC2745R10-Q1: Connection Handover question. How to configure the candidate node params?

Hello Jiang, 

Please give me a few days to look through the project and attempt to replicate your problem. 

Firstly, what is the reasoning for fixing these variables? It seems you don't desire a specific value, so why not just keep the values the default? See the image below: 

Second, can you provide me the main goal for the connection handover implementation? What has been eliminated from the Car Node example pertaining to connection handover? 

Let me know, and I will provide a response by Thursday (07/10). 

Thanks,

Isaac

Hello Isaac,

Thank you for your response.

For your first question, we noticed that these variables are fixed in the `ble_device_connection_handover.py` script, as shown in the image below.

Additionally, the `handover_data["data"]` in the script corresponds to `pEvt->pData` in the `HandoverExtCtrl_startSnEvtHandler()` function of app_extctrl_handover.c, as shown in the second image.

Therefore, we fixed these variables, but the actual handover data is still coming from the serving node.

Regarding your second question, our goal is to implement the connection handover feature in one of our DK projects. We have referenced both the Car Node example and the SDK user guide (connection-handover.html) to integrate the connection handover functionality into our project.

Please let us know if there is any misunderstanding or if we missed any important details.

Looking forward to your feedback. Thank you very much!

Best regards,
Jiang

Hello Jiang, 

Ok, so you are attempting to move the connection handover demo into the C project and eliminate the python? 

I am still looking into the problem, but a quick recommendation. Try increasing the number of missed connection events. This would be a workaround I suppose, but it may work for the time being. 

Let me know. 

Thanks,
Isaac

Hi Isaac,

Yes, we are working to integrate the connection handover demo into the C project and remove the Python component. We have already tried increasing the number of missed connection events, but the issue still persists. I plan to test the connection handover function with the evaluation board as soon as it arrives, either today or tomorrow. I look forward to any further findings you may have regarding this issue.

Thank you,

Jiang

Hello Jiang, 

Can you run me through the steps you are moving from Python to C? I want to double check that nothing was missed. 

Additionally, it's difficult for me to test this specific case as I do not have a working connection handover project with everything moved to C. The MIC error indicates the packets sent between the peripheral and central failed. This can be due to a variety of reasons such as encryption/decryption problems, or if there is a collision between the encryption request and other packets. 

The unsuccessful handover is the important case. According to the stack, the only time the connection is terminated w/ handover failure is when the connection fails due to the link supervision timeout. 

What data are you transferring from the Serving node to the Candidate node? How are you transferring the data? 

Please let me know. 

Thanks,
Isaac

Hi Isaac,

We use a CAN message to initiate the handover process. Upon receiving this message, the serving node calls Handover_startServingNode(), as shown in the attached screenshot. The minGattHandle and maxGattHandle are calculated as indicated by the red rectangles.

After that, we obtain the handover data in HandoverExtCtrl_startSnEvtHandler, and then call HandoverExtCtrl_sendSnDataToCn to send the data to the candidate node using 5 CAN messages. In my case, the handover data length is 276 bytes, and the size of AppExtCtrlHandoverSnStartEvent_t is 12 bytes. We also append a 1-byte checksum (calculated over the previous 288 bytes) in HandoverExtCtrl_sendSnDataToCn, making the total data length 289 bytes.

When the candidate node receives all 5 CAN messages, it extracts the 276 bytes of handover data and calls Handover_startCandidateNode(). We have also verified the handover data on both the serving and candidate nodes by printing via UART, and the checksums match. This indicates that the handover data is being transferred correctly from the serving node to the candidate node.

Please let me know if you need any further details.

Thank you,
Jiang

Hello Jiang, 

We will reach out to the team to figure out what is happening with this problem. Apologies for the delayed response. 

Thanks,
Isaac

Hi Isaac,

Thank you for following up on this issue. We have made some discoveries that may help identify the root cause:

New Findings:
1. Time-dependent behavior with cell phones
When connecting a cell phone to the serving node, if we wait several minutes before initiating handover, the 0x3D error does not occur. This suggests there may be a connection stabilization period required before handover can succeed.

2. Device-specific behavior differences
iPhone: Handover generally succeeds on the candidate node
Android phone: Still experiences 0x3D (MIC_FAILURE) errors during handover

Why is there a several-minute stabilization period required? What causes the difference between iPhone and Android behavior?

Thank you,
Jiang

Hi Jiang,

Jiang Landa said:

1. Time-dependent behavior with cell phones
When connecting a cell phone to the serving node, if we wait several minutes before initiating handover, the 0x3D error does not occur. This suggests there may be a connection stabilization period required before handover can succeed.

Does this occur with both iPhone and Android?

Jiang Landa said:

Why is there a several-minute stabilization period required? What causes the difference between iPhone and Android behavior?

I'm not sure for the first question. The second question could be answered because the iOS stack and Android stacks have different implementations. An ellysis log of both may help us debug the issue.

Best,

Nima Behmanesh

Hi Nima,

For the first question, both iPhone and Android show the same behavior—both require waiting several minutes before initiating the handover to avoid the 0xFD error.

Regarding the ellysis log, the device is currently with our partners at another location. We will collect and share the logs as soon as the device is available again.

Thank you for your support.

Best regards,
Jiang