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.

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