|Product Performed to Expectations:||10|
|Specifications were sufficient to design with:||9|
|Demo Software was of good quality:||10|
|Product was easy to use:||9|
|Support materials were available:||9|
|The price to performance ratio was good:||7|
|TotalScore:||54 / 60|
I’ve been excited to explore this Bluetooth LE (BLE) sensor board for quite a while!
Here’s a 4-minute overview and video demo of the board:
The reason for being interested in this board, is that it contains an extraordinarily small compute and wireless system-in-package (SIP) device that is easy-to-use. It seems like a game-changer because anyone can create tiny wearable projects, smart wireless headphones, watches and toys with this device. Its footprint is three times smaller than a micro SD card, and that includes a built-in antenna.
The 8 x 6 x 1.5mm package internally contains a chip called the , along with antenna, inductors, capacitors and crystals so that apart from a few pull-up resistors, nothing extra is needed for operation.
The contains that RSL10 SIP device pre-soldered onto a main board. The board is the size of a large coin, and is populated with some sensors too. The underside of the board has a battery clip for a 3V CR2032 coin cell. A separate programmer/debugger board is supplied, and a cable with 10-way 1.27mm connectors for interfacing it to the main board. There’s also a small Near Field Communication (NFC) antenna that plugs in directly to the board.
The on-board sensors include a light sensor, temperature, humidity, pressure, air quality (it measures the amount of volatile organic compounds in the air – i.e. types of chemical fumes, rotting fish and garbage cans) an inertial measurement unit (IMU) and a compact digital-output microphone.
That’s a lot to explore! I may explore the sensors in a later blog post, but this review is going to focus on the core part, the tiny RSL10 SIP device, to get to the point of using it in custom designs.
The name is quite long, so in this review it will be more informally just called the RSL10 kit or RSL10 board for short. Incidentally there are other evaluation kits for the RSL10 SIP and the RSL10 available too, one of them , but the RSL10-SENSE-DB-GEVK kit is the one I had for review. There is a slightly similar-named kit too, but that doesn’t include the programming header and separate programmer board, and for that you are expected to bring your own debugger and cable if you wish to put your own code on the device. Some of the larger RSL10 SIP and RSL10 evaluation boards have an on-board debugger and are lower cost, so there’s plenty of choice. The kit being reviewed here can be operated with a coin cell and is compact, so it would be handy when evaluating the RSL10 SIP for use in products where size and power consumption are important.
BLE operates at 2.4 GHz, and, as its name implies, is very useful for low-power communication! Devices using BLE can sometimes operate for a year or longer using a coin cell.
As far as the software interface to BLE is concerned, information can be read or written via handles known as characteristics. The underlying BLE software stack will perform the magic needed to get that information across using the radio interface. The communication is not generally symmetrical; each BLE device instead plays a ‘role’. The two main roles (there are actually four that are possible) are known as BLE Central Device, and BLE Peripheral Device. The peripheral device can advertise periodically to everyone that it exists. The advertisement may contain sufficient information for the recipient, but in many use-cases more information is needed, so the recipient of the advertisement will try to connect. The initiator of the connection plays the Central Device role, and in effect it is a master to the slave peripheral.
The board is quite feature-packed. Plenty to keep one busy.
Once you insert the battery, the device starts advertising, ready to be connected to an app. Unfortunately the required app seemed to be temporarily removed from the Android app store : ( The app is important, because it shows you one way to transform the RSL10 board into an IoT wireless sensor node that communicates to the cloud using your mobile phone as the gateway. That’s a massively important type of workflow simply because it has so many uses. In my case, it was of less concern since I wished to develop my own apps.
Since there are many RSL10 boards, there could be a desire to modify code intended for one board to another. These are the pin names that are used on this board; this information comes in handy when working with the code (see further below).
|Feature||I/O Pin Name||Notes|
|Push Button 1||15||Input|
|Push Button 2||12||Input|
|RGB LED: Red||2||Output|
|RGB LED: Green||1||Output|
|RGB LED: Blue||0||Output|
|I/O Interface Pin 3||3||-|
|I2C SDA and I/O Interface Pin 4||4||I2C Master|
|I2C SCL and I/O Interface Pin 3||5||I2C Master|
|IMU (BHI160) Interrupt||9||Input|
I have to repeat it again, I love the size of the RSL10. I get the feeling it could become my favourite substitute for other microcontroller chips for a while : ) Even if the BLE wireless capability were not needed for a project, it could still be a nice-to-have feature that could be used to eliminate other wired interfaces for configuration purposes, remote logging, and over-the-air software updates. The wireless capability incidentally doesn’t need to be BLE. The RSL10 exposes registers for direct access to the RF hardware, bypassing any BLE stack. So, you can implement proprietary protocols that could work around any BLE restrictions too. On Semi supply example code that does just that, for low-latency audio streaming.
The diagram here shows what is inside the RL10.
There are a total of 16 input/output pins exposed on the RSL10 SIP module, and they can be used as general purpose digital input/output or for any of the other purposes shown in the diagrams, including analog input. There is a lot of flexibility; any pin can be configured for any purpose, there doesn’t seem to be any specific pin multiplexing restriction.
The RSL10 board was run using some example code (see further below to see what examples I ran with the RSL10), powered from an external power supply (I removed the on-board coin cell, and wired the supply to the 0.1” header on the board). I used a 2.8V power supply, and monitored the current with a Keithley DMM6500 meter.
The chart below shows the current consumption at power-up, for two minutes. For the first minute, the RSL10 board sent out BLE advertisements (this was what the programmed code was supposed to do) with current spikes of around 2-3 mA. I believe the subsequent spikes are related to the on-chip buck regulator (the RSL10 uses a low core voltage) but this is just a guess.
The software programmed into the RSL10 stops advertising after 60 seconds, until a button is pressed. The chart below shows what happens when the button is pressed, followed by a connection from a BLE Central Device, and characteristics written and read each second:
A zoomed-in view of a few seconds during the time the characteristics were being written and read is shown below. Each spike presumably corresponds to radio transmit or receive operations:
Another benefit of the RSL10 is the documentation. While some of the website stuff had issues (broken links), the actual PDF manuals for the hardware and software are well written. The library code for BLE and the on-chip peripherals such as the ADC and serial interfaces is documented in a single PDF – that’s nice and easy to navigate. Apart from the on-chip DSP, all the other features appeared to be well documented. The DSP uses third party tools, and requires discussion with On Semi to be able to use it.
From the RSL10 SIP product page On Semi supply a freely downloadable integrated development environment (IDE) and libraries for use with the device. In brief, everything I tested worked well, and there were no issues using the development environment. The IDE runs on Windows (I didn’t see a download for other operating systems) but in theory it would be feasible to use the GNU GCC compiler for ARM too.
I followed the RSL10 Eval Board user guide (PDF) as well as the RSL10 Getting Started guide (PDF) – they are written quite well. I did have some website issues - there didn’t seem to be any way to download a particular software pack. I eventually found it – if you too have the same issue, visit this other Bluetooth dev kit page and download the software pack from there).
The development environment is based on Eclipse, so it will be familiar to many embedded engineers. The key thing when using it with the RSL10 is that along with the usual Code and Debug perspectives that are seen in Eclipse, there is also a perspective called CMSIS Pack Manager. Click on that, and you can install additional packs of software. Various software packs are available from ARM and from On Semi, and the packs provide APIs, drivers and example source code into the development environment.
After the packs were added, the rich palettes of libraries, APIs and example code were visible. There are real-time operating systems (including FreeRTOS and RTX and RTX5), drivers for serial interfaces and all the sensors on the board, and the BLE stack too of course, and perhaps close to 100 example projects. Help is also fully integrated. Nearly all the APIs and drivers have clickable help. I found the best place to start was using an example app, and building from there. Note that because there are many RSL10 boards, you may need to change some I/O pin definitions if you choose an example app intended for a different board, but this is straightforward.
I followed the guide to import the blinky app. The example was intended for a different RSL10 board, so I changed the LED and button pin number definition in the app.h file for the code to function with my board, using the table listed above in the Board Features section. All of the sensors communicate using I2C.
Once the code was compiled it was a quick matter to upload the code onto the board and it worked. Great! This was a small step, but smooth so far, so I continued with exploring some of the other examples.
Next, I took a look at an Eddystone Beacon code example called solarsens_env_beacon_v3. It was designed for a different board with different sensors, so this was a nice opportunity to explore how to use the libraries to add a sensor into the code. This was fairly straightforward – the trick is to click on the .rteconfig file in the project view, and then you’ll see a clickable list of things you can add to the project. I used that to switch off the non-existent sensors and add the sensor which I intended to use.
With some tweaks to the source code, it was fairly easy to get an Eddystone beacon functioning, advertising temperature to a mobile phone running an app that can scan for beacon data. I used an Android phone and Blue Gecko from Silicon Labs.
If you wish to try it, the tweaked source code bundle is attached to this review.
With this bit of confidence, I decided to examine a BLE Peripheral type of app. It is the most likely type of app I would want to create often with the RSL10.
Looking at the example apps, I noticed one called sense_ics_firmware_sleep which I believe is similar or identical to the default app that was on the device (since by now I’d deliberately overwritten the firmware that had arrived on the board, I could not confirm). In any case, this is a BLE example that is intended for use with a mobile app that I could not find on the Android App Store at the time of writing, at least for my mobile phone. In any case, I decided to reverse-engineer it a little bit to figure out how it worked, so that I could modify it in future to support my custom sensors, and to work with my own apps rather than the missing Android app.
It took a while to figure it out, but the protocol design and the implementation is quite interesting. The protocol relies on forward-slash separated values in a string. Once that is received by the RSL10 device, it will decode the string to pull out a transaction identifier (e.g. 0 for the first transaction), a subsystem identifier (e.g. AL for the Ambient Light sensor) and then the actual request (e.g. L for enabling the light sensor). So, a complete instruction would be:
There are two forward-slashes at the end because this instruction does not include any value to write.
Once the command has been executed, the remote device can send a request to read a BLE characteristic, and the response will contain the transaction identifier. An example from the AL subsystem would be:
which would indicate a light level of 155.00 lux.
Once the protocol running on top of BLE was figured out, the next step was to communicate with it, to build a usable solution. The question was, how to do this? In the past, I’ve used several methods, such as using other BLE-enabled microcontrollers, or a Raspberry Pi. This time around, I figured it may be worth trying something new (to me). For about a year, the Web Bluetooth API has been evolving. This is an interesting API that runs in a web browser (Google Chrome supports it, other browsers do not support it currently). By using the API, web pages can interact with the BLE chip inside your PC. No application needs to be installed on the PC!
The demo of it is shown in the earlier video.
The RSL10 is an extremely interesting device. It is tiny, and this could enable wearables projects. The fully integrated system-in-package is great for reduced time-to-market too.
Since the SIP simplifies BLE implementation in products immensely, this could be handy to encourage BLE use in products that ordinarily may not have it. Combined with a mobile phone app, or Web Bluetooth API-enabled Chrome browser app, it is very convenient for configuring and monitoring products without requiring physical connectors. The BLE feature may pay for itself once the cost saving from not requiring connectors is factored in. The RSL10-SIP costs about $6.50 in quantities of 1000 or $10 in single quantity. That seems pricey, but laying out a Cortex-M3 chip with BLE radio, plus the required crystal, capacitors, inductors and antenna could approach this cost.
It proved to be straightforward to work with the RSL10, and I was able to successfully work with the RSL10 demo code, and understand it sufficiently to adapt the examples to run on the particular RSL10 board I had, and to build my own browser-based application to communicate with the RSL10.
I hope the information in this review was useful. Thanks for reading!