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

Amphenol Air Quality Engineering Dev Kit - Review

I would like to thank Amphenol and Element14 for giving me the opportunity to review this set of sensors. Having spent the last year or so working with two environmental sensor systems I wanted to see how Amphenol’s solution compared. My initial proposal was to test Amphenol's solution in an environmental chamber where I would be able to test the system in a controlled and calibrated environment. Unfortunately this was not possible due to unforeseen circumstances.

Having tested the other two systems, a LiVPi - intended for indoor sensing as well as a AirVisual Node - intended for both indoor and outdoor sensing, I decided to use these as pseudo calibrated units. All three units (the LiVPi, AirVisual Node and Amphenol’s solution) have temperature, humidity and CO2 sensors. Beyond this they differ in that the LiVPi also reports pressure, the AirVisual Node Reports P2.5 concentrations (and P10.0 but only via file access) and the Amphenol solution provides dust concentrations of various particle sizes.

With the increase in air quality awareness there has been an explosion in companies providing sensors as well as in the range of sensors available. The issue then becomes how to know the quality and reliability of each of these sensors. Unlike temperature or humidity, CO2 and dust concentrations are not things we grow up paying attention too and become innately aware of. This makes understanding as well as knowing when a sensor is reading correctly is a lot more difficult.

I have therefore taken a multi staged approach to reviewing these sensors. Firstly I would like to see how robust they are. Being environmental sensors I would like to see how they live up to the environment they should be able to sense. Secondly I would like to see how well they agree with other sensors, both calibrated and not calibrated. Lastly and because this kit is specifically designed for testing the sensors to then be used in a standalone product, how easy is it to understand their documentation and subsequently use them.

Robustness

Sensors that are meant to sample and test their environment should be able to withstand that environment with no issues. One way to be sure they can survive is to push the boundaries and see how they react.

Using a rural environment that is open to the sun and wind (sheltered from rain) I decided to leave the unit outdoors for two weeks along with my other two units. The idea behind this was to see how the sensors would behave as well as test the ABC logic of the CO2 sensor. I also wanted to see if there would be any effect on the readings of the sensors while exposed to the elements.

The first and most noticeable environmental element that the sensors needed to deal with was the wind and more specifically the sand. Being only a few tens of meters from the beach the wind can be quite vigorous (sustained 23 km/h, gusting to over 31 km/h). I was quite impressed that even through this the sensors carried on working with no issues. While the temperature and humidity sensor is IP67 rated the others are not. As can be seen in the picture below, after two weeks the board and sensors are well covered in sand.

Amphenol sensor kit covered in sand after 2 weeks of outdoor testing

An interesting point, whether designed as such or not the dust sensor, while adequately sensing dust conditions did not get sand in the sensor. This was verified both by looking inside the sensor after removal of the cover tape and inspection of said tape. It should be noted that while the sensor was not pointed into the wind but, was approximately parallel to it, the area where the sensor was sheltered has vortexes and as such sand could have gotten into the openings. The CO2 sensor had no issue due to the air permeable covering over the sensors opening.

Tape used to cover the mirror cleaning port with no viable sand on the inside section

Along with the wind there was rain and often enough driving rain. Together the wind and rain made quite a formidable duo. Fortunately the sensors remained dry for the most part. There were some rain drops that landed on the CO2 sensor but again there was no adverse effects. While not waterproof or even rated as water resistant, the air permeable cover worked well at keeping the few raindrops that did land on the sensor out.

Throughout the full two weeks the sensor array had no issue at all. The CO2 sensor was quick to acclimatize and start producing agreeable readings. The temperature sensor was the closest to the actual temperature of the three sensors placed. Even with direct sunlight on the sensor the Amphenol sensor maintained the lowest overall reading. I would like to note an issue with the temperature/humidity sensor that was received. The air permeable membrane on the one side appears slightly removed potentially allowing for water and other particles to enter.

T9602-3-D-1 with cover properly covering air opening

T9602-3-D-1 with cover not properly covering air opening

Agreement between sensors

Having two other sensor kits that have been tested in a calibrated environment I though this may be a valid and useful way to test the Amphenol sensors. Unfortunately I did not have a method setup during this period to log the data from the three systems. This is something that is currently being worked on and will hopefully be set up shortly with a publicly accessible web interface where others can see and compare the data between the systems.

