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 in passive is lost without finishing the connection

Part Number: CC2642R-Q1


Hello,

I'm using a simple peripheral to connect to an iPhone. When the connection is established, the connection info parameters are sent through CAN to several passives. Each passive receives the connection info and starts CM.

After some iterations some of the passives loose the connection and the ones that are still connected start reporting the RSSI with lower delays between messages. The connection is set in the simple peripheral to not update the connection parameters. 

What could be the issue?

Than you and best regards,

Rodrigo.

  • Hi Rodrigo,

    Which SDK are you using? Do you have a sniffer log of the connection by chance? Would be interesting to see if the session drops during a channel map update or connection param update. 

  • Hello Evan, thank you for your answer

    I'm using 7.10.0.98 SDK. 


    What I've done is to send the connection info periodically from the peripheral to the passives and this stops the problem of the lower rssi report rate from them and also most of the times, the passives that were disconnected, connect again. However, there are still some times where a passive is not able to reconnect if it is not reset.

    At the moment I don't have a sniffer but I could try to get one.

  • Hello Rodrigo,

    If you could please use SDK 7.10.01.00

    If you could send a sniffer log that would be very helpful.

    In the meantime, I have a few questions to help debug this issue –

    • What iOS version and iPhone is being used? If possible please test with an android device and report on any changes.

    • How many passive devices are being used?

    • Do the dropped ones rejoin the ongoing connection after they are reset or does the entire setup need to be restarted to be able to get them to connect again?

    • Is this happening with the same passives every time or random ones? If it is the same passives then could you set up a debugger on the ones that disconnect and provide a screen-shot of the terminal output for the peripheral and passives?

    • Also, is this being used with the baseline version or a modified code? If modified, are you able to pass along the parameters used to setup the connection and/or the modified code?
    • You mentioned the passives are being connected via CAN and I wanted to verify that this is the automotive BUS Controller Area Network.
  • Hello Matt, thanks for answering

    • What iOS version and iPhone is being used? If possible please test with an android device and report on any changes.
      We are currently using 2 iPhones. iPhone 11 -> iOS 163.31 and iPhone 12 -> iOS 17.0.3

    • How many passive devices are being used?
      On my setup now, I'm using 2 passives but we have tested up to 7.

    • Do the dropped ones rejoin the ongoing connection after they are reset or does the entire setup need to be restarted to be able to get them to connect again?
      Only the dropped ones need to be reset. After the reset, they connect again. 

    • Is this happening with the same passives every time or random ones? If it is the same passives then could you set up a debugger on the ones that disconnect and provide a screen-shot of the terminal output for the peripheral and passives?
      It is happening randomly. Sometimes passive1 is failing, sometimes passive2 or sometimes both of them.

    • Also, is this being used with the baseline version or a modified code? If modified, are you able to pass along the parameters used to setup the connection and/or the modified code?

                 We are using the baseline version. Not many changes have been done, mostly the integration of CAN and skipping the params update.

    • You mentioned the passives are being connected via CAN and I wanted to verify that this is the automotive BUS Controller Area Network.

                 Yes, that's right

    Thank you and best regards,

    Rodrigo.

  • Hi Rodrigo,

    Thanks for the additional information. I would like to suggest that we verify the system compatibility with the CAN protocol. 
    I also want to reemphasize the importance of a sniffer log or if that is not possible, alternatively using a debugger to get device logs. Would this be possible?

  • Hello Rodrigo,

    I just wanted to follow up and see if there is an update, please let me know if this is an ongoing issue.

  • Hello Matt,

    For the moment, the solution of sending the updated connInfo periodically has solved our main problems. In the future we might go back to this topic.

    Thank you and best regards,

    Rodrigo.

  • Thanks for the info Rodrigo! I'm going to go ahead and mark this resolved and please feel free to reply to this thread to reopen the topic in the future

    Regards,

    Matt