No reference to Eddystone-URL Flags about eddystone HOT 13 CLOSED

@roywant, @mmocny can you take a look at this?

from eddystone.

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 = 0x10. I removed the complexity of the description field to be more in-line with what UID looked like.

If the flags are important to mention now, we can document, but it will require software updates to take advantage anyway, right?

from eddystone.

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.

from eddystone.

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?

from eddystone.

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

from eddystone.

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.

from eddystone.

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

1. the "flags" field is not referenced in the eddystone-url frame spec, it is part of the old URIBeacon spec, but seems to have been depricated for the eddystone-url frame format. Is this an error in the unit test, or is it missing documentation?

2. Assuming that the "flags" field (aka the frame type) is in fact the lower 4 bits of the Frame Type field, then for an eddystone-url frame it would look like 0x1X, where X is the 4 bits of flag data, correct? I am double checking because when I implemented this the eddystone-url-config-validator fails.

This leads me to believe that the eddystone-url frame documentation is out of synch with the eddystone-url validation app.

from eddystone.

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.

from eddystone.

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

from eddystone.

Hi keremgocen & BlackstoneEngineering,

I'm PM for the Eddystone-URL team and think I can help clear up some of the confusion here:

• The UriBeacon flags are not in Eddystone-URL by design
• The lower-order 4 bits of the Frame Type byte are reserved for future use as flags, but for now must be set to 0. Thus, the possible Frame Type byte values are 0x00, 0x10, 0x20.
• The Eddystone-URL configuration service spec and is being amended to remove the URL Flags characteristic. The corresponding validator is being amended to have the Flags test removed.

from eddystone.

The validator app was fixed by #47 (which was just merged). @roywant: The spec still has to be amended to remove the reference to the flag.

from eddystone.

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
Eddystone-URL Frame code as 0001, and the bottom 4-bits are reserved flags for future use, and must be set to 0000. As a result, the characteristic currently has a fixed value of 0x10, and although it is a read/write value, it should not be changed. When the lower 4-bit flags are defined,
this documentation will be updated, and the flag values can be written accordingly."

from eddystone.

Should the validator app be updated to make sure writing to the characteristic modifies the correct bytes of the packet?

from eddystone.