RSL10 Sensor Development Kit - Review

Table of contents

RoadTest: RSL10 Sensor Development Kit - Industrial Sensing

Author: BigG

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?: TI's CC2650STK SimpleLink Bluetooth Smart SensorTag loT Kit would be considered closest as also uses an ARM Cortex M3 processor and would contain a similar mix of sensors. Another compact, multi-sensor BLE development kit would be the Nordic Semiconductor Thingy:52. This has a 32-bit ARM Cortex-M4F CPU.

What were the biggest problems encountered?: I had requested the debug option and then my TC2050 (10-pin needle adaptor) failed to arrive when ordered separately. In terms of running the demo, I had trouble setting up MQTT cloud options using the demo app. Limited documentation available and the cloud receive option did not work.

Detailed Review:

 

Let's find out...

 

 

1.0 Introduction

 

Firstly, I would like to thank Element14 and ON Semiconductor for providing me with the RSL10 Sensor Development kit (RSL10-SENSE-GEVK).

 

I am someone who has never used any of ON Semiconductor's development kits before, so this was an opportunity for me to get to know this kit together with the IDE provided by ON Semiconductor.

 

I'm a firm believer of the view that having great hardware without a decent firmware development environment is not much use to anyone and so a key aim of mine for my road test review was to evaluate the degree of effort it takes to get familiar with the RSL10 SIP application development environment using the demo's provided and then see what you can develop based on the hardware specification and the available firmware libraries.

 

Unfortunately, things haven't quite gone to plan for this road test. I received the non debug version , even though I had requested the debug version (RSL10-SENSE-DB-GEVK). To remedy, I then ordered the TC2050 (10-pin needle adaptor) connector, but for some reason the delivery package never arrived (investigation ongoing at time of writing).

 

So, unfortunately, I am not able to test the different BLE examples that come with the RSL10 BLE CMSIS pack at this stage and can only look at the demo example provided together with the Android (RSL10 Sense and Control) app.

 

I am exploring alternatives, mind you.

 

For example, I noticed that the GNU open source SWD debugger tool I received with the Particle.io Mesh kit has the same pinout and is compatible with the debugger footprint on the SENSE board. It also just so happens that I had some compatible 1.27mm pitch header pins lying around, which I've now soldered onto the board and it all powers up. However, I never had enough time to test if this little hack of mine works (for fear of wrecking the demo).

 

 

2.0 Hardware Review

2.1 RSL10-SiP

 

 

{gallery:autoplay=false} RSL10-SiP

 

The RSL10 SIP is Bluetooth 5.0 certified and fully-certified to worldwide regulatory wireless standards. The radio Rx Sensitivity is -93 dBM and transmitting power is between -17 to 0 dBm.

 

The RSL10 SIP is a complete off-the-sheld single miniature package which includes an integrated antenna, a RSL10 Radio SoC tother with all the passive components required.

 

There's no doubt, the RSL10 footprint is small. Here is a comparison against a Cypress EZ-BLE 4.1 module.

 

 

The big marketing push for this chip is its low power consumption. According to the data sheet, it achieved an EEMBC® ULPMark™ score of 1090 ULPMark CP @ 3 V and 1260 @ 2.1 V.

 

Here are the specs for Deep Sleep Mode, which is given by different battery voltage:

  • Deep Sleep Current Consumption (1.25 V VBAT):
    • Deep Sleep, IO Wake−up: 50 nA
    • Deep Sleep, 8 kB RAM Retention: 300 nA
  • Deep Sleep Current Consumption (3 V VBAT):
    • Deep Sleep, IO Wake−up: 25 nA
    • Deep Sleep, 8 kB RAM Retention: 100 nA

 

And similarly, here is current consumption for wireless communication depending on battery voltage:

  • (1.25 V VBAT):
    • RX: 5.6 mA
    • TX (0 dBm): 8.9 mA
  • Deep Sleep Current Consumption (3 V VBAT):
    • RX: 3.0 mA
    • TX (0 dBm): 4.6 mA

 

During my road test, I did not test to verify any of these claims.

 

