Setting the iB003N State

The iB003N can transmit up to three channels: iBeacon, Custom and Accelerometer Data. If you only want to send iBeacon, the iOS and Android app ‘Config’ screen implicitly sets the state to iBeacon only transmission when you set the iBeacon parameters.

On iOS only, the Eddystone screen allows you to set the custom channel to send Eddystone that implicitly sets the state to transmit the Custom channel only.

What if you want to transmit both iBeacon and Custom channels or also send the acceleration data? What if you want to enable motion triggered broadcasting? For cases such as these, you have to set the beacon state explicitly (manually) via the Bluetooth Service Characteristic 0x2A80 as described in the iB003N user guide .

Sleepy bit rot on Twitter has produced a useful table showing what values have to be set for some specific configurations:

Provisioning Bluetooth Mesh Devices from Smartphones

We previously mentioned there are currently no app examples of how to provision Bluetooth mesh devices via apps on smartphones. Well, Filip Nowakowski has announced:

Make Your Mac Advertise iBeacon

Want to experiment with beacons without buying one? There’s a new command line tool mBeacon that allows you to set up your Mac to advertise iBeacon.

You use by typing the following command:

$ mbeacon -uuid "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX" -major 0 -minor 0

The ability to easily change the UUID, major and minor is also useful for development purposes where you wish to test, for example, an app that’s looking for lots of different beacons.

Nordic nRF5 SDK for Mesh v2.0.0 Released

Nordic, who provide the System on a Chip (SoC) in many beacons, have released v2 of their Mesh SDK that implements standard Bluetooth Mesh.

The main improvements are around support for Bluetooth GATT. It’s now possible for devices such as commercial beacons or smartphones to participate in the mesh via the GATT Proxy mechanism. It’s also possible for devices such as smartphones to provision new devices via GATT through Provisioning Bearer GATT (PB_GATT) rather than via firmware API or the serial API. Unfortunately, there are currently no app examples so there’s a large learning curve and development mountain to overcome to implement products based on these mechanisms.

Martin Woolley, who works for the Bluetooth organisation as an evangelist, has new slides (PDF – needs login at Google for some reason) from a Bluetooth Mesh talk at DroidConIT. The slides explain many of the mesh concepts. Here’s the slide showing the GATT proxy mechanism:

The documentation for Mesh v2 is on the Nordic web site.

Beacons in the Smart Workspace

Sensorberg has a great new video that provides inspiration regarding what’s possible in the smart workspace:

This video also provides a learning for marketers. As with all the best ideas (and promotion), it’s often best not to mention how things are achieved – in this case predominantly using beacons. People don’t need to know this and are more interested in what it does, the benefits and how it makes people feel.

Long Range Beacons Don’t Solve Blocking Problems

We coincidentally had two customers last week with the same query and the same resolution. They wanted to know why their ultra long range beacons weren’t achieving the expected range.

It turns out both customers where expecting the beacons to transmit through obstacles. It’s important to understand what can block signals. When a signal gets blocked, there’s no point trying beacons with longer ranges in the hope they will push the signal through the physical obstructions. Longer range beacons only work long range when there is unobstructed line of sight such as in a large warehouse or event space.

The Risks of Using SaaS – The Easy Way Isn’t Always the Best Way

In recent years there has been a movement towards software being provided “as a service” whether supplied free to induce users to buy/use other services/products or via a subscription model. The software provider usually gains through having a long term revenue stream. Companies gain easy access to ready-made and managed solutions to their problems. It all sounds perfect. However, there are risks in using Software as a Service (SaaS) that need to be understood and managed.

Creating an app or platform that integrates a 3rd party SaaS API ties you to that platform. If the platform is discontinued you have the complex task of re-writing to use the new API and migrating existing data. If there’s no similar alternative, you are faced with implementing the SaaS provided service for yourself.

Most SaaS providers are VC funded which means they tend to initially give away their APIs for free or at low cost to attract customers. Once shareholders start to want to see revenue, monthly fees increase. We are already seeing this with many beacon platform providers. Once Angel or VC funding runs out, platforms can disappear. A high profile example in the beacon ecosystem at the moment is Onyx.