Temperature results from testing the LiVPi and AirVisual against a calibrated instrument

Testing was therefore conducted using visual checks at random times. With the exception of external heating (due to direct sunlight) the largest temperature reading spread was approximately 2 ℃. While this does not confirm the reading of the T9602-3-D-1 is calibrated within ∓ 0.5 ℃, it at least shows it's very close.

While the temperature measurements have been very close the same cannot be said for the other sensors. The humidity measurements have been as far as 10% apart  with this being predominantly noticed with the AirVisual Node. The measurements between the LiVPi and the T9602-3-D-1 have been closer with variations usually under 5%. From the calibrated test results it can be seen that the LiVPi does have a curve closer to the real values. This would imply that the T9602-3-D-1 is again pretty close to if not at its stated accuracy.

Humidity results from testing the LiVPi and AirVisual against a calibrated instrument

The last sensor that could be checked in a direct comparison with other sensors was the CO2 sensor (T6713-6H). Of the sensors this is the first that we have no innate understanding of. For this reason this is the first measurement that there is complete reliance on sensors. The spread between the three different sensors was very large. Unfortunately in this case Amphenol solution was the outlier. In outdoor test both the LiVPi and the AirVisual Node were measuring around 400 ppm, which is normal background CO2 levels. In the same environment the T6713-6H was measuring ~350 ppm which depending how you look at it could be pushing the “±30 ppm ±3% of reading” specification. In an office environment the three sensors have been seen measuring: 1485 ppm - T6713-6H, 1241 - LiVPi and 1197 - AirVisual Node. In this case the Amphenol solution is way past its accuracy in comparison with the other two sensors. While this is not definitive and definitely allows for determining basic air quality it leaves the stated accuracy in a bit of question.

Amphenol’s T6713-6H CO2 sensor solution

Senseair K30 CO2 sensor solution

It should be noted that in comparison with the LiVPi sensor (Senseair CO2 Engine K30) the T6713-6H is much more compact and product friendly. Due to its smaller size it would be a lot simpler to incorporate in end user products. The ability to use I2C and UART also allows for easier incorporation. The T6713-6H does have a smaller input voltage range (4.5V ~ 5.5V) in comparison to the Senseair solution (4.5V ~ 14V) which can affect where or how it is incorporated in products.

The last sensor included is the SM-PWM-01C dust sensor. While no direct sensor or calibrated source to test with, the AirVisual Node’s P2.5/P10 sensor was used as a semi comparison. During the three tests that were conducted mixed results were obtained as will be explained. The first test was using smoke. Newspaper was burned in a low oxygen environment causing lots of smoke to be produced.

Initial test setup using smoke

Unfortunately in the above setup the dust sensor would not register any particles. The setup was then changed to have the sensor down wind from the smoke, at this point the sensor started to register a somewhat elevated particle count. This was not at all encouraging as one of the stated uses is smoke detection. In contrast the AirVisual Node which was upwind from the smoke immediately registered elevated levels. This can be seen in the images below

Levels before and after testing using smoke

AirVisual’s display clearly indicating extremely elevated levels of fine particles

It should be noted that it was later discovered that the covering to the mirror cleaning port was not in place. While the bad measurement quality may be attributed to this, I believe the levels measured should have been elevated if even only slightly. This belief is taken from the levels of both P2.5 and P10 measured by the AirVisual Node. At those extremely high levels something should have registered if even only slightly.

The next test, done by accident was a cooking test. Frying oil produces a lot of very fine smoke. While this may have a noticeable odor it is not very visible. In this case the dust sensor did register a “Yellow” condition. These two test left the sensor in a limbo regarding its reliability. A third test was therefore conducted.

The last test performed was with sifting flour in a room with airflow produced using a ceiling fan. In this case the results were again mixed. While sifting the flour through a very fine sieve no elevated dust levels were registered. To be sure enough dust was produced, the dusting went on for more than 30 seconds and relatively close to the sensor. This left a fine white coating of the testing area and sensor kit.

T6713-6H being tested with flour

When this test was thought to be completed and the sensor to have failed, an air compressor was used to blow the flour away. This was when the sensor started to register elevated levels. The sensor quickly registered levels as high at 40 (ug/m3, units unclear).

T6713-6H detecting fine flour being blown with an air compressor

