How to include custom sensor data in Eddystone about eddystone HOT 23 OPEN

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 [email protected] 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
#88 (comment).

from eddystone.

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.

from eddystone.

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?

from eddystone.

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.

from eddystone.

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 [email protected] 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
#88 (comment).

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

from eddystone.

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
[email protected]
voice: 425.941-6045
skype: bob.whelan

On Thu, Sep 10, 2015 at 10:56 AM, Roy Want [email protected] 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 [email protected] 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
#88 (comment).

---

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
#88 (comment).

from eddystone.

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.)

from eddystone.

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

Bob

Bob Whelan
Co-founder
[email protected]
voice: 425.941-6045
skype: bob.whelan

On Thu, Sep 10, 2015 at 10:37 PM, Michael Ashbridge <
[email protected]> 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
#88 (comment).

from eddystone.

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.

from eddystone.

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.

from eddystone.

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.

from eddystone.

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.

from eddystone.

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

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

from eddystone.

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).

from eddystone.

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

from eddystone.

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

from eddystone.

@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

from eddystone.

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

from eddystone.

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

from eddystone.

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.

from eddystone.

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.

from eddystone.

@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.

from eddystone.

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.

from eddystone.