search

google / eddystone

Specification for Eddystone, an open beacon format from Google
Apache License 2.0
3.08k stars 762 forks source link

Specification for Interleaving #57

Closed alexvanboxel closed 9 years ago

alexvanboxel commented 9 years ago

I just implemented a prototype on a nRF51-DK board that uses all frame types (UID, URL and TLM). Using all 3 frame types is a valid use-case. The only thing I'm missing in the spec is guidelines for interleaving all frame types.

A good description of interleaving is written in the TLM section, but I think interleaving deserves a separate page with guidelines and good practices for implementors.

I did the sensible thing and interleave URL and UID one by one, and every 10 frames send a TLM frame. I see the frames appear on my Android device. Still it would be good to have some extra information on good interleaving strategies.

scottjenson commented 9 years ago

The issue really depends on your use case. Each format specifies how often you broadcast. For example, Eddystone-URL recommends every 700ms. That is low enough for a long battery life but still quick enough to be responsive for the user. However, you're welcome to broadcast faster if you'd like to. Eddystone-UID has it's guidelines on timing as well. You shouldn't think of it as interleaving as much as broadcasting based on the appropriate interval (e.g. UID every 300ms, URL every 700ms, and TLM every 10000ms) These numbers are just examples and not hard recommendations.

mashbridge commented 9 years ago

Yes, it's hard to provide any meaningful one-size-fits-all advice here. Another consideration is how people will use your beacons. If you're expecting them to be used in an active scanning context where your users have some app running in the foreground and performing an aggressive scan, you'd want to be broadcasting very frequently. But if your app is scanning infrequently as a background service, then you could get away with broadcasting much less frequently (and so on and so forth).