Constantly getting BLE_GAP_EVT_DISCONNECTED although BLE traffic correct

[olgo]

I am working on a BLE to ANT (Specifically FTMP to FE-C) gateway.

HW used is the pca10059 dongle.

Windows10, Programmer 3.0.4, Segger 5.42a.

SW is nRF5_SDK_17.1.0_ddde560

Softdevice ANT_s340_nrf52840_6.1.1.

ANT part works and BLE part sort of works also but I cannot figure out why I am getting BLE_GAP_EVT_DISCONNECTED(GATT_CONN_LMP_TIMEOUT) every about 40s.

Being a newbie on BLE, I decided to start from the ble_hrs_c example and adapt it (also taking inspiration from ble_lbs_c. 

I registered a new UUID for the FTMP (0x1826) successfully.

I manage to connect to the FTMP trainer, which grants me a total of 10 services (had to increase the max # of services to 10 to get them all).

I save the cccd handles of my needed services and use them to request the bike to start transmitting data (does not work for some reason but not the issue of the ticket) and to get notifications from the bike data.

(I can get the nRF Connect app to get the bike to start transmitting data, it seems to remember the state)

All is well, the data appears and is converted to ANT and shows up on mt garmin watch.

BUT! For unknown reasons I keep getting this GATT_CONN_LMP_TIMEOUT every 40s, lose connection to the trainer and need to start over. It reconnects and loses connection 40s later.

If I do not use the cccd handles to request notification nor try to start the trainer via the not working service, I get the exact same behaviour so I guess it probably has nothing to do with them?

I am a bit blind and only have the LED outputs to lead my troubleshooting efforts (and sending debug data over ANT) since I haven't managed to get the log info to the USB port.

Any suggestions what might be causing the timeouts?

Thanks for any advice

/Ola

[Kenneth]

Hi,

An on-air sniffer log would be useful:
https://www.nordicsemi.com/Products/Development-tools/nrf-sniffer-for-bluetooth-le 
https://infocenter.nordicsemi.com/topic/ug_sniffer_ble/UG/sniffer_ble/intro.html 

I expect the problem here is that a procedure (e.g. dle or mtu exchange procedure) is initiated on one of the peers, but the other peer does not follow up/respond to the event. In such case the procedure will timeout after for instance 30-40 seconds, and the link will be terminated. If you are able to provide an on-air sniffer log it should be possible to take a look and see if one lack a response, else you will just have to go through the central and peripheral examples and check if there are some ble events that are missing handling in your code by comparing.

Kenneth

[olgo]

Thanks for your suggestion.

After some further reading up on BLE in general and connection handling specifically, I am leaning towards "connection parameter updates" or mtu exchange. Maybe there are other alternatives also, like DLE as suggested.

When I connect using the nRF Connect app (which succeeds without timeouts by the way) together with nRF logger, I can see in debug view that there are a few entries that I possibly do not comply with. I am unsure if they are handled inherently by the SD or if I need to add code for it:

- A number of Connection parameters updated (every 5s or so). Do I need to add code to handle this?

- A number of gatt.SetCharacteristicsNotifications (seems to be one per service). Do I need to add code to handle this? Could it be the cause of the timeout if I don't?

I cannot see any explicit MTU/DLE exchange or similar in the nRF Debug log, but maybe they are not visible?

I will see if I can find any example handlers for such exchanges in the BLE central examples.

Thanks again for your support.

[olgo]

Forgot to say that restarting the computers made no difference also.

Notably, both computers succeed in programming and debugging using Segger Embedded, but none can program using the nRF tool Programmer nor rfGo. I never get the possibility to Write although having erased all many times.

[Kenneth]

What software versions do you have compared to those listed in the user guide?
https://infocenter.nordicsemi.com/topic/ug_sniffer_ble/UG/sniffer_ble/min_requirements.html

Kenneth 

[olgo]

I do fulfill all the minimum requirements.

Just got a reponse from Michal in the other ticket concerning the sniffer that verifies my findings:

"

Unfortunately, there are some issues with the nRF52840 v3.0.x, because of the new interface MCU chip. They use nRF5340, while the old DKs used a Microchip IC (sam3u128).

Which is also why you cannot flash the firmware made for the old interface MCU on the new one. The firmware for the new interface MCU is not available for download at the time.

I will ask the developers about the current status, but I know that there is an issue with nRF Sniffer and a few other things not working properly on the new DKs.

"

[olgo]

I guess this leaves me with one last option: to use run the nRF sniffer on my nRF52840 Dongle instead.

I am however worried that flashing the dongle with the sniffer hex file will render my dongle not possible to reprogram without a debugger afterwards. I will have a look at the hex file for the sniffer, maybe it resides up in application space, then it shouldn't be a problem.

Can you verify that?

Thanks

[Kenneth]

Hi,

There is a guide here on how to reprogram the nRF52840 dongle if that will be required:
nRF52840 Dongle Programming Tutorial 

I suspect you will need to use the nRF52840-DK afterwards to reprogram the nRF52840 dongle yes. I was not aware of the nRF sniffer problem with the v3 of the nRF52840-DK, so thanks for letting me know.

You will find that the nRF sniffer if a very useful tool, so even you are experiencing a lot of hazzle with getting it to work at the moment, I believe it will be useful also for other issues you will or may experience.

Best regards,
Kenneth

[olgo]

Installing it using the dongle was a breeze, thanks. Wireshark now shows all BLE comms.

Also, I noticed it was located above the MBR so I decided to install it. I can still press reset to get back to "programming mode" so all seems well.

Best regards and thanks for great support,

/Ola

[olgo]

Just to sum it all up, in the end it was the MTU exchange that was missing, as suggested. No more timeouts after implementing it.

Annoyingly enough, I had already implemented that in the original "Dongle code" but had missed to increase the MAX_MTU_SIZE.

Cheers.

/Ola