I have a bunch of generic beacons from China that I'd like to upgrade to Eddystone. How do I go about doing this?
Some beacon hardware vendors like Estimote and Kontakt.io now support Eddystone™ too. You are able to easily change the broadcasting scheme of your beacon to iBeacon or Eddystone protocol. In the below video by Pushmote URL, you can see how to change Estimote beacons' broadcasting scheme to Eddystone™ protocol:
https://www.youtube.com/watch?v=gX0AlAOB6NU
As it's possible with Estimote and Kontakt.io beacons, it might be possible with yours too. Contact with your hardware manufacturer to see the possibilities.
I am quoting it from here
Generally the "transmit these bytes" instructions are carried out in
firmware on the beacon and can't be controlled in real-time via
software. Many beacon manufacturers have updated their provisioning
applications to allow their devices to broadcast Eddystone frames. For
generic beacons (maybe you mean raw BLE chips? or Arduino/R-Pi sets?)
you'll need to set the bytes to Tx manually since there's no generic
provisioning app (or not that I'm aware of).
Thanks to Michael Ashbridge (aka) mashbridge
Unfortunately, you probably can't. Generic beacons typically don't offer firmware upgrades, and few if any generic vendors offer Eddystone support.
Full disclosure: I am Chief Engineer at Radius Networks, which sells beacons with Eddystone support.
Related
We're designing a Bluetooth LE peripheral that implements some primary GATT service and needs to advertise the existence of the service as well as a few bytes of data related to the service. The device is intended to connect to arbitrary consumer smartphones (therefore mostly Android and iOS). We use a 16-bit service UUID and plan to advertise the related data via the advertising data type 0x16 (Service Data - 16 bit UUID). Due to the limited size of the advertising PDU, we'd like to avoid any additional advertising data, most notably we'd like to avoid advertising the same UUID also via data type 0x03 (Complete List of 16-bit UUIDs).
As the device should be used with consumer smartphones, compatibility is a major concern and therefore the compliance with relevant standards is as well. A critical aspect seems to be that the smartphone OSes should be able to do efficient filtering for devices advertising our service, so the app may run and listen in the background.
A safe approach would be to advertise both, 'service data' as well as 'complete list of UUIDs', because all OSes are certainly able to filter for UUIDs advertised in the latter, but this would exceed the size of the advertising PDU. We could also configure the mobile's BLE scanner to return all BLE devices nearby, without any filtering and do the filtering in our own code, but this wouldn't be efficient and wouldn't allow to run in the background.
We did some testing with different smartphones (Android and iPhones, older and newer ones) and at the first glance filtering for service UUIDs when only the service data type is advertised, seems to work just fine. However, we couldn't find any documentation (neither for Android nor for iOS) that definitely states that this is a supported scenario, so we can't be sure that it works on all phones and also in the future.
The Apple Accessory Design Guidelines section 36.4 refers to the Bluetooth Core Specification Supplement, Part A and states the following:
The advertising data sent by the accessory should contain at least the following information as described in the Bluetooth Core Specification Supplement, Part A:
Flags
TX Power Level
Local Name
Services
[...]
The primary services should always be advertised in the advertising PDU.
However, this doesn't make clear which kind of advertising data type should be used and the same is true for the Android documentation.
With this context my questions are:
Is it a good idea to advertise the primary GATT service solely via the 'service data' data type?
Would this even comply to the Bluetooth Core Specification?
Is there any documentation for Android and iOS that makes clear, whether this is a supported scenario from the OS standpoint (I actually don't mean the OS source code)?
Are there any Android (>= 5.0) or iOS (>= 11) devices that would not be able to filter for service UUIDs advertised via the 'service data' data type?
What is the best practice in such a case, given the limited size of the advertising PDU?
Thank you for your thoughts!
Is it possible to program a BT beacon to advertise a sequence of different Eddystone-URL/UID's in sequence? I imagine I could from something like a Raspberry Pi3 with a BT adapter, but I was wondering about something like an actual beacon.
Yes, this is possible. This technique is called "interleaving", and it is possible to do with both software beacons and hardware beacons.
Eddystone actually relies on this technique in order to match its multiple frames. When a receiver sees an Eddystone-TLM frame coming from the same device as Eddystone-URL or Eddystone-UID, it knows that the telemetry is for that beacon frame.
Using the same technique, it is possible to send out multiple URL or UID frames from the same device using different identifiers for each frame. Some commercial manufacturers such as Radius Networks support doing this in some of their products.
I dont think so. Im pretty sure you would need to have some smart device nearby that is running a program that is periodically changing the UIDs. The micro-controllers that power these beacons are pretty bare bones and are really optimized for transmitting bluetooth signals.
Here's how to do it.
EddyStone supports four types of payloads/frame-formats i.e, UID, URL, TLM, and EID.
Eddystone UID/EID are the frame-formats to use for this purpose.
As far as using the 'NordicSemiconductor NRF line' of beacons just make sure that these are fully Eddystone compliant i.e, support the EID frame-format.
Freely available Google Beacon Cloud platform is great for trying this out (called 'registering and provisioning your beacon').
It can be implemented w/o building or requiring any custom app at the client end.
On the client-side.
Use 'Google Nearby Notifications' & 'Google Nearby Messages'
On the server/cloud-side.
Google Proximity API for 'registering and provisioning your beacon'
Use 'Google Nearby Messages' API
Good luck with your project .
I have a couple of questions concerning BLE beacons:
1) Are beacons based on nRF51822 chip the best solution? Or are there any other chips better than nRF51822? I want to take up BLE beacon development and struggling to find the right hardware for these needs. As a novice developer I want the beacon to be as cheap as possible in order not to waste money in case of a failure.
2) Is it possible to buy pure Eddystone beacon (not iBeacon)? The reason for choosing Eddystone is that Eddystone is capable of broadcasting URLs that are essential for me.
The second question stems from my failed attempts to find a pure Eddystone beacon on Chinese electronics sites like alibaba.com or aliexpress.com where the only firmware available is iBeacon. But iBeacon is not an option because it can't broadcast URL the way Eddystone does.
Apart from the above questions It would be great if someone wrote a quick guide for taking up BLE development with Eddystone and covered basic topics like: chip to use, beacon model, best website to buy beacons at, etc.
Thanks in advance,
Pavel
1) I've worked with Estimote beacons and Chinese beacons from Amazon and in my opinion, they do not differ in terms of accuracy too much. Especially for prototyping, I'd buy cheaper ones to test if your use case can be satisfied with BLE beacons. If it is too inaccurate with Chinese beacons, chances are that it won't work with more expensive ones either.
2) Why do you need the URL broadcast? If the app is going to use the url, it would have to be connected to the internet. Therefore, you can just query the beacon's IDs to a web service to get back an URL and use that. Personally, I think this is a better approach as you can configure the web service from anywhere to change the url for beacons where as if you want to change the URL of the Eddystone, you have to go to the beacon to configure it.
The nRF51822 is a common implementation, is flexible, well understood and can be very inexpensive. Be aware though that development costs, add on circuitry for power and/or peripherals, and packaging can easily eclipse the Bluetooth chip when you get to production cost savings.
If you want to buy an off the shelf beacon, most models supporting Eddystone also support iBeacon, simply because supporting both adds no additional hardware cost. Newer Radius Networks and Estimote beacons all support both. And, yes, cheaper generic Chinese suppliers often have bulk manufactured inventory from before Eddystone existed at only support iBeacon.
I am using a generic BLE plugin for PhoneGap when developing a BLE enabled application. It gives me beacons identification and RSSI, but reading more advanced attributes like battery status or TX power require specific communication with a beacon, which is manufacture dependant as far as I know. Does anybody of you know, how to read for example the battery status from Stick'n'Find BLE beacons. So far I have been able to discover, that it's necessary to connect to the beacon and after it a characteristic has to be read. But here, I am lost.
Marek
You must use a manufacturer SDK to do this. One user reported:
I reached out to the manufacture and they have an SDK (and sample app), you have to sign up for a free account to get access: https://bluvision.com/developer/beeks-beacons-sdk/ http://bluvision.com/developer/wp-content/uploads/sites/2/2014/09/Android-SDK.zip
See here: https://stackoverflow.com/a/26424648/1461050
I'm looking to implement the Bluetooth protocol over a physical Wi-Fi based transport, if that makes sense.
Basically my phone has Bluetooth, and my laptop has a Wi-Fi card (802.11a/b/g).
I know that Wi-Fi operates over the range 2.412 GHz - 2.472 GHz, and that Bluetooth operates over the range 2.402 GHz - 2.480 GHz.
I couldn't help but notice the overlap here. So my questions are:
What sort of low-level APIs would I need (preferably in C, on Windows) in order to send a signal out at certain frequencies on the Wi-Fi card?
Would I be able to implement a Bluetooth stack on top of this?
So basically, can I transmit Bluetooth using my Wi-Fi card as essentially a radio transmitter?
Thanks
Implementing the Bluetooth protocol over a physical Wi-Fi based transport does make sense!
Bluetooth high speed (v3.0) defines the possibility to use alternate MAC/PHY layers, known as AMP feature. The L2CAP and higher layer protocols from Bluetooth can be transmitted over a Wi-Fi MAC/PHY layer rather than a Bluetooth MAC/PHY layer with a resulting higher throughput. Some products are on the marked supporting this - look for 'Bluetooth High Speed', AMP or Bluetooth v3.0 support.
No, you can't do this. Bluetooth devices are typically wrapped up all in one chip. Plus, they use completely different modulation techniques. No low-level anything is going to allow you to transmit anything different, unless you are flashing the device. Even then, it may not get you much closer.
Bluetooth Modulation Information:
http://www.palowireless.com/infotooth/tutorial/radio.asp and http://classes.engr.oregonstate.edu/eecs/spring2003/ece44x/groups/g9/jon_gillen/white_paper_jon.pdf
About the only thing you can share between WiFi and Bluetooth devices is the antenna. (Assuming only one device is using it at a time... don't blast 32mW into the receiver of the other radio!) The radio itself is all wrapped up into the same chip. The same is generally true for WiFi.
Bluetooth and Wifi have different phy layer protocols and thats what is coded into their chips, hence you can't use one chip to transmit packets of the other protocol.
Moreover most of the chip vendors, do not expose any RF logic.
Technically yes but there are some things to consider such as the pre existing coding on the chip and if the chip can support Bluetooth coding as well as wifi coding, I mean if you have two separate wifi chips go ahead and try but be warned I tried and nearly killed my computer because of preexisting copyright protection coding on other parts of my pc that prevented any programs on the chip from starting until I reset the chip to factory defalts.