Acknowledged
over 1 year ago

Simulator v7.2.0 Bug: With Sim v7.2.0 BLE connections made with nRF dongle drop after connect

With Sim v7.2.0 BLE connections made with nRF dongle disconnect immediately, after a device has successfully paired and connected.

  • I looked into this issue using a Nordic Thingy52 and our test app. I didn't see any issues with the devices I tested (a couple Edge devices and some Fenix and Forerunners). The logging statements that we have in the OnCharacteristicWrite callback delegate showed that it was being called and used. 

    You may need to do what Jim suggested and add queueing or timeout logic in the application.

    I would assume that when you were switching between SDKs that the nRF dongle was connected and running, but just incase; Make sure the nRF dongle is already connected before starting the simulator.

  • @jim_m_58 I tracked this down further, buy switching forth and back between SDK 7.1.1 and SDK 7.2.0 and watching my app running with inserted debug statements. Running the same code with the same BLE hardware and context.

    Result is, that with 7.2.0 callback function onCharacteristicWrite of the BLEdelegate never fires. In 7.2.0, 10 seconds after onConnectedStateChange fired with CONNECTION_STATE_CONNECTED, it fires again with status CONNECTION_STATE_DISCONNECTED. While in 7.1.1 there is stable connection and datastream of BLE sensor device.

  • And 7.2.0 works fine with all my apps and the BLE devices I have.

  • Thanks for this hints. I will do some more investigation, e.g. by reinstalling the whole SDK. Until now, i can clearly prove: it works with SIM 7.1.0 / 7.1.1 and it stops working with SIK 7.2.0.

    No kind of queuing in my (simpledatafield) app.

  • Since CIQ BLE came out, I've seen the sim getting in an odd state (often due to an app crash), where simply closing the sim, cleared it up.

    In your app, do you have any queueing or timeout logic?  The projects I posted in the CIQ/Raspberry Pi blog post have a file called CommQueue.mc which is the main code for both.  Without proper queueing, things can get odd and having a timeout helps if things go odd.