0

BlueFruit NRF52 problem with recurring disconnects
Moderators: adafruit_support_bill, adafruit

Please be positive and constructive with your questions and comments.

BlueFruit NRF52 problem with recurring disconnects

by _Joost_ on Sat Sep 22, 2018 2:24 am

Hi everybody,

thanks for helping each other and thanks to Adafruit for this cool little board (Feather NRF52).
I am currently building a bike computer head unit consisting of the feather, a tiny 300mAh LiPo and a small ePaper display (which works well already); later on all fitted in a 3d printed case.
The sensor on the bike in use is commercially available, it is a Wahoo Speed Sensor implementing the Bluetooth CSC specifications.

https://eu.wahoofitness.com/devices/bike-sensors/bluetooth-speed-sensor?stay
https://www.bluetooth.com/specifications/gatt/viewer?attributeXmlFile=org.bluetooth.service.cycling_speed_and_cadence.xml

I successfully implemented a working prototype using the Espruino Pixl.js (my working code example can be found here http://forum.espruino.com/conversations/323575/), managing to connect to the sensor without unwanted disconnects.

Now, switching to the Feather for size reasons and easier interfacing of the ePaper display, I have the following code (copied directly from my IDE, this exact code exhibits my problem), adapted from the HRM API example:

Code: Select all | TOGGLE FULL SIZE
#include <bluefruit.h>

BLEClientService speedsensorservice(UUID16_SVC_CYCLING_SPEED_AND_CADENCE);
BLEClientCharacteristic speedsensorcharacteristic(UUID16_CHR_CSC_MEASUREMENT);
uint32_t millis_connect,millis_disconnect; float connect_duration;

void setup()
{
  Serial.begin(115200);

  Bluefruit.begin(0, 1); //peripheral, central
  Bluefruit.setName("Bluefruit52 Central");

   speedsensorservice.begin();
  speedsensorcharacteristic.setNotifyCallback(csc_notify_callback);
  speedsensorcharacteristic.begin();

  Bluefruit.Central.setDisconnectCallback(disconnect_callback);
  Bluefruit.Central.setConnectCallback(connect_callback);

  Bluefruit.Scanner.setRxCallback(scan_callback);
  Bluefruit.Scanner.restartOnDisconnect(true);
  Bluefruit.Scanner.setInterval(160, 80); // in unit of 0.625 ms
  Bluefruit.Scanner.filterUuid(speedsensorservice.uuid);
  Bluefruit.Scanner.useActiveScan(false);
  Bluefruit.Scanner.start(60);                   // // 0 = Don't stop scanning after n seconds
}

void loop()
{
}

void scan_callback(ble_gap_evt_adv_report_t* report)
{
  Bluefruit.Central.connect(report);
}

void connect_callback(uint16_t conn_handle)
{
  millis_connect = millis();
  Serial.printf("Connected at %d\n", millis_connect);
  Serial.print("Discovering CSC Service ... ");

  if ( !speedsensorservice.discover(conn_handle) )
  {
    Serial.println("Found NONE");
    Bluefruit.Central.disconnect(conn_handle);
    return;
  }
  Serial.println("Found it");Serial.print("Discovering Measurement characteristic ... ");
  if ( !speedsensorcharacteristic.discover() )
  {
    // Measurement chr is mandatory, if it is not found (valid), then disconnect
    Serial.println("not found !!!");Serial.println("Measurement characteristic is mandatory but not found");
    Bluefruit.Central.disconnect(conn_handle);
    return;
  }
  Serial.println("Found it");

  if ( speedsensorcharacteristic.enableNotify() )
  {
    Serial.println("Ready to receive CSC Measurement value");
  }else
  {
    Serial.println("Couldn't enable notify for CSC Measurement. Increase DEBUG LEVEL for troubleshooting");
  }

  Bluefruit.printInfo();

}

void disconnect_callback(uint16_t conn_handle, uint8_t reason)
{
  (void) conn_handle;
  (void) reason;

  millis_disconnect = millis();
  Serial.printf("Disconnected due to reason nr. 0x%x\n", reason);
  Serial.printf("Disconnected at %d\n", millis_disconnect); connect_duration = (millis_disconnect - millis_connect)/1000;
  Serial.printf("Duration: %f sec\n", connect_duration);
}

void csc_notify_callback(BLEClientCharacteristic* chr, uint8_t* data, uint16_t len)
{
  uint16_t current_wheel_revolutions;
  if ( data[0] & bit(0) )
  {
    memcpy(&current_wheel_revolutions, data+1, 4);
  }

  Serial.printf("Wheel revolutions: %4d\n" ,current_wheel_revolutions);
}


This establishes a connection successfully and receives the CSC notifications via csc_notify_callback, but in contrast to the Espruino impementation suffers from recurrent disconnections every 70 seconds. This is the console output:

[Starting] Opening the serial port - /dev/ttyUSB0
[Info] Opened the serial port - /dev/ttyUSB0
Connected at 1941
Discovering CSC Service ... Found it
Discovering Measurement characteristic ... Found it
Ready to receive CSC Measurement value
--------- SoftDevice Config ---------
Max UUID128 : 0
ATTR Table Size : 2048
Service Changed : 0

--------- BLE Settings ---------
Name : Bluefruit52 Central
Max Connections : Peripheral = 0, Central = 4
Address : CF:86:12:67:1E:0B (Static)
TX Power : 0 dBm
Conn Intervals : min = 20.00 ms, max = 30.00 ms
Peripheral Paired Devices:

Central Paired Devices:


Wheel revolutions: 83
... (going on 70secs; receiving correct data as I did not revolve the sensor - revoloving the sensor does not change the disconnect interval)
Wheel revolutions: 83

Disconnected due to reason nr. 0x13
Disconnected at 71993
Duration: 70.000000 sec
Connected at 72327
Discovering CSC Service ... Found it
Discovering Measurement characteristic ... Found it
Ready to receive CSC Measurement value
--------- SoftDevice Config ---------
Max UUID128 : 0
ATTR Table Size : 2048
Service Changed : 0

--------- BLE Settings ---------
Name : Bluefruit52 Central
Max Connections : Peripheral = 0, Central = 4
Address : CF:86:12:67:1E:0B (Static)
TX Power : 0 dBm
Conn Intervals : min = 20.00 ms, max = 30.00 ms
Peripheral Paired Devices:

Central Paired Devices:

Wheel revolutions: 83
Wheel revolutions: 83


Now, the disconnect reason is reported as 0x13 (GATT CONN TERMINATE PEER USER). The completely regular interval of 70 seconds reminds me of some kind of timeout triggering the disconnect (btw., not prolonged if using/revolving the sensor). I found very sparse hints as to the cause and only stumbled over these threads:

https://github.com/adafruit/Adafruit_nRF52_Arduino/issues/100
https://devzone.nordicsemi.com/f/nordic-q-a/27066/ble-central-disconnect-after-exactly-65-5-sec (coincidentally started by Gordon Williams, the creator of Espruino - he seems to have solved this problem...)

Can anyone shed some light on the reason for these disconnects happening and help me get a stable connection to the sensor?
Thanks everyone for reading this long post and for any comments,

Joost

_Joost_
 
Posts: 11
Joined: Sat Sep 22, 2018 1:57 am

Re: BlueFruit NRF52 problem with recurring disconnects

by jps2000 on Sat Sep 22, 2018 4:04 am

It is likely the same ploblem like this:

https://github.com/adafruit/Adafruit_nR ... issues/183

>>Ok, adding a BLE_GAP_EVT_CONN_PARAM_UPDATE_REQUEST handler seems to have fixed the central mode issue........

Need to wait till hathach or others find resources to resolve this

Though its cold comfort : you are not alone with this problem.

In fact bluefruit52 does not handle central mode correctly now. Hence it fails with commercial peripherals.

thanks

jps2000
 
Posts: 405
Joined: Fri Jun 02, 2017 4:12 pm

Re: BlueFruit NRF52 problem with recurring disconnects

by _Joost_ on Sat Sep 22, 2018 7:47 am

Thanks for your information; fwiw here is a corresponding GitHub issue now: https://github.com/adafruit/Adafruit_nRF52_Arduino/issues/185

Should anyone know of a workaround, perhaps using the Nordic SDK directly, please give us a hint! I believe we would need to catch the BLE_GAP_EVT_CONN_PARAM_UPDATE event and respond accordingly, but am completely in the dark as to how to receive this event.

Thanks, Joost

_Joost_
 
Posts: 11
Joined: Sat Sep 22, 2018 1:57 am

Re: BlueFruit NRF52 problem with recurring disconnects

by hathach on Mon Sep 24, 2018 2:18 pm

thanks for posting the issue, as @jps2000 said, we are prioritizing the release of nrf52840. Please be patient, we will address this issue later. BLE Central isn't used much, so there may be bug here and there.

hathach
 
Posts: 986
Joined: Tue Apr 23, 2013 1:02 am

Re: BlueFruit NRF52 problem with recurring disconnects

by jps2000 on Tue Sep 25, 2018 1:00 am

@hathach
thanks
are you talking about weeks, months, year(s)?
problem should be same in 52840 .......
so PLEASE, PLEASE, PLEASE,

jps2000
 
Posts: 405
Joined: Fri Jun 02, 2017 4:12 pm

Re: BlueFruit NRF52 problem with recurring disconnects

by hathach on Tue Sep 25, 2018 1:08 am

there is no ETA, since I am working on both front Arduino & CircuitPython, this takes a bit longer than expected. I will switch back to troublshooting after nrf52840 could reach a decent workable state e.g usb cdc, msc + qspi flash is running, all peripherals are working, most of popular lib is compatible etc .... And we are close to that already. But many minor things still need to be correct. Please be patient :D

hathach
 
Posts: 986
Joined: Tue Apr 23, 2013 1:02 am

Re: BlueFruit NRF52 problem with recurring disconnects

by _Joost_ on Wed Oct 03, 2018 12:12 pm

Hi,

is there any progress on this topic?
I imagine this kind of setup with the nRF52 as a Central might be more common than thought of and perceive the current incomplete/buggy firmware unsatisfactory for a commercially sold product.

Thank you & best regards,

Joost

_Joost_
 
Posts: 11
Joined: Sat Sep 22, 2018 1:57 am

Re: BlueFruit NRF52 problem with recurring disconnects

by jps2000 on Wed Oct 03, 2018 1:14 pm

I do no think so. It would have been announced solved at github..
It is at our own risk to use open source stuff for a commercial product. And in the tutorial they mention that it is still work in progress.

What I would like to understand is why the hell the Bluetooth group has foreseen this parameter update request.

As mentioned the Polar H7 HRM peripheral disconnect every 60 seconds. I just got another chinese HRM with RR output which does not disconnect. That means the buggy bluefruit52 central example works fine with that HRM.
So it seem the protocol followed is not the same in all products. - a real fun for testing and release.

jps2000
 
Posts: 405
Joined: Fri Jun 02, 2017 4:12 pm

Re: BlueFruit NRF52 problem with recurring disconnects

by p2w on Fri Oct 05, 2018 5:04 am

Hey _Joost_,

I am using an BlueFruit Feather nRF52 board for connecting to our cycling power meter all the time and do not experience these disconnects - it is rocksteady. My device updates parameters every 30 seconds.

Seems to me this is some very weird specific problem. I don't catch the connection parameter update events either. Any idea what the connection parameters look like on the device you connect to? Could it be the device wants to reduce power consumption by offering (too) slow connection intervals only? Does your disconnect() callback report a reason for disconnection?

(Edit: hold on, it says so in your post. 0x13 means nothing really, just "BLE_HCI_REMOTE_USER_TERMINATED_CONNECTION". Seems to me the device disconnects for its own reason. Prolly because the timing parameters could not be satisfied? We just don't know... "check the logs Luke!". A BLE sniffer could provide a bit more insight.

Anyway, in SDK 15 (sorry, not sure which version bluefruit was based on and too lazy to check) allows a handler to be installed in ble_conn_params_init() but that handler AFAIK just gets BLE_CONN_PARAMS_EVT_FAILED and BLE_CONN_PARAMS_EVT_SUCCEEDED info (see ble_conn_params.h). You'ld have to instrumentate more in the SDK I guess.

Ciao, Joost

p2w
 
Posts: 83
Joined: Fri Dec 15, 2017 5:29 am

Re: BlueFruit NRF52 problem with recurring disconnects

by _Joost_ on Tue Oct 16, 2018 8:20 am

Hi everybody and thanks p2w for your reply;

the situation seems to be that the Arduino BSP for the Feather (in Central role) does not respond to connection parameter update requests by the peripheral, which leads to dropping connections by certain peripherals.
Lately I had seen that in BSP 0.8.6 a setter for supervision timeout is available, but manually setting the required values (I can see those via nRF Connect on Android) in connect_callback() on the Feather nRF52 Central did not convince my BLE peripheral to stay connected. Seems like it wants some kind of handshake for a successfull parameter update.
I ordered a Micro:Bit and tried to capture the traffice with BTLEjack, but did not succeed due to the frequent connection drops. BTLEjack needs some time to analyse ongoing connections.

In my opinion, two things might help others (like jps2000) and me:

a) implement the callback in the Feather nRF BSP
or
b) a pointer on how to implement the necessary parts from the SDK itself in an Arduino Sketch.

