Hacker News new | ask | show | jobs
by tdicola 3992 days ago
This looks really cool, in particular the telemetry packet is a nice idea for transmitting sensor data with BLE broadcast packets. Using that you can 'passively' read many nearby sensors without having to connect to them. I've had some similar ideas and played around with doing similar things using a nRF51822 (like a BLE radio + little cortex M0 chip) but ran into a ton of trouble with the BLE API's of various operating systems (like CoreBluetooth on OSX and bluez 5.3 on Linux).

In particular most BLE implementations like CoreBluetooth and bluez have a lot of caching and assume that a device's broadcast & advertisement data rarely changes. This causes a ton of trouble when you put frequently changing data in broadcast packets since you can easily get stale or cached data instead of the most recent broadcast. I'd love to know if the Eddystone developers ran into similar issues with their telemetry packets and had any workarounds.
1 comments
IshKebab 3992 days ago
This isn't a problem with the BLE implementations. It's in the BLE specification!

> Duplicate advertising reports are not required to be sent to the Host. A duplicate advertising report is an advertising report for the same device address while the Link Layer stays in the Scanning State. The advertising data may change; advertising data or scan response data is not considered significant when determining duplicate advertising reports.

Advertising really is designed to advertise the presence of a device. It isn't for putting data in - for that you should connect to the device.

link
tdicola 3992 days ago
I'd argue its an omission or mistake with the spec then. Being able to passively collect sensor data without connecting to a device is very handy as it allows many devices to read data from many local sensors. If they all have to connect to each sensor then there's contention over the connection (only one device can connect to a sensor at a time) and it wastes power to setup and tear down the connection constantly (negating the whole point of BLE).

If advertising isn't for putting data then arguably iBeacon, URI Beacon, Eddystone, etc. go against the spirit of the BLE spec.

link