Bluetooth Eddystone sample does not correctly implement Eddystone beacon

[nashif]

Reported by Henry Bruce:

Expected behavior Run sample (on Arduino 101). Start beacon finder app on smart phone that will detect Arduino 101 beacon and take you to https://www.zephyrproject.org/

Observed behavior Run sample (on Arduino 101). Start beacon finder app on smart phone but Arduino 101 bean not detected. GATT debug tool shows that Eddystone service UUID is incorrect

Workaround Use the beacon sample instead, it correctly implements an Eddystone beacon. Suggest removing Eddystone sample.

(Imported from Jira ZEP-641)

[nashif]

by Henry Bruce:

• eddystone.log (size: 2767)

[nashif]

by Henry Bruce:

• gatttool.log (size: 2031)

[nashif]

by Henry Bruce:

• Screenshot_2016-08-10-13-39-17.png (size: 149847)

[nashif]

by Luiz Augusto von Dentz:

And where are the logs? Btw we are following these spec:

https://github.com/google/eddystone/tree/master/configuration-service

Not this (which seems much older and with uses different UUIDs):

https://github.com/google/eddystone/blob/master/eddystone-url/docs/config-service-spec.md

[nashif]

by Henry Bruce:

I'm not a GATT expert but it seems that the primary service UUID should be 0000FEAA-0000-1000-8000-00805F9B34FB as per https://github.com/google/eddystone/blob/master/protocol-specification.md. See also validator test tool at https://github.com/google/eddystone/blob/master/tools/eddystone-validator/EddystoneValidator/app/src/main/java/com/google/sample/eddystonevalidator/MainActivityFragment.java, line 75.

The eddystone sample only advertises the configuration service (UUID a3c87500-8ed3-4bdf-8a39-a01bebede295) so it not being detected as an Eddystone beacon. The attached gatttool output, sample log and Android GATT sniffer app screen show all confirm this.

The beacon sample advertises a UUID of 0000FEAA-0000-1000-8000-00805F9B34FB so is detected by Eddystone beacon scanners (including Google's Android Eddystone validator app).

Out of interest which beacon scanning tool did you use to validate? Maybe I'm misunderstanding the purpose of this sample.

[nashif]

by Luiz Augusto von Dentz:

0000FEAA-0000-1000-8000-00805F9B34FB is not a GATT service, the https://github.com/google/eddystone/tree/master/configuration-service is pretty clear about what it shall be advertise when on configuration mode:

'Once your beacon becomes connectable, we recommend broadcasting the configuration GATT service's UUID as a 128-bit service UUID in the scan response, along with a local name data type that identifies your beacon.'

So while at this mode you should be able to configure it, the spec actually suggests to have a timeout of 30 seconds and if there is no connection in the meantime it will turn back into beacon mode which is something the sample is not doing but as far as configuration mode it seems correct, note that it will never turn into beacon mode while it is connected but once disconnected it shall advertise the configure URL.

[nashif]

by Luiz Augusto von Dentz:

I end up updating the sample with a timeout as suggested by eddystone specification:

https://gerrit.zephyrproject.org/r/#/c/4092/

Note: This is currently on bluetooth branch but will be merged to master once the merge window opens.

[nashif]

by Henry Bruce:

What beacon scanner / config software did you use to test your update? I will validate once this is merged into master.

[nashif]

by Anas Nashif:

status?

[nashif]

by Mark Linkmeyer:

Fixing incorrect priority

[nashif]

by Dawei Wu:

Henry Bruce , the latest zephyr code has timeout 30s for configuration and beacon mode switch , see below. So you can have a try , if it's OK for you we can close this . Thanks.

[bt] [WRN] set_static_addr: Using temporary static random address
[bt] [INF] show_dev_info: Identity: f8:12:a4:14:1f:dc (random)
[bt] [INF] show_dev_info: HCI: version 4.2 (0x08) revision 0x0000, manufacturer 0xffff
[bt] [INF] show_dev_info: LMP: version 4.2 (0x08) subver 0xffff
Bluetooth initialized
Configuration mode: waiting connections...
Switching to Beacon mode.

[nashif]

by Henry Bruce:

OK to close.

[nashif]

by Dawei Wu:

So close this.