RoadTest: RSL10 Sensor Development Kit - Industrial Sensing
Author: stevesmythe
Creation date:
Evaluation Type: Development Boards & Tools
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?: The nearest comparison that I know of is the CC2650STK SimpleLink Bluetooth Smart SensorTag loT Kit . This is also low-power, wearable and provides similar sensors together with Android/iOS apps. It is lower cost than the RSL10, but the RSL10 has an RFID chip and realtime sound processing capability.There is also the Nordic Thingy:52, which is somewhat larger than the RSL10 but with similar features.
What were the biggest problems encountered?: The Android app seems to have some significant bugs.
Detailed Review:
The subject of this RoadTest is the ON Semiconductor RSL10 Sensor Development Kit. There was some initial confusion with this RoadTest - the initial batch of kits sent to element14 did not include the debugger so some people only received the RSL10 device but some (like me) also received the associated Segger J-Link debugger board. There is another RoadTest where the participants were sent the debugger version. Consequently, I RoadTested the version without debugger first, to show what you could do with the RSL10 device as shipped from the factory. I then RoadTested the device with the debugger to show what benefits you would gain if you bought the debugger version.
| {gallery} Unboxing the RSL10 |
|---|
 |
 |
 |
 |
[Note: Egg shown for scale. It is not included in the kit!]
The RSL10 Sensor Development Kit (RSL10-SENSE-GEVK) consists of:
ON Semiconductor NOA1305 (Ambient light sensor) with 16-bit ADC and I2C interface
Bosch BHI160 (Integrated low power smart hub with 3-axis accelerometer and 3-axis gyroscope)
Bosch BMM150 (Low power, low noise 3-axis digital geomagnetic sensor)
Bosch BME680 (Integrated high-accuracy gas, pressure, humidity and temperature sensor)
INMP522 (Ultra-low noise digital Microphone)
APTF1616 (Programmable RGB LED)
N24RF64 (64kB NFC EEPROM)
Three programmable push-buttons
The debug version of the kit (RSL10-SENSE-DB-GEVK) also includes:
If you only have the non-debug version, you will not be able to change the default firmware as the debug header is not populated. You would either need to solder an SMD 10 pin debug header or buy a TC2050 10-pin needle adaptor and connect it to the PC via a Segger J-Link board if you wanted to put different firmware on the board. The default firmware is designed to work with the companion RSL10 Sense and Control app (Android or iOS) to demonstrate the low-power use of the board with most of the onboard sensors.
You could buy the (non-debug version of) the kit and just use it "as is" with your mobile device. It would suit various applications including wearables, horticulture and sport. Most of this review covers the non-debug version so that people can understand what is possible and what the limitations are.
The debug version of the kit is aimed at developers looking to use the RSL10 SIP module in their low-power designs. Towards the end of the review I will cover the other things that you can do with the RSL10 board if you have the debugger.
This is not intended to be exhaustive, but I have RoadTested a fair few IoT devices over the past eighteen months and each of them has had its own "niche". The table below sets out some of the different devices that I have tested, and their associated "use cases".
| Symbisa | Particle Xenon | AVNET Azure Sphere MT360 | HARTING Mica | ON Semi RSL10 | |
|---|---|---|---|---|---|
| Sensors included | Yes Light, humidity, temperature, pressure, accelerometer, GPS | No | Yes (Light, accelerometer, gyro, temperature, pressure) | No (Bosch CISS sensor recommended) | Yes (Light, accelerometer, gyro, temperature, humidity, pressure, gas, sound) |
Intermediate transmission protocol? | n/a | Thread mesh | n/a | n/a | BLE |
| Connection to cloud | Built-in cellular modem (2G) | WiFi (Particle Argon) or Cellular (Particle Boron) | WiFi | MQTT via hardwired Ethernet port | MQTT via mobile device and 3G/4G/WiFi |
| Key differentiator | Works anywhere, includes GPS | Uses Thread mesh to overcome poor WiFi coverage. Low-power applications | Security – each field device is tied to an Azure account | Industrial – designed and certified for harsh conditions | Small size, low weight, low-power |
| "Use cases" | Suits periodic location and sensor monitoring e.g. asset tracking | Low power applications | General purpose | Condition monitoring | Wearables, horticulture, sports |
| Disadvantages | Cost per message payload can make it expensive. No "real-time" data. | Large deployments can be expensive due to Particle's cost model. | Can be complex to set up | Expensive | Needs BLE device as intermediary |
| Cloud platform | Private cloud only – no public cloud options | Private (Particle Cloud) or public cloud | Public cloud only | Public cloud only | Public cloud only |
The ON Semiconductor website has a web page devoted to the RSL10 kit. One of the links on the "Documentation" section takes you to the main "go to" document for this kit (the RSL10-SENSE-GEVK User Guide (EVBUM2614)). After a brief hardware description, this takes you through six pages describing the process of downloading the debugging environment (which would be confusing for people with the non-debug version). I did think "Oh no. Not another IDE to install and learn", but at least the ON Semi IDE is based on Eclipse, upon which a lot of IDEs are based. The User Guide then describes the RSL10 Sense and Control app before moving on to describe how to install and debug new firmware.
There is further documentation available on the RSL10 SIP web page.
Generally, I would say that the documentation is quite comprehensive (but slightly hard to follow) except for the RSL10 Sense and Control app which is notably lacking (or at least I couldn't find it).
The instructions in the “User Guide” do not quite match the current terminology on the On Semiconductor website. Where the User Guide refers to the RSL10 SDK, the website refers to RSL10 Software Package. It is not very clear that you have to install two "CMSIS packs” (one called ONSemiconductor.RSL10.3.0.534.pack and one called ONSEMICONDUCTOR.BDK.1.10.2.PACK). The Cortex Microcontroller Software Interface Standard ("CMSIS") is a vendor-independent hardware abstraction layer for microcontrollers that are based on Arm Cortex processors. For the purposes of this kit, the CMSIS packs are necessary in order to get the demo example code and dependencies.
While looking for documentation, I came across an interesting alternative to On Semiconductor's software - Atmosphere. I haven''t pursued this avenue yet, but I will investigate further.
If you are deploying a number of these devices in the field, I guess it would be useful to have a quick way of identifying which is which and perhaps automating the discovery process. As delivered, the RSL10 emulates an ISO5693 NFC tag. I guess that there is a way to configure the chip but, if so, I didn't find it. However, I could read the tag easily.
In essence, the RSL10 board connects via Bluetooth to a device running the RSL10 Sense and Control app. This is available for Android or iOS. I tested both versions (on my Motorola G6 phone and Apple iPad respectively).
You use the app to pick which sensor data you want to monitor (or send to the cloud). You can save this as a “configuration” and give it a name.
You can choose, in the app, whether to view sensor data on the Android or iOS device, or send it using MQTT to the cloud.
The screenshot below shows an example of what you see if you choose to view sensor data on the device. Note that the air quality sensor is not available in the default low-power firmware that is installed when you receive the board.
You can switch between "tile view" and "graph view" for each sensor on an individual basis. In the screen below, I have changed the Temperature display to "graph view".
The app allows you to configure an MQTT broker of your choice. There are existing configurations but I think these are useful to keep as examples, so I set up my own connection to CloudMQTT, which has a free plan that is ideal for testing and low-volume applications.
You can also choose whether to use a secure connection, which is essential for production environments. For my testing, I just used an unencrypted channel as there was no data of any significance being sent.
| {gallery} Connecting to the cloud |
|---|
 |
 |
 |
I decided to send analyse and graph my data with Node-Red. This involved the following steps (on Windows 10):
This can take a while. Sorry for the lack of a screenshot but I already had NPM installed.
If you stream your data to the cloud, you will need to know how the MQTT payload is structured. After experimenting with MQTTlens and Node-Red, it seems that each sensor that you select in the app sends a separate MQTT message. The MQTT payload varies according to which sensor(s) is/are involved but each of the sensors sends a “cmd_id” message to identify the sensor and a “cmdVal” message containing the data. These are sent as strings.
In the screenshot above, I had selected the "ALS-NOA1305" (light level) and "Environmental" sensors in the app and you can see that they have cmd_ids of "9" and "E" respectively. If you know the cmd_id, then you can make sense of the data.
| cmd_id | Sensor | cmdVal | Meaning |
|---|---|---|---|
| "9" | ALS-NOA1305 (Light) | String (e.g. "51") | 51 Lux |
| "E" | BME680 (Environmental) (only updated every five minutes in low-power mode) | String array (e.g. "206,59,0,97") | Temperature 20.6C Humidity 59% rh Air quality 0 (not available in low-power mode) Atmospheric pressure 9.7kPA |
| "A" | BHI160 (Accelerometer) (updated every three seconds in low-power mode) | String array (e.g. "0,-10,-27") | 0, -10, -27 m/sec/sec in x,y,z planes respectively |
| "G" | BHI160 (Gyrometer) (updated every three seconds in low-power mode) | String array (e.g. "21,0,980") | 21,0,980 deg/sec in x,y,z planes respectively |
| "M" | BMM (Magnetometer) (updated every three seconds in low-power mode) | String array (e.g. "-197,-328,82") | -197,-328,82 micro Tesla in x,y,z planes respectively |
The Sense and Control app comes in two versions – one for iOS and one for Android. I shall comment first on the iOS app.
I found that, to be able to save a configuration with a (meaningful) name, you have to create it first with the “Enable broadcast” option turned off. If you try and create a configuration “Broadcast” enabled, it saves the configuration but gives it a name such as NewProfile, NewProfile_1 etc. You can delete unwanted configurations by pressing on the little wastepaper icon and releasing. Then a dialogue pops up (see below). Whilst you can save configurations (profiles) in the Android and iOS versions of the app, it seems that the “delete configuration” option in the Android version does not work.
Note that, in its default configuration the RSL10 is operating in low power mode (which means you need to have the RSL10 within a couple of feet of your iOS device). Also, several of the icons on the app do not apply to the RSL10 as supplied because they are intended for measuring or controlling additional sensors and actuators.
I set up some flows on Node-Red to process the MQTT data. The first thing I discovered is that everything is published under one topic - and one that is not particularly easy to discover. It turned out to be (in my case "_565AF326-8421-4B66-AAB2-CB8A3EB1704E"). I found that subscribing to all topics (#) got me all the data, which made things easier.
| {gallery} Node-Red |
|---|
 |
 |
 |
 |
 |
In the default low-power mode, the environmental sensor only updates every five minutes (see Dashboard graphs below).
I found that, although the app appears to keep running when my iOS screensaver (autolock) kicked in (i.e. it seemed to be streaming data), this stopped the actual transmission of the data to cloudMQTT. Turning off autolock fixed it (although, of course, my iPad battery drained fairly quickly).
Although it is called Sense and Control, as far as the (as supplied) RSL10 device is concerned, there is nothing to control. I suppose you could control the RGB LED, but that is not very exciting. In any case, I don’t know how you would discover what topic to publish to since the documentation doesn’t seem to tell you that anywhere.
Each RSL10 has a unique "mac_id": (e.g. "60:C0:BF:28:7C:88"), so if you have more than one RSL10, you can filter by that too.
Annoyingly, the MQTT output of the device is different depending on whether you use the Android app or the iOS app. Here is the JSON payload (two messages) from the Android app with just the Environmental sensor selected:
{
"token":"OSGatewayActivity",
"event":"/updates/",
"mac_id":"60:C0:BF:28:7C:88",
"cmd_id":"6",
"cmdVal":"27.86",
"Temperature_6":"27.86",
"Source_60_C0_BF_28_7C_88_Temperature":"27.86"
}
and
{
"token":"OSGatewayActivity",
"event":"/updates/",
"mac_id":"60:C0:BF:28:7C:88",
"cmd_id":"E",
"cmdVal":"279,37,0,98",
"Environmental Sensor_E":"279,37,0,98",
"Source_60_C0_BF_28_7C_88_Environmental Sensor":"279,37,0,98"
}
And here is the output (one message) from the iOS app with just the Environmental sensor selected:
{
"cmd_id":"E",
"mac_id":"60:C0:BF:28:7C:88",
"cmdVal":"234,62,0,98",
"event":"/updates/",
"Environmental Sensor_E":"234,62,0,98",
"cmd":"","token":"OSGatewayActivity",
"Source_60_C0_BF_28_7C_88Environmental Sensor":"234,62,0,98"
}
This is quite annoying because it means that you would have to have different code in Node-Red (or whatever you are using to analyse the data stream) depending on whether you were using the Android app or the iOS app.
I only discovered this when I found that my Node-Red dashboard didn’t work properly when I switched apps.
The Segger J-Link is a well-regarded debugger and the J-Link LITE for Cortex-M is a vendor-specific version for the RSL10 board. It is only licenced for use on the RSL10 board but I did wonder whether it would work on other boards. I tested it on an NXP FRDM-KW41Z board (Cortex M7) and it worked just fine but I leave it up to the reader to decide whether to make use of that knowledge.
The main RSL10 circuit board has a row of 2.54mm pitch pin headers (unpopulated). As well as power, these allow access to the I2C bus and one GPIO pin. This would enable you to add different sensors or actuators to your design.
To program the RSL10, you need to download and install the ON Semiconductor IDE and the RSL10 SDK from here.
The instructions in the “Getting Started Guide” do not quite match the current terminology on the On Semiconductor website. Where the Getting Started Guide refers to the RSL10 SDK, the website refers to RSL10 Software Package. It is not very clear that you have to install two CMSIS “packs” (one called ONSemiconductor.RSL10.3.0.534.pack and one called ONSEMICONDUCTOR.BDK.1.10.2.PACK). Having done that, I got a warning message about unresolved dependencies. Trying to resolve this by right clicking on the yellow message and choosing “Install required packs” didn’t resolve the problem (whatever it was). Nevertheless, everything still seemed to work OK.
Once the IDE and SDK was installed, it was now possible to tweak the existing firmware. Some of the settings are available through a configuration file (CMSIS Configuration file).
However, I decided to install the “normal power” version of the demo app. This allows you to use the Air Quality Sensor and provides environmental sensor readings every three seconds, rather than every five minutes. I also found that you don’t have to keep the RSL10 right next to the iOS device. Compared with the low-power version, this was a welcome relief – it provided a reliable connection and frequent readings. Compare the smoothness of the readings with the one obtained with the default firmware above.
I think that this would make a better firmware to supply to people who buy the kit without the debugger.
The SDK comes with around half a dozen examples that you can use and modify.They are written in C and not very heavily commented, so it takes a lot of effort to work out what is going on in the code.
The RSL10 is a fantastic little device which is perfect for developing wearables and other applications. However, without the debugger, you'll be stuck with the low-power version of the sensor demo application which is a bit disappointing as the main sensors only update every five minutes.
The documentation is, on the whole, poor.
In addition to not being able to find any documentation about the RSL10 Sense and Control app, neither could I find the source code for the app. In the absence of any documentation, it is hard to see how you could control any additional devices without remaining tethered to the debugger.
It appears that the Android app is the poor cousin of the iOS app and some of its functionality does not work fully:
1. You can’t delete profiles
2. Environmental sensor data is not updated unless you reboot the RSL10 board
3. Publishing data to the cloud repeatedly fails due to network connectivity being lost
As a result, I gave up on using the Android app.
Neither version of the app supports the microphone or the RFID chip. One of the SDK examples supports the microphone and the EEPROM, so you can, at least test them out in "tethered mode".
I plan to investigate connecting additional devices a bit more and see if I can work out how to access them via the app. I will update this RoadTest report after I have done so.
In summary, great little device, let down by poor or missing documentation.
Top Comments
I found this to be a useful roadtest. I liked your use of the Node-Red Dashboard for visuals and great spot finding those differences between the IOS and Android apps. Yes, I would totally agree with you…
Yes, I agree that if you already have the debugger version you wouldn't want several Segger J-Links kicking around. However, if you then buy lots of RSL10 boards without the debugger, you'll still have…
Hi Steve,
What a great review. I saw this roadtest when it came out but wasn't sure if I could show it off and therefore didn't apply, however your roadtest report explains very well what this product does…