The risks aren’t constrained to using VC funded companies’ services. Google has recently removed services related to the Physical Web.  They are about to deprecate Google Cloud Messaging (GCM) that’s used in thousands if not millions of apps.

So what can you do? The first thing is do your due diligence. Is the company providing the SaaS you are considering likely to be around for the lifetime of your project? Is the company (like Google) renowned for deprecating services? Do you really need all the SaaS functionality or could you make do with a simpler developed or open source solution? Might you be able to use the SaaS for a proof of concept or minimum viable product (MVP) and plan to move to a developed solution?

Read about Generic Beacons

Consider our Software Development Services

Is The Physical Web Dead?

Important: This web page is provided for historical purposes.

On 25 October 2018, Google announced they are discontinuing Nearby Notifications on Android. This mechanism should no longer be used.

Read about using Beacons for Marketing

There has been speculation that the Physical Web, as championed by Google, is dead.

Here’s what we know:

  • In October 2017, Google removed Eddystone URL from Chrome on iOS and Android.  Eddystone URL in Chrome on iOS wasn’t being used much and Eddystone detection had been moved to (and is still in the) the Android OS.
  • In November 2017, Google Nearby Beacon Functionality Was Severely Cut by Google. This is different to Eddystone-URL and relies on Eddystone-UID beacons being registered at Google. The result was that the Beacon Tools app only works with Eddsytone GATT beacons (not iBeacons).
  • There has been no activity in the Physical Web GitHub account for about a year. Google is no longer working on improving Eddystone. This is unfortunate because Bluetooth 5 presents lots of new opportunities that require evolution of the Eddystone standard.
  • In 2017, Scott Jenson, the person who brought the Physical Web to Google and became the Product Manager of the Physical Web team, moved to the Chrome UX team and since more recently moved to the Android UX team.
  • Very recently, Scott said “If there was still a Physical Web team, it would be fun to create these more semantic layers on top of the URL.” So, we now know there’s no Physical Web team and there probably hasn’t been since Scott moved teams.
  • The Physical Web Twitter account says “This account is no longer active”.
  • Despite Google moving away from active development of the Physical Web, they are still fixing problems. There was issue with the Physical Web proxy that was recently fixed where “issue triggered in the presence of an invalid URL beacon (ex: a non-HTTPS page) in the proximity of other valid beacons.”. This is reason why some scenarios might not have previously worked (and will now work).

In summary, while new development on Physical Web is dead, the mechanism still works and Google is still applying fixes. Google has removed some functionality that was rarely used and has disbanded the Physical Web team. However, Google is still maintaining the Physical Web proxy and Eddystone notifications still work on Android.

Meanwhile, a group of people led by Agustin Musi from Switzerland is contemplating creating PhysicalWeb2. There’s a Slack channel you can join or you can email them at contactus@phwa.io. There’s also a new site at phwa.io.

Read about using beacons for marketing.

Diversity in Uses of Beacons

The latest Spring 2018 WirelessQ Magazine (pdf) from Nordic demonstrates some diverse uses of beacons. For example, it mentions the use of Beacons to open doors for the visually-impaired:

A later article in the magazine explains how Bluetooth Low Energy is rapidly
expanding into industrial markets:

“Bluetooth LE technology is growing far beyond its consumer roots by underpinning innovative solutions for the Industrial Internet of Things”

 

Obtaining Distance from RSSI

RSSI is the signal strength at the Bluetooth receiver. The signal type, for example, iBeacon, Eddystone or sensor beacon is irrelevant. The value of the RSSI can be used to infer distance.

The accuracy of the distance measurement depends on many factors such as the type of sending device used, the output power, the capability of the receiving device, obstacles and importantly the distance of the beacon from the receiving device.

The output power isn’t known to the receiver so it’s sometimes added to the advertising data in the form of the ‘measured power’ which is the power at 1m from the sender.

The closer the beacon is to the receiver, the more accurate the derived distance. As our article mentions, projects that get more detailed location derived from RSSI, usually via trilateration and weighted averages, usually achieve accuracies of about 5m within the full range of the beacon or 1.5m within a shorter range confined space.

There’s some Android Java code on GitHub if you want to experiment with extracting distance from RSSI. There’s an equation for iOS on GitHub.

Need more help? Consider a Feasibility Study.

Beacons that flash/vibrate at a given distance.