How to include custom sensor data in Eddystone

[lijundr]

Is it possible to include custom sensor data other than battery level, temperature, advertising counts and uptime to TLM?

[mashbridge]

Not currently, but we've included a version byte in the frame because we know other types of telemetry will be useful. Do you have anything specific in mind?

[lijundr]

There can be various types of sensors which record humidity, pressure, or any custom data types. I am just thinking it will be useful to leave some space for custom data types in TLM.

[roywant]

This is a work in progress. There are several schemes proposed. As soon as there is wide agreement we'll create either a new Sensor Frame type or add additional TLM versions

--Roy

On Thu, Sep 10, 2015 at 9:27 AM, lijundr notifications@github.com wrote:

There can be various types of sensors which record humidity, pressure, or any custom data types. I am just thinking it will be useful to leave some space for custom data types in TLM.

— Reply to this email directly or view it on GitHub https://github.com/google/eddystone/issues/88#issuecomment-139301500.

---

Roy Want Google Android MTV-43-206P Cell: 650 691 3600 www.roywant.com/cs

[bobwhelan]

Sorry to jump in the middle of this thread. You may have already discussed this, but I was under the impression that the Ephemeral ID was something that would be added to the TLM packets. Is there any update on the status of the EID implementation?

Thanks in advance,

Bob Whelan

Bob Whelan Co-founder bob@smartwhere.com voice: 425.941-6045 skype: bob.whelan

On Thu, Sep 10, 2015 at 10:56 AM, Roy Want notifications@github.com wrote:

This is a work in progress. There are several schemes proposed. As soon as there is wide agreement we'll create either a new Sensor Frame type or add additional TLM versions

--Roy

On Thu, Sep 10, 2015 at 9:27 AM, lijundr notifications@github.com wrote:

There can be various types of sensors which record humidity, pressure, or any custom data types. I am just thinking it will be useful to leave some space for custom data types in TLM.

— Reply to this email directly or view it on GitHub https://github.com/google/eddystone/issues/88#issuecomment-139301500.

---

Roy Want Google Android MTV-43-206P Cell: 650 691 3600 www.roywant.com/cs

— Reply to this email directly or view it on GitHub https://github.com/google/eddystone/issues/88#issuecomment-139326860.

[mashbridge]

Ephemeral ID will be a new frame type. (And in order to guarantee the best possible security/privacy, we'll recommend that implementors don't interleave EID frames with other frame types that broadcast data unique to that beacon, like TLM data.)

[bobwhelan]

Michael, I'm eager to hear more... Thanks

Bob

Bob Whelan Co-founder bob@smartwhere.com voice: 425.941-6045 skype: bob.whelan

On Thu, Sep 10, 2015 at 10:37 PM, Michael Ashbridge < notifications@github.com> wrote:

Ephemeral ID will be a new frame type. (And in order to guarantee the best possible security/privacy, we'll recommend that implementors don't interleave EID frames with other frame types that broadcast data unique to that beacon, like TLM data.)

— Reply to this email directly or view it on GitHub https://github.com/google/eddystone/issues/88#issuecomment-139458491.

[glenne]

I envision a beacon that might record physical events like a button press, door opening, or occupancy (parking slot, room presence, bike rack) etc. It would be nice to use eddystone to communicate this data "upstream". In my particular interest is in a timing app where start and finish events are recorded via a key fob like button.

[glenne]

Can you give a link to the 'various schemes' being proposed?

I would like to see a scheme that was not a fixed binary format but rather a form that could be arbitrarily extended with additional (or missing) fields. For example if I send temperature in version 1 and temperature and humidity in version 2 I shouldn't break implementations that understand version 1. I should also be able to just send humidity without temperature. Clients should be forgiving of missing or additional fields to achieve high coefficients of robusticity. This is very important for future extensibility.

I imagine this as a set of name/value pairs efficiently encoded such as a binary form of json: { 't' : 100.0, 'h' : 49.7 }. At it's lowest level it's just name/value,name/value. If I receive a v2 name I don't understand, I can just skip over it. Value should be any type such as int, float, string or a nested map of more name/value pairs. e.g. over and over. Protobuf encoding can be used for efficiency of encoding the values. This would allow tracing and decoding of unknown payloads.

Another aspect to consider is to allow data to be sent for 'custom' applications that do not have a standard set of names defined for the name/value pairs yet. To cover this you could require the first N bytes be the equivalent of a schema reference, perhaps using fewer bytes for 'standardized' items and a 10 byte url hash like the UID for proprietary or standard under development prototypes.

[atsutomiyata]

Roy mentioned about new TLM version in 11th of Sep. Very interested to know about the new TLM version. What kind of time-frame are you looking at? End of this year? Next summer? In addition to already mentioned sensors, motion sensors, open/close sensors for door/window would be nice to apply this technology for security systems.

