Got a debug log... 

debug.log -> doing as described above
debug-device-info.log -> doing device-info page where the device is found

The initial difference I see in the device-info one is that bluetooth_adapter shows both 59:58:6E:11:2E:22 and 93:C9:98:3A:9F:FC, but in the one that's broken it is just 59:58:6E:11:2E:22

I'm not entirely certain what those MAC addresses are (as they're not BLE devices it seems), but could it be they are the actual BLE radios? And for some reason when trying to find the Nordic UART, Chrome is only using the internal Bluetooth radio, which doesn't do BLE?

By the way - the Bluetooth radio it set up in Bluetooth manager to ensure the default is the CSR one that does do BLE.

Deleted: ChromeBLEdebug.log 18.0 KB

ChromeBLEdebug.log 18.0 KB View Download

Deleted: ChromeBLEdebug_device-info.log 16.4 KB

ChromeBLEdebug_device-info.log 16.4 KB View Download

I wonder if macOS doesn't cache services while BlueZ does once device is paired.
Can you try and let me know if that works out for you?


navigator.bluetooth.requestDevice({
    filters:[{ name: 'Puck.js' }],
    optionalServices: [ NORDIC_SERVICE ]})
.then(function(device) { /* ... */ })

Looking at bluetooth logs, you're right Gordon. There is ascan response from first LE advertising report. So it should work...

#1

Bluetooth HCI Event - LE Meta
Event Code: LE Meta (0x3e)
Parameter Total Length: 29
Sub Event: LE Advertising Report (0x02)
Num Reports: 1
Event Type: Connectable Undirected Advertising (0x00)
Peer Address Type: Random Device Address (0x01)
BD_ADDR: c3:25:1d:c7:ef:bd (c3:25:1d:c7:ef:bd)
Data Length: 17
Advertising Data
Flags
Device Name: Puck.js efbd
Length: 13
Type: Device Name (0x09)
Device Name: Puck.js efbd
RSSI (dB): -79

#2
Bluetooth HCI Event - LE Meta
Event Code: LE Meta (0x3e)
Parameter Total Length: 30
Sub Event: LE Advertising Report (0x02)
Num Reports: 1
Event Type: Scan Response (0x04)
Peer Address Type: Random Device Address (0x01)
BD_ADDR: c3:25:1d:c7:ef:bd (c3:25:1d:c7:ef:bd)
Data Length: 18
Advertising Data
128-bit Service Class UUIDs
Length: 17
Type: 128-bit Service Class UUIDs (0x07)
Custom UUID: 9ecadc240ee5a9e093f3a3b50100406e
RSSI (dB): -78

Note: In Comment 2, change "name" to "namePrefix".

Just tried this and yes, it works. I'm putting that code in for now.

I am not able to reproduce this issue with espruino_1v84.214_nrf51822.hex image on MacBook Air - OS X El Capitan - 10.11.5 (15F34)

I've used: https://googlechrome.github.io/samples/web-bluetooth/get-characteristics.html?service=6e400001-b5a3-f393-e0a9-e50e24dcca9e and I don't have a CSR Bluetooth Dongle.

I've tried with Apple Bluetooth Host Controller and external USB Micro Adapter GBU521 (https://www.iogear.com/product/GBU521/)

To add to this, using https://googlechrome.github.io/samples/web-bluetooth/get-characteristics.html?service=6e400001-b5a3-f393-e0a9-e50e24dcca9e I can see devices that I have previously connected to, but not devices that I haven't.

If I connect to a new device then go back to that page and try again, it'll appear.

This, sadly, seems like a lower level issue. When you pass in the service to requestDevice we pass those services to "scanForPeripheralsWithServices"[1] which starts a scan and filters out all devices that are not advertising those services. In this case the fact that Francois couldn't reproduce this issue with his MacBook Air leads me to believe the CSR adapter is filtering out your device.

We could do an open scan and filter in software but this is discouraged by Apple due to being very inefficient.

Might the CSR adapter be doing a passive scan instead of an active one? Only active scans would receive the Scan Response packet that contains the service UUID. But active scans without rotating local device addresses are bad privacy-wise, so it's reasonable for a dongle to do passive scans if it doesn't have the ability to rotate addresses.

Well, in the PacketLogger log it does show what looks like the correct data (a packet with the UUID in), so it seems like the data is getting in, it just isn't being interpreted for some reason.

Gordon, can you test if it also fails with the CSR adapter plugged to your Chromebook?

You'll need to select as default the CSR adapter in bluetooth console.
Open Chrome OS shell with [Ctrl]+[Alt]+T and follow:

crosh> bt_console 
[NEW] Controller A4:17:31:78:A6:04 Chromebook_0A65 [default]
[NEW] Controller 5C:F3:70:62:75:1B BlueZ 5.39 
[CHG] Controller 5C:F3:70:62:75:1B UUIDs: 00001112-0000-1000-8000-00805f9b34fb
[CHG] Controller 5C:F3:70:62:75:1B UUIDs: 00001801-0000-1000-8000-00805f9b34fb
[CHG] Controller 5C:F3:70:62:75:1B UUIDs: 0000110e-0000-1000-8000-00805f9b34fb
[CHG] Controller 5C:F3:70:62:75:1B UUIDs: 00001800-0000-1000-8000-00805f9b34fb
[CHG] Controller 5C:F3:70:62:75:1B UUIDs: 00001200-0000-1000-8000-00805f9b34fb
[CHG] Controller 5C:F3:70:62:75:1B UUIDs: 0000110c-0000-1000-8000-00805f9b34fb
[CHG] Controller 5C:F3:70:62:75:1B UUIDs: 0000110a-0000-1000-8000-00805f9b34fb
[CHG] Controller 5C:F3:70:62:75:1B UUIDs: 0000111f-0000-1000-8000-00805f9b34fb
[bluetooth]# select 5C:F3:70:62:75:1B 
Controller 5C:F3:70:62:75:1B BlueZ 5.39 [default]

Hey Gordon, I've tried on my MacBook Air with latest Chrome Canary and it works great: https://beaufortfrancois.github.io/samples/web-bluetooth/device-info.html?service=6e400001-b5a3-f393-e0a9-e50e24dcca9e

Can you reproduce as well?

Deleted: 1.png 135 KB

	1.png 135 KB View Download

Yes - just tested and it works fine on Canary 57 now.

Chrome 55 works but repeatably shows up fewer devices than 57 does - I *think* it's refusing to show the devices with a longer advertising interval.

But hey - 57's fixed! \o/ Thanks!

See https://github.com/espruino/espruino.github.io/pull/2