search

google / eddystone

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

Eddystone-URL uses BroadcastMode? #36

Open arpit-ag opened 9 years ago

arpit-ag commented 9 years ago

I need clarification on a few points:

  1. What type of Advertisement PDU is used for each Eddystone Frame type?
  2. Eddystone-URL Configuration Service spec says Eddystone-URL should not be connectable during regular URL Advertising mode which means beacon device acts as a broadcaster, and thus accoeding to bluetooth spec 4.2 device in the broadcast mode shall not set the ‘LE General Discoverable Mode’ flag or the ‘LE Limited Discoverable Mode’ flag in the Flags AD Type. So Flags must not be there in EddyStone-URL Frame. Correct me if I am wrong.
mashbridge commented 9 years ago

Every Eddystone frame shares a common structure and each frame type is encapsulated in the Service Data data type.

I'll let @mmocny and @roywant talk about the URL-specific questions.

arpit-ag commented 9 years ago

Actually for first question I want to know the PDU type(like ADV_IND / ADV_NONCONN_IND / ADV_SCAN_IND / ADV_DIRECT_IND) used for each Eddystone frame in BLE Advertisement packet Header. Does all uses the same PDU type? And also can you clarify is FLAGS AD mandatory (which will depend on what PDU Types is used in Advertisement Header ) in each Eddystone Frame or its upto the developer.

mashbridge commented 9 years ago

We've intentionally left the specific flags undefined. Some implementations may want to remain connectable so they're always configurable, others may want to interleave frames with scan responses, others may want to lock things and be non-connectable after provisioning. While we have advice (like preferring NONCONN in dense 2.4 GHz environments etc.) we feel implementors know their own use cases better than we do.

arpit-ag commented 9 years ago

Thanks a lot @mashbridge for clarifying.

arpit-ag commented 9 years ago

@mashbridge I have another doubt. Since EddyStone -UID says: The length of this frame is fixed and takes up the full 31 bytes of the ADV packet. The value of the Service Data Length byte must be 0x17(23 B). Existing UID implementations that truncate the frame to omit the RFU bytes will use 0x15(21B). This calculation comes only if FLAGS AD is included in Frame. According to BT4.2 CSSv6 we can skip FLAGS AD if we use ADV_NOCONN_IND. So is it mandatory to use the Length specified in the Specs. Same is the case of EddyStone-TLM.

davidgyoung commented 9 years ago

I had not noticed the statement that the length must be 0x17. If this is true, how is it possible to have shorter URLs that do not use all the bytes available in the PDU?

mashbridge commented 9 years ago

@arpit0410 Good catch. An earlier revision of the spec did fix the flags etc. but this should speak only w/r/t the service data PDU. @davidgyoung This is just for UID frames. URL frames are have variable length.

arpit-ag commented 9 years ago

@mashbridge So Is there any Plan to Use those 3 Bytes that we get from FLAGS AD which won't be there in ADV_NOCNN_IND PDUs. In that case spec needs to change these Service Data Length Value to allow use of full use of 31 Bytes available.