heartratemonitor sketch will not connect to nRF Toolbox

[bluesquall]

• Arduino board: Arduino UNO
• Arduino IDE version (found in Arduino -> About Arduino menu): 1.6.12
• Bluefruit board: BluefruitLE UART Friend
  • Nordic Chip: nRF5182
  • Firmware: 0.7.0
• Android nRF Toolbox version 1.18.4

Possible defect in heartratemonitor example sketch (as of git commit 0c841d49, but sketch was last touched f248eec9).

In short, try the nRF Connect app if the nRF Toolbox app doesn't work.

As expected:

The Bluefruit shows up under AVAILABLE DEVICES: as Bluefruit HRM, followed by the MAC address.

Not expected:

Attempting to connect fails, and the nRF toolbox gives a notification:

The device does not have required services.

Short-term solution

However, using the nRF Connect app instead does allow me to connect, and it does show the appropriate output for Body Sensor Location and an updating output for Heart Rate Measurement.

Just getting started in this, so I'm not sure whether the problem connecting to nRF Toolbox is due to incomplete information on the Bluefruit side or to a bug on the nRF Toolbox side.

[microbuilder]

The most likely explanation is that the heart rate monitor service's UUID needs to be in the advertising packet for the Nordic app to be happy and it isn't being added, but it could be a timing issue or something else.

Thanks for filing this so it doesn't slip between the cracks, though.

PS: Just suggesting the adv packet off the top of my head from previous experience ... I'll need to look at the code in more detail since I don't remember the exact details around the helper classes and example code for this demo.

[bluesquall]

The advertising packet is in the service UUID, added with a GATT command string. I will check to see whether it is malformed when I go back through that example sketch using the GATT interface (instead of writing GATT commands as strings).

On Wed, Oct 5, 2016, 16:33 Kevin Townsend notifications@github.com wrote:

The most likely explanation is that the heart rate monitor service's UUID needs to be in the advertising packet for the Nordic app to be happy and it isn't being added, but it could be a timing issue or something else.

Thanks for filing this so it doesn't slip between the cracks, though.

PS: Just suggesting the adv packet off the top of my head from previous experience ... I'll need to look at the code in more detail since I don't remember the exact details around the helper classes and example code for this demo.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/adafruit/Adafruit_BluefruitLE_nRF51/issues/21#issuecomment-251829397, or mute the thread https://github.com/notifications/unsubscribe-auth/AAfX5vedHzarXa2TfFavVFMmtbICmCOVks5qxDOrgaJpZM4KPZAg .

[bluesquall]

Confirmed the example sketch (and my copy, modified for BLE UART using different pins) are both setting the correct advertising data:

AT+GAPSETADVDATA=02-01-06-05-02-0d-18-0a-18

The 0d-18 (0x180D) is the UUID for the HR service, and 0a-18 (0x180A) is the UUID for device information service.

[bluesquall]

Noticed the nRF toolbox also displays battery status for the connected monitor, so I figured that might be the missing service the app was expecting.

After adding the battery service (UUID 0x180F), the example worked as expected when connected to the nRF toolbox.

Things were always visible in the nRF Connect app, so that was helpful in working on this.

[bluesquall]

Just to be complete, I tried going back to the original example, without the battery service advertised or added. Now it works... different day?

The only reason I can guess right now is that Android may have been caching some details (e.g., Service UUIDs) for a short period, and it caught the UUIDs from the Bluefruit while it was in factory reset at the beginning of the cache. Seems unlikely, but that's all I can think of. I saw some behavior like this in nRF Connect, where I would add a new service or change the properties of a characteristic, and it would still show the old parameters when I connected again. Hitting SCAN => Refresh seemed to solve that.

In any case, the original example works fine for me now without adding the battery service, and without telling me "The device does not have required services." So I'm closing this issue.

If anyone runs into similar problems, try refreshing the bluetooth scan table. The nRF Connect app lets you do this. Disabling and re-enabling bluetooth altogether may also do it.

[microbuilder]

Thanks for the feedback here for other customers. Caching causes endless issues on both iOS and Android, which is why we had to add those extra menu options. Glad they came in handy here.