Table of contents

RoadTest: RSL10 Sensor Development Kit - Industrial Sensing

Author: waleedelmughrabi

Creation date: 3 Dec 2019

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.

Detailed Review:

Introduction

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:

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:

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:

V=IxR

300mV=Ix100

I=3mA

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.

Fig[10]

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

Summary

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