Overall this left me wondering about the specifications of this sensor as well as its intended uses. Perhaps better airflow should be recommended or range of particle size detection better explained. Either way, this sensor did provide some usefulness detecting fine smoke (frying with oil) as well as fine flour but not seemingly larger smoke or flour particles.

Documentation and easy of use

This kit and the sensors in the kit are provided in such away as to allow developers to test them and learn how to incorporate them into new products. In order for this to be successfully achieved accurate, reliable and understandable documentation is required. This unfortunately is also one of the last steps in getting a product ready to be shipped. Becasue of this a decent number of products have great potential but have unsatisfactory documentation at best and confusing documentation at worst. Since this kit comprises three sensors and one daughter board there is a mix of documentation.

Starting with the dust sensor (T6713-6H) the documentation was terrible. The images are not intuitively or labeled in a useful and meaningful way. This has lead to unclear explanations and misunderstandings. Output pins are labeled but not necessarily explained. There are 5 pins of which 4 are explained. The last pin either called RX or N/C is not explained and sometimes not even labeled. It can only be assumed that this pin has no real use but with differing and somewhat contradictory documentation this is unclear. How the sensor detects different particle sizes is also not well explained which has lead to an unclear understanding of how to use the sensor.  

Image explaing how particles are counted/measured but not well explained

There are references to the figures in the documentation but most of the figures are not labeled leading to a need to count through the images to find the figure being referenced. The documentation also uses abbreviations that are either not explained or explained somewhere else in the document. It is clear from the documentation the low power consumption of the sensor (5V @ 90mA), it’s fast start up time (90 seconds) as well as the sample rate (5 Hz).

The other two sensors have much better and clearer documentation. The simpler of the two is the T9602-3D-1 temperature/humidity sensor. With a stated accuracy of ∓ 0.50 ℃ and 2% RH over its range of -40 ~ 125 ℃ and 0 ~ 90 RH (RH >90% accuracy can suffer up to ∓ 3%) this is a very usable and capable sensor especially with its IP67 rating. The documentation is clear on how to hook up the sensor, what external components are needed as well as the power consumption (3.3V @ 750 ~ 1100 uA). It's also clear that while there are 8 pins on the internal sensor IC only the communication and power pins are broken out. It would have been nice to have signals such as high/low alarms broken out as well as the ready signal. Its also nice to see that the 3.3V power line is separated from the signal line by ground. This is a well known but not always used technique to reduce EMI. The communication protocol (MODBUS) using both I2C as well as UART is well explained both in the text and with a very well designed infographic.

Infographic explaining the communication protocol for the T9602-3D-1 sensor

Both the I2C address and communication speed is configurable with a large range of options allowing for lots of sensors to be connected on the same I2C port. Tips on how to use the sensor for most accurate measurements are also mentioned. This includes using pulse measurements to reduce ontime of the sensor thus reducing heating of the sensor. Overall the documentation follows a logical progression making the reading and understanding of this sensor easy. It should be noted that the pages referenced for each figure are off by one.

The last sensor is the CO2 sensor (T6713-6H). This sensor has the most documentation and in some ways is the most complex. While there are not a lot of options or settings there is a start up sequence that allows for some customizations to be made depending on the environment the sensor is being used in. The T6713-6H also uses the MODBUS protocol for communication. While this possibly added a level of complexity it does allow for some level of commonality between various sensors. The remaining documentation other than explaining the various commands as well as how to change the I2C address explaines the internal ABC logic.

The ABC logic works by remembering the lowest measured value over a 24 hour period. After doing this for 7 days a statistical algorithm is used to determine if the sensor needs to be recalibrated and using those values this is done. For this to work correctly the sensor needs to see ~400 ppm of CO2 3 times in a 7 day window. Alternatively the sensor would need to see 400 ppm 4 times in a 21 day window. The ABC logic will not take into account any measurements taken from less than a 24 hour window. This means the sensor needs to run for a minimum of 24 hours before it will allow a reading to be read as a minimum value. If it is assumed the sensor will not see a 400 ppm value, the ABC logic can be turned off. Once calibrated the sensor can produce stable values in 10 minutes but has a start up time of two minutes. This would limit it uses in some products/environments where the on/off cycle time can be very short thus not allowing the sensor enough time to adequately startup or use the internal ABC logic. One thing to mention with this sensor is the list of chemicals that can adversely affect it. On this list besides ammonia, chlorine and NOx is ozone. As ozone is a natural chemical found in most environments this is an odd chemical to list as having an adverse effect.

