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?: 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.
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 Size||256 kB||384 kB|
Measured TX current(Dev board current at 3V)
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 pushbuttonsN24RF64 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 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: Telematics unit prototype
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 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 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
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 right, is a suggested location for a mesh style BLE network to work as a repeater for all the nodes connected.
Fig: left: location of main unit, right: locations of wireless sensor boards
Fig: 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:
|Position||Top left||Top right||Bottom right||Top left||Top right||Bottom right|
|Advertisement discovered by hub||100%||80%||80%||100%||90%||90%|
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 below shows a snapshot of a 50% loaded tank being heated.
Fig: CFD model
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: RSL10 Schematic of different power sources
Fig 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: Testing Setup
Figures 7-9 below show current measurements at different stages, Fig shows the peaks while the device is advertising,
Fig shows the change when the device wakes up from deep sleep, and Fig 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: Advertisement measurement
Fig: Transition from deep sleep to normal operation
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).
/** Whether there is any device connected. */
/** Message id assigned by APP_TASK for measuring callback. */
/** Delay between voltage measurements in 10x ms. */
/** How many samples to average to get final voltage. */
/** How many measurements are summed in acc_value. */
/** Accumulator for voltage measurements. */
/** Last measured battery level. */
/** Measured voltage level representing fully charged battery.
* All voltage levels above this value will be treated as 100%.
/** Measured voltage level representing discharged battery.
* All voltage levels below this value will be treated as 0%.
Two ICs were not fitted on the board, the schematic in Fig 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.
Fig shows the output of the another example code in the SDK provided.
Fig: 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.
These are some other BLE dev kits that I am planning to test before making a decision for a final design.