Joost

_Joost_
 
Posts: 11
Joined: Sat Sep 22, 2018 1:57 am

Re: BlueFruit NRF52 problem with recurring disconnects

by p2w on Tue Oct 23, 2018 10:16 am

_Joost_ wrote:Hi everybody and thanks p2w for your reply;

the situation seems to be that the Arduino BSP for the Feather (in Central role) does not respond to connection parameter update requests by the peripheral, which leads to dropping connections by certain peripherals.

Did you play with Bluefruit.Scanner.setInterval() yet? I've seen a couple of devices that won't allow connection (or drop connections) with the default allowable interval that is set in most examples (being 100 - 150 msec).

What does the peripheral mention as allowable intervals (hint: check with nRF Connect)?

Anyway, check bluefruit.cpp, search for BLE_GAP_EVT_CONN_PARAM_UPDATE. It is handled there (or so it seems) in AdafruitBluefruit::_ble_handler()

p2w
 
Posts: 83
Joined: Fri Dec 15, 2017 5:29 am

Re: BlueFruit NRF52 problem with recurring disconnects

by hathach on Fri Jan 04, 2019 12:01 am

Bluefruit central indeed doesn't handle BLE_GAP_EVT_CONN_PARAM_UPDATE_REQUEST now. But it shouldn't affect OP's particular issue since the DEBUG LOG doesn't show such as request. The prph seems to happy with the connection parameter that feather nrf52 offer and doesn't try to negotiate that. Though I will update the code to handle the request later.