Lastly is the documentation for the kit as a whole. For the whole kit only 4 pages of documentation are provided. Of these one is the title page, one is how to connect up the sensors another is a link to the git repository and the last one is a list of links to the sensors documentation. While this allows you to get the kit up and running by showing how to plug the sensors into the main board that's about all it provides. It would have been nice if a bit more information, even if just a synopsis of the sensor features as well as how to use the sensors, was provided. While a link to Github repository is provided, the landing page provides no useful information as where to find the actual code. Once it is realized that you need to use the Telaire subdirectory (all the sensors are supposedly from that subsidiary) you still are not presented with any code. This is because the code is in branches and each subsequent code release is a different branch as opposed to being a milestone or version number on a single branch. This leaves you unclear as to what branch to use. As no branch is labeled Uno or Arduino evaluation code or kit what code/branch to select is left ambiguous. The only help that is somewhat provided comes from a document recently added. The document labeled Changing the code in the Arduino has directions on where to download the code from. This note mentions “From https://github.com/AmphenolAdvancedSensors/Telaire/tree/Evaluation_Board_v1.4 download all files into My Documents/Arduino/TelaireSensors directory.” This is the only clue as to what code is to be used with the kit. I would be nice if Amphenol/Telaire updated the way they use git to better reflect code progression instead of separating versions of the code into different branches.

Conclusion

I believe Amphenol has provided a useful and easy way to test their environmental sensor suite. The ability to quickly and easily evaluate each sensor using either the provided OLED display or by changing the code to output the data over serial is very useful. The sensors have shown that they can successfully operate in the environment they are meant to as well as in harsher outdoor environments. The temperature/humidity sensor included was shown to live up to the expectations set by Amphenol. The results for the CO2 sensor are unclear as the readings are often quite different from two other sensors in the exact same environment. Whether this is due to a faster response time or the sensor not living up to its expectation is unclear, further testing would need to be conducted. The results from the dust sensor also left an unclear result. Responding to smoke from frying and fine dust being blown around yet not responding to thicker smoke or blowing flour. Whether this was due to misunderstandings brought out from inadequate/unclear documentation or from the performance of the sensor itself is currently unclear. Lastly the kit is well made. There are some improvements that can be made such as clearer labeling for directional connection of sensors or changing connectors all together. While the connectors selected are low cost and easy to use, an extra $1 or $2 would greatly improve the user experience and possibly allow for more favorable results for Amphenol when their sensors are being tested. (A blown sensor because of incorrect connection is never helpful in promoting a product). Overall I look forward to continuing to evaluate this product both against other sensors in my inventory as well as against calibrated sensors from reputable organizations.


Original post on Element14 can be found here

Sending Atmospheric Data from the MSP430 and CC3100 Wi-Fi BoosterPack to Plot.ly

Figure 1. Terminal screen displaying live data being transmitted and demo Plot.ly graph

For a while now I have been thinking about the ability to remotely monitor what is going on environmentally in a location. I have thought about this with regards to the summer, with a cottage more than an hour away it would be nice to know what the weather pattern is for the cottages location (not the general city or county) to decide if it is worth the long drive. I have also thought about this with regards to parts of my house, such as the attic, basement etc, to help determine how well the insulation is working or what is going on in parts of the house where people may not often frequent. Lastly it has come up in many conversations with storekeepers who want to know how their fridges are performing and to know when there may be an issue. With all these usage cases I decided I should come up with a solution.

When TI came out with their CC3000 I thought I would give that a try. I spent a few weeks working with this BoosterPack in conjunction with a Stellaris (Tiva C) and MSP430G2553  launchpad but had a good few issues that just didn't seem easily resolvable as well as some limitations that hinder the usability of the system, besides by then TI had come out with the CC3100 that was supposed to resolve a lot of issues as well as be some what easier to use.

Figure 2. CC3100 layout and pin assignment

At the same time I was introduced to Plot.ly, an online graphing tool that allows for real time plotting of almost any form of data. After looking over how Plot.ly works I decided these two tools together would make a good start to resolving my real time remote data logging problem.

As I have a decent background with TI devices the use of TI products was a natural and convenient choice.The MSP430F5529LP was chosen as the brains behind the system and as previously stated the CC3100  was chosen for the Wi-Fi connection. The MSP430F5529LP was chosen do to the wide availability of example code and wide usage of this launchpad with the CC3100.

Figure 3. MSP430F5529 pin assignment for use with BoosterPacks

The Wi-Fi connection is a CC3100 Boosterpack that contains an integrated TCP stack and is interacted via SPI. One of the important features about this BoosterPack is its conformity to the BYOB (build your own board) standards.

Figure 4. Build Your Own Board pin assignment layout

This means that all the pin connections are in predetermined locations allowing for ease of use with other BoosterPacks. The sensor chosen is a MPL3115A pressure sensor from Freescale and was integrated using the Xtrinsic sensor board from Element14 and Freescale. Lastly as this needs to be able to work in a remote location I decided to add a local power source, for this the Fuel Tank BoosterPack from Element14 was chosen. This choice however does present its own issue. The Fuel Tank BoosterPack does not conform to the BYOB standard. With some connections in contention this board was connected via jumper leads and for now only provides power, the power monitoring ability of the BoosterPack has not been implemented but hopefully will be in a later iteration of this project.

Figure 5. Fuel Tank BoosterPack pin assignment (non-conforming)

The project is based on the TCP_Socket demo for the CC3100. This demo has the basics needed to connect to an access point (AP), open a socket and send data, this provides a very substantial start for the project. This code was modified one step at a time. The first step was to allow for data of my choosing to be transmitted. This was tested and verified using a piece of software from HW-Group called Hercules. This software allows you to have a server running on your PC and to easily receive and see incoming data. One this was done the code needed to be further modified to allow for one connection to be made and multiple packets of data to be transmitted. This was done by splitting the BSDclient function into two distinct functions. The first function would take care of creating a socket and connecting to it. The second function packetTx would then take care of transmitting the desired data. Once this was done (with some difficulty, see forum posts for details), it was time to start transmitting data to Plot.ly.

The website for Plot.ly origanly did not provide a lot information if you were not using one of there standard platforms (Arduino, Matlab, etc) or one of there chosen languages (Python, R, Arduino), I therefore had to take the Arduino code (the easiest to understand) and parse it so it could be used in the format needed by the CC3100. From this code (Plotly’s Arduino code) I was able to create a graph using the REST API commands. These commands in their most basic form look like this:

POST /clientresp HTTP/1.1

Host: 107.21.214.199

User-Agent: MSP430F5529/0.5.1

Content-Length: 243

where the IP address “107.21.214.199” is the address of Plot.ly. The content length is the length of the following string in bytes that actually creates the graph (Note each line is terminated with a carriage return as well as a new line (“\r\n”)):

version=2.2&origin=plot&platform=Stellaris&un=Kas&key=ABCDEFGHI&args=[{"y": [], "x": [], "type": "scatter", "stream": {"token": "1234567890", "maxpoints": 500}}]&kwargs={"fileopt": "overwrite", "filename": "test plot", "world_readable": true}

I will explain this string briefly. Platform is the platform or language being used, from what I can tell changing this has no effect on how the graph behaves. “un” is the username, mine is Kas. “key” is your unique identifier key that allows access to your account. “args” is used to set up the individual traces, in this case I have only one trace so there is only one set of args. if you wanted more than one trace you would use something like this:

version=2.2&origin=plot&platform=MSP430F5529&un=Kas&key=ABCDEFGHI

&args=[{"y": [],"x": [],"name": "Temperature","type": "scatter", "stream": {"token": "1234567890", "maxpoints": 500},"yaxis":"y1"}, {"y": [],"x": [],"name": "Pressure","type": "scatter", "stream": {"token": "1a2b3c4d5e", "maxpoints": 500}, "yaxis": "y2"}]

&kwargs={"filename": "Temperature and Pressure", "fileopt": "overwrite", "style": {"type": "scatter"}, "layout": {"title": "Temperature and Pressure vs. Time", "xaxis": {"title": "Time (s)"}, "yaxis": {"title": "Temperature (Celsius)"}, "yaxis2": {"title": "Pressure"}}, "world_readable": true}

for a full listing of commands you can look at this documentation. “kwargs” is the settings for the overall graph such as the title, public/private access as well as others. At this point I had a graph created and was able to see it in my workspace on the Plot.ly website. I now needed to stream data, using the Arduino code for this however did not appear to help very much. I will again show the commands to open a stream and stream data and then explain them.

POST / HTTP/1.1

Host: stream.plot.ly

User-Agent: Python

Transfer-Encoding: chunked

Connection: keep-alive

plotly-streamtoken: 1234567890

In this code the main command that you need to edit is “plotly-streamtoken”. This line is used to specify the specific trace that this data should be posted to, it is the same as the token in the args passed to create the graph. Note each line is terminated with a carriage return as well as a new line (“\r\n”). Once the stream is open data can be sent to tos graph and trace specified this is done by the following line:

3134

{"x":1,"y":5}

3134

{"x":2,"y":5}

This is where it gets confusing, the 3135 appears to be meaningless but is is infact hex for 14. There are 14 bytes transmitted here including a new line. The “X” value here can be seen to be 1, 2 and the “Y” value is 5. The order of the “X” and ”Y” does not appear to matter. Data must be transmitted once per minute or Plot.ly closes the stream, you can choose to reopen the stream (Plot.ly would prefer you don’t consttly open and close sockets) or preferably send a heartbeat (“\r\n”) if it will be longer then a minute before your next data transmission. Now that we can open a connection with Plot.ly using the CC3100, stream data to plot in reat time its time to get the data from the desired sensor.

I chose to use the MPL3115A as it is a relatively simple sensor to use and I had one laying around. The MPL3115A uses I2C to communicate and once set up to take a reading every second there is not much to do other than poll for data. This will eventually be changed to an interrupt based system which would ideally allow for the MSP430F5529LP to sleep for approximately 95% of the time (back of the envelope calculation) increasing the units life by orders of magnitude.

Figure 6. Xtrinsic Sensor Board and pin assignment configuration

This code was initially developed separately from the TCP_Socket code and was slowly merged allowing for issues to be easily resolved. The main issue encountered was the “Error: "Program will not fit into" after adding interrupt handler” this was eventually resolved by simply removing the interrupt handler for “USCI_B1_ISR” in board.c. Once the data is read in it needs to be changed to a string and assembeled as message that Plot.ly can interpret. This is all done in the “plotlyPlotString” function, two integers are passed in as well as a pointer to a char array. The integers are converted to chars and inserted into the string ready to be sent to Plot.ly (this function in its entierty can be confusing so if anyone would like more clarification I would be happy to further exlpain it below). One integrated and tested the system performed pretty well.

Figure 7. MSP430F5529 with CC3100 BoosterPack mounted and connected to the Xtrinsic Sensor Board (P4.1, P4.2) and Fuel Tank BoosterPack (3.3V, 5V, GND)

Next Steps

Moving forward there are a number of improvements that need to be made. As of now the system disconnects from Plot.ly after ~530 data points (this does not happen with the Hercules server), this issue will need to be resolved and is currently under further investigation. There is also the issue of inadvertent disconnections from the AP that for a robust system will need to be taken care of, this will involve checking that the connection has not been closed and if it has, to reconnect. There is also the need to check that the socket has not been closed and again if it has to reopen it before continuing to send data. Lastly for complete robutness the system should be able to check for error messages from Plot.ly and react to them in a meanigfull manour.

Besides for these steps the inclusion of pressure data on a separate “Y” axis would allow for a better use of the chosen sensor. Also the full implementation of the Fuel Tank BoosterPack with power monitoring and plotting time remaining, battery voltage and possibly other metrics would be a useful addition.

I will update this post as the project evolves. If you have any questions or comments I would be happy to address them in the comments below.

For those who would like to try this and may run into the same issues I have, I have included a link to the issues I had and how TI helped me resolve each of them

CC3100

Can't use I2C device with CC3100BOOST

CC3100 TCP Client Receive

MPS430F5529 Low Power Mode Hanging.

Code hanging at "establishConnectionWithAP(); "

CC3100BOOST Rev 3.1 vs Rev 3.3

Upgrading CC3100 Firmware

Error: "Program will not ft into" after adding interrupt handler

CC3100 Error while sending the data

Get_Time / Get_Weather Code size issue

CC3100 + MSP430F5529 No Console Output

MSP430F5529 I2C Example Issues

Original post on Element14 can be found here