Introducing the Environmental Sensor Development KitFollow article
How do you feel about this article? Help us to provide better content for you.
Thank you! Your feedback has been received.
There was a problem submitting your feedback, please try again later.
What do you think of this article?
Modular sensor solution provides highly flexible hardware platform for Air Quality project.
The DesignSpark Environmental Sensor Development Kit (ESDK) is an open source hardware platform that is designed to make it as easy as possible to prototype custom sensor solutions. It has been created to support the engineer activism Air Quality project, but could easily be put to use in other sensing projects — and for that matter, potentially a great many more IoT and wider applications that have a need for a small Linux computer with integrated touchscreen and GPS etc.
Let’s start by taking a look at the requirements which guided development of the ESDK hardware.
The key requirements were that the ESDK must be:
- Powerful, but not power hungry
- Modular and easily extensible
- Relatively low cost (no exotic parts)
- Able to read numerous attached sensors
- Able to support multiple outputs:
- Local display
- Local data logging
- Remote data logging
- Able to support fixed and mobile use
- Hacker/maker friendly
There was much initial discussion regarding the first point and while microcontroller platforms were considered, it was decided to build the ESDK on the Raspberry Pi platform. This would mean that there would be a full Linux system at our disposal, with plentiful local storage, no shortage of options when it came to programming languages and frameworks, plus numerous other benefits.
It’s true that a deeply embedded microcontroller based solution would mean that we could also operate on battery power for extended periods, or perhaps even solar. However, it would also severely limit us in terms of how it was programmed and to an extent what peripherals we could use, while potentially making it less accessible as it may require more specialist development skills.
The other points above will be covered in the rest of this article.
The ESDK System
It was important that the ESDK had:
- A modular system with a consistent form factor
- A single connector type and pinout for interconnection
- Interfacing that would support a daisy-chained bus topology
With the above in mind two initial module sizes were settled upon: a single width unit (1U) and a double width unit (2U), both of which the same length. All the first set of sensor modules would use one of these two sizes and if need be in future we may have e.g. triple width (3U) modules.
It was decided to use a two row 2.54mm pitch box header for interconnection, with this providing a suitably low cost and sufficiently robust solution, which also lends itself to easy prototyping. The male connector is set back from the PCB edge, so as to help protect its pins, while the female connector overhangs. Every sensor module is fitted with one of each, fitted to opposite edges and with all the pins bussed through, in order to support daisy chaining.
I2C was the obvious bus protocol, since this supports addressing, would run the distances required across a number of interconnected modules and, importantly, it should be easy enough to source the different types of sensors required that use this for interfacing. In addition to I2C, the connector also carries two plain GPIO pins, which may be used for simpler sensors, such as PIR.
Next let’s take a look at the system components.
The Main board plugs onto the Raspberry Pi and since it is a little larger than the form factor prescribed in the HAT specification, it doesn’t quite qualify as a HAT. However, this is not really a concern and features have been incorporated from this, such as integrating an ID EEPROM.
Most notably the board is equipped with a small, bright IPS display, complete with capacitive touch screen. In addition to which there are four hardware buttons for convenience, e.g. triggering a clean shutdown or some other action which would benefit from not being touch screen driven.
Power is supplied via a USB-C connector on the Main board, which is used to power the circuits on the board, the attached sensor chain and the connected Raspberry Pi.
The Main board has its own 3v3 regulator, so as to avoid overloading the Raspberry Pi 3v3 rail, plus polyfuses and TVS diode protection for both the 3v3 and 5v power supplied to to the sensor chain. There is a real-time clock (RTC) chip for the Raspberry Pi, plus provision for a coin cell to maintain this when the main power supply is removed.
Finally, there is a GPS receiver to enable the position to be accurately reported along with sensor readings with mobile use.
The Raspberry Pi and sensor modules will typically be fitted to mini DIN rail, with the Main board sitting at an elevated height. Hence some mechanism of transitioning between the Main and sensor boards was required. This is where the PicoBlade-to-ESDK adapter (PEA) board comes in, which as the name suggests, is connected to the Main board via a cable and PicoBlade connectors.
The PEA board also includes two LEDs to indicate the power status at the start of the sensor chain, one for the 3v3 rail and one for 5v.
The first of the sensor modules is the THV board, which provides measurement of temperature, humidity and total volatile organic compounds (TVOC), with the latter being a key metric for indoor air quality. In addition to being a generally useful measurement, temperature is also needed as an input to the TVOC index algorithm, hence it made sense to create a single module which combined the temperature+humidity sensor with a TVOC sensor.
The temperature+humidity sensor is the SHT31 from Sensirion and this can be seen above on the left, with PCB laminate routed out around this so as to reduce the possibility of thermal conduction. The TVOC sensor is on the right and this is a Sensirion SGP40.
The CO2 sensor board is based on the Sensirion SCD41 and since this has a reasonably high peak current draw, the module has its own dedicated 3v3 regulator.
The last of the initial set of modules is PM2 and this is based on the Sensirion SPS30, which uses laser scattering to measure particulate matter, with readings for 1.0, 2.5, 4.0 and 10 microns.
Software support for the ESDK hardware is provided via a Python module named DesignSpark.ESDK, which is modelled loosely after the DesignSpark.Pmod module that was created to support a selection of popular Pmods. The module makes it easy to access the underlying hardware capabilities and is used as the basis of the Air Quality device firmware. This will be covered in more detail via a future article, once it progress past the alpha development stage.
As noted earlier, the ESDK is designed to be easy to extend and in a future article we’ll take a look at designing a custom sensor module, then adding software support for this. Detailed technical information for both the ESDK hardware and DesignSpark.ESDK Python module will also be made available, as part of a reference documentation collection that is being created.