Hardware Design

The non-limited list of tasks of the hardware designers consists of the:

development of a prototype using a processor and sensor boards;
development of a custom battery powered PCB;
development of the mBed device drivers;
integration of the mBed firmware in mBed OS;
communication with the software development team using the Agile SCRUM Software Development Methodology.

Prototype

In an early stage, a fast proof-of-concept must be build using a prototype design. This design can be build using existing processor boards, breakout sensor boards and other pre-made hardware. This design will serve as a platform to test and develop firmware. In the next stage, a custom PCB with all the components must be build.

Our pcb, (designed by Gain Gary and Bonne Robbe) is made in the recommended software CircuitMaker. Afther a long time of searching how the whole program works, started I (Bonne Robbe) to design a schematic and board just to test the temperature/humidity sensor (si7013Atum20). This because the sensor is too small to test it on a breadboard.

The schematic:

the board:

Testing temperature and humidity sensor

(The testing of the SI7013 sensor was done by Gary)

For the measurement of the temperature and humidity the SI7013 sensor was used, this becaus of its low power consumption, usage of I²C communication, long term stability and the availability of loads of documentation. In fact, the manufacturer recommends the use of this sensor type for indoor weather stations. The datasheet can be found here.

Connection

On the image below the connection of the sensor is given, this setup is used for typical applications. In the datasheet the usage of 10K pull-up resistors is recommended for the I²C communication. However using these values resulted in the impossibility of having I²C communication because the clock wasn't a nice square wave. To solve this problem usage of 3.3K resistors is recommended.

Library

we use the SILABS_RHT library, which is compatible with different sensor types from the same manufacturer. It controls the complete I²C communication, the conversion of the measured values to mili-percent / mili-°C and contains a wide range of methods that can be used to test the sensor. The complete documentation for the library can be found here.

While testing the sensor we have determined that the address of our physical sensor and the one defined in the library weren't the same, so it was changed in the library.

/** I2C device address for Si7013 */
#define SI7013_ADDR      0x80     //original address in datasheet: 0x82

Code used

complete code of the main.cpp used to test the sensor.

#include "mbed.h"
#include "SILABS_RHT.h"
 
I2C sensorI2C(D14, D15); //D14=SDA, D15=SCL (PC_1=SDA, PC_0=SCL on PCB)
silabs::SILABS_RHT rhtSensor(&sensorI2C);
Serial device(USBTX, USBRX);
 
volatile bool busChecked = false;
 
void respondedCallback( void ) {
    busChecked = true;
}

int main() {
    printf("Starting rhtSensor measurement\r\n");
    int retval = rhtSensor.check_availability(si7013, respondedCallback);
    printf("Available? %s\r\n", (!retval ? "SUCCESS" : "FAIL"));
    

while (true) {
    retval = rhtSensor.measure(si7013, respondedCallback);
    printf("Measure? %s\r\n", (!retval ? "SUCCESS" : "FAIL"));
    
 
    if(rhtSensor.get_active()) {
        printf("Temperature: %d.%03d degC\r\n", rhtSensor.get_temperature()/1000, rhtSensor.get_temperature()%1000);
        printf("Humidity: %d.%03d %\r\n", rhtSensor.get_humidity()/1000, rhtSensor.get_humidity()%1000);
    } else {
        printf("No sensor found\r\n");
    }
    wait_ms(5000);
    } 
}

Code operation

Check if the sensor is active and responding.

