Beacons are small computers that run software, more specifically firmware. Beacon manufacturers write the firmware that uses Bluetooth software libraries to send out iBeacon, Eddystone and/or sensor data advertising.
When a beacon supports over-the-air (OTA) update, it allows that firmware to be updated without physically connecting to the beacon with wires. A smartphone app, such as the manufacturers’ app or the generic Nordic nRF Toolbox is used to connect to the beacon via Bluetooth and update the firmware.
In practice, manufacturers never update their firmware so whether a beacon supports OTA update or not isn’t usually an issue. An exception is Sensoro beacons, when the user wants to switch between standard Sensoro firmware and Eddystone Standard GATT firmware.
A further use of OTA is the facilitation of custom firmware when the standard firmware needs to be updated to provide for specially required functionality. This is non-trivial and ideally needs to be performed by the original manufacturer because they have the original source code. We have arranged this for a few customers but it tends to only be financially viable for large orders.
It’s also possible to completely replace the software in some beacons, something we provide via custom solutions and used in our social distancing and mesh solutions. In these cases, OTA tends to be too slow so wired programming jigs are sometimes used instead.
This is part 3 of a 3 part series that explains what’s inside a beacon. In this part we take a look at the System on a Chip (SoC) software and programming for the Nordic nRF range found in the majority of beacons.
Despite the small size and memory, a typical beacon contains lots of code written in the c programming language. The code required to implement Bluetooth, called the Bluetooth stack, is very complex. It also has to pass tests by the Bluetooth SIG, called qualification. To prevent every product vendor using the SoC having to write the Bluetooth part themselves, Nordic supply what’s called a SoftDevice. A SoftDevice is a precompiled and linked binary library implementing a wireless protocol, Bluetooth in our case.
For the nRF52, the S132 SoftDevice provides a qualified Bluetooth® 5 low energy (BLE) Central and Peripheral protocol stack solution. It provides eight connections with an Observer and a Broadcaster role all running concurrently. Use of a softdevice allows developers to concentrate on their own high level product functionality rather than lower level complexities.
Beacon manufacturers or 3rd party developers such as ourselves create a program using either SEGGER Embedded Studio (SES), MDK-ARM Keil µVision, GNU/GCC or IAR Workbench. Most development now uses SEGGER Embedded Studio because Nordic have licensed it to allow Nordic developers to use free of charge. Most Nordic code examples in the nRF52 SDK now include a SEGGER Embedded Studio project file.
There are two ways of programming, either pre-programming the SoC with production code before mounting using socket programming or programming the SoC after mounting in the circuit. The PCB holes mentioned in part 1 are used to program the beacon in the circuit. A jig with pogo pins (pins with springs) can be used to help programming larger number of devices:
The other end plugs into a nRF52 DK that has a debug out header at the top right:
If you keep the pins connected to your beacon, you can run and debug the code, in situ, via the SEGGER IDE. However, debugging is not that capable because it’s not possible to continue from breakpoints. You have to re-run or rely on lots of logging to the console.
The nRF52 DK also contains a nRF52 which means it can be used in the initial stages of product development prior to moving to actual hardware.