Well, I'm always on the bleeding edge. Haha. I have a photon 2 running 5.8 that is connected to a peripheral device that is sending data to it over the standard UART service and characteristic ID's and this data is manipulated and then sent from the Photon 2 to an iPhone running the iOS 17 and acting as a peripheral. It is transmitting data on a custom service ID and custom Characteristic ID's.
During normal operation, the system with all 3 devices, phone, photon2 and the special peripheral device will work normally, however, at some random points I have yet to figure out, I will see the following in my logs when the photon 2 is sending data to iOS
0000851560 [hal.ble] TRACE: handleConnectionStateChanged: connection lost cause 0x108
[INFO][BLE: onDisconnectedFromPhone] Disconnected from phone
The 2nd log statement is mine when a disconnect occurs.
It will attempt to readvertise and establish a connection but this can fail for up to a minute or so.
I'm not sure what is causing this error
I have tried to catch this disconnect and restart the BLE stack but I'm having trouble doing that successfully. It seems to hang when turing the BLE off and back on.
Has anyone run into this and have any suggestions on how to deal with this or what might be causing it?
I've run into BLE (and Wi-Fi) issues on Device OS 5.8.0.
Does your issue happen as well on Device OS 5.8.2?
Note: I have also run into BLE/Wi-Fi issues on 5.8.2 ,so I'm eagerly waiting on 5.9.0, wich brings stability improvements in both fronts. You can check the fixes here:
Unfortunately, same issue. I feel like I could work around this when it happens by resetting the BLE stack however, there is no function to do this that I am aware of. And going through an organized process of disconnecting, stopping advertising and then turning BLE off and on causes it to hang. My only resort at this point is to let it keep trying (which can take several minutes of errors but then miraculously starts working again) or I can detect the situation and force a reset of the device.
I've heard that calling the BLE API from a BLE callback can create issues.
Would you like to look at your code and try to rule this out?
In case your FW is sending data received to the phone on the RX handler of the other peripheral, you might want to extract that behaviour out of the handler...
well it no longer hangs but what I am doing does not appear to reset the BLE to the same state that it would be right after reset unfortunately. I still get the same errors. Here is my setup / restart code.
void restartBLE()
{
restartBLEFlag = false;
BLE.disconnect();
delay(250);
BLE.stopAdvertising();
delay(250);
BLE.stopScanning();
delay(250);
BLE.off();
delay(1000);
BLE.on();
// begin BLE and start advertising
log("BLE: setup", "Setting up BLE");
BLE.onConnected(onConnectedToPhone, NULL);
BLE.onDisconnected(onDisconnectedFromPhone, NULL);
// BLE.selectAntenna(BleAntennaType::AUTO);
BLE.addCharacteristic(timeCharacteristic);
BLE.addCharacteristic(eegStreamCharacteristic);
BLE.addCharacteristic(bltEventsCharacteristic);
BLE.addCharacteristic(bltConfigCharacteristic);
BLE.addCharacteristic(bltTriggerCharacteristic);
BLE.addCharacteristic(bltSDFilesCharacteristic);
timeCharacteristic.onDataReceived(onTimeDataReceived, &timeCharacteristic);
bltConfigCharacteristic.onDataReceived(onConfigDataReceived, &bltConfigCharacteristic);
bltTriggerCharacteristic.onDataReceived(onTriggerDataReceived, &bltTriggerCharacteristic);
BLE.begin();
BleAdvertisingData advData;
advData.appendServiceUUID(BLT_SERVICE_UUID);
advData.deviceName((char *)BLT_DEVICE_NAME, strlen(BLT_DEVICE_NAME));
BLE.setDeviceName(BLT_DEVICE_NAME);
BLE.advertise(&advData);
log("BLE: setup", "Advertising as BLE peripheral to phone");
// setup implant characteristic subscriptions
implantRXCharacteristic.onDataReceived(onImplantDataReceived, &implantRXCharacteristic);
}
Did you end up solving the disconnection issue, or were you just able to recover from it?
It feels similar to something I was running into on iOS, but when the Photon 2 was the peripheral. It would happen consistently when my phone was closer to the wifi router on my desk.
Nope, it still does it relatively consistently, but at random times. I currently am just doing a System.reset() for now to try to get the recovery to happen more quickly. Keeping my fingers crossed for 5.9
