It seems that range 0x00-0x06 is exactly the same as 0x07-0x0D in the Eddystone-URL HTTP URL table.

Example
0x00 = .com
0x07 = .com

is this by design. If not? Better to remove it. If it is it should be explained in the document.

Is there is any solution for getting notification when the app not running state (killed).Ibeacon can wake up the ios app, is there is any equivalent in Eddystone ?. please replay

Is it possible to include custom sensor data other than battery level, temperature, advertising counts and uptime to TLM?

I wanted to request that the byte codes for the Eddystone-URL HTTP URL encoding include expansion to the .me domain. As they say: "a byte saved is a byte earned".

After saving a new URL in the Android App the Android device no longer detects the Beacon unless you once again out it into configuration mode. I am not sure if this is an issue with the CSR1010 code or the Android APP...? Appreciate any help...

The function func didLoseBeacon(beaconScanner: BeaconScanner, beaconInfo: BeaconInfo) it´s never fired. Everything else it's working fine but this. When a new beacons is detected the right method (didFindBeacon) it's fired; every second the method didUpdateBeaconis called too. I try removing the battery of my beacon and the method it's never called even if the seconds declared in "var onLostTimeout: Double = 15.0" occur.

Hi guys. I am working with BLE beacons for some time now (>1 year), and also worked on creating the OneBeacon Android SDK for these things, which also supports detection of Eddystone beacons too, Also,I just published on Play Store my own app that creates virtual Eddystone URL/UID beacons (search for Beacon Toy).

After thinking on this for a while, I have some suggestions for the URL format of packets. I can see that the payload only uses ASCII characters, which basically means 16% of the payload is unused.

My suggestion: allow for some better compression (new schemes prefix) by only using 7 bits for each character in the URL. This way, you have room for all current reserved values and expansion codes, but also gain 17 more bits, which means the URL length can be extended by 2 characters (plus 3 more bits for optional flags, great as a header maybe?).

A second solution, which allows even more compression, but has stricter URL requirements:

Encode each URL character to 6 bits (basically decode to base64), but forget about expansion codes (no room). Also, translate the two user-modifiable base64 chars (_ and +) to '.' and '/' (to compose the URL). So this means the URL cannot contain anything else except letters, digits, dots and slashes.

However, the maximum URL length would be extended to 22 characters, instead of the current 17. This would be a great value for URL shortener services that currently do NOT fit inside a Eddystone URL beacon (for example youtu.be short URLs do not fit with the current spec). Even if you lose some compression due to '.com' etc. not being encoded, there's now more room for a custom domain (most of them are 2-letter country TLDs).

Thanks and good luck!

Hello,

I'm not too familiar with Swift but in Eddystone.swift file in the class func frameTypeForFrame(advertisementFrameList: [NSObject : AnyObject])
-> EddystoneFrameType.... I don't know how to resolve this error...

if let uuid = CBUUID(string: "FEAA")....Xcode 7 reports:

Eddystone.swift:126:9: Initializer for conditional binding must have Optional type, not 'CBUUID'

It might be good to add a Windows 10 implementation of Eddystone-URL. Someone is trying to here and not sure how: http://stackoverflow.com/questions/33334157/how-to-advertise-eddystone-url-frame-using-windows-10-ble-api

Flags incorrectly states that their type is uint8. The flags should be just a nibble.

Unsigned value is not being cast back to a signed value in Eddystone.swift.

I'd like to set a name to my eddystone beacon (knowing it will reduce its lifetime) and I wonder if the eddystone spec says something about now allowing scan responses.

Hi,
In the specification you write:

and also

The Service Solicitation data type as defined in The Bluetooth Core Specification Supplement (CSS) v5, Part A, § 1.10. The List of 16 bit Service Solicitation UUIDs must contain the Eddystone Service UUID of 0xFEAA. This is included to allow background scanning on iOS devices.