[mkopa]

Hi, now I'm using URL frame to sending binary data from devices like accelerometer or gyroscope. You can encode this data to eg. base 64 and put it to URL frame. Anyway, additional frames to any binary data will be very helpful.

On 2 November 2015 at 07:32, atsutomiyata notifications@github.com wrote:

Roy mentioned about new TLM version in 11th of Sep. Very interested to know about the new TLM version. What kind of time-frame are you looking at? End of this year? Next summer? In addition to already mentioned sensors, motion sensors, open/close sensors for door/window would be nice to apply this technology for security systems.

— Reply to this email directly or view it on GitHub https://github.com/google/eddystone/issues/88#issuecomment-152930706.

[atsutomiyata]

passage-san, Thank you for the tips. I see that URL frame can be used to encode data. However, I am currently interested in applying eddystone-tlm for a commercial products. Therefore I am eager to see the new TLM version with additional sensor capability.

[ukBaz]

Wouldn't this type of thing be better done using Bluetooth Notifications?

Good overview at: https://vimeo.com/144811493

[petekmet]

Any progress or preview for custom data in eddystone frames ? Especially custom telemetry frames and ephemeral ID frame (for one-time IDs). For telemetry - since we are very space constrained, maybe you can consider TLV-frame-like which uses BER-TLV-like markup or define tags with predefined length as defined in Bluetooth characteristics specification (https://goo.gl/wU4kKf).

[alexvanboxel]

Hey all, I do see a need for custom frames. So here is a proposal for two custom frames and I think fits nicely in the Eddystone spec. Now let's hope it get's accepted:

Pull request: #122

[PoliteSM]

Hi All,

Apologies if this is not the correct place to inquire, but this was the only open ticket that referenced EIDs.

Is there an update regarding EID implementation?

Thanks

[ninu]

@PoliteSM Thanks for your inquiry and patience. We're gearing up for a significantly large and exciting update to Eddystone. In the meantime, here's some info regarding Eddystone at our Ubiquity conference last month in SF. https://www.youtube.com/watch?v=-67DfhSX9LM

[mashbridge]

EID specification was just launched today: https://github.com/google/eddystone/tree/master/eddystone-eid https://security.googleblog.com/2016/04/growing-eddystone-with-ephemeral-identifiers.html

[nev-eng]

Hi everyone,

I just wanted to known if there has been any update on the TLM frame format or other ways to include custom data from other type of sensors in the Eddystone frames.

Thanks

[mrquincle]

This is quite relevant indeed. The handling on Eddystone advertisement packets is namely 1000 times better than any other format I've come across. I don't know if there has been another team responsible for it in Google/Android, but the difference in regular updates on the app side is shocking.

See e.g. this Nordic scanner visualization: https://github.com/crownstone/bluenet/blob/master/docs/LOCALIZATION.md

This means we'd immediately use any standard type of sensor data support in Eddystone as soon as it comes available.

[adriancretu]

I'm 100% sure that visualization just proves that the iBeacons were transmitting less often or with less TX power. There's absolutely no separation in Android's BLE stack between what kind of payload a beacon contains versus how often it is "received", since this is purely a physical radio property.

[mrquincle]

@adriancretu The "purely physical radio property" of Android devices is absolutely not sufficient to explain the behaviour on Android regarding BLE advertisements.

We program our beacons ourselves, so TX power nor advertisement frequency is sufficient to explain this behavior. I will check this again tomorrow, but I'm afraid I can't share your certainty about that every type of advertisement goes in exactly the same way through the code base.

[adriancretu]

Unpacking the BLE advertising record into Eddystone/iBeacon structures is done by libraries (e.g. Play Services or Chrome) sitting above the platform's BLE api. So there's no reason to see scan result activity differences no matter what the payload contains, unless hardware-related issues (what I meant by "purely physical radio property"). I bring to the case the fact that Android BLE scanning was introduced in API 18, years before Eddystone even existed as a registered Service UUID, so I doubt that it might be somehow "baked in" into the AOSP to have any priority. So any optimisations or filtering would only be brought by the library or app performing the actual scan.

LE: all of this makes sense if there's no custom-filtered low-latency scan running during your experiment. In which case results might variate based on the applied scan filters.

[eric-appion]

Re: ukBaz comment about wouldn't it be better to use notifications: Notifications are great, but they require a connection. Adding a small amount of custom data to a beacon is useful because it doesn't require a connection. Under some circumstances or with some hardware configurations, it may be easier to receive a beacon advertisement than to establish a two-way connection.

It would be very useful to have a custom Eddystone frame type. alexvanboxel's pull request #122 would allow for two custom frame types, which would be great, although even one would be sufficient for my client's needs. I'd really like to see this adopted.