Unable to find BLE heart rate monitor

[rvandegrift]

RunnerUp doesn't find my BLE heart rate monitor. BLExplorer shows the device, it has a Heart Rate section with these values:

• characteristic UUID: 00002a39-0000-1000-8000-00805f9b34fb
• service UUID: 0000180d-0000-1000-8000-00805f9b34fb
• value: 101 = 257 = ^A^A

The device is an Amazfit Bip configured according to [1].

Should this work?

[1] - https://codeberg.org/Freeyourgadget/Gadgetbridge/wiki/Heart-Rate-data-sharing

[gerhardol]

GadgetBridge is not supported directly, need to be implemented in the app as a separate "protocol".
An attempt to implement this:
#430

[rvandegrift]

Hmm, I'm not sure that describes my use case. That looks like it's for devices that would require gadgetbridge to forward the data to runnerup.

But this watch supports BLE operation - I can stop gagetbridge and still see it's data in BLExplorer. The service UUID (posted above) matches the GATT identifier at [1] for heart rate monitors.

[1] - https://www.bluetooth.com/specifications/gatt/services/

[gerhardol]

I am not sure what is needed - can you debug?

[rvandegrift]

Sure - I don't knwo what would be most helpful. I don't know how helpful this will be, but here's some logcat output during various actions.

1. BLExplorer, browse to amazfit bip heart rate monitor and press Read:

09-29 12:25:53.921 19156 19178 I bt_btif_gatt: set_read_value len = 2
09-29 12:25:53.922 19234 19272 W BluetoothGatt: onCharacteristicRead() - Device=E8:9D:27:95:DF:58 handle=103 Status=0

1. Open RunnerUp heart rate monitor and scan for BLE sensors:

09-29 12:29:36.687  4253  4334 D AudioService: Stream muted, skip playback
09-29 12:29:36.689 19339 19339 W System.err: getHRProvider(AndroidBLE)
09-29 12:29:36.700 19339 19339 W System.err: [ RetryingHRProviderProxy: AndroidBLE, attempt: 0 ], state: OPENING, request: OPENED, onOpenResult(true)
09-29 12:29:36.726 19339 19351 D BluetoothLeScanner: onClientRegistered() - status=0 clientIf=10 mClientIf=0
09-29 12:29:36.807 19339 19358 D mali_winsys: EGLint new_window_surface(egl_winsys_display*, void*, EGLSurface, EGLConfig, egl_winsys_surface**, egl_color_buffer_format*, EGLBoolean) returns 0x3000,  [1218x759]-format:1

If there's anything more useful to capture, let me know. I'll also look for more info on the BLE capabilities of the device, since this doesn't look promising.

[rvandegrift]

I've done some more investigation - according to gadgetbridge folks, these devices are normal BLE heart rate monitors. In the past they worked with OpenTracks (but then OpenTracks removed/disabled their BLE setup screen).

My initial post contains the wrong characteristic, it should've been 00002a37-0000-1000-8000-00805f9b34fb (which is the usual HRM value).

I skimmed the BLE code in RunnerUp and confirmed that the UUID I'm seeing from the device match, but so far don't know it doesn't appear in the scan.

[gerhardol]

Thanks for the feedback.
I assume this requires debugging in the code, I do not see what the problem is (have not done much with the code here, no obvious leads).

[d3m3vilurr]

I check the this issue with miband 3.

1. startLeScan wouldn't pass bonded devices; https://github.com/jonasoreland/runnerup/blob/master/hrdevice/src/org/runnerup/hr/AndroidBLEHRProvider.java#L517
   I added hack before calling startLeScan.

   for (BluetoothDevice btDevice: btAdapter.getBondedDevices()) {
       if (btDevice.getType() != BluetoothDevice.DEVICE_TYPE_LE)
           continue;
       mLeScanCallback.onLeScan(btDevice,0, null);
   }
   

   but I don't know the reason that btDevice.getUuids() would return the null
   (maybe it needs connecting before call method)

2. this device looks doesn't have FIRMWARE_REVISON_UUID. so I used HARDWARE_REVISION_UUID "00002a27-0000-1000-8000-00805f9b34fb" instead of it.

after changed it, I got the HR values very normally.