but the 0x03 is the Complete List of 16-bit UUIDs data type. Also the Android app advertises with type 0x03, not 0x14. As the beacon does not have any service (it's non-connectible) the Solicitation data type should be used, in my opinion, as stays in the doc.

It would not be right to publish the application validator for both Android and for iOS as well as source-only?
This would facilitate all testers and builders of beacons that are not necessarily forced to compile the source code in order to proceed with the tests of the firmware on their beacons.

In my peripheral(lets say a raspberry pi), after installing Bluez and adding a USB module, how can I set the URL?

For example, this is what I have to do for iBeacon

sudo hcitool -i hci0 cmd 0x08 0x0008 1E 02 01 1A 1A FF 4C 00 02 15 [ 92 77 83 0A B2 EB 49 0F A1 DD 7F E3 8C 49 2E DE ] [ 00 00 ] [ 00 00 ] C5 00

which gives the value in [uuid][major][minor] format

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.

Commit 543071d changed the UUID from FEAA to DEAD

Hello,

I've bought a cheap Android phone to run the pre-built Eddystone-URL Validator apk on.
When I try to load the apk I get the following error:

Is this an Android version issue?

Here are the details of the phone:

Thanks,
Barry

The core spec supplement (CSS) v6.0 just came out today so it would be a good idea to update to match it.
One benefit is that you can now leave out the first 3 bytes of the payload (length, flag data type, flags data) and thereby have more room for payload (or just save airtime).

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 .

I'm curious of the rationale for choosing +16dBm as the transmit power in the TxEddystone-UID example.

I'm assuming this is a guess, since the API doesn't expose a way to know what the MIN, LOW, MEDIUM, etc. constants translate to for a given device (wouldn't that be nice??)…as a guess, this seems high. Is the intent to force the beacon to the top of the range sort?

If it's a guess or derived from some experiement, it would probably be good to document/comment it as such. Many folks will copy that code wholesale.

If would be helpful to give examples for each packet type in the spec.

Google should make it so Eddystone allows easy integration for other mobile platforms like Cyanogen, Tizen, Firefox OS, Ubuntu Phone.

One contextual protocol to rule them all \o/

A humble requests that the branding guidelines be amended to include an allowance for use of the Eddystone mark in a light (white?) color as well as the black. Forcing black makes it difficult to include the mark on marketing materials otherwise branded with a darker background color scheme. Even the Physical Web's standard blue (roughly #3c82c6) is really too dark to see the black mark.

https://github.com/google/eddystone/tree/master/branding

The Common Elements section of the Eddystone Protocol Specification states that every Eddystone frame type must contain the List of 16 bit Service Solicitation UUIDs (0x14) data type including the Eddystone Service UUID.

The example frame shown below this statement contains the Complete list of 16-bit Service UUIDs (0x03) data type instead. By not including the Service Solicitation UUIDs it is not following the specification.

Or am I missing something?

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.

The 'Eddystone Validator' app displays a voltage of '0' as an error. The value '0' for voltage is valid as defined in the TLM packet specification:

'Battery voltage is the current battery charge in millivolts, expressed as 1 mV per bit. If not supported (for example in a USB-powered beacon) the value should be zeroed.'

We are currently working to resolve this issue.

Would you consider expanding the capabilities (new version) of the TLM frame type for alternate data encoded with ProtoBuf? Seems like a logical serialization for the constrained data space available - enumerations and low-value scalars.

An example application is to have my house windows tell me (a mobile app, actually) if I left them open. Hall effect sensor, for example. Beacons are very power conserving, so a long-life battery device is possible as a sensor.

Something to consider?

It is possible to receive an Eddystone notification on a android phone (Galaxy S3) without an app?

I'm using a Kontakt Beacon and have changed the profile from ibeacon to Eddystone and created an action with a 17 character URL, but the only way i can get it to work is to download the Physical Web app.

Any ideas?

There are characteristics that can be shared between all types of frame. For example, Advertised TX Power Levels and TX Power Mode. Also, Beacon Period can be shared in some sense. If those are only for URL frames, is there any means to set TX power and period for UID and TLM frames?

4 return codes are listed in Section 1.4, but only the sections 3.1(Lock), 3.2(Unlock) and 3.7(TX Power Mode) described usages. Which condition should be checked first overall, in order to determine a proper return code? Length, lock state, and then range? Or the other way around?

By the way, in section 3.2, there are two identical return codes, each of which has different description. How is it translated?

For marketing / display use, it would be beneficial to have a logo with a title in a stacked/vertical layout, similar to the existing horizontal layout with same color options (svg, minimally).

There is no info in specification that negative values are not valid for TLM frames, so I think it would be logic to expand range in Eddystone Validator app(now it's 0 to 60 degrees Celsius).

Specify the endianess for battery voltage, temeperature, PDU count and seconds count in the TLM format. The same should be clarified for the ID Namespace and ID Instance in UID. Basing on the indexes in the table I assume it's Big Endian in all cases. It's more common in Bluetooth Smart to use Little Endian thou.

Similar to PR filed on google/physical-web#447, machine-specific files should not be in the Android projects. the URL validator .gitignore looks good for this, but the TxEddystone-UID sample is allowing IDE workspace and IML files to committed (and indeed have already been committed).

I'll be generating a PR for this shortly.

As per the Eddystone-UID Frame Specification the frame size is 20 bytes, with the last 2 bytes having a value of 0 and RFU.

However, the ios-eddystone-scanner-sample code checks that the frame size is equal to the size of ESSEddystoneUIDFrameFields (18 bytes). This structure does not include the 2 RFU bytes.

https://github.com/google/eddystone/blob/master/tools/ios-eddystone-scanner-sample/EddystoneScannerSample/ESSEddystone.m#L170

The Android eddystone-validator tool, check that the last 2 bytes of the 20 byte frame are set to zero.

https://github.com/google/eddystone/blob/master/tools/eddystone-validator/EddystoneValidator/app/src/main/java/com/google/sample/eddystonevalidator/UidValidator.java#L76

Does the iOS scanner example need to be corrected?

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.

I don't have beacon so I try using TxEddystone-UID to broadcast Eddystone-UID BLE packets.

I try to validate it using EddystoneValidator but receive Frame errors: null service data. The LogCat shows:

11-17 12:42:52.759 23069-23069/com.google.sample.eddystonevalidator E/EddystoneValidator: 4A:91:20:15:4B:66: Null Eddystone service

I try to randomize namespace and instance ID but still facing null service data. I do not modify the source

I run this on Asus Zenfone 2 and Mi4i both running Lollipop

Where is the problem actually lies? is it on the advertiser or scanner?

Originally started from here.

I have a Radius Network USB beacon which behaves as follows:

1. I see on the Android app an "ID" which, if I am correct, is the Eddystone UID and is composed by "Namespace+ Instance id". Something 16bit with this style: F878EF540E104A32F87100000000000001
2. If the device loses power this UID gets reset.

According to Radius this is the hard reset way of the beacon so shouldn't be a bug but a default behavior. However I write this issue here so you guys judge better if it's really a bug :)

PS: Radius tags (dots) keep this UID after "switching them off" but should lose the UID after loss of power (according to docs - cannot confirm this).

eddystone-tlm:

Beacon temperature is the temperature sensed by the beacon and expressed in a signed
8.8 fixed-point notation. If not supported the value should be zeroed.

What are the units? Degrees C? Degrees K?
If it is the former, it is ambiguous, because the "not supported" value (0) is also a valid value for an outdoor beacon.
It can't be the latter because 8.8 is not big enough to represent common temperatures.

One thing that would work is degrees C, but with "not supported" represented by -128 (0x8000).

I'm using the sample Swift code supplied by Google for Eddystone. Radius Networks suggested this would be a good place for my issue. I need to take the telemetry data and convert it to human readable form. Is there any sample code to help do the conversion. Here's the data I'm receiving:
Telemetry: [FEAA: <20000bf9 18b30000 30f80000 19af>]
20 Telemetry Frame Identifier
00 Telemetry Version
0bf9 Battery Level
18b3 Temperature Reading
000030f8 PDU Count
000019af Up time"

Any help or links would be great.
Jerry

Is it possible to turn an iOS device into an Eddystone, by broadcasting the Eddystone-UID frame (similar to what txeddystone-uid tool for Android does). This would be a very useful feature.

Thank you

I have read in the specs docs that the FEAA service is added to allow IOS devices to scan Eddystone Frame from background. As far as I know the only way to detect BLE beacon devices in such conditions is using CoreLocation and iBeacon Format.

Maybe I´m losing something...

Can you tell me someting more about this...

Thanks and congrats for you innovative and primising work.

Also let me point that I think you need to redefine the URI-Config mode to a more general Eddystone-ConfigMode and allow then to change the 10 bytes UID and the 6 bytes ID...(Unlocked devices of course)

I think this is necessary to have a complete independant specification...otherwise this changes will be done via propietary protocols, as it is done right know...

Nice weekend !!

An IPv4 address when written as a string tops out at 16 characters, fitting within the Eddystone-URL specification's 17 character length.

An IPv6 address is much larger: if written out as a string it will be up to 40 characters long. Please consider adding the ability for a beacon to advertise an IPv6 address. This would likely mean introducing a new mode where numeric addresses can be directly represented. Perhaps a 0xFF in the HTTP URL Encoding could designate that the remaining bytes are numbers, or perhaps a URL Scheme Prefix could be introduced for IPv6 addressing modes (one for HTTP, one for HTTPS).

Many mobile phones for example have IPv6 but not a known DNS name: they should still have some option to advertise their address as a Eddystone-URL. Similarly, IoT devices could benefit from being able to advertise their addresses directly rather than needing to maintain DNS names. google/physical-web#413 (comment) mentions IPSP, a 6lowpan over BLE protocol; another place where it would be good to be able to advertise IPv6 addresses.

I ran the application and set my device as a beacon.

However it is seen as "registered"
How can I set it's status to "unregistered" ?

I looked at code and saw no such mode

public static final int ADVERTISE_MODE_LOW_POWER = 0;

/**
 * Perform Bluetooth LE advertising in balanced power mode. This is balanced between advertising
 * frequency and power consumption.
 */
public static final int ADVERTISE_MODE_BALANCED = 1;

/**
 * Perform Bluetooth LE advertising in low latency, high power mode. This has the highest power
 * consumption and should not be used for continuous background advertising.
 */
public static final int ADVERTISE_MODE_LOW_LATENCY = 2;

/**
 * Advertise using the lowest transmission (TX) power level. Low transmission power can be used
 * to restrict the visibility range of advertising packets.
 */
public static final int ADVERTISE_TX_POWER_ULTRA_LOW = 0;

/**
 * Advertise using low TX power level.
 */
public static final int ADVERTISE_TX_POWER_LOW = 1;

/**
 * Advertise using medium TX power level.
 */
public static final int ADVERTISE_TX_POWER_MEDIUM = 2;

/**
 * Advertise using high TX power level. This corresponds to largest visibility range of the
 * advertising packet.
 */
public static final int ADVERTISE_TX_POWER_HIGH = 3;

What an unexpected surprise....

So, don't panic...ready to convert our UriBeacon plans to Eddystone approach.

M

BLE is developer lingo so in branding/marketing related texts you should change that to say Bluetooth Smart(tm). That what the marketing name is for BLE.
In the code, dev-related docs etc it is perfectly fine with BLE.

Examples of where it should be changed is the approved phrases in the branding document.

Hello, is it possible to flash a generic beacon to Eddystone firmware and control the frames with app/software?

Checked Pi hardware and BTLE dongle with another app. Updated bluez. Ran advertise-url with the v switch. Output looks as expected.

..
Encoded uri length: 16
Message: 1d 02 01 1a 03 03 aa fe 15 16 aa fe 10 ed 02 76 69 72 74 75 61 6c 2d 74 65 63 68 6e 6f 07 00 00
sudo hciconfig hci0 up
sudo hcitool -i hci0 cmd 0x08 0x000a 00
sudo hcitool -i hci0 cmd 0x08 0x0008 1d 02 01 1a 03 03 aa fe 15 16 aa fe 10 ed 02 76 69 72 74 75 61 6c 2d 74 65 63 68 6e 6f 07 00 00
sudo hcitool -i hci0 cmd 0x08 0x000a 01

Also checked that phone can see the RPi (but did not pair it of course)
Then fired up the Physical Web Andoid app from playstore and started it.
Shows "Nearby Beacons" but does not find any.

What are the next steps to find out why my beacon is not found?

Thx. Paul

When trying to run the scanner from the project written in Objective, I get this error.
Unsupported frame type (0) detected. Ignoring.

Swift build works just fine after a small adjustment. Posted a PR fixing this.

Any ideas?