The 4th Industrial Revolution (4IR), also known as Industry 4.0, is the use of technology to improve operational efficiency, increase throughput, minimise downtime, improve quality and lower costs. We have an article that explains how beacons are part of 4IR.
There’s a lot more to 4IR than tracking items and analysing data. It also includes areas such as automation, robotics, cyber security and 3D printing. There’s a free online Industry 4.0 Magazine that can help you get up to speed.
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:
Jig in use at BeaconZone
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.
We sometimes get asked “What is iBeacon Technology?”. In terms of the beacon itself, iBeacon doesn’t imply much. The underlying Bluetooth does most of the hard work. iBeacon is only one of many possible formats of standard Bluetooth advertising.
The iBeacon advertising consists of three identifiers UUID, major and minor. We have an article explaining how these are usually set up.
The more useful functionality is in iOS itself. Apps can declare an interest in particular beacons and be triggered even when the app is not running. The triggering is usually used to cause a notification on the phone that the user can tap on to do more. If the app is already open, it can look for beacons and display appropriate app content.
Android may also trigger and scan for iBeacons but this is in the context of scanning for Bluetooth advertising as opposed to specific iBeacons.
This is part 2 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), in particular the Nordic nRF range, found in many beacons.
In part 1 we identified the Nordic nRF52832 SoC. The nRF52 is a newer version of the Nordic nRF51 that has been used in millions of beacons. The new version has more memory, uses less power and includes NFC. The extra memory is useful for applications such as Bluetooth Mesh.
nRF52832
The Nordic nRF52832 SoC wasn’t created just for beacons. It’s a general purpose device for any electronics that needs to have 2.4GHz wireless communications and software processing. The nRF51 and nRF52 series can be found in many fitness trackers and wearables. For example, the BBC micro:bit, the Polar GPS multisport watch and Garmin’s child activity monitor.
The SoC is a stand alone computer having an ARM® Cortex™-M4 CPU with a floating point unit. The NFC-A Tag can be used in pairing and payment solutions which makes it suited for use with smartphone apps. The SoC also has digital peripherals and interfaces such as PDM and I2S for digital microphones and audio.
nRF52832 Block Diagram
It has very low power consumption via an on-chip adaptive power management system. It uses between 0.3 μA and 1.9 μA, depending on the mode, and can still respond to events. For beacons, it periodically wakes up for about 1ms, during which it uses about 5.3 mA (at 0 dBm power output).
Power use during iBeacon advertising
The SoC supports ANT™, IEEE 802.15.4, Thread, and proprietary protocols operating in the 2.4 GHz bandwidth as well as Bluetooth®.
The marking on the chip denotes the variant with different RAM and flash combinations:
The image in part 1 shows the i7 beacon has the QFAA variant with 64 kB RAM 512 kB Flash. As with SSDs, the flash can only be erased and written so many times. For the nRF52832 this is 10,000 erase/write cycles. This is irrelevant for most beacons as they save very little data, irregularly, usually only when settings are changed. However, for applications such as mesh, the number of erase/write cycles needs to be minimised to prevent the device wearing out in a short period of time.
Tracking things and/or people makes organisations more efficient through enhanced productivity. Most organisations want to improve a specific problem in one of the following areas:
Stock Control – Knowing how much you have, where, without any human checking
Finding Items – Picking items without time-consuming manual searching
Safety & Security – Knowing when assets move, go missing, are dropped or crashed into
Process Efficiency – Preventing human error of manual audits, knowing an expensive asset is being fully utilised, providing real time workplace instructions
Having solved a problem, it’s often the case that the act of digitisation allows other problems to be identified and also solved.
There are many ways to track assets using beacons. Beacons can be put on assets and detected by smartphones, Bluetooth gateways, Bluetooth mesh, or other Bluetooth LE devices such as single board computers. Alternatively, beacons can be fixed and the detecting device(s) can move. Software can be in the detecting devices and/or at a server receiving data from the detecting devices. It’s also possible to use a real time locating system (RTLS) to map the positions of assets.
The optimum solution depends on your situation and requirements. Here are some aspects to think about that will determine the optimum solution:
What’s the size of area(s) and sub-areas (rooms, zones) you need to cover and is this outside?
What’s the physical makeup of the areas (walls, racking) and their composition?
What’s the electrical infrastructure (power, WiFi and Ethernet availability) and can this be upgraded?
What assets need to be tracked?
What attributes of assets need to be tracked (just location or sensor data as well?)
How many need to be tracked?
How many are in the same place, at the same time?
How often do the assets move?
How accurate do you need the locating?
How up to date do you need the tracking?
Who needs to do the tracking, from where?
How many people need to do the tracking simultaneously?
What kinds of information/report do you require and what’s the desired method of receiving?
This is part 1 of a 3 part series that explains what’s inside a beacon. In this part we take a look at the physical beacon.
All beacons are similar inside because they are based on standard circuit designs from Nordic Semiconductor, Dialog Semiconductor or Texas Instruments. These semiconductor manufacturers produce a complete system on a chip (SoC) that requires minimal external components. The SoC is a small computer with memory that runs software created by the manufacturer of the beacon. We will take a deeper look at the SoC in part 2 and the software in part 3.
For this series of articles we going to take a deeper look at Minew’s i7 beacon. It’s based on Nordic Semiconductor’s nRF52832 SoC.
Minew i7
Inside the case is a PCB with a CR2477 slide in battery at the rear.
Inside the i7
The main chip you can see is the mRF52832. At the top you can also see the antenna that’s created using a track in the printed circuit board. The holes at the bottom right are connections used to program the beacon.
To understand more, we need to look at the printed circuit board design and circuit schematic:
i7 design
Circuit diagram – click to see larger in new window
It can be seen that there aren’t many external components. Y1, the metal component at the top is the crystal used to maintain timing. The SoC has a number of programmable input/output (PIO) pins that are multi-purpose. In a beacon some are usually connected to LEDs and a switch as shown at the left hand side of the circuit diagram. There are also capacitors that need to be external to the SoC.
Prognostics is the determination of health of assets to diagnose anomalous behaviour and predict the remaining useful life. It’s used to:
Prevent catastrophic failures
Increase asset availability through less downtime and less time wasted through ‘no fault found’ tests
Extend maintenance cycles
Execute timely repair
The overall aim is to lower lifecycle costs via fewer inspections, repairs and manual inspections. It can be applied to all types of assets across all sectors but is particularly applicable to manufacturing, industry and infrastructure. Infrastructure includes roads and ports as well as utility industries such as water, power and gas.
Prognostics and in-situ testing isn’t new. However, what is new is substantially improved viability and economics. New sensors, such as beacons, are easier to use, can be attached to legacy equipment and have much lower costs. The cost of connectivity and cloud storage is also decreasing. This means more assets can be retro-actively connected and the sharing of data across assets and platforms enables a more complete operating picture. This opens up new business opportunities.
The paper explains the four main types of prognostic management strategies: corrective, fixed-interval preventative, failure-finding, and condition-based maintenance (CBM). It also explains a new fusion approach to prognostics:
The paper gives examples of use of prognostics in the manufacturing, heavy industry, energy generation, transport & logistics, infrastructure assets, automobile, medical, warranty and robotic industries.
It ends with the mention that, in the future, current research and work on energy harvesting will benefit sensors used for prognostics.
Beacons are small computers with a complete System on a Chip (SoC). There are four main companies that manufacturer SoCs: TI, Dialog, NXP and Nordic. Nordic is the most popular SoC for use in beacons, mainly because of the lower (tool) license cost and ease for beacon manufacturers developing the software (actually called firmware) that runs in the beacons.
Nordic has a new free Wireless Quarter Magazine that showcases uses of Nordic SoCs in many types of device, not just beacons.
Learn about:
Gartner research showing sensor innovation fosters IoT growth
Beacons help U.S. shoppers find way
Bluetooth LE in Amazon FreeRTOS
Bluetooth LE smart textiles on the rise
Article combining Bluetooth Low Energy and LPWANs
Firmwave’s use of Bluetooth Low Energy beacons to build an inexpensive satellite broadcast system
The G1 gateway collects advertising data from iBeacon, Eddystone, Bluetooth LE sensor and other Bluetooth LE devices and sends it to your server by HTTP(S) or MQTT/ using WiFi or Ethernet.
It’s often the case you need to know if a beacon is working and advertising the correct information. It’s also sometimes necessary to differentiate between beacons, based on their signal strength, so you know you are setting up the correct beacon. Other times, you might want to know a beacon’s MAC address.
The best scanning app is Nordic nRF Connect that’s written by the manufacturer of the System on a Chip (SoC) in most beacons. Nordic nRF Connect detects all beacons and indeed all Bluetooth LE devices, irrespective of the SoC manufacturer because it just looks for standard Bluetooth advertising. nRF Connect is intelligent in that it works out the kind of beacon and displays the appropriate type of information.
It’s important you use the Android version of nRF Connect. Due to over-zealous efforts by Apple to hide identities, it’s not possible for iOS scanning applications to see advertising iBeacon (UUID, major and minor) information nor the Bluetooth MAC address.
Here’s an example scan:
In the above screenshot you can an iBeacon that has been tapped on to show extra information. All devices have the MAC address and a Received Signal Strength Indicator (RSSI). The MAC address uniquely identifies the device.
Devices that scan for beacons will experience a signal strength (RSSI) that varies depending on the distance to the beacon. It’s expressed in dBm and is always negative. A more negative number indicates the beacon is further away. A typical value of -10 to -30 dBm indicates the beacon is close. A typical value of -110 indicates the beacon is near the limit of detection. You can use this to determine which beacons are closest. You usually configure beacons when they are right next to the phone and have a higher, less negative, RSSI.
nRF Connect also shows the advertising period that’s based on how often the app sees the advertising as opposed to what has been set in the beacon. The value is rarely exactly what you have set because Bluetooth requires some randomisation of the advertising period to reduce the possiblity of collisions between devices, in the vicinity, that are set to the same period. Also, being wireless, not all advertising is seen which causes jumps in the shown advertising period. Read more about choosing the advertising period.
There’s also a ‘RSSI at 1m’ which is the beacon’s self-declared value, in the advertising data, of what the RSSI should be at 1m. This can be used by scanning devices, such as apps, as a form of calibration for determining distance. In most cases this value isn’t used and should be ignored. Read more about power and the measured power calibration value.
