RN4020: Eddystone beacon tutorial

13

In this blog post I will show you how to configure the RN4020 module from Microchip as an Eddystone Bluetooth beacon, using one BLE2 click and one USB-UART click board from MikroElektronika. Of course, this tutorial applies to any other RN4020 breakout boards and can be used with almost any FTDI-based USB-UART which provides RTS and CTS data pins.

As a prerequisite, the RN4020 module must be updated to the latest firmware version BTLE v1.33.4 BEC. If your RN4020 module comes with an older firmware version you have to upgrade it first – see also the RN4020 firmware upgrade tutorial for instructions.

Before we go to the RN4020 configuration, a few words about Bluetooth beacon technologies…

Bluetooth beacons

First of all, what the heck is a Bluetooth beacon? Well, it’s a small device that exist for the sole purpose to broadcast information to nearby smart devices that are listening for those advertisement packets. So, to use a beacon one must have a smart device with Bluetooth enabled, and depending on the beacon type you might need a dedicated app that listens to those broadcasted packets and performs different actions.

The most obvious use is as a shopping aid, broadcasting special offers, etc. Museums can use beacons to act like a virtual guide, allowing for a dedicated app to display personalized information. Packets broadcasted by beacons can be used to provide accurate location. And those are only a few possible applications of the Bluetooth beacon…

One must observe that actually the beacon itself is a “dumb device” – it does only broadcast messages, the rest is done by the application installed on the smart device. The beacon does not track you. It simply can’t, as it’s a broadcast-only device. If there’s any user tracking, that is done within the application on the smart device.

Beacon technologies

By now three major beacon technologies are on the market: iBeacon, AltBeacon and Eddystone.

iBeacon is a technology developed by Apple in 2013. An advertised packet consists on a standard iBeacon prefix, 16-byte UUID, followed by a 2-byte major and 2-byte minor. Although any beacon can be regarded as an Ibeacon if it broadcasts according to the Apple standard, the use of iBeacons is limited by the strict Apple licensing policies.

AltBeacon is a standard developed by Radius networks as an open and inter-operable specification for proximity beacons.

Eddystone beacon technology was developed by Google in 2015 and brings some nice enhancements over the AltBeacon standard. Eddystone beacons can be detected by both Android and iOS devices. Eddystone is an open standard, the specifications being available on https://github.com/google/eddystone. In many ways the Eddystome beacons can be regarded as the foundation of the physical web, which aims to be an “open approach to enable quick and seamless interactions with physical objects and locations”.

An interesting aspect of the Eddystone beacons is that it provides several different advertising frames:

  • Eddystone-UID: A unique, static ID with a 10-byte Namespace component and a 6-byte Instance component.
  • Eddystone-EID: A time-varying beacon frame that can be resolved to a stable identifier by a linked resolver.
  • Eddystone-URL: A compressed URL that, once parsed and decompressed, is directly usable by the client.
  • Eddystone-TLM: Beacon status data that is useful for beacon fleet maintenance, and powers Google Proximity Beacon API’s diagnostics endpoint. TLM frames are usually interleaved with an identifying frame such as Eddystone-UID or Eddystone-EID.

From a maker’s point of view, one of the most interesting aspects of the Eddystone beacon technology is the ability to broadcast URL information. Thus, many smart devices that run Google Chrome with physical web enabled can receive the URL information, without the need of a dedicated app.

With Eddystone I can simply place one beacon outside my maker space, advertising it to anyone in the close proximity. All I have to do is broadcast a short URL to my blog page. Simple as that. And you will see that it’s so easy to implement such a beacon, and it uses only one RN4020 and a pair of AA batteries.

Going for a such simple approach means that some sacrifices must be done – the beacon I propose today broadcasts only URL frames. No TLM (telemetry) frames are broadcasted, so you can’t check the beacon status from a distance. Also no UID frames, as those are usable only with a dedicated app, and writing apps for iOS and Android is beyond the purpose of this blog.

1 2 3

Share.

