Skip navigation
> RoadTest Reviews

RSL10 Sensor Development Kit - Review


Product Performed to Expectations: 9
Specifications were sufficient to design with: 7
Demo Software was of good quality: 8
Product was easy to use: 9
Support materials were available: 8
The price to performance ratio was good: 10
TotalScore: 51 / 60
  • RoadTest: RSL10 Sensor Development Kit
  • Buy Now
  • Evaluation Type: Development Boards & Tools
  • Was everything in the box required?: Yes
  • Comparable Products/Other parts you considered: I came across BlueTile (STEVAL-BCN002V1B) from ST at Hitex/ARM conference held last week in Warwick, there is also NXP FXTH87 which is a TPMS board but it is still the same concept: a small BLE board powered by a coin cell with a few sensors on board, last is Thunderboard React a very interesting BLE board with many onboard sensors, and a Cortex M4 processor
  • What were the biggest problems encountered?: Digging into BLE characteristics by dissecting the reference codes, which would have been much quicker to integrate this board as part of a project if there was more documentation. The basic RSL10 board is supported by Keil uVision however the RSL10−SENSE−GEVK is not, I tried to port the sample codes and SDK to Keil but stopped as it seemed like a very time consuming task.

  • Detailed Review:


    I am writing this review based on a potential use case for the RSL10−SENSE−GEVK, I have read the other reviews in this road test and learned

    a lot of useful information. Hope this can be helpful as well. While testing the RSL10-SENSE-DB-GEVK I compared it to another board called

    BlueTile from ST microelectronics. I was looking for an ultra-low power BLE and sensors reference design as a starting point instead of designing

    from zero, and these two boards were very close to my requirements.

    I tried to compare a few points that caught my attention about each product in the table below:





    Flash Size256 kB384 kB

    Measured TX current

    (Dev board current at 3V)
    On-board Modules

    BALF-NRG-02D3: ultra-miniature balun and harmonic filter

          - LSM6DSO: iNEMO 6DoF inertial module, ultra-low power and high accuracy

          - LIS2MDL: magnetic sensor, digital output, 50 gauss magnetic field dynamic range, ultra-low power, high performance, 3-axis magnetometer

          - VL53L1X: long range Time-of-Flight sensor based on ST FlightSense technology

          -  MP34DT05TR-A: MEMS audio sensor omnidirectional digital microphone, 64 dB SNR, "-26" dBFS sensitivity, top-port, 122.5 dBSPL AOP

          -  LPS22HH: ultra-compact piezo-resistive absolute pressure sensor, 260-1260 hPa, digital output barometer, full-mold dust resistant, holed LGA package (HLGA)

    HTS221: capacitive digital sensor for relative humidity and temperature

           - 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 pushbuttons

    N24RF64 RFID/NFC tag (an ISO5693 NFC tag (with 64kb EEPROM)) with antenna connector




    I came across the RSL10-SENSE-DB-GEVK board as I was preparing for a project starting in March to develop an IoT application, my first thought was

    “Wonderful!!! it ticks all the boxes”. The project is basically a telematics unit that will monitor and track ISO tanks, these tanks transport liquids all over the

    world whether the product is hazardous or not.

    The rigorous and painstaking regulations (ATEX, HAZLOC,… etc), has forced this industry to stay behind and not keep up with technology, Fleet management

    systems (FMS) were still dependent on having big offices with many people manually phoning up to chase up jobs and track tanks.


    For the mentioned reasons many off-the-shelf IoT devices are generic and not optimised for this industry, which is why a bespoke telematics unit integrated with

    the FMS is needed, fig[1] below shows a prototype of the main device that will collect sensors data (wired and wireless) and connect to the cloud. The modem

    board is based on a design from AVNET with a few modifications, which I will write a blog post about soon.


    Fig[1]: Telematics unit prototype



    How will the BLE sensor board fit in the project

    The main issue here is monitoring temperature as these tanks have got a network of pipes engulfing the bottom part of the cladding,

    hot steam is injected into these pipes to heat products that need to stay within a certain temperature range. Some of these products are

    very sensitive that is why we need to monitor steam temperature to make sure that the tank is heated according to the specs of the product.

    Fig[2] left, shows the location of the main unit (the hub), it will replace an analogue temperature gauge that is already fitted on all the tanks.

    It has a display to show the tank temperature, an NBIOT/GNSS modem and various other modules. Fig[2] right shows a bottom view of the

    tank, the yellow circles show the locations of where temperature needs to be monitored, having wired sensors is not an option for these

    locations which is why BLE seemed a more suitable solution (More compatible with global standards and accepted frequency bands than

    other technologies).

    The challenge in radio and microwaves in this scenario is that all the surroundings are made of steel, especially the bulky steel beams that

    make the frame. The faraday cage effects, and attenuation can be very tricky to deal with.


    The red circle in Fig[2] right, is a suggested location for a mesh style BLE network to work as a repeater for all the nodes connected.


    Fig[2]: left: location of main unit, right: locations of wireless sensor boards


    Fig[3]: Steam pipes


    I tested the RSL10 and BlueTile to get a feel of how the boards will perform while mounted in the yellow marked locations:




    PositionTop leftTop rightBottom rightTop leftTop rightBottom right
    Advertisement discovered by hub100%80%80%100%90%90%
    Successful transmission100%85%70%100%80%80%


    The importance of measuring these points is to match the CFD heating model to real life scenarios in order to predict accurate heating time

    required. Fig[4] below shows a snapshot of a 50% loaded tank being heated.

    Fig[4]: CFD model


    Current measurements


    To verify power consumption mentioned in the datasheet, a power supply was connected along with a series resistor to measure and

    visualize current on an oscilloscope. The schematics of RSL10-SENSE-DB-GEVK show that the P3V0_VEXT is the name of the net

    connected to the external I2C port, which can be used to power the board instead of the coin cell.

    Fig[5]: RSL10 Schematic of different power sources


    Fig[6] below shows the setup after soldering connectors to the I2C port (designator: INTERFACE) to use the VCC and ground pins with

    a power supply, a 100 ohm resistor was attached in series with a differential oscilloscope probe connected across it.

    Fig[6]: Testing Setup



    Figures 7-9 below show current measurements at different stages, Fig[7] shows the peaks while the device is advertising,

    Fig[8] shows the change when the device wakes up from deep sleep, and Fig[9] shows the bursts at every transmission,

    and shows that the device is transmitting every 5 seconds.

    The current can be calculated as follows:






    However, these calculations were based on measurements that suffered from aliasing as it was measured at an insufficient sampling rate,

    for that reason I used a multimeter with edge detection and higher sampling frequency and got results reaching to 8 mA.


    Fig[7]: Advertisement measurement



    Fig[8]: Transition from deep sleep to normal operation



    Fig[9]: Transmission



    Module Battery measurements

    One extra feature in the module is that it can also measure battery voltage, the following struct is taken from “BLE_BASS.c” even though

    this is a useful feature it is not enough of an indicator for battery state of charge (SoC). A fuel gauge could be a very useful addition to the

    board like the MAX17055 or others, as it can measure  current, voltage, temperature and compensates for cell aging, temperature, and

    discharge rate, and provides accurate state of charge (SOC in %) and remaining capacity in milliampere-hours (mAh).


    struct BLE_BASS_Resources


        /** Whether there is any device connected. */

        bool enabled;


        /** Message id assigned by APP_TASK for measuring callback. */

        ke_msg_id_t measure_msg_id;


        /** Delay between voltage measurements in 10x ms. */

        uint16_t measure_sample_rate;


        /** How many samples to average to get final voltage. */

        uint8_t measure_avg;


        /** How many measurements are summed in acc_value. */

        uint8_t total_samples;


        /** Accumulator for voltage measurements. */

        uint32_t acc_value;


        /** Last measured battery level. */

        uint8_t batt_level;


        /** Measured voltage level representing fully charged battery.


         * All voltage levels above this value will be treated as 100%.


        uint16_t vbat_max;


        /** Measured voltage level representing discharged battery.


                      * All voltage levels below this value will be treated as 0%.


        uint16_t vbat_min;


        BLE_BASS_BattLevelInd level_change_ind;







    Crypto Authenication

    Two ICs were not fitted on the board, the schematic in Fig[10] shows the two security and authentication ICs, even if they are not fitted,

    it is great that they were considered in the design, I will try to experiment with it early next year.





    Output of “sense_production_tests”

    Fig[11] shows the output of the another example code in the SDK provided.



    Fig[11]: sense_production_tests Terminal output





    -          The RSL10-SENSE-DB-GEVK packs a lot of useful features (Various sensors, BLE, small footprint, optimised

            use of the PCB area, option to add crypto authentication).

    -          Power consumption was very close to the numbers in the datasheet.

    -          BLE performance even in challenging conditions have showed great results slightly better than other comparable boards.

    -          The developers have provided a good level of examples and tutorials to get started.

    -          More documentation about the mobile app would have been useful.

    -          It was disappointing not being able to debug in Keil and use “ulink plus” debugger as it has great capabilities to get inside

           the MCUs internals and use the System Viewer, Event Recorder, System Analyzer, Designing a custom Component View,

           and analyse detailed power consumption of peripherals.

    -          Using a normal resistor in series to measure current consumption is not an accurate way  monitor and visualise current,

           a better alternative would be using a sense resistor with a fuel gauge.



    Other options to consider

    These are some other BLE dev kits that I am planning to test before making a decision for a final design.


Also Enrolling

Enrollment Closes: Aug 13 
Enrollment Closes: Sep 15 
Enrollment Closes: Sep 8 
Enrollment Closes: Aug 21 
Enrollment Closes: Aug 28 
Enrollment Closes: Aug 25 
Enrollment Closes: Aug 18 
Enrollment Closes: Aug 18 
Enrollment Closes: Aug 17