int main() {
    printf("Starting rhtSensor measurement\r\n");
    int retval = rhtSensor.check_availability(si7013, respondedCallback);
    printf("Available? %s\r\n", (!retval ? "SUCCESS" : "FAIL"));

Perform measurement

while (true) {
    retval = rhtSensor.measure(si7013, respondedCallback);
    printf("Measure? %s\r\n", (!retval ? "SUCCESS" : "FAIL"));

As already mensioned previously the sensor measured values are converted in the library to mili-percent / mili-°C

//Code from library for humidity
/* Convert value to milli-percent */
			_rhData = (((_rhData) * 15625L) >> 13) - 6000;

//Code from library for temperature
/* Convert to milli-degC */
			_tData = (((_tData) * 21965L) >> 13) - 46850;

get_active gets the current state of the sensor, active or inactive. However the check_availability method must be called upon first. After this we call upon the get_humidity/ get_temperature methods to get the last measured relative humidity/ temperature data. Because of the measured value conversion in the library the stored values need to be converted again to % / °C.

if(rhtSensor.get_active()) {
      printf("Temperature: %d.%03d degC\r\n", 
      rhtSensor.get_temperature()/1000, rhtSensor.get_temperature()%1000);
      printf("Humidity: %d.%03d %\r\n", 
      rhtSensor.get_humidity()/1000, rhtSensor.get_humidity()%1000);
   } else {
      printf("No sensor found\r\n");
   }

Custom PCB

In the next stage, a custom PCB must be build using only the essential components. The PCB must also make use of battery power to operate, and must be optimized to run as long as possible. PCB's can be ordered online using a service like http://www.allpcb.com/ or an alternative service.

The PCB can be designed using the design software of your preference. We recommend CircuitMaker, but Eagle is also a good option.

The schematic

For the design of the custom PCB I (Lennert Bogaert) used the recommend software, CircuitMaker. The board is divided into 5 categories.

CPU
Power supply
Temperature and humidity sensor
PIR sensor (movement detection)
LoRaWAN module

Block diagram:

We used the STM32L476RGT6 as CPU. This is the same CPU as the NUCLEO-L476RG and is chosen because our board had to be low power. We had to take another CPU because the previous didn't have enough RAM. This second one has the same pin layout as the first and is therefore compatible.

CPU schematic:

R1, R2: voltage divider -> measure battery voltage
R3, R4: I2C pull-up resistors (10k)
D1, D2, D3: debugging LED's
X1: crystal (32kHz)
C1, C2: capacitors for crystal (4,3pF)
I1: programming header
P1: debugging header
Y1: crystal (8MHz)
C3, C4: capacitors for crystal (20pF)
C5, C6: stabilization capacitors (100nF)

Power supply schematic:

This header (J3) can be chosen to power the board via the LDO or directly from the batteries.

V.R.1: low-dropout regulator (LDO)
BT1: battery holder

Temperature and humidity sensor schematic:

This header (J4) can be chosen to power the sensor via a CPU pin or directly from the LDO. The temperature and humidity sensor uses I2C to connect to the CPU.

PIR sensor schematic:

This header (J2) can be chosen to power the sensor via a CPU pin or directly from the LDO.

LoRaWAN module schematic:

The LoRaWAN uses SPI to connect to the CPU.

The board

Afther the works I (Robbe) did on the temp/hum sensor and the schematic was ready. Started Gary and I the designing of the pcb itself.

The board with all layers:

Crystal for usage without internal clock 32KHz (X1)
Test pins above to deactivate the voltage regulator for testing
cut-outs around the temp/hum sensor to avoid wrong measurements due to extra heat from components nearby
Placed the voltage regulator far away from the temp/hum sensor to avoid extra heating.
Resistors/capacitors all 0805
Power TEMP/HUMI and Power PIR1 are able to swith by a resistor pad so If they are not needed or don’t work its possible to switch them off
Antenna trace width is 1mm thick. Smaller traces would result in a bad impedance matching (50 ohms). What would make the antenna inefficient, or even unable to work at all.
We also have an extra crystal on it to stabilize usb connection (Y1,8MHz).

Board lay-out as seen from the bottom layer:

Testpins for programming µC are those in the left corner containing NRST,DIO1,TCK and TMS pin.
Testpins above connected with the uart of the µC to read from it. Via those pins it is able to check the data from the temp/hum sensor or PIR.
Putted them togheter with the reset button on the bottom layer to test/reset it when its in his case.

mBed device drivers

The mBed device drivers should be developed according to the Object Oriented Paradigm (OOP), for instance in C++. As a good software developer you should create abstractions for all hardware. For each device that will be interfaced by the mBed, the driver software should be based on at least one class. A recommended approach is to divide the software in at least three sections: the interface (e.g. GPSmodule.h), the implementation (e.g. GPSmodule.cpp) and application (e.g. GPStest.cpp) (see image below).

Integration of the mBed firmware in mBed OS

ARM mBed OS is an open source embedded operating system designed specifically for the "things" in the Internet of Things (see image below). It includes all the features you need to develop a connected product based on an ARM Cortex-M microcontroller, including security, connectivity, an RTOS (Real-Time Operating System) and drivers for sensors and I/O devices.

More info about mBed OS can be found at https://os.mbed.com/.