13 Comments

  1. So I have a question on this. you show the encoded value is

    0303AAFE1216AAFE10F2036269742E6C792F6D7962636E

    but you entered in
    03AAFE and
    16AAFE10F2036269742E6C792F6D7962636E

    so the first 03H and the 12H (payload size) are missing.

    I agree this works, because I copied and got it to work. Just dont understand why those two bytes were left out.

    • The first 03H is the length of the first packet. Also 12H is the length of payload (18 bytes). Both values are automatically computed and added to the encoded value by the software within RN4020.

  2. I don’t follow the encoding of the NB messages NB,03AAFE and NB,16AAFE10F2036269742E6C792F6D7962636E.
    The RN4020 firmware release note for 1.33BEC says that the NB command format is based on altbeacon and the first parameter is the AD Type (03 = Complete list 16-bit UUIDs, 16 = service data) it doesn’t seem to match the Eddystone format that you’re using.
    Am I missing something ?

    Please advise,
    Thanks

    • Hi Chris!

      Please refer to RN4020 Firmware v1.33BEC Release Notes.

      On page 4 the description of ND command sais: NB,
      This command is used to customize non-connectable advertisement payload.

      On page 5 you have the different types of AD
      AD Type HEX Description
      01 – Flags
      02 – Incomplete list of 16-bit UUIDs
      03 – Complete list of 16-bit UUIDs
      04 – Incomplete list of 32-bit UUIDs
      05 – Complete list of 32-bit UUIDs
      06 – Incomplete list of 128-bit UUIDs
      07 – Complete list of 128-bit UUIDs
      08 – Shortened local name
      09 – Complete local name
      0A – TX power level
      0D – Class of device
      0E – Simple pairing hash
      0F – Simple pairing randomizer
      10 – TK value
      11 – Security OOB flag
      12 – Slave connection interval range
      14 – List of 16-bit service UUIDs
      15 – List of 128-bit service UUIDs
      16 – Service data
      FF – Manufacture Specific Data

      With this information, you can build any broadcasting packet (including AltBEacon, Eddystone, and Ibeacon).

      Please note that the RN4020 performs some internal processing of NB information entered, and adds extra information to that (such as packet length).

      So, in my case of Eddystone beacon, the protocol is (according to https://github.com/google/eddystone/blob/master/protocol-specification.md):

      Every Eddystone frame type must contain the following PDU data types:
      – The Complete List of 16-bit Service UUIDs as defined in The Bluetooth Core Specification Supplement (CSS) v5, Part A, § 1.1. The Complete List of 16-bit Service UUIDs must contain the Eddystone Service UUID of 0xFEAA. This is included to allow background scanning on iOS devices.
      – The Service Data data type, Ibid., § 1.11. The Service Data – 16 bit UUID data type must be the Eddystone Service UUID of 0xFEAA

      Thus, two NB commands are needed to build one single Eddystone frame. One for the “Complete List of 16-bit Service UUIDs”, the other to define the “Service data”.

      In the case of other beacon standards such as AltBeacon or Ibeacon, the syntax might differ. There’s an example for AltBeacon in the release notes. So, if you wish to broadcast in that format you can use that file as reference.
      I haven’t explored the possibility to send Ibeacon frames yet.

      What type of beacon are you trying to make? Is it Eddystone, or something else? I could do more to help you if you can tell me exactly what you are trying to do…

      Regards,
      Teodor

    • Hi,

      As I understand, you have to stop the beacon service before doing any serial communication. You can resume the beacon operation after the serial communication is completed.
      Note that in beacon mode the RN4020 is only broadcasting packets. It will not listen on Bluetooth communication either.

        • Hi,

          You can build almost any type of packet to be broadcasted, just like I did with the Eddystone frame in my example. You can, for example, follow my procedure to build one Eddystone frame then broadcast it. Then you can stop the broadcast, set up a new frame (let’s say iBeacon), then start broadcasting it. And so on.
          Just remember that you have to stop the broadcast during the activity on the serial port, and you have to re-enable broadcast once you are done.

          The question is, what do you want to broadcast? In the situation of Eddystone and other well-defined beacon formats, the receiver knows what to do with the broadcasted data. You can define your own beacon format but you have to write also the software that receives the broadcasted information. Also, mind the current (Bluetooth) communication standards, you don’t want to interfere with other services running on Bluetooth.

          • Hi

            I can manage the App side so i can manage the data received.

            I would like to clarify my question : lets say i want to broadcast data (by feeding the serial port), but without “real” ble connection, i.e only broadcast. and the App side is just a listener. how can i do it ?

          • Any packet you build using the NB command will be broadcasted to whoever is listening. This is the main advantage of a beacon. No connection is made between the beacon and the receiver.

            You can read the “Non-Connectable Advertisement Payload” section of http://ww1.microchip.com/downloads/en/DeviceDoc/RN4020%20Firmware%201.33BEC%20Release%20Note-May2016.pdf for more information. You’ll also find a good example for AltBeacon there – that’s just another (simpler) beacon.

            Probably you’ll have to do something like NB, XXYYYYYY, where XX is the ad type from Annex 1 of the above file, and YYYYYY is your data to be broadcasted.

Leave A Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.