search

google / eddystone

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

In Eddystone It' said we can combine all frame then what's it's maximum support bytes #48

Closed himanshumistri closed 9 years ago

himanshumistri commented 9 years ago

Hello ,

In Eddystone we have three type of data format like Eddystone-UID,Eddystone-URL and Eddystone-TLM .Now we can able to combine all this three format in one beacon device current ? If yes then what's length of Data spec byte length it can support . Also any example for combine all three protocol specification into one beacon .

keremgocen commented 9 years ago

No combination of 2 of the 3 frame types would be small enough to fit in one single advertising packet when you have a maximum of 31 bytes advertising payload. Maybe a second frame could fit in the scan response but I would not imagine the general purpose scanners would expect that behavior either.

I would consider interleaving options as an alternative depending on your use case. On Jul 30, 2015 13:25, "Himanshu" notifications@github.com wrote:

Hello ,

In Eddystone we have three type of data format like Eddystone-UID,Eddystone-URL and Eddystone-TLM .Now we can able to combine all this three format in one beacon device current ? If yes then what's length of Data spec byte length it can support . Also any example for combine all three protocol specification into one beacon .

— Reply to this email directly or view it on GitHub https://github.com/google/eddystone/issues/48.

marcwan commented 9 years ago
  1. One device can totally emit all three beacon types, sure. You'll of course want to understand your usage scenarios well, but there are already hardware beacons that support this.
  2. As @keremgocen mentioned, there's very little flexibility in frame sizes — these are fixed, and if you want to support more than one, you'll have to have your device emit each frame type separately (which is what existing devices do).
  3. Furthermore, scan response tends to have undesirable performance characteristics (it temporarily locks the beacon while it's communicating with the device asking for the scan response) so there has been a tendency to shy away from using that.