-
Notifications
You must be signed in to change notification settings - Fork 760
No reference to Eddystone-URL Flags #12
Comments
I believe these must be all 0 right now, and serve only a reserved-for-future-purpose, and so the value of the byte has to be = If the flags are important to mention now, we can document, but it will require software updates to take advantage anyway, right? |
Is the "hidden" flag still supported with Eddystone-URL? That might be the flag in question; it's the lowest order bit of what is now the frame type. |
In the Eddystone-URL Config Validator under Core Eddystone-URL tests, there is a test called "Flag Written are Broadcasted", where it writes a 1 to the flags, and expects to see the flag change in the advertisement. There is no mention of where this flag is actually located in the advertisement packet. It makes sense that it could be the lower four bits of the frame type, but they are currently reserved and must be set to 0000. Where are the flags located in the URL advertising packet, what are the acceptable values, and is the aforementioned validator test still applicable with the new spec? |
@collinmast Indeed there is no mention in the advertising packet spec, and we will fix this. @devunwired Indeed the flags fit into 4 bits of the frame type (though I believe it is the highest-order bits). I am under the impression that 0000 is the only valid value, but am working to confirm and compile a list. Very sorry for the lack of clarity here, expect an answer from @roywant next week. |
Flags are actually a common feature of all frame types, and are documented in the common frame protocol specification document. It is in fact the four low-order bits, and the values are indeed reserved for future use and must be 0000 for now. This means that we are not currently using the "hidden" (aka "Invisible Hint", aka "machine-to-machine") flag that uribeacon used. It was not commonly implemented anyway, but we will consider reintroducing it if need arises. Perhaps it is odd to document the flags only in the common section and not mention it in each frame spec, given that the frame type byte is specified there. I will update the docs to point to the flags section. |
Can i get a clarification please? I am trying to implement the Eddystone URI frame and every test except for the flags test passes. I have 2 concerns
This leads me to believe that the eddystone-url frame documentation is out of synch with the eddystone-url validation app. |
There is some confusion here but you're right about tests not being identical for UriBeacon and Eddystone URL flags. Check lines 524 and 481 from TestHelper.java in eddystone-url-config-validator. Indeed 3rd byte of the URL frame is right shifted 4 bits and compared with the written value which then corresponds to the higher 4 bits of URL Schema byte in Eddystone URL Frame spec. Flags are not mentioned in the spec yet above implementation is what the tests expect. |
Pretty sure this is an issue of the validator app being out of synch with the spec, this pull request looks to fix it #43 |
Hi keremgocen & BlackstoneEngineering, I'm PM for the Eddystone-URL team and think I can help clear up some of the confusion here:
|
After some discussion we have decided to leave the Flags characteristic as a read/write uint8 value for future expansion. The documentation now provides the following guidance on its use: "The Flags characteristic is a single unsigned byte value. The top 4-bits are defined by the |
Should the validator app be updated to make sure writing to the characteristic modifies the correct bytes of the packet? |
In the Eddystone-URL readme there are not mentions to the URL flags. I believe the URL flags are the 4 most significant bits of byte 3.
The text was updated successfully, but these errors were encountered: