Raspberry Pi 2/3 Weather Sensor Shield - Review

I would like to thank Element14 and TE for selecting me for this roadtest. The Raspberry Pi 2/3 Weather Sensor Shield (DPP904R000) piqued my interest for a couple of reasons. First is my ongoing interest in evaluating sensor suits. Because more companies are producing their own sensors its becoming increasingly more complex to select a sensor. Adding these sensors to my comparison chart would allow for a better understanding of the offering from TE. As an ongoing project a platform, for easy comparison of the data, has not yet been established. The second reason for wanting to review the Weather Sensor Shield is a weather balloon project that is due to be completed by the time the weather is more favourable.

First impressions - Unboxing (Lack Thereof)
The board arrived in a padded envelope and an anti-static bag. While I often prefer minimal packaging this was very much bare bones. Being accustomed to receiving even single components in large boxes this was very unusual. Without even a small box for protection, keeping the sensors safe is that much more complicated. Another point to note was the lack of any documentation. While most products do not ship with lengthy guides they do at least ship with a getting started guide or link to an online document. In this case there was nothing included to get a new user started.

The packaging the board arrived in, a shipping box from Element14, which contained the padded envelope in which was the anti-static bag 

On the positive side the board is well marked. Each of the four sensors are clearly labeled. The connector orientation is also well marked to ensure correct mounting. Overall it is a simple board with ample space around each sensor to prevent thermal and mechanical interference between sensors.

Each sensor is clearly labeled as is pin #1 on the connector

Test Outline
I had outlined a series of tests for this kit to determine how user friendly it is as well as how it performs against its outlined specifications. Unfortunately, due to some issues that will explained, most of these tests could not be completed before writing this review.

The test procedure I had outlined for DPP904R000 contained approximately 5 individual tests. These ranged from the usual to those definitely not intended for this kit. The tests outlined in the proposal where as such:

1. How easy would it be to use this with another platform 
2. Can we get the calibration data from the PROMs easily and reliably 
3. Does the data from various sensors match up (they each have a temperature sensor) 
4. Can these sensors survive the outdoor environment, in a sheltered but not sealed enclosure 
5. Can the needed calculations be carried out on a microcontroller without overloading the system 
6. What is the true power consumption of these sensors 
7. What is the theoretical maximum altitude that can be measured with the pressure sensor (taking temperature as well as air pressure into account) 

Due to mainly documentation complications only the first two test have been conducted so far. As more progress is made further updates will be added.

Platform Compatibility
Physical Compatibility
The first test was to see if the DPP904R000 is compatible with with other platforms that have a Raspberry Pi connector. The board selected to test this kit with was the MangOH Red from Sierra Wireless.

MangOH Red from Sierra Wireless

This board has a 26 pin instead of a 40 pin, Raspberry Pi connector. Even with this, only two of the six pins used are not supported. These two pins are apparently used by the Raspberry Pi to read a shields ROM chip for identification purposes. Since the ROM is not used with the MangOH Red, it would not be a concern.

The DPP904R000 mounted on the MangOH Red, only 26 of 40 pins make contact

Communication Compatibility
Using terminal commands to test the basic compatibility between the boards was the next step before moving to any of the other tests. This would also be the first time the documentation was consulted in detail. Any product that survives needs good documentation or support. This is where the Raspberry Pi Weather Sensor Shield started to have issues.

i2cdetect shows 0x76 is reserved by the system and that only the TSD305 at 0x1E is detected

 
The first sensor tested was the HUT21D humidity sensor. This sensors has an easy to follow communication structure. Shortly after reading the datasheet humidity data was being reported back. This quick victory gave a positive feeling towards the Raspberry Pi Weather Sensor Shield, sadly this victory was short lived.

The HTU21D humidity sensor with thermal isolation 

The second sensor to be used with the MangOH Red was the TSYS01. The address listed for the TSYS01 temperature sensor is 0x76 and 0x77 depending on whether the CSB is pulled high or low. Since the MangOH Red has a sensor (BMP280) at 0x76 the TSYS01 sensor could not be reached at this address. However, because the TSYS01 can change its I2C address, there was hope. Looking at the schematics it was revealed that TE did not design this option into their board. While cost could have been a factor ($0.03 for the 0𝛀) there are ways around this (Freescale now NXP, is great at giving options without increasing cost). Unfortunately because of this, the TSYS01 is unusable with the MangOH Red. It would later be discovered that in fact the address could not be changed without causing another conflict.

The TSYS01 temperature sensor with multiple layers of thermal isolation 

The next sensor to be checked for compatibility was the TSD305. While even bad hardware can be made to work with great documentation, no hardware can work with no documentation. This was in essence the case with the TSD305. 

The TSD305 contactless temperature sensor 

 
The datasheet lists the address as 0x00. Interestingly Raspbian (which this board is specifically made for) and other Linux distributions, reserve this address and so its not accessible to the userspace. This left this sensor unusable until I was lead to TE’s GitHub repository. Initially I was shown python drivers, while I was working in the terminal and C this was still more promising than the documentation. Looking through the files it became clear the correct address for the TSD305 is 0x1E. Due to receiving this information rather late, no further testing was conducted with this sensor.

Datasheet displaying 0x00 as the sensor address 

The last sensor to be tested was the MS5637 pressure sensor. Following the sequence of steps need to complete a measurement it is unclear what addresses need to be written/read to/from. At issue are the large number of address available write too. Whether reading pressure or temperature data there are 6 different registers that can be written too, each with a different OSR value. Compounding the matter, is the lack of explanation regarding OSR or how it affects the measurements. Choosing one of these at random the data still needs to be read from the ADC. With no mention of one or two ADCs, at first glance is unclear what address each data point should be read from. Through more careful reading it can be inferred that there is in fact only one ADC.

The MS5637 pressure sensor

Once the sequence of events were clarified an attempting to connect with the MS567 was made. The address for the MS5637 is listed as 0x76. As previously noted, this address is already used by the TSYS01. Besides this address not being incompatible with the MangOH Red, its not compatable with the TSYS01 on the same board (DPP904R000 ). With the unclear sequence of steps along with the an incorrect device address, this device’s documentation is the worst of the four sensors on the DPP904R000 .

Datasheet displaying 0x76 as the sensors address 

As mentioned with the TSD305, the driver files do contain usable information. Very disappointingly TE carried over their mistake from the documentation to the repository. While the hex value is listed as 0x77, which is correct, no one checked the binary value copied over to notice it is in fact 0x76.

The define statement for MS5637_ADDR lists the address as 0x77 and 0b1110110 which are not the same value

 
This leads to another issue. Why would TE select address for different sensors to be the same. Regarding the ability to change address the TSYS01 documentation states “Therefore, two TSYS01 can be interfaced in the same I2C bus”. How can this be so, if the application requires a pressure sensor the second address would be consumed by the MS5637. With 124 address available TE selected two separate sensors that could easily be used in the same application to have overlapping addresses.

Easy of Use with Higher Level Code
The sequence of steps needed to conduct a measurement for these sensors are not necessarily very efficient. The HUT21D requires the system to wait for the measurement to complete before receiving a response. During this time there are two options available. The first option is to wait while the HUT21D holds the SCL line low. This prevents anyone else from using the I2C bus. It may also hold up the system depending how the code is implemented. The second option is to poll the HUT21D waiting for an ACK. While this allows others to use the I2C bus it does require the system to poll the sensor. The other three sensors only provide polling as an option to retrieve data. A better and more efficient option would be to implement an interrupt pin. While this could still require polling in some systems, the time needed to do so would be reduced from milliseconds clock cycles.

This may not be an problem in some systems and even more so in the systems that appear to be targeted by TE. However in low power or time critical systems the extra cycles can reduce battery life or the ability to process data ontime. This would lead to a contradiction in the claim to low power yet the need to use more power to execute and retrieve a measurement.

Documentation and GitHub Repository
As previously noted the documentation for these sensors is lacking, some more than others. There is both missing information as well as clearly incorrect information. The biggest issue found working through these datasheets was the with the TSD305. In this case the sensor address was incorrectly listed as 0x00 instead of 0x1E. Other less critical omissions are lack of explanations or clarifications on how the sensors behave. The most noticeable of these is the OSR values in the MS5637 datasheet. Also unclear in this datasheet is the number of ADCs, the relevance is whether or not there are multiple addresses to read from or not. This though can be clarified with a more careful reading of the datasheet.

One thing that that is very helpful and allows a user to achieve the stated accuracy quickly are the worked examples. The datasheets for each sensor has a fully worked example from capturing the ADC value to computing the actual measured value. Even the simplest of sensors, the HUT21D, has simulated input data that is then converted. This gives a user real values to run through the code to check the calculations with.

Possibly the biggest omission in the documentation is the mention of a GitHub repository for these sensors. This repository contains generic C and python drivers. Also in the repository are demos and drivers for Arduino. The complication here appears to be two different product pages for the same product. The page linked from Google as well as some of the vendors does not mention GitHub or IBM BlueMIX. However, another page found does, under “Related Materials”, mention both of these resources. Also at issue is, while these are mentioned in the datasheet for the DPP904R000, it is done so at the bottom where most companies put their copyright and revision information. This means its in a place a decent number of users will not look.

This lack of exposure puts TE’s sensors at a disadvantage over other sensors. While other companies are showing off the drivers for their sensors, TE is not effectively letting users know theirs exist.

Next Steps
Moving forward I am looking to complete my testing with this board. Once completed the data should be available in real time to compare with other sensors in my lab environment. Beyond this is the hope to be able to integrate the sensors (excluding the TSYS01) in the weather balloon project. This would help to determine how reliable they are in such an application as well as how altitude affects them. Included in this is a test to see what is the maximum altitude that the MS5637 can reliably report.

Conclusion
From the limited amount of testing possible with the DPP904R000 it can be said this board is mostly compatible with other platforms. At issue is TE’s decision to not take advantage of the ability to change the I2C addresses where possible. This not only limits its compatibility with the MangOH Red but, potentially with other boards that may be used in conjunction with it. Indeed it is true that this would not help on this board, that is because TE has decided to allocate overlapping addresses to different sensors. Why TE would select address that potentially conflict with their own sensors is baffling at least and self harmful at worst.

The documentation also for the most part does allow for a developer to complete his task. The problem here is the extra time needed to do so due to missing or incorrect information. With a few fixes this could easily and quickly be resolved. Along the same lines is to fix the product pages. Not just the page of the DPP904R000 but of each sensor to include a link to the GitHub and IBM BlueMIX pages.

Once these obstacles are resolved the DPP904R000 would be a great product to work with for most applications. Not included in this category would be time critical and potentially power sensitive applications. The stated accuracy, factory calibration make for a reliable sensor for indoor environmental sensing applications.


Original post on Element14 can be found here

MangOH Red Launch and Legato Framework

Sierra Wireless has just launched their newest offering in the IoT space. The MangOH Red is a smaller and more compact board than it's older brother the MangOH Green. Aimed at a being used in an end product rather than the development, the board resembles the footprint of the Raspberry Pi. With onboard Bluetooth and WiFi, the MangOH Red is ready to be used in any IoT application. Still standard are the CF3 modules with their on chip cellular connectivity and GLONASS and GPS positioning capabilities. The CF3 module cellular options include 3G, 4G LTE and LTE-m1/NB-IoT modules.

MangOH Hardware

The MangOH Red has a notably different hardware setup from the MangOH Green. Being more compact, the MangOH Red has one CF3 slot and one IoT expansion card slot. Because the MangOH Red has onboard bluetooth and WiFi there is an onboard antenna as well as  u.fl connector to allow for an external antenna to be attached for these services. The other previously supported antenna connections (cellular, Glonass and diversity) are all still provided. No longer provided onboard is ethernet, RS323 and the arduino shield connector. For the users who may miss these, they are still available via the IoT expansion cards. The debugging interface has been made simple with a micro USB connector.

New to the MangOH Red are pressure, light and temperature sensors. These new sensors along with the IMU gives the board spacial awareness right out of the box. Also new the the MangOH Red is a Raspberry Pi Hat connector. This allows for the more complex and capable boards designed for use with the Raspberry Pi to be used with the MangOH Red.  Built in battery charging and monitoring circuitry allow for a rechargeable battery to be added. With this setup Sierra Wireless has made a product that a true IoT board that is ready to be deployed anywhere monitoring is needed.

Unboxing and Setup

The MangOH Red comes in a neatly packed box with everything you need to get started. One big improvement from the MangOH Green is the inclusion of a universally compatible sim card. With 100MB of data this is enough to get anyone started with the demos and basic applications. Setting up the MangOH Red is quick and easy The WP module is slipped into the module holder and the cover snapped closed. After connecting the cellular antenna all that is left to do is connect the USB cables. These are used to provide power and access to the console. While it is possible to provide power from either USB cable, access to both the console and CF3 module via SSH is useful.

The documentation for the MangOH Red has been revised and updated from the MangOH Green. This new revision has produced a clearer and more concise set of documents. The initial setup time, from out of the box to getting the demos running has been reduced with the aid of better step by step instructions. The “MangOH Red Setup Guide” is especially helpful in getting the system setup and performing its first set of data logging to the cloud.

After everything has been connected the hardware is ready to be used. Upon powering up the system, you will need to work through the getting started guide. This will setup your environment on your PC as well as install the latest applications on the MangOH Red. The only issue encountered was a change in RSA key which the command line explained how to resolve.

Once done, completing the installation is easy and smooth. The rest of the getting started guide follows the same well explained step by step paradigm. As the rest of the setup and getting started is self explanatory we’ll move to the software structure of Legato used by the MangOH

MangOH Software - Basic Structure

The MangOH boards use the Legato framework as the basis for their software. The Legato framework provides a lot of APIs take care of the simple as well as to simplify the more complex tasks that can be performed with the MangOH boards. The framework, while well thought out and logically ordered, can take some time to get used to for those just starting out. The basic file structure as well as the chain between variables and peripherals will be explained below.

Basic organization of the Legato file structure

The first folder (application folder) acts as a container for the application and is often named with the name of the application. This folder contains the application definition file as well as the component folders. The application definition file (adef) allows the compiler to know what components are used in the application as well as what peripherals are required. The adef also binds external hardware or devices to internally used variables.

Application Definition File (ADEF)

Using a very simple example we will look at the heartbeatRed application. In this application which uses very few resources and has only one component the  the adef looks as shown below. Starting from the top, the executables defines what code should be run in this application. In this snippet the heartbeatComponent is what we would like the application to run. Since a component can be run with multiple instances each instance is given a unique name. In the code below there is only one instance named heartbeat. Now that the instance has been named, we let the system know under processes that we would like this instance to be run. To do this we place the instance name heartbeat in the subsection run. This will start the application when the system loads (provided we have put on line 3 “start: auto” and not “start: manual”). If it is set to manual, you will need to do: app start heartbeatRed. Lastly there is the bindings section. This links the external devices (ports, files, etc.) to variables the software can use. In the code below we would like to be able to control pin 34, this is the onboard LED. To accomplish this the variable mangoh_led which is found in the heartbeatComponent and is part of the heartbeat executable is connected to the  gpioService. This service through the Legato GPIO service  then connects the variable to the specified pin.

sandboxed: true version: 1.0.0 start: auto executables: {    heartbeat = ( heartbeatComponent ) } processes: {    envVars:    {        LE_LOG_LEVEL = INFO    }    run:    {        ( heartbeat )    }    faultAction: restart } bindings: {    heartbeat.heartbeatComponent.mangoh_button -> gpioExpanderServiceRed.mangoh_gpioExpPin14    heartbeat.heartbeatComponent.mangoh_led -> gpioService.le_gpioPin34 }

heartbeatRed adef file as found in the heartbeatRed application folder

Component Definition File (CDEF)

Now that we have shown the compiler what components are to be included as well as what devices are needed and provided a handle for components to access them, let's look at the file that explains how the component is put together. The component definition file (cdef) explains how the various files are integrated as well as what source files the component needs to be correctly compiled.

As mentioned in the adef, we would like to have access to peripherals and as such we have linked a variable to them in the adef. In the cdef we now connect them to an API to allow us to manipulate and interact with these hardware or service components. This is done in the requires section by listing the variable in the api subsection and linking it to the required API. In this code snippet we need access to the gpio API, the mangoh_led variable is therefore linked to the le_gpio.api. The other section in this code snippet lists all the source files needed by the component to function correctly.

requires: {    api:    {        mangoh_button = ${LEGATO_ROOT}/interfaces/le_gpio.api        mangoh_led = ${LEGATO_ROOT}/interfaces/le_gpio.api    } } sources: {    heartbeat.c }

Component.cdef file as found in the heartbeatComponent folder

Source Code

Let's now have a quick look at the source file that makes up this component and controls how the LED behaves. Below is the full source code for this component it is the code listed in the cdef and used to turn on and off the onboard LED. The first thing to note is the inclusion of both legato.h and interfaces.h. The first allows us to use any of the legato header files used by the component, all legato programs will use some legato header. The second file include.h links in the auto generated header file from the cdef.

Moving further down the code we see in the function LedTimer a variable called mangoh_led_Deactivate, this variable is created through the binding section in the .adef file. In essence this is using the variable mangoh_led, created in the cdef and linked to hardware in the adef, with the api. We are therefore saying the variable mangoh_led should be used with the function call Deactivate to turn off the specified pin. This same principle applies to the other variables in the code that use the legato APIs. The next function, ConfigureGpios sets the pin with the LED attached as an output. If this fails the legato API is then used to send a message to the system log using LE_FATAL_IF. This ability set in the cdef under envVars and allows the system to log messages at the info level and lower.

The last and most important part of the C source file is the COMPONENT_INIT. This is similar to main() in C programs but, because there is no main() in legato applications, we need a different entry point. The COMPONENT_INIT is this entry point. It is important to note though, that unlike main functions this function must return. If COMPONENT_INIT does not return then the rest of the application will not run. In this specific COMPONENT_INIT function a timer instance is created to control the intervals between turning on and off the LED. After an instance is created various parameters for the timer (period, whether to repeat or not as well as its handle) are set.  Lastly the gpios are configured using the previously created function and the timer is then started. After all this is done the COMPONENT_INIT is exited and control is handed back to the legato framework.      

/** * @file * * Blinks the user controlled LED at 1Hz. If the push-button is pressed, the LED * will remain on until the push-button is released. * * <HR> * * Copyright (C) Sierra Wireless, Inc. Use of this work is subject to license. */ #include "legato.h" #include "interfaces.h" #define LED_TIMER_IN_MS (1000) static bool LedOn; static le_timer_Ref_t LedTimerRef; /*------------------------------------------------------------------------------------------ * Toggle the LED when the timer expires */------------------------------------------------------------------------------------------ static void LedTimer(le_timer_Ref_t ledTimerRef) {    if (LedOn)    {        mangoh_led_Deactivate();        LedOn = false;    }    else    {        mangoh_led_Activate();        LedOn = true;    } } /*------------------------------------------------------------------------------------------ * Turn the LED on and disable the timer while the button is pressed. When the  button is * released, turn off the LED and start the timer. */------------------------------------------------------------------------------------------ static void PushButtonHandler(bool state, void *ctx) // {    if (state)    {        LE_DEBUG("turn on LED due to push button");        le_timer_Stop(LedTimerRef);        mangoh_led_Activate();    }    else    {        LE_DEBUG("turn off LED due to push button");        mangoh_led_Deactivate();        LedOn = false;        le_timer_Start(LedTimerRef);    } } /*-------------------------------------------------------------------------------------------------- * Sets default configuration LED D750 as on */-------------------------------------------------------------------------------------------------- static void ConfigureGpios(void) {    // Set LED GPIO to output and initially turn the LED ON    LE_FATAL_IF(mangoh_led_SetPushPullOutput(MANGOH_LED_ACTIVE_HIGH, true) != LE_OK, "Couldn't configure LED GPIO as a push pull output");    LedOn = true;    // Set the push-button GPIO as input    LE_FATAL_IF(mangoh_button_SetInput(MANGOH_BUTTON_ACTIVE_LOW) != LE_OK, "Couldn't configure push button as input");    mangoh_button_AddChangeEventHandler(MANGOH_BUTTON_EDGE_BOTH, PushButtonHandler, NULL, 0); } COMPONENT_INIT {    LedTimerRef = le_timer_Create("LED Timer");    le_timer_SetMsInterval(LedTimerRef, LED_TIMER_IN_MS);    le_timer_SetRepeat(LedTimerRef, 0);    le_timer_SetHandler(LedTimerRef, LedTimer);    ConfigureGpios();    le_timer_Start(LedTimerRef); }

heartbeat.c source file as found in the heartbeatComponent folder

While this was a rather simple and easy to follow demonstration it outlines the most important parts of setting up a legato application. The most complex and important part of this example is how variables are linked to the device or hardware they wish to control. The adef links the device to a variable name. The cdef then links this to an API which the source code can then use to interact with and manipulate the device.

I am planning on releasing another blog post shortly that will explain the more complex redSensorToCloud application. This application has multiple components and uses linux drivers for some of the peripherals.