Recently I got back into Arduino to control the speed of a fan with my heart rate. It's for an indoor cycling setup. The Garmin HR sensor HR value is read and the fan speed is adjusted. All is stable, works great.
I've coded it, like in many examples, to start searching for the sensor if it gets disconnected when e.q. I walk away out of range. When I return the sensor connection is re-established.
However, the other day after a long(er) 20 minutes coffee break the sensor was not reconnected anymore (the software, Rouvy did detect the sensor again).
Looking in GitHub and searching the internet I found issues with the scan() function but not exactly what I experience. Is this a known issue?
As workaround I now 'reset' the BLE after 5 minutes of scanning by doing a call to BLE.end(), BLE.start() and restart the BLE.scan for the HR service UID. And that seems to work.
I had actually seen that one, but slipped my mind, thanks for reminding.
As far as I understand a fix (commit ccdca60) was merged with the main branch but not included in the latest releases of the BLE library. On a side note: why was it merged (2 years ago) but never included in the last few releases? Not tested or so?
The issue is not a real show-stopper for me and I don't want to start delving into source code of the library and changing things, I rather wait for it to be included in an official release.
I did a more extensive test today. In summary: the BLE.end(), BLE.start() as a reset does not work.
This morning I switched on the Nano and it started searching/waiting for the Garmin HR sensor to become available as programmed. I left it searching for more than 2 hours. When it was time to get dressed for the afternoon club ride I did put on the HR sensor but when I came near the Nano it did not detect the HR sensor. I programmed to have a blinking blue LED while scanning and a green LED when the connection is made and HR data is received. No joy. It kept blinking blue.
I pushed the reset button and with 2 seconds or so the Nano found the HR sensor and as programmed the green LED turned on. I took my bicycle and left home for the club ride. I left the Nano running.
When I returned from the ride a few hours later none of the LED's were signaling the status of the device, I've programmed it so that always a LED is signaling something. No red LED for error, no blinking LED for scanning, no steady blue LED for peripheral found no green LED for connected and receiving HR data. Working assumption: the Nano was hanging somewhere or crashed.
Again I pushed the reset button and 2 seconds later the HR sensor was found and the green LED was on.
When I do the previous scenario but with only minutes instead of hours the Nano plays nice.
The scenario of having the Nano scanning for hours is nothing that will happen in my case, in a certain sense the test was "artificial" but it seems that the combination of Arduino core, Nano 33 BLE and ArduinoBLE library is not as solid as hoped for.
I'm thinking of a sort of 'crowbar' solution now: to replace the BLE.end() BLE.start() sequence and call NVIC_SystemReset(). Or wire a 2nd reset button so I can reset in case needed when I have all installed in a small box/case.
Do I understand correctly that your issue is that the central is scanning for advertising which is not taking place and fails after a long time of not finding it?
The .end() and .begin() solution seems to be working in a different context where the peripherlal is indeed advertising but the scanning central does not find it for some unknown reason. The Central does not cease its other functions when it loses contact.
We'll see if the NVIC_SystemReset() is required there, and if the restart of the central to initial conditions causes issues given that the system is responding to a changing environment.
I have a Nano 33 BLE that acts as central and scans for the Garmin Dual HR sensor (as peripheral). The Garmin sensor correctly advertises it services (I never had issues with other gear connecting to that sensor).
Yes, on short scan times (which is the normal use case in my situation) it works fine. It was more or less by chance I noticed it did not find the peripheral after longer scan times. It would have not been a showstopper for me, but I "hate" such loose ends .
.