@_Joost_ please try to call requestPairing() to have secure connection to see it could help.

hathach
 
Posts: 986
Joined: Tue Apr 23, 2013 1:02 am

Re: BlueFruit NRF52 problem with recurring disconnects

by _Joost_ on Sat Jan 12, 2019 6:48 am

Hi everybody,

just wanted to say thanks for your ongoing efforts to help/debug! I'll have to admit I paused/halted the project as this stuff got too complicated for me (just a hobbyist with no formal technical/IT/programming education). Perhaps I'll take it up at some point again; also just checked the recent releases and thought perhaps CircuitPython might be a good alternative for me.

Thanks again,

Joost

_Joost_
 
Posts: 11
Joined: Sat Sep 22, 2018 1:57 am

Re: BlueFruit NRF52 problem with recurring disconnects

by jps2000 on Sat Jan 12, 2019 8:03 am

just to mention that hathach had resolved the con update request handling. It will be included in next release and is already in the development branch on github ( replace BLEcentral.cpp in your library)
@joost
Dont give up. Problems use not to disappear with other programming language.
It is the hardiness that lastly ends in success and satisfaction.

jps2000
 
Posts: 405
Joined: Fri Jun 02, 2017 4:12 pm

Re: BlueFruit NRF52 problem with recurring disconnects

by Kippiis on Sat Jan 12, 2019 10:23 am

Hello everyone.
I have the same problem and all these suggestions didn't help me.

Kippiis
 
Posts: 1
Joined: Thu Dec 27, 2018 9:42 am

Please be positive and constructive with your questions and comments.