There’s a new article at Bluetooth.com that explains how to capture Bluetooth packets on iOS. The PacketLogger can decode all protocols defined by the Bluetooth Special Interest Group (SIG) and Apple, perform filtering, automatically highlight problems and search and export data.
This will work for both Core Location and Core Bluetooth. Core Location is using the iBeacon APIs while the lower level Core Bluetooth allows scanning and connection to any Bluetooth LE devices, not just beacons. It’s best to use the Core Location APIs and only use Core Bluetooth for more involved scenarios not supported by Core Location.
Note that Core Bluetooth, even though it’s lower level, can’t scan the iBeacon UUD, major and minor. Apple hides these values to force you to use Core Location.
Here are the top questions we get asked as a Bluetooth LE developer:
For apps, can the app work without Bluetooth and location on? No. There’s no special OS mechanism on iOS nor Android that uses Bluetooth LE without the user having Bluetooth and location on. Many users leave Bluetooth and location on to allow ease of use with cars and audio headphones. Location is also usually one due to use with maps.
How does leaving Bluetooth on affect battery life? Bluetooth is no longer drains the battery as was the case in the early days of smartphones. It can be left on with negligible extra battery use.
What’s the maximum range? The range depends most on the Bluetooth device to are connecting to. Most devices, running on battery, work 50m to 100m. Devices with larger batteries, running from mains or USB can work up hundreds of metres. We have a device that works up to 4000m.
What SDK should be used? Most, but not all, SDKs and 3rd party libraries tend to be poorly implemented/documented, tie your code into using a particular beacon and rarely get updated to use newer mobile platform APIs. We recommend software use the iOS and Android Bluetooth APIs directly to make your code independent of the beacon type and readily able to be updated when the mobile platforms themselves are updated.
There’s often the requirement to show data triggered by beacons detected by iOS and Android apps. There are many SaaS subscription systems to do this for you but what if you want to host the data yourself or have a large number of beacons where SaaS solutions aren’t economically viable?
You could create your own CMS. However, take a look at SBCMS. SMCMS provides a simple open source CMS that can be hosted on your own server or automatically on a Heroku cloud server instance.
There’s a new updated version of the Universal Bluetooth Beacon Library that works on Windows 10 (UWP) and Android (Xamarin). The core library also works on iOS, Mac and Linux. It allows you to write applications to parse iBeacon and Eddystone advertising.
We are sometimes approached by companies after their initial choice of developer has let them down. The usual pattern is failure to meet deadlines after which the developer gives excuses why they can’t continue on the project. iBeacon projects introduce extra complexities that, if not experienced previously, can slow or stall projects. In the worst of cases this can cause developers to drop out wasting valuable time and in some cases loss of money that can’t be recovered.
A resultant problem is that it’s difficult to take on others’ code. The only time this is usually possible is when the developer has left for a good reason and is still around for a short time to answer questions. Noone wants to take on abandoned code as as it’s usually poorly implemented and documented.
Organisations are generally too casual about how and who they take on for development, concentrating on cost and speed at the expense of risk. Do some checking so you reduce some of the risks.
Ask who (yes a person, not a company) will be actually doing the work. How long have they been with the company? Try to assess whether they are likely to see your project through to the end. Try to get a reference for work done by the person. Ask the reference about quality and whether the work was completed on time. The better developers provide weekly or even daily builds for you to review. This allows you to evaluate progress and provide feedback. Think about how much pre-sales feedback has been received. For most projects, developers ask things and provide initial advice. If it’s all ‘can do’ or ‘yes’ then suspect something is amiss.
Successful development is a long term relationship and a random approach to choosing one is more likely to land you in trouble. It’s sometimes the case that there’s more work to be done on amendments, enhancements, solving end-user problems and creating variants than on the original development. Think longer term.
Most of the time, beacons transmit and the receiving software such as apps on iOS and Android or applications on single board computers (SBC) only read the advertising data. There’s no connection to the beacon. However, for programmatic setup of beacon parameters or accessing some sensor data, applications might need to connect via Bluetooth GATT.
There’s a recent article on How to Work Properly With BT LE On Android. It provides some useful pointers such as not performing scanning and GATT connection simultaneously, avoiding auto-connect and not blocking GATT callbacks.
GATT can be flaky on Android. While scanning for advertising data usually works well, we have found that GATT connections fail all the time on about 5% of devices. This is due to poorly implemented OS Bluetooth software. This means beacon manufacturer-supplied configuration apps can’t connect. The only solution is to use a different phone (or the iOS version of the app on iPhone).
Nordic Semiconductor has recently published a great downloadable guide on programming Bluetooth LE and hence Beacons on Android. It covers Android permissions, scanning and how the API varies across versions Android 4, 5 and 6. There’s are also a section on GATT connections and how to use Android as a GATT Server.
For some of our beacons such as the Axaet and Sensoro product ranges the manufacturers haven’t documented their Bluetooth Service Characteristics. This means that while they are ok for scanning/proximity type applications, you can’t write your own app to, for example, change programatically the UUID, major and minor and must rely on the manufacturer’s configuration app or, in the case of the Sensoro beacon, their SDK. While this of no consequence for the majority of uses, more ambitious scenarios might want directly access the Bluetooth GATT services.
Uri Shaked has written a great article on Medium on how to Reverse Engineer a Bluetooth Lightbulb. His method uses the developer logging in Android 4.4 and later to allow inspection of the Bluetooth packets and hence the Bluetooth Services and Characteristics that are being used. This method can equally be used with iBeacon and Eddystone beacons to reverse engineer the Bluetooth GATT information.
If you are developing a beacon app to receive unique iBeacon and Eddystone ids (as opposed to URLs), an area you should think about is caching text, images and other media.
Beacons transmit unique ids and these ids need to match up with information held elsewhere, not on the beacon, that determine what the app does and what’s displayed to the user. The problem is that in many scenarios the beacons have to be placed where the user is likely to have no or poor Internet connectivity. Poor connectivity can be as just as bad as no connectivity if larger size media such as images needs to be downloaded.
Your app and sometimes server design might need to take into account the caching of information. Some of this information can usually be bundled with the app at the time of install while information that needs to be up to date might need to be fetched ahead of time. In some cases, you might need to use a combination of the two with information bundled with the app being replaced as new information becomes available.
Here are the kinds of things you need to think about:
What information is included at the time of install. In the extreme case, where you think a large number of people will be foreign and roaming, this could be all your information.
Whether the bundled information needs to be updated at the time of install.
A server side mechanism to determine when information is out of date and needs to refreshed. Such mechanisms should prevent the same information from being downloaded more than once.
A client, app side mechanism to get notified of information updates.
Whether the information is updated in app background or under control of the user.
For optimal display of images, provision of different size images for different (screen) size devices.
Strategies to reduce client device resources (battery) and server stress. This might include grouping associated information that’s likely to have to be used together.
What the end user sees when information is being updated or not available yet.
If and how information eventually gets purged to save space.