Allow for two custom frames.

[alexvanboxel]

I see a need to allow for broadcasting custom data and still be within the Eddystone spec. This could easily be done by allowing for two custom frames.

But they should never be allowed to broadcast without at least a URL or UID frame, otherwise you don't have a way to detect it's an Eddystone beacon. The other reason to have the UID or URL frame is that you will only be able to decode the frame when you identified the provider.

Example, say provider X has a need to broadcast humidity and pressure, they can do this in CUSTOM frame 0. The receiver can identify the provider by URL or UID.

[petekmet]

Well, after some time distance I realise why Google may never include "custom sensor data" into Eddystone because of simple reason. Device is either a beacon (broadcasting identification/navigation data) or it is some kind of probe broadcasting sensor data. This specification is solving beacon-specific data. To keep things simple it may stay just that - broadcasting navigation/identification data. On the other hand, should you need broadcast sensor data (like environmental sensing) nothing prevents you to interleave Eddystone frames with your custom advertisement frame (which is application-specific anyway), leaving you full 31 bytes (or even scan responses) of custom payload while observing Bluetooth specifications.
Just my observation.
Peter

[alexvanboxel]

Let me disagree here. Eddystone is about proximity beacons, whatever it is. Allowing for custom frames just puts an end to questions that will keep popping up as long as we don't have custom frames.

The worst thing that can happen is what you suggest is that people will interleave arbitrary raw data frames (and it will happen if it's not in the spec). If you have out-of-spec raw data you have the possibility to clash with the spec. For example, say you're first byte is pressure data and it's 0x10: oeps this is the URL frame-type start byte. Having this frame prefixed with type 0xE0 or 0xF0 at least makes sure it wont clash with the defined Eddystone frames (and you only sacrifice 1 byte, still leaving 30 bytes of data).

[heypiotr]

Why do you need your custom data to be branded as an Eddystone frame? Why not just broadcast a custom frame? (With a non-Eddystone service UUID, to prevent the clash you described above.)

There's a ton of Bluetooth devices already on the market that broadcast custom sensor data, what's the gain if they were broadcasting that data under the Eddystone service UUID?

The Bluetooth spec itself already provides standardized service UUIDs for most common sensors, plus a "manufacturer specific data" frame type. Re-implementing that in Eddystone seems redundant.

[petekmet]

As Piotr said, having non-beacon data in Eddystone payload is just wasting the bandwidth. I never suggested your custom advertisement frame shall contain whatever bytes comes to your head - you need obey Bluetooth specs. Have a look at https://goo.gl/ggVXQC to see what data can be included to avoid collision. Note, adv.packet is just length-type structure, similar to BER-TLV.

[Suretronic]

In my view an Eddystone 'custom' sensor data frame would most useful for enabling** generic** Eddystone Android etc applications to display (almost) any sensor data, i.e. using a compression standard that balances flexibility (perhaps to display more than primitive values) against space. An example might be accelerometer data, or interpreted accelerometer data of some sort.

[heypiotr]

Sure, that'd be nice, and TLM already sort of paves way for that. This pull request however is about a completely custom, manufacturer-specific, non-standardized frame.

[alexvanboxel]

TLM as define: telemetry and is useful for monitoring the health and operation of a fleet of beacons. But custom censor data has nothing todo with the health of the beacon.

Let take an 'fictive' example: I have my own facility an want to monitor pressure throughout my facility. I have control over the beacons so I know what the data means though-out the facility. If the custom frames is defined the Eddystone software library could expose these frames to our own in-house software without worrying about BLE.

Something we're considering in a warehouse is broadcasting rack location. Because it's so narrow or niche I don't see rack location ever coming into the spec. And even as a business we write our own Android app, we don't want to bother with having to dig through the complete BLE spec. Having a custom frame makes this possible. I would be able to broadcast the rack location in that custom frame.

You see, custom frames are not only meath for sensor data.

[Suretronic]

Ok, I get the point, according to the spec '..The Eddystone-TLM frame broadcasts telemetry information about the beacon itself.' The implication is that another frame type is needed to encapsulate 'custom' data that isn't about the beacon, including something like rack location. Again though whatever encoding scheme is defined should enable a generic Eddystone client app to usefully display the data contained in any type of frame.
Presumably then there would be nothing to prevent broadcasting multiple custom frames containing different types of data? In which case if the requirement for the TLM frame to contain data about the beacon was relaxed, it could itself encapsulate custom data. A (highly) compressed, hierarchical, name/value pair scheme would allow applications to route that TLM data to relevant processing end points.

[LouisCAD]

What direction is this taking? Will we be able to have Eddystone beacons that broadcast their orientation, their stability (know if a beacon has been moving, and when), the air pressure and so on?