RoadTest: Beagle Bone Black Industrial IoT Kit
Author: shabaz
Creation date:
Evaluation Type: Evaluation Boards
Did you receive all parts the manufacturer stated would be included in the package?: True
What other parts do you consider comparable to this product?:
What were the biggest problems encountered?: No issue experienced that wasn't a quick web-search away (such as dealing with the Linux Bluetooth protocol stack called BlueZ). There are high quality libraries created specifically for the supplied SensorTag which avoid needing to directly interact with BlueZ utilities. Everything I could have wanted was available. One point knocked off for not having a dedicated website for the entire bundle, and it would also be nice to have a display included in the bundle but really I'm nit-picking.
Detailed Review:
The BeagleBone Black (BBB) was a revolution when first released; it was low cost, ran fully featured Linux (a full-blown regular distribution of Linux, not cut-down) and was fully open hardware. Over the years it has proven to be a remarkably resilient design that has been replicated by many businesses.
The BeagleBone Black Industrial version is identical in functionality to the original BeagleBone Black but is intended for industrial purposes.
I’ve used the BeagleBone Black for several years so it was good to re-examine it and see if it will be relevant in 2017 for IoT and particularly industrial IoT. The kit comes with wireless add-ons from Texas Instruments and LM Technologies, as well as an industrial grade 8GB microSD card from Panasonic. The LM Technologies add-on is a very tiny Bluetooth Smart USB adapter.
The Texas Instruments add-on is a ‘SensorTag’ which is an extremely interesting product (and it was very unique when first introduced). The SensorTag is a pocket-sized showcase of sensors combined with wireless and a low power microcontroller allowing it to run from a watch battery for years. I’m on my third SensorTag and everyone that sees it is fascinated by its capabilities. Invariably I end up giving them to family members/kids because they’ll have many hours of fun with it.
In a nutshell the BeagleBone Black is a Raspberry Pi sized computer (and it is often compared with the Raspberry Pi) with built-in DRAM and Flash memory and comes with Linux pre-installed. It is based around Texas Instrument's AM335x series Sitara processor (ARM Cortex-A8 core). Getting it running is easy; plug the USB port into a PC and it will power up via the cable and it will appear like a device on a network provided the drivers are installed (which incidentally are supplied on the BeagleBone Black too because the USB connection also looks like a mass storage device (MSD) to the PC.
The BeagleBone Black is a thoughtfully designed board with many features. Physically it can fit inside a standard Altoid’s mint tin (provided it is protected against shorts) and has two rows of dual-in-line (DIL) sockets for connecting to additional hardware. There is built-in battery charging capability and it can function from a single LiPo cell; this is also useful where a backup supply is needed when the main power source accidentally gets disconnected.
The build quality is excellent; there is a barrel socket for DC power (it can also be powered directly from the 46-way DIL sockets) and there are holes for 3mm screws to secure it into a case.
It is easy to wire a power switch to it, and for a more ruggedized interface connectors like DB-9 can be wired into the DIL rows of sockets as shown in the photo below.
The BeagleBone Black has a wealth of information, full schematics and in-depth system reference manual. All the parts have full datasheets too; in the case of the processor there are several thousand pages of detail. Anyone is free to replicate the BBB design and Element14 has improved on the original design by tightening up the components so that it is specified for operation at -40-+85 degrees C (thermal considerations should still be taken in account of course but there detailed thermal design guide and thermal considerations documents available from Texas Instruments). This might sound extreme but it is definitely possibly to hit high temperatures in industrial environments and low temperature extremes in parts of the world. The BBB Industrial should therefore be well suited for outdoor deployment and it has a clear transparent conformal coating for long service life outdoors and in vehicles.
The design is stable and there are known to be deployments of the BBB reference design converted into custom designs. Businesses have taken the original design, modified it to suit their needs and offer products with BeagleBone at the heart even though it might not be advertised as such.
Although it is possible to connect up a keyboard, mouse and monitor to the BBB for many scenarios it makes sense to dispense with all that and perform all communication over the network (either using the Ethernet connection or by plugging in a 802.11 USB adapter and connecting wirelessly.
It is useful to keep a USB-to-Serial (UART) adapter handy when using single board computers. It provides a useful console session if all other forms of connectivity fail.
The BBB runs a full desktop version of Linux so creating applications for it is straightforward in any programming language. A software library called BoneScript provides an Arduino-like way to access input/output connections. The coding is done in JavaScript either on the command line or in a web browser (there is a web server running by default). It is possible to open up a browser on the PC (or on the BBB if connected to a monitor and keyboard) and begin typing and running code straight away! The screenshot below shows the view; once the code has been typed/modified the ‘run’ button can be clicked for immediate code execution.
I sometimes prefer C programming and to do this, there is a C language GPIO API described here that was co-developed with vegetableavenger who enhanced it and added many features. It makes it easy to immediately connect hardware with inputs/outputs using a simple C-based API without needing to know any Linux related internals.
Toggling a digital pin (in this case pin 12 on the DIL header marked J8 on the BBB) is as easy as
#include "BBBiolib.h"
#define MY_LED_PIN 8,12
{
iolib_init();
iolib_setdir(MY_LED_PIN, BBBIO_DIR_OUT);
pin_high(MY_LED_PIN);
pin_low(MY_LED_PIN);
}
For more information on the library and example code/diagrams check out the github page.
It’s a (literally) little thing, but microSD cards can require extremely careful selection for industrial use-cases. Panasonic’s KC series has a combination of features that make it a good choice. Firstly to keep the price realistic it is based on Multi-Level Cell technology (MLC) although Single-Level Cell (SLC) versions are offered by Panasonic too (SC series). MLC stores multiple bits of information per memory cell which means that voltage detection thresholds need to be tighter when reading the data back out of the cell. Secondly it has a -40 to +85 degrees C operating temperature range. Thirdly it offers static wear levelling capability which is very useful especially where the microSD memory has become almost completely full.
Flash memory has a finite number of write cycles and so in a scenario where a similar amount of data is being written, read and then deleted (for instance data or log files) it wouldn’t be wise to store the next log entry repeatedly in similar locations (i.e. locations that have just had their contents deleted) in the Flash memory. Wear levelling places the data physically in a different location each time so that memory cells are exercised more evenly. However this strategy doesn’t work when the memory card is almost full with data because there are less cards to shuffle so-to-speak. In that scenario static wear levelling comes into effect; it actively moves already-stored data to allow wear-levelling to be effective in prolonging the microSD card life. This feature greatly reduces the risk of damage to memory cells when the microSD card is almost full. The graphic here explains it at a high level. The blue area could be considered to be memory locations that are not deleted often (e.g. storing the operating system and application code). The memory card on the left doesn’t have static wear levelling capability and thus there is a high risk of destroying the red cells which could be sensor data or log files that are moved in and out of the memory card on a frequent basis. The same scenario with static wear levelling is shown on the right side.
The KC and SC series also have a couple of very interesting features also not normally seen in consumer microSD cards. Firstly it has a refresh function to prevent errors that reach the point where they cannot be corrected. I’m not entirely sure how this works but I believe it periodically reads data and then checks voltage levels read, and actively corrects and re-writes to prevent the error threshold occurring.
Secondly there is a very cool feature to recover data even when an external power failure occurs. It works by storing data (presumably in internal fast/low-power static memory) briefly so that any power glitches will have reduced effect because the contents can be written to Flash cells when power resumes. I didn’t have time to test the theory but I hope to do so at some stage.
For an IoT project it would be great to have a small status display so one was created using some LED display modules that I’d had in the spare parts bin for ages. I wrote some code to display custom messages from the Linux command shell by just typing
./led_display “Boo!”
The source code for the led_display program is on github.
Much has been written about the BBB (a good book that goes from high-level all the way into deeper topics is BeagleBone Cookbook: Software and Hardware Problems and Solutions by two experts in the field, Mark A. Yoder and Jason Kridner.
One of the interesting features is the built-in microcontrollers known as Programmable Real-Time Units (PRUs) that are embedded inside the AM3358 chip. These microcontrollers run at 200MHz and provide input/output capability at those speeds too. Data can be fed into the PRUs from the same memory used by Linux! The PRU’s are programmable in C or assembler. The main aim of the PRUs is to implement low-level protocols that are time sensitive; they will execute at the defined 200MHz clock rate with no impact from context switching for the processes running on top of Linux. The PRUs are therefore also great for data acquisition for instance, or other real time tasks that must not be delayed.
Another cool feature is the excellent digital audio capability. It is possible to connect up audio ADCs and DACs to the BBB and clock the BBB’s internal circuitry from the same (external if desired) clock source as the ADC or DAC. This means that a high quality clock can be used for reducing noise in the analog audio.
I also like that it is extremely easy to power the BBB and have a backup supply. And for portable applications the BBB can be exclusively powered from a small Li-Pi cell without needing and external DC-DC conversion or external charger; the charging circuit is built-in.
The BBB has a decent Cortex-A8 processor which includes NEON functionality (this accelerates things like data processing/filtering and graphics manipulations, up to ten-fold compared to older non-NEON-enabled ARM processors.
In many ways the BBB out-performs SBCs because of the additional processors. It is possible to have sustained Gbps-level throughput by feeding data in through the PRUs.
One question that might get asked could be is the BeagleBone Black design still relevant when some single board computers (SBCs) now have four cores? The answer is yes not just because of availability (TI processors are committed for a minimum of 10 years and at least 12 months notice for unforeseen circumstances) and direct TI support, but also because the BBB has extensive documentation and there is deep information on the power supply, temperature and other environmentals for each part. The TI AM335x series and the reference designs have been used by businesses in their products so this brings a high level of confidence to the table.
The CC2650STK SensorTag is essentially a microcontroller board with wireless capability and a lot of sensors, all powered from a coin cell. It is smaller than a box of tic-tacs and has an unusual soft rubber sleeve that can be removed to reveal a plastic case that opens to access the circuit board and battery. Small holes/cut-outs in the rubber sleeve and plastic case allow for the sensors to measure the environment. There are also buttons, LEDs, a buzzer and a microphone! The diagram here shows all the sensors available with the SensorTag.
The CC2650STK is the second SensorTag design from Texas Instruments; the first was based around a 8051 series microcontroller core however the newer SensorTag discussed here has an ARM Cortex-M3 core as part of the CC2650 integrated circuit from TI. The wireless communication method as supplied is Bluetooth Smart but the CC2650 is also capable of ZigBee and 6LoWPAN.
Any desired sensors or custom features can be added to the SensorTag by using the DevPack Connector that is on-board. Some DevPacks are already available for (say) attaching LED lighting to the SensorTag. There is also a Debugger Devpack that is worthwhile acquiring. It has two main uses; it allows for easy interfacing of additional sensors or actuators to the SensorTag, and it also provides a convenient USB to JTAG debugger capability useful for firmware development and programming the device.
Note that if you just need the sensors that are already on the SensorTag then there is no need for modifying the supplied firmware; it is ready to go and will be understandable by any Bluetooth Smart capable computing device. Press the button on the SensorTag and it will remain powered up for around 3 minutes, waiting for a device to connect to it. See further below for details on how to get the BBB-Industrial to connect to it.
Bluetooth Smart, also known previously as Bluetooth 4.0 LE (Low Energy) is a subset of Bluetooth 4.0 and is very different from the older Bluetooth standards as used on wireless headphones for example. Bluetooth Smart is intended for low data rates and can consume very low energy and has the significant advantage that many smart phones support the technology too. Compatibility levels are high through the use of standardised identifiers/attributes. It means it is very easy to take a Bluetooth Smart capable product from any manufacturer and connect it to (as an example) a mobile phone from any vendor, i.e. not be tied into (say) an Apple eco-system. It also means it is very easy to forward information from a personal area network (PAN) to a wide area network (WAN) using a mobile phone as a stepping stone. In fact the supplied TI phone app can do exactly that and push data received via Bluetooth Smart to the cloud over the mobile network or WiFi. This is the same thing that many fitness bands/watches do (they too rely on the CC2650 or similar devices; therefore the SensorTag can be used as a custom programmable fitness device; it is missing some sensors like for heartbeat measurement but it has others that could be useful such as the accelerometer to estimate walking/running steps).
When communicating using Bluetooth Smart devices play one of two roles known as the Peripheral and as the Central device role. The device that can send out broadcasts is the Peripheral device. The SensorTag is programmed to be a Peripheral device. The device that can initiate communication with Peripheral devices is known as the Central device; in our scenario the LM506 Bluetooth-USB adapter is playing the Central device role.
The communication between the BBB-Industrial and the Central device is sent using a protocol known as HCI (Host-Controller Interface). Note that in the case of the BBB-Industrial and the LM506, the transport is USB of course but other devices could use HCI over UART for example. The LM506 is responsible for converting the HCI messages into low-level radio communication. The HCI messages are higher level and make working with Bluetooth Smart devices easy without having to mess with learning the low-level radio interface.
Each Bluetooth Smart Peripheral device offers ‘services’ such as a temperature service or a humidity service. Each service has characteristics or attributes that can be read or written. For example there will be a characteristic value that provides the temperature.
There are just a handful of HCI messages that are used, in particular HCI Command, HCI Event and HCI DATA messages. On top of that, a link layer protocol known as L2CAP is run and on top of that is a protocol known as GATT which performs the very high level actions such as reading and writing attributes end-to-end. The GATT commands of most interest are Characteristic Read and Characteristic Write. There is a table of services and the corresponding characteristics that are supported by the SensorTag and it is possible to read any one of them by performing a Characteristic Read operation from the BeagleBone. In practice a Characteristic Write is first needed to switch on a sensor, and then the Characteristic Read is performed. To send such Characteristic Read and Write commands from the BeagleBone, some driver software is needed to handle the encapsulation into HCI and sending the data over USB. This is done in Linux using the BlueZ protocol stack which is already installed in the supplied Debian Linux image.
The LM Technologies LM506 is a compact Bluetooth USB adapter that supports Bluetooth Smart and classic Bluetooth. It is based on the Cypress/Broadcom BCM20702 device and comes with drivers for all modern operating systems (including OSX and the latest Windows 10). It works with the BeagleBone Black Debian images immediately with no need to install any additional drivers.
It looks well-constructed, no wobbly bits, and the slightly translucent moulding allows the very discreet, very dim internal blue status LED to be visible end-on or from the side. It protrudes 11mm from the edge of the BBB; this is a good compromise because the internal antenna needs space away from metal objects to perform well. It has a class 2 output level (4.7dBm) which performed as expected. I didn’t explore much in this area but just to provide some very basic real-world range indication, the range was sufficient to maintain communication with the SensorTag through brick walls across the other end of the home and out into the garden with no effort on positioning for best range. To reach the end of the garden I did need to strategically position (this is not unexpected behaviour for Bluetooth Smart devices).
There are several BlueZ supplied applications that are useful for working with Bluetooth Smart devices but in reality just one called ‘gatttool’ is needed. Although gatttool works, it doesn’t mean it is a good tool for the task at hand however. The tool requires some table look-up (the SensorTag table is here, scroll to the bottom) and result interpretation to make any sense of the data that will be retrieved from the SensorTag. It is intended as a simple standalone utility and doesn’t go well with combining it with higher-level applications without a fair amount of effort.
A Bluetooth Scan can be performed to find the address of the Peripheral device (the SensorTag in this case) if it is not previously known using another BlueZ supplied utility. As root user:
hcitool lescan
Switch on the SensorTag by pressing a button until a green light starts flashing and the scan results should appear with the address:
LE Scan ... A0:E6:F8:B6:DD:81 (unknown) A0:E6:F8:B6:DD:81 CC2650 SensorTag
To use gatttool the device address as shown above is needed, along with the characteristic identifier that needs to be read or written using the Characteristic Write or Characteristic Read operations. The identifier is known as a handle value shown in the first column in the table mentioned earlier. In the case of the temperature service a Characteristic Write operation is needed at handle 0x24 to switch on the temperature sensor, and then a Characteristic Read operation is needed at handle 0x21 to obtain the temperature value (for this scenario the value that is returned happens to be a 4-byte value that contains the ambient temperature and the infrared measured temperature of objects in the field of view of the SensorTag’s sensor).
The gatttool commands are shown here and the resultant 4-byte output in this case:
gatttool --char-write -a 0x24 -n 01 -b A0:E6:F8:B6:DD:81 gatttool --char-read -a 0x21 -b A0:E6:F8:B6:DD:81 Characteristic value/descriptor: 84 08 84 0c
Some byte manipulation is then needed to convert the bytes into human-readable values.
Although this all works, a far easier way is to use JavaScript and a Bluetooth Smart library and high-level library for the SensorTag. These libraries provide a higher-level method of interacting with SensorTags or other Bluetooth Smart peripheral devices. It avoids the messy gatttool.
A software platform called Node.js allows one to write code in JavaScript and execute it on a computer (the BBB-Industrial in this case). Usually JavaScript runs in a web browser but Node.js allows it to run just like any other program from the Linux command line shell.
The Bluetooth and SensorTag libraries are added to Node.js with the following commands (run apt-get update and apt-get upgrade first:
npm install -g node-gyp npm install noble npm install -g sensortag
There is an example application which waits for the SensorTag to be powered on and it will automatically connect and start printing the temperature information (ambient and infra-red derived temperature values) to the console.
connectAndSetUp
enableIRTemperatureSensor
Object Temp = 19.8 deg. C
Ambient Temp = 25.1 deg. C
Object Temp = 20.4 deg. C
Ambient Temp = 25.1 deg. C
Object Temp = 19.1 deg. C
Ambient Temp = 25.1 deg. C
Object Temp = 19.3 deg. C
Ambient Temp = 25.1 deg. C
Object Temp = 20.2 deg. C
Ambient Temp = 25.1 deg. C
Object Temp = 20.1 deg. C
Ambient Temp = 25.1 deg. C
Object Temp = 16.7 deg. C
Ambient Temp = 25.1 deg. C
Object Temp = 17.4 deg. C
Ambient Temp = 25.1 deg. C
The next step was to show the information on the LED display (see earlier for the description of this) and then send it to the cloud!
The IBM Watson IoT platform was covered in another RoadTest and it would work identically with the BeagleBone Black so it was decided to pick another platform for experimentation, in this case the Amazon Web Services (AWS) IoT platform.
If you already have an Amazon account for online Amazon store purchases then it is easy to enable AWS on the account and it provides access to an extremely rich suite of Infra- and Platform-as-a-Service (IaaS and PaaS) offerings. They are generally charged on a usage basis. There are two ways to manage AWS features; either using the management portal or using an API that they provide. AWS is extremely flexible and powerful but can be daunting sometimes simply because of the rich capabilities and configurability on offer.
Working with AWS IoT entails downloading a software development kit (SDK) to the BBB-Industrial that can be used to connect and transfer information with AWS IoT. There is an AWS IoT guide on the Seeed website that shows how to do this; I used an amalgamation of the information there and the documentation from the AWS site to get going.
A number of different resource types can be created from the AWS IoT portal. Some of the important ones are highlighted in the screenshot here. The end goal will be to get data into the portal as shown highlighted on the right side. To get there, devices or ‘IoT Things’ are defined on the portal to represent the connected devices (the data from the SensorTags as collected up by the BeagleBone Black Industrial in this example). Certificates are needed for secure authentication between the devices and AWS IoT. The certificate resources glue an access policy and the IoT device together. Rules (triggers) are used for causing actions (which will be created later) to occur when thresholds are reached. Without rules the portal merely displays data; with the rules actions can be taken.
Code is needed on the BeagleBone Black to take the information from the SensorTags (using the btsmart application written earlier) and push it to the cloud securely (using HTTPS and certificate based authentication). Some existing JavaScript demo code from the AWS IoT documentation was modified to create an application. To use the code, the easiest way is to create a credentials file containing the device-specific details and the names of the certificate files. My file contained this:
{
"host": "b6j8dm9ntxspao.iot.eu-west-1.amazonaws.com",
"port": 8883,
"clientId": "bbb-1",
"thingName": "bbb-1",
"caCert": "root-CA.crt",
"clientCert": "94c15979c1-certificate.pem.crt",
"privateKey": "94c15979c1-private.pem.key"
}
Then run the code by typing the following (pass the name of the file using the -F parameter):
nodejs myapp.js -f cert -F credent.js -g eu-west-1 -t 2 -T bbb-1 registering bbb-1 connected to AWS IoT Device thing registered. unexpected delta in device mode: bbb-1 got 'accepted' status on: bbb-1 updated state to thing shadow temperatures are 22.3 and 14.1 closing code 0
The Node.js code was modified to read the temperature from the SensorTag periodically, and then call the led_display program to present the information on the LED display, and also to push the data to AWS IoT in the form of two data values called ‘ambient’ and ‘ir’.
The next step was to investigate how rules could be helpful.
There are many offerings under the AWS umbrella; and an interesting one called AWS Lambda provides the ability to execute code in the cloud without needing a dedicated virtual machine running at all times. This means that such code is only charged for when triggers occur. The amount charged depends on how much compute time the code took. It is more advanced that the simplistic ‘if-this-then-that’ controls available in some solutions, because full-blown code can be executed.
The screenshot here shows the key aspects to AWS Lambda; the trigger rule mentioned earlier, the code itself, and the monitored metrics for Lambda which provide an idea of what it might cost by indicating over time how many triggers occurred and how long the code executed for.
The example in the screenshot doesn’t have much practical use but shows that a trigger occurs if the infra-red reported temperature rises above 21 degrees C, and the code sets a data value under that condition. The sky is the limit considering that full code can be executed. Filtering and data analysis could be achieved, data could be pulled from other sources on the Internet, information can be stored in databases (another AWS service) and e-mails can be sent (yet another AWS service). Lambda code can be written in JavaScript or Python.
The BeagleBone Black Industrial board functioned as expected and the icing on the cake is that the same board can be deployed in industrial environments without redesign. There is also nothing stopping engineers from taking the design and rolling their own embedded BeagleBone Black functionality into their circuits.
The Debian Linux image makes it easy for users to have a familiar desktop environment to run applications. The supplied Bluetooth USB adapter worked with no driver installation needed.
The new SensorTag is better than the older one; smaller, more sensors, better processor and a lot more flexibility with the DevPack add-ons and the ability to code for it using free tools. It is a fascinating device, the rich sensors and standardised Bluetooth Smart capability makes it really flexible. There is something for everyone. Non-programmers and kids with an interest in sensing, measurement and science will have fun exploring the possibilities available with the mobile app, and developers can work at the gateway or cloud level, or go in and modify the firmware at the device level too. Web developers will have fun playing with Node.js and the SensorTag library.
The Bluez protocol stack is unfriendly but it was nice to see just how mature Node.js is nowadays and the rich libraries and Amazon Web Services (AWS) IoT connector mean that an IoT gateway can be programmed entirely in JavaScript!
AWS IoT worked as expected but to make full use of it one should invest time examining the entire suite of AWS offerings (and perhaps attend some courses).
Top Comments
Good overview of these products Shabaz, It would be nice to see how each could be purposed in a particular IOT application, although this would again be more work...thanks
Hell of a review.
Well done, very comprehensive.
Mark
Very nice review.
It confirms many of the capabilities I knew about the BB and identified some key features I had missed.
Well done.
DAB