The Thingy:53 is a bleeding edge IoT prototyping platform featuring the flagship nRF5340 dual-core Wireless SoC. It also contains several sensors and a rechargeable Li-Po battery, making it an excellent tool to rapidly prototype an application that can be deployed in the field. To learn more about Thingy:53, please visit the product webpage and watch the webinar, which is available on demand.
In this blog post, we will set up the Thingy:53 as a sensor hub that takes measurements from the onboard BME688 environmental sensor, BH1749 color and light sensor, and the on-chip SAADC to read out the Li-Po battery voltage. The data will also be available to read over GATT by a connected Bluetooth LE central device.
We will go through all the necessary steps to get this prototype up and running in the section below, but if you wish to skip directly to the finished firmware to test it for yourself, it is linked at the end of this blog post. If you at any point are unsure about the Zephyr devicetree, application configuration, or macro-usage, then we would highly recommend going through the nRF Connect SDK Fundamentals course in the Nordic Developer Academy before proceeding. It is an excellent course for gaining an understanding of how the nRF Connect SDK works behind the scenes.
Table of Contents
Setting up the project
Having installed the nRF Connect SDK v2.1.0 using the Toolchain Manager, we start by using the 'Create a new application' option in Visual Studio Code (VS Code) to create a freestanding application based on the peripheral LBS sample. Once the project has been created we need to add a build configuration for the thingy53_nrf5340_cpuapp_ns target, which means we are building the application to run on the application CPU in the non-secure environment. This might sound scary, but it is in fact making our firmware more secure as it will incorporate TF-M into the build and create a secured domain that is separate from the non-secure one. Steps for adding a build configuration can be found in the nRF Connect for VS Code documentation.
The main reason for choosing the peripheral LBS sample as our place to start is that it is already compatible with Thingy:53. So it already has the necessary DFU parts implemented and some of the Bluetooth LE functionality, which lets us focus on the data collection and transmission.
We need our application to feature DFU right from the beginning because Thingy:53 does not have an onboard debugger. Therefore we need to implement a means of updating the application on the Thingy:53. For convenience, we could, of course, have used a standalone debug-probe, or another DK's debugger, to perform the programming of the Thingy:53, but that would require additional hardware. It would have robbed us of the opportunity to see how easy it is to add DFU to our application.
After building the project, the DFU-ready application can be found in <project_path>/build/zephyr/dfu_application.zip. If you already have an existing application that you would like to add DFU to, you could follow this guide.
Trimming down to a minimal project
To highlight the necessary steps for the sensor hub implementation, we will start by trimming away the peripheral LBS-specific functionality from our application. In this case, we do not need any of the LBS specific code or the button functionality - we can keep the generic Bluetooth parts and the LEDs. Removing all the LBS service specific code leaves us with the following, minimal main.c which will be used as baseline for our project:
We will also need to make some changes to the prj.conf - we'll keep the general Bluetooth parts, and remove the LBS specific parts. In addition, we have renamed the device to 'T53_sensor_hub' for convenience and easy discoverability by a BLE central device during scanning. The prj.conf which should look like this afterwards:
Lastly, you can delete the Kconfig and prj_minimal.conf files from the sample directory as well.
Setting up the BH1749 color and light sensor
We may now start to add the data collection functionality to our project. We will use the BH1749 to collect sensor readings of the ambient light in the environment, specifically the red/green/blue values. To make things easy for ourselves, we will here make use of the SENSOR module, which works with the variety of sensors already implemented in Zephyr. We start by adding the following configurations to our prj.conf:
The specific function of each of these configurations can be checked by either going to the kconfig reference search, or by hovering over the specific configuration in the prj.conf opened in your VS Code editor, as shown below.
Now we need to add the source code that brings the sensor functionality into our project. In main() we will retrieve the sensor from the devicetree and check for its readiness. In addition we will create a separate function sample_and_update_all_sensor_values for sampling all the sensors, which gets called from the main loop. In that function the sensor data is sent to sensor_hub_update_* functions which handle the BLE data transfer over GATT. We will go over that functionality in the sections below.
It is also required to make a slight modification to the connected/disconnected bluetooth callbacks and in the main loop, so that the sensor sampling is only done if there is a BLE central device connected to the Thingy:53 (allowing for energy savings), and when the LEDs are off. This is because the BH1749 is right next to the RGB LED on the Thingy:53 board, and that would influence the readings if we were to sample the sensor when the LED is on.
Setting up the BME688 environmental sensor
Now we can also add the BME688 sensor, to gather the pressure, humidity and temperature data. We will also here make use of the SENSOR module, as shown in the previous step. Since we already have some of the sensor modules kconfigs added, we will only need to add the following to our prj.conf:
At the time of writing, the BME688 sensor that we are gointhg to be using is not declared in the thingy53_nrf5340_common.dts file, which can be found in <sdk_path>\<sdk_version>\zephyr\boards\arm\thingy53_nrf5340. This is the devicetree file that contains the hardware definition for the board (e.g. buttons, LEDs, sensors). It would also be possible to add the BME688 sensor declaration into the overlay files in <project_path>/boards, but doing it on the SDK file will make the change available for any project targeting Thingy:53.
We will have to make a small amendment to include the missing sensor. As we see on the file, the i2c1 instance is already used for both BH1749 and the BMM150, but there is no mention of the BME688 that we are interested in using. Looking at the Thingy:53 hardware files, downloadable from here, tells us that these three sensors are on the same I2C bus, and so we can just add it to the declaration as so:
Similarly to the previous section, we need to add the source code that brings the sensor functionality into our project. In main() we will retrieve the sensor from the devicetree and check for its readiness. In addition we will add the BME688 sampling to a the function sample_and_update_all_sensor_values.
Setting up ADC to read Li-Po battery voltage
The final peripheral functionality to be added to our project is the ADC, which allows us to read the on-kit Li-Po battery voltage battery. Since the battery voltage exceeds the nRF5340 supply voltage, it will be read through an on-board voltage divider with two resistors that is enabled via a GPIO. This can be found on page 4 of the boards schematics.
This voltage divider is also defined in the device tree, on the earlier mentioned thingy53_nrf5340_common.dts file. The properties in the vbatt node tell us that ADC channel 2 is being used to sample the voltage through a 1M5+180k ohm resistor ladder, and also that P0.16 is used to enable the ladder.