So, by way of comparison, here are some stats I extracted from the TI CC2650MODA spec sheet. It achieved an EEMBC CoreMark® Score of 142 (but I've no idea how this compares, to be honest). Then the current consumption figures are as follows:

 

  • Active-Mode RX: 6.2 mA
  • Active-Mode TX at 0 dBm: 6.8 mA
  • Active-Mode TX at +5 dBm: 9.4 mA
  • Active-Mode MCU: 61 µA/MHz
  • Active-Mode MCU: 48.5 CoreMark/mA
  • Active-Mode Sensor Controller: 0.4 mA + 8.2 µA/MHz
  • Standby: 1 µA (RTC Running and RAM/CPU Retention). Otherwise, typical chip power consumption is 30 uA.
  • Shutdown: 100 nA (Wake Up on External Events)

 

Other key technical features include:

  • Supports FOTA (Firmware Over−The−Air) Updates
  • Advanced dual-core architecture. This is made up of:
    • The ARM Cortex-M3 Processor: A 32-bit core for real-time applications, which is clocked at 48MHz. This processor provides general-purpose processing that is used to configure and control all of the components of the RSL10 system including the LPDSP32 DSP, the RF front-end, and the Bluetooth baseband.
    • LPDSP32 Digital Signal Processor (DSP): A 32-bit Dual Harvard DSP core that  supports different audio codecs required for wireless audio communication. If not used for audio applications, this core can be used for other signal processing tasks for advanced developments that need additional processing power.
  • Built-in power management.
  • 1.1 to 3.3 Voltage Supply Range.
    • The power supply is regulated by a DC-DC converter consisting of a low dropout voltage regulator (LDO) and a buck converter (can be used for VBAT > 1.4V). It produces VCC, which is a filtered supply voltage in the range from 1.0 to 1.32 V that is used as the supply for the rest of the system.
  • Memory instances, registers and other components, are all accessible from the ARM Cortex-M3 processor (more detail provided below). Headline numbers are:
    • 384 kB Flash, 76 kB Program Memory, 88 kB Data Memory
  • Configurable analog and digital sensor interfaces (GPIOs, LSADs, I2C, SPI, PCM)
  • A set of interfaces and peripherals to assist in applications that have an audio component
    • An Asynchronous Sample Rate Converter (ASRC)
    • A set of audio sink clock counters (used to measure the timing of samples received from an audio source)
    • Two digital microphone (DMIC) input channels
    • One mono output driver

 

The memory space of the RSL10 SoC is subdivided into four main segments:

  1. The program memory used for storing and/or executing code on the ARM Cortex-M3 processor and/or the LPDSP32. This segment of the RSL10 memory map contains:
    • A 4 KB ROM instance
    • A 384 KB flash instance
    • Three 2 KB flash sectors supporting non-volatile records
    • One 1 KB redundant flash sector supporting configuration information in a non-volatile record from the RSL10 manufacturing test
    • Four 8 KB program RAM instances dedicated to the ARM Cortex-M3 processor
    • Four 10 KB program RAM instances accessible to either the LPDSP32 DSP or the ARM Cortex-M3 processor
  2. The data memory used for storing data and intermediate variables of the ARM Cortex-M3 processor, the LPDSP32, and/or the Bluetooth protocol baseband hardware. This segment of the RSL10 memory map contains:
    • Three 8 KB data RAM instances dedicated to the ARM Cortex-M3 processor
    • Six 8 KB data RAM instances accessible to either the LPDSP32 DSP or the ARM Cortex-M3 processor
    • Two 8 KB baseband data RAM instances acting as exchange memory between the Bluetooth protocol baseband hardware and the ARM Cortex-M3 processor
  3. The peripheral bus accessible memory-mapped control and configuration registers
  4. The private peripheral bus accessible ARM Cortex-M3 processor system registers

 

 

2.2 RSL10 Sensor Development Kit (RSL10-SENSE-GEVK)

 

The RSL10 Sensor Development Kit consists of:

  • A compact PCB in the shape of a dot or circle featuring the RSL10 SIP module, 4 different types of sensors, a digital microphone, a programmable RGB LED, an ISO5693 NFC tag (64kb EEPROM) with antenna connector, a CR2032 coin cell battery holder and three push buttons. There is also a TC2050-IDC footprint for flashing firmware (via a 10-pin needle header) and for the debug version of the board (variant RSL10-SENSE-DB) the 10-pin debug header will also be populated.
  • A CR2032 coin cell battery
  • A flexible NFC (ISO15693) antenna
  • And, a Segger J-Link LITE CortexM debugger (debug variant only)

 

 

The tiny board includes the following 4 sensors:

  • NOA1305 (Ambient light)
  • BHI160 (Integrated low power smart hub, 3-axis accelerometer, 3-axis gyroscope)
  • BMM150 (Low Power, Low Noise 3-axis digital geomagnetic sensor)
  • BME680 (Integrated high-accuracy gas, pressure, humidity and temperature sensor)

 

There is also the N24RF64 RFID/NFC tag which has 64kbit EEPROM. It is worth noting that this uses the ISO/IEC 15693 RFID protocol rather than ISO/IEC 14443.

 

The board's schematic is available here for reference.

 

The hardware, when running the demo firmware, is then also supported by the RSL10 Sense and Control app, which is available for download on either Android or IoS Bluetooth LE compatible phones.

 

 

2.3 Other RSL10 Development Kit Options

 

If you like the RSL10 SiP but feel that the Sensor Development Kit is not for you then there are other options available.

 

 

3.0 Getting Started

 

3.1 Unboxing

 

Unboxing can perhaps best be described as a little uneventful, I'm afraid.

 

The product arrives in a little brown box with a large label describing the contents within - interestingly the only place I spotted the product serial number was on this label.

 

{gallery:autoplay=false} Unboxing

 

Inside the box, the dev kit is accompanied by a “Kit Disclaimer” leaflet. This reads as follows:

 

 

And that is it... of course, having read the legal disclaimer you may be thinking, well the RSL10-SiP is fully certified so why is this still a case of wear-beware if being used “as is” as a wearable... especially within the EU. Who knows.

 

Anyhow, putting that aside, let's see how we can get started with this kit.

 

As there is no printed guidance included with this kit, it is a matter of taking a freestyle approach using freely available resources online.

 

Here is what I've learnt.

 

 

3.2 Getting started with the User Guide (EVBUM2614)

 

As we well know, most users would've purchased the product online and if purchased through a distributor, such as AVNET or Farnell, for example, they would've either been presented with the RSL10-SENSE-GEVK User Guide (document EVBUM2614) as a PDF or they would've had a link to the Onsemi.com product page for the kit. As the User Guide was presented to us as a reference guide for this road test, let me start here.

 

Overall, I found this User Guide document (EVBUM2614) to be quite comprehensive and it is essential reading to getting started.

 

The style of the documentation matches the style of the Onsemi website, namely pack as much information as you can per page and keep to the point. So, for example if you are looking for a document version number, you'll need to check the page footer for the reference.

 

The EVBUM2614 document essentially focuses on the software, leading you all the way from how to download the IDE through to selecting the firmware from the CMSIS pack and then flashing this on to your device.

 

Near the rear of document is a brief description on how to use the app and then it jumps into detail about all the different low power Firmware Modes for each sensor. This is rather confusing as it is badly formatted with indenting of number points and then bullet sub-points.

 

Then the document finishes off with a section on Compiling and Flashing of other firmware examples, which come with the BDK CMSIS pack and also includes details on how to debug using the J-Link debugger tool.

 

So, overall the main issue I had with the document is the lack of a contents section in this document, as there is no clear document structure with clear identifiable or nicely formatted sections and subsections. The document is 23 pages long after all and it is something you reference quite a bit as you work through the getting up to speed process, so having this would be rather useful.

 

Then a minor issue I had, which caused me a little confusion when reading the document for the first time, was that the actual file name of demo firmware is not explicitly stated at the beginning of the SOFTWARE section when it states “The RSL10−SENSE−GEVK boards are, by default, configured with the ultra−low power firmware". It is only when you get to item number 4, under sub-section  “Compiling and Flashing of Ultra Low Power Firmware” that you can infer that the example given here is in fact the installed demo software “Choose the example Custom Service Firmware with Deep Sleep (RSL10-SENSE-GEVK)”.

 

Other than that, I had no problems following the steps and really found the mix of images and instruction to be very helpful in getting me up and running quickly.

 

 

3.3 Getting started using online resources

 

With product and document names kept nice and short, it was easy for me to understand the linkages between say RSL10 and say RSL10-SENSE-GEVK products This helped me when it came to downloading all the required software from IDE through to CMSIS packs as you had to know what you are doing on the Onsemi.com website.

 

Yep, the Onsemi website is a weighty slow database driven juggernaut in need of a revamp.

 

There were a number of times when the website simply timed out when trying to access or log in. But besides the slowness and the legacy design, it works. I had no issues getting to the information I needed, although it does take a good deal of squinting to read all the small font text.

 

So, if I typed "RSL10-SENSE" in the onsemi.com search tool, we get:

 

 

You will notice that we are provided with a number of tabs, each of which contains links to drill down into. The "Documents Tab (10)" is a useful one for reference.

 

I simple started my journey by clicking on the link for the Sensor Development Kit (RSL10-SENSE-GEVK).

 

Here we are presented with a detailed description of the kit, including Features and Applications. At the bottom of this page is the document reference. Here, I noticed that we are missing the application notes (which are provided in the previous documents tab) for how to link to AWS, IBM or Azure cloud platforms etc.

 

 

The Technical Documents section does give you a link to the relevant software and the User Guide is also included here. However, there is no clear section on what to do to get started. For the novice they may get stuck here and not think to look on the RSL10 (System in Package) SIP web page itself. This page is the more comprehensive with a better page structure and it clearly shows what options are available for download. For example, an important download link would be the "RSL10 Documentation Package", which is not found elsewhere.

 

 

3.4 Using the RSL10 Sense and Control App

 

Only the Android app was used during my road test.

 

I downloaded the app onto my Samsung phone (Android OS 5.1) and onto my Lenovo Tab3 7" tablet (Android OS 8 GO version) without any issues. The layout of the app is better suited, in my opinion, to devices like tablets, which have larger screen sizes than a phone, as this provides a better view of the time series charts provided.

 

To be honest, the app should be treated as a nice to have and is NOT essential to get going with the Sensor Development kit but it IS essential if you want to test the demo firmware.

 

The reason for this is primarily down to the lack of easily accessible documentation about the BLE service used within the demo firmware. I had to use a BLE utility app (nRFconnect) to learn that the demo firmware uses a single custom Bluetooth LE GATT Service and two custom characteristics - one for RX and one for TX.

 

Unfortunately, the way the demo firmware is designed, the RSL10-SENSE needs to receive an instruction from the central device (as in the phone or tablet) to tell it which sensor data you want to receive. Without delving into the demo code itself, there is no documentation that I could find that gives me this detail.

 

Anyhow, I tried out the app, which works reasonably well. It certainly has a number short comings mind you.

 

By way of summary, here are my observations:

  • I found that the scan by default is a distraction and is not very energy efficient for the phone or tablet. It is also not necessary to scan by default once you have set up and saved your configuration for the device. I would prefer to have a button to manually trigger a RSL10 device scan instead.
  • I found that if the default scan period times out, and you do not select the retry option, then there is no obvious way to start a scan again.
  • I found that there is no way of deleting a saved configuration.
  • I found that within the "Manage Receive Channel" menu option, the "Receive via cloud" option does not work. I also could not find any information about this feature.
  • I found that I could set up a number of generic MQTT broker configurations, except for PubNub.
  • I discovered that no information is provided on the "topic" used to publish data from the app and this is not something you can configure yourself. I had to work this out myself through trial and error. I subsequently discovered that the Event Payload data structure and topic information is provided only in the "connecting to the IBM cloud" application note and no where else.
  • The MQTT JSON payload appears to be somewhat overloaded with unnecessary data.
  • The export function works and the app was able to save the profile text file on my Google Drive folder. But it is unclear what the JSON structure data actually means and what is its purpose. An example of the file is shown below.

 

{"profiles":[{"name":"LightSensorOnly","boards":[{"name":"HB_BLE_Terminal","fr_name":"HB_BLE_Terminal","address":"60:C0:BF:0D:83:EE","components":[{"name":"ALS-NOA1305","type":"sensor","subtype":"als","cmd_id":"9","id":"4","iconId":2131558412}]}]}]}

 

I have captured my app user experience via this video footage.

 

 

 

4.0 Developing Firmware

 

Following the instructions given in the User Guide, I had no problems getting the Eclipse based IDE installed on my 64-bit laptop, which uses Windows 7 OS. I also was able to install all the necessary CMSIS packs without issue.

 

 

I also had no problem selecting the firmware example noted in the User Guide and was able to copy this across to my workspace. I was then able to build the firmware as described without issue.

 

 

That is as far as I could take it, application wise.

 

Following further searching, I found that the RSL10 Documentation Package contains a number of PDF documents about how to develop your firmware and then flash this onto your RSL10 device. I think you will have to spend a fair bit of time reading all this low level documentation, such as the 407 page "RSL10 Firmware Reference" document, for example.

 

Other than this documentation, I did come across a "getting started" video on the website: https://www.onsemi.com/support/design-resources/video/1171564

 

So what next. Well, usually I find that when getting familiar with a new package you will want to explore the different examples. If you have an application project in mind then you will try and find examples that are relevant to your project. Well, this is where the ONSemiconductor IDE fails to deliver, when compared to some other IDE's.

 

If you look at the above list of examples. There is no description given about the example. You have to download it first. Unfortunately, this appears to be a weakness of all Eclipse based IDE's. However, others at least give you a one or two line text description to give some guidance. Here you get nothing.

 

So, if you open up an example, as say the one shown above, you will get a readme file.

 

 

These are certainly well worth reading to find the nuggets... for example:

 

NOTES

 

Sometimes the firmware in RSL10 cannot be successfully re-flashed, due to the application going into Sleep Mode or resetting continuously (either by design or due to programming error). To circumvent this scenario, a software recovery mode using DIO12 can be implemented with the following steps:

  1. Connect DIO12 to ground by pressing the PB2 push button.
  2. Press the RESET button (this restarts the application, which will pause at the start of its initialization routine).
  3. Re-flash RSL10. After successful re-flashing, disconnect DIO12 from ground, and press the RESET button so that the application will work properly.

 

Then it is simply a case of learn by doing.

 

On this front, at the time of writing this road test report, I unfortunately was not able to do much due to the inability to flash the device. As mentioned in the introduction, I had the idea of using the OpenOCD SWD Particle.io debugger, without much thought as to how. Unfortunately, Zadeg and me are not best of friends at the moment, having had endless hassles getting the USB drivers sorted out on my Windows 7 OS laptop. And that was just the start. So I have left it at that.

 

 

5.0 Conclusions

 

The Sensor Development kit is certainly small and nicely designed. I really like the fact that the board opened up the I2C bus to allow the developer to interface with other I2C based sensors. I think this board will be very useful for field testing in industrial and wearable applications to quickly get a wide range of sensor data. The incorporation of the ISO15693 NFC antenna also opens up a range of unique applications. It is a pity that I could not test the N24RF64 device on the board, other than confirm that a NXP PN7150 controller could read this tag.

 

The demo firmware works pretty well with the RSL10 Sense and Control app, although I did find that the app could certainly do with a few more updates (last updated on 28 October 2018) to address its many shortcomings.

 

The Eclipse-base IDE makes good use of the CMSIS pack implementation. Something that I had not see before. It works well enough. When it comes to learning functionality, all I could see was a couple of PDF documents that give you a reference guide. I did not come across any online tutorials on the ONsemiconductor website other than a gettings started video.

 

So, at face value, I think the RSL10 is ON the money, but I'm not sure about the development effort detail to make a final judgement.

Anonymous
  • By all the boards, I meant to say the SOLAR-SENSE board, the SENSE-DB board, and all the other boards that on-semiconductor has made using the rsl10. Can you elaborate a bit on the last para? Or share some resources that could help me dig deeper?

  •   wrote:

     

    I don't know if you guys noticed, but all the different boards that use this small device have different I2C,UART,SPI pins. I found this weird since generally the pins for these interfaces are fixed and then I found out that any GPIO can be used as one of these interfaces in the RSL10. This is quite amazing if you ask me. Unfortunately this is not mentioned in the datasheet of the rsl10 sip for some reason, maybe because this is available only in other packages like QFN48. Anyone who can shed more light on this?

     

    Maybe elaborate what you mean by "all the different boards".

     

    I know some dev boards use the SiP module (includes antenna) while others are using the SoC (has a separate antenna on the board).

     

    Also, if you look at the RSL10 Bluetooth 5 Radio System-on-Chip (SoC) datasheet, there is some good diagrams showing the system architecture that help show what's going on.

     

    What you will find is that while you have a good deal of flexibility on which pins you can select for I2C, SPI, UART etc. you are actually constrained by the function resource. So, for any application you are limited to only 2 x SPI "resources/blocks", or 1 x I2C "resource/block" or 1 x UART "resource/block" etc. This would be handled within the IDE with the pin configuration module for the chip.

     

    Hope that makes sense.

  • I don't know if you guys noticed, but all the different boards that use this small device have different I2C,UART,SPI pins. I found this weird since generally the pins for these interfaces are fixed and then I found out that any GPIO can be used as one of these interfaces in the RSL10. This is quite amazing if you ask me. Unfortunately this is not mentioned in the datasheet of the rsl10 sip for some reason, maybe because this is available only in other packages like QFN48. Anyone who can shed more light on this?

  • Well that's a good start. Unfortunately, we seldom get everything we want laid out on a plate, so my only suggestion is that you cut the BLE code from another example and paste it in the example with the correct data speed for the accelerometer.

     

    There is a little more to it though as with BLE you need to define the GATT service and the characteristic. Usually with this sort of application you would define the characteristic to have a NOTIFY property etc. So this does require a bit of upfront learning and experimentation. If you have any specific questions on the technical detail just post and we can see if we can help.

  • Dear BigG,

    I have uploaded other example and found accelerometer data in terminal with better update speed than a mobile app. but that code only give data to terminal not in app.

  • Have you looked at any of the other examples available?

  • Hello BigG,

    Firstly, I tried example with name "custom service firmware"  without deep sleep, but I am not receiving any data on the mobile app, maybe due to such function might not available in that example code. I am interested to see data on mobile app with maximum update speed.

    Secondly, Deep-sleep mode given here means device continuously in deep sleep mode and giving data after a particular interval or it goes into deep sleep mode when no any activity it has or jumps into Deep-sleep in between broadcast interval?

    Third,  I am not able to locate a particular parameter line in source code by which we can change sensor data update speed. Please help

  • Reason for slow data transfer is explained in the getting started document.

     

    To increase update speed the device cannot be put into deep sleep mode. Within the SDK there is the another example with same name "custom service firmware" but without deep sleep. You will need to upload that one and see if that improves things - if no improvement, then you will need to change some of the parameters within the code.

  • Hello all,

    I have uploaded example "custome service firmware with deep sleep" but getting sensor data ( acceleration and gyro etc.) slow in mobile app that may be due to slow aquisition or bluetooth transfer rate ,don't know exactly.

    I want to increase updating speed of data on app for vibration analysis.

    Can anyone guide me how to minimize that delay without much changes?

    Thanking you in advance

  • Thanks for the comment Steve.

     

    I think I was naively optimistic about my abilities to use the Particle debugger as I'm still learning the ropes. Thankfully some good documentation on Particle.io to guide me. Only concern I have is that the RSL10 may require some unique feature in script that I'm not aware of. Segger did list RSL10 as a specific version of ARM Cortex M3.

     

    Yes, you are correct. I too could not find a datasheet for the RSL10-SENSE-GECK board. For the benefit of others, I have cut n pasted what I could find for the RSL10 SiP and summarised for the sensors.