IDT Wireless Flow Rate, Humidity&Temp Sensing Kit - Review

Table of contents

RoadTest: IDT Wireless Flow Rate, Humidity&Temp Sensing Kit

Author: Gough Lui

Creation date: 20 May 2019

Evaluation Type: Development Boards & Tools

Did you receive all parts the manufacturer stated would be included in the package?: True

What other parts do you consider comparable to this product?: 6LoWPAN Module - Microchip/Atmel ATSAMR30M18, EBVElektronik Janus Temperature/Humidity Sensor - Bosch BME280, Silicon Labs Si7021.

What were the biggest problems encountered?: Lack of publicly available documentation regarding many aspects of the design. Undocumented design compromises limiting ability to evaluate full performance of included hardware.

Detailed Review:

IDT SDAWIR03 Wireless Flow Rate, Humidity and Temperature Sensing Evaluation Kit RoadTest

By Gough Lui – May 2019

As someone who is excited about the Internet-of-Things (IoT) revolution and who knows a thing or two about networks and radios as a licensed radio amateur, I couldn’t pass up the opportunity to give the IDT SDAWIR03 Wireless Flow Rate, Humidity and Temperature Sensing Evaluation Kit a try. It features a 6LoWPAN radio module operating in the sub-GHz band which is something I have not tried before. Unlike common technologies such as Wi-Fi or Bluetooth, this has the ability to form mesh networks, consume less energy and perhaps even reach further distances without the crowded clutter of the 2.4GHz band.

It is with thanks to Integrated Device Technology (IDT) and the team at element14 Communities that I have this opportunity to evaluate the device and present this RoadTest review. As with my more recent RoadTest reviews, this review is merely a summary with the full content of each chapter in its own blog posting linked afterward. Feel free to click-through on chapters which interest you for a more detailed report. If you find this review interesting, helpful, useful or entertaining, I’d appreciate if you would leave a like, a rating or a comment. Feel free to ask any questions – I’ll do my best to answer them.

A Plethora of IoT Networking Choices – Why 6LoWPAN?

Realising practical Internet of Things (IoT) projects requires careful balance of several potentially conflicting variables, which may include cost, convenience, power consumption, bandwidth, processing power and security just to name a few. Even when just considering the communications needs of IoT devices, there is rarely a one-size-fits-all solution as it depends on the individual project needs. As a result, there are a wide range of IoT-related networking technologies in use today.

When looking at the table, it may be difficult to identify the correct technology for your needs as it doesn’t summarise all the characteristics of each technology, as many details are implementation-specific and dependent on operating condition. Some of the technologies are built upon others (e.g. of the IEEE 802.15.4 physical layer). Bandwidth, power consumption, range, operating band, cost of module, cost of operation, openness of standard and operating model are all factors which decide whether a given technology is suitable for a given application.

Of the technologies on offer, 6LoWPAN is a sensible choice for those looking for a sub-GHz networking technology that is standardised without ongoing operator costs, with a mesh-networking topology and “transparent” IPv6 communication capability with inbuilt security that does not require complex gateway devices.

In the market of sub-GHz 6LoWPAN modules, there are not many choices, with only the IDT ZWIR4512 and ZWIR4532, Microchip (formerly Atmel) ATSAMR30M18 and EBVElektronik Janus being the units identified. It is possible, however, to create a 6LoWPAN radio system by integrating a sub-GHz transciever with a microcontroller running the 6LoWPAN stack software (e.g. uIP/Contiki, Nanostack, etc) although this requires additional integration effort. As a result, it appears that IDT is a leader in the niche area of 6LoWPAN sub-GHz modules, although their modules are more expensive than the Microchip module.

For more details, see IDT SDAWIR03 RoadTest-in-Depth: Ch1 - Why 6LoWPAN?

Introduction to the Kit and Unboxing

The SDAWIR Evaluation Kit comes in a white box with a colour label on the outside listing the kit contents and features. This particular version is the SDAWIR03-AMZ01-GB which comes with multi-country power supply plugs and features the FS2012-1010-NG Gas Flow Sensor, HS3001 Relative Humidity and Temperature Sensor and ZWIR4512 6LoWPAN Module.

In addition to the hub and sensor cube, the kit includes two high-quality XP Power VER05US050-UB 5V 1A power supplies, some vinyl tubing, a mini HDMI adapter and microUSB-OTG cable. The included items are very safely packaged in anti-static foam, with a highly professional metal-badge labelling finish on both the hub and sensor cube. The hub is based on a Raspberry Pi Zero-W with its familiar size and shape, housed inside a black plastic case including a pre-installed microSD card ready to run. The sensor cube is in a custom clear plastic case, allowing its innards to be admired. The power supplies come with a long list of approvals and four different plugs that cover almost all countries including Australia.

It seems that the ZWIR4512 has a long heritage, with the datasheet first released 15^th April 2013, making the module six years old. It is still branded ZMDI as Zentrum Mikroelektronik Dresden AG (ZMDI) was acquired by Integrated Device Technology (IDT) in 2015. That being said, IDT themselves were acquired by Renesas just recently in late 2018.

For more all the pretty pictures with some commentary, see IDT SDAWIR03 RoadTest-in-Depth: Ch2 – Intro & Unboxing

Teardown

The IDT SDAWIR03 hub is built around a Raspberry Pi Zero-W with a custom-built “hat” utilising the surface mount ZWIR4512 module on a printed antenna coil. The module uses the UART for communication with the Raspberry Pi. The PCB appears to be poorly manufactured, with registration issues between the drill layer and the copper/silkscreen/solder-resist layer. The connector appears to have been hand soldered, although fairly well. The unit uses a Sandisk Edge 8GB microSD card for storage.

The sensor cube itself has an interesting board which seems to make a lot of use of the Texas Instruments TPS6220x high-efficiency DC-to-DC step-down converter. It also uses a different version of the ZWIR4512 module which has a castellated PCB with integrated antenna connector instead. The PCB utilises a more compact chip antenna instead of a printed antenna. The battery holder appears to be soldered a little roughly, but construction is otherwise compact and neat, with two reed switches serving to change modes or reset the cube.

The two sensors plug into the board, although the orientations are not clearly marked. The HS3001 has a very simple PCB which only features two de-coupling capacitors, whereas the FS2012-1010-NG features a more complex PCB with a 28-pin IC lacking identification and a number of other supporting components. The flow sensor uses barbed fittings to connect to a gas flow moving from P1 to P2. It has an unused analog output and a seemingly unreferenced J2 connector.

While the boards may be good for demonstration purposes, they do not appear to be tailored for easy development or modification.

For more close-ups, see IDT SDAWIR03 RoadTest-in-Depth: Ch3 – Kit Teardown

Setup and Documentation

The sum-total of the documentation provided by IDT on the SDAWIR03 product page is a 22-page PDF user manual. The user manual summarises the kit contents, its features, the setup process, basic usage, operation with Amazon Web Services (AWS) and firmware update operation.

Unfortunately, in all other respects, the documentation is lacking. There are no schematics, no software image downloads, information about how the software may be customised or even what software is being used. There are some poor suggestions and unexplained claimed capabilities. The kit itself is not particularly user friendly for those who want to evaluate the hardware aspects and is at times frustrating to reverse-engineer the software aspects. Additional information is said to be available on request but has not been furnished to me at this time.

This is a little disappointing for a kit that retails for AU$293.78 + GST from element14. Developers looking to work with the ZWIR4512 module are probably better served by the ZWIR4512-KIT which makes debugging and testing more easily accessible and comes with better documentation. Integrators looking to test the HS3001 and FS2012 sensors need not require the 6LoWPAN solution and are better off evaluating the sensors on their own without the interference of the platform. Those looking to put sensor data on to AWS may well have a demo that works with this kit, but lack all the implementation details needed to customise and truly make this platform their own.

The setup process is very much plug-and-play with a little bit of waiting. Getting up-and-running with sensor data showing in the browser can easily be accomplished in minutes without any technical knowledge whatsoever by using the inbuilt virtual AP network. Various settings for sensor name, transmission policy, battery information and network configuration can be easily accessed and configured to enable access to the AWS cloud.

The kit does, however, possess some security risks which users should be made aware of, such as default SSH login passwords, the persistence of an open Wi-Fi access point after joining to your own network and the possibility for network relay via an SSH tunnel. While these are easy things to fix for those who are familiar with Linux, instructions should really be provided. Additionally, pointers should be provided for those wanting to record data without the use of Amazon Web Services to save users time trying to reverse-engineer their own demo kit. While it seems that channel modifications are possible, due to limitations in cube firmware and hub software, it does not seem to operate correctly, which is an additional disappointment.

For the full process, see IDT SDAWIR03 RoadTest-in-Depth: Ch4 – Setup & Documentation

Sensor Cube Testing

Testing of the sensor cube was made using a local UDP capture of JSON data which was processed into CSV using a simple Python script. Testing of battery life operating on two Varta CR2032 cells yielded a lifetime of just under 9 days of continuous operation, implying an average current of around 1.1mA. The RSSI remained constant despite the declining battery voltage, indicating a well-regulated power supply.

Outdoor comparison tests with a Bosch CISS sensor revealed the IDT to be very similar in terms of trends, although the design perhaps suffered more from direct radiative heating and condensation from moisture, resulting in slightly different results. In both cases, the limited resolution of the temperature sensor was apparent, with about 0.6-degree Celsius steps rather than the datasheet claimed 0.015-degree Celsius steps.

Testing in extremes in the fridge and freezer showed that operation in the fridge was no problem, although the freezer was able to reduce the performance of the CR2032 batteries enough to prevent the cube from being able to operate. Patterns in door opening are visible in the humidity traces and the transmissions were able to penetrate the fridge door.

Testing of the gas flow sensor was done at zero flow conditions which appears to have uncovered a periodic “spiking” of the signal to about 2SLPM under no-flow, comprising about 8% of the returned values. The remainder show a low background level reading. Testing with a photographic blower bulb showed the sensor to be functional, although its accuracy could not be determined.

Testing the sensor cube does show the 6LoWPAN module can be quite efficient with power consumption when operating off coin cells. However, it seems that the software does not take full advantage of the HS3001’s temperature reading capabilities and the FS2012 also exhibits some spiking anomalies. As a result, it seems this kit might not be showing off the IDT sensors in their best light, casting further doubt as to the kit’s intended purpose.

To see all the tests, see IDT SDAWIR03 RoadTest-in-Depth: Ch5 – Sensor Cube Testing

Radio Emission Testing

Unfortunately, the SDAWIR03 did not impress when it came to radio performance. In range testing, a range of 4m was obtained, with the unit dropping out by 5m. This range is below that of Wi-Fi and even Bluetooth, even though on-paper, it would seem that a range equal to or surpassing that was to be expected. The reason appears to be poor antenna design or matching, as with the two units stacked together, the transmitter-to-receiver loss was a whopping 60dB. As a result, in order to gain the same amount of coverage, one would have to deploy more nodes and run them in a mesh. Unfortunately, with just one sensor cube supplied, it was not possible to evaluate the effectiveness of the mesh system.

Despite the IEEE documents denoting the North American band as 915MHz and my expectation that the hub and cube may use a channel randomly, it was found that the cube appears to have been fixed to 906MHz. While this is fine for operation in North America, in more restrictive markets such as Australia, we are only allowed to operate in the 915-928MHz band as the commercial mobile telephone service (CMTS) band uses the lower portion for mobile-to-base uplink.

While it was proved that the hub could be switched to a channel that would be legal to operate in Australia (the upper five channels, as the module starts at 906MHz with 10 channels, each separated by 2MHz), it was found that the hub software would detect such a channel change as if the region had not been set and refuse to operate. Furthermore, it was found that contrary to the manual, the cube will not follow the hub to any channel (aside from one EU and one US as pre-programmed) due to battery life restrictions.

As a result, it is not legal to operate this equipment in Australia or many other 915MHz/920MHz band countries. I have suggested that they choose another channel, perhaps 916, 918 or 922MHz which are channels which are common to nearly all the 915/920MHz band countries in the IEEE 802.15.4 standard. Upon this discovery, I discontinued all usage of the SDAWIR03 kit as I did not want to cause interference to other licensed services or open myself to legal problems. It seems rather frustrating that the hardware appears to be capable of legal operation, but the software is not.

For more test results, see IDT SDAWIR03 RoadTest-in-Depth: Ch6 – Radio Emission Testing

Power Consumption & I2C Bus Testing

The SDAWIR03’s sensor cube was determined to operate as low as 2.029V from a bench power supply, with the LEDs failing to function below about 3V. This matches well with the ZWIR4512 datasheet which allows operation down to 2V without use of ADC or 2.4V with the use of ADC. Use of two CR2032 cells is necessary to ensure the voltage does not fall below this level during peak current demands (e.g. during transmission), especially as CR2032 cells have rather high internal resistances as they are designed for continuous loads of about 0.5mA.

The power consumption profile as measured shows that with the flow sensor installed, a background consumption of about 29mA is registered with a cyclical component of about 2mA corresponding to the LED on the flow sensor, making it clear why battery operation is impractical. At 2000ms intervals, with both sensors installed, average current is 29.477mA. With just the humidity/temperature sensor installed, this falls to 1.6891mA, with the background closer to 1mA which suggests the ZWIR4512 is sitting with the radio off but not in its deeper standby/sleep modes. This suggests there could be room for further improvement, especially as the I2C and radio indicator LEDs were also observed to consume about 2.5mA each.

With the duty cycle changed to 1000ms intervals, the current increased to 30.166mA and 2.3118mA. At 500ms, the module reported about every 110ms and consumed 43.778 and 16.249mA respectively. The difference is mainly due to the quiescent draw versus the peak draw.

Looking at the current profiles closely, it appears that the unit wakes up and spends about 40ms on I2C communications, followed by two spikes for communication. The current draw did not change much with voltage, peaking in the 28-30mA ball-park.

Decoding the I2C bus makes clear that the unit seems to query the Flow Sensor in an undocumented way, perhaps to determine its model, followed by waking the temperature sensor for a measurement. It waits a fixed period of time (about 35ms) before reading the values from the temperature sensor, followed by the flow sensor. This amount of time is longer than the 17ms claimed by the datasheet, resulting in excess energy consumption. Only reading three-bytes of results means the LSB data for the temperature is lost, limiting the resolution to 0.64457059 degrees Celsius rather than the datasheet stated 0.015 degrees Celsius that the sensor is capable of. This seems to be a rather unfortunate tradeoff. No other addresses were seen to be queried by the bus, thus only these families of sensors from IDT are supported without modification.

For more information, see IDT SDAWIR03 RoadTest-in-Depth: Ch7 – Power & I2C Testing

Conclusion

The IDT SDAWIR03 Wireless Flow Rate, Humidity and Temperature Sensing Evaluation Kit features the ZWIR4512 6LoWPAN Wireless Module, FS2012-1010-NG Gas Flow Sensor and HS3001 Relative Humidity and Temperature Sensor from IDT packaged in an attractive, professional-looking hub and sensor-cube form factor. The hub is powered by a Raspberry Pi Zero-W with a custom-made hat, whereas the sensor-cube is bespoke with the provision to be powered from either USB or two CR2032 lithium coin cells. The system is designed to provide readings of relative humidity, temperature and gas flow rate to local viewers via an HTML interface and to the Amazon Web Services cloud (the latter of which, I did not test).

The main drawcard of 6LoWPAN networks is that nodes can be accessed as if they were on a regular IPv6 network with gateways that require only limited resources. This makes sensor nodes appear as if they are on your network, simplifying application development in not requiring translation using a gateway between protocols. The standard is also open and the equipment follows a private ownership model which ensures cost of operation is kept in check. Some level of interoperability may exist although unlike Wi-Fi or Bluetooth, there are many radio bands and physical modulations/rates used by 802.15.4-compliant radios thus not every 6LoWPAN module would be interoperable. Each stack often has some deviations from the RFCs due to computational limitations, with the IDT product being of no exception.

The kit was easy to set-up, being a relatively plug-and-play experience with intuitive flow. The functionality was, however, relatively limited to displaying 600s of readings with no other features for data exporting by default. Documentation was rather light, consisting of a single publicly available user manual which mostly detailed procedural steps in set-up with no technical details such as schematics, code or bill-of-materials which would make it useful for hardware developers to customise the design to their needs. Likewise, the manual omits any documentation regarding the software, its components and how they work together or can be customised. There is no documentation included within the package bar a disclaimer, with other documents (presumably) available through direct contact (although none have yet been furnished despite enquiring along with some other questions via @rscasny). If they were concerned about the documentation being publicly available, the least they could do would be to slip in a CD-ROM with the documents, source code and design files.

The lack of documentation leads to a frustrating user experience for those who want to truly understand and perhaps develop with the kit. Despite the claims of being easy to adapt to other 3.3V I2C devices, there is no method by which to do this at the present time. For those who want more than just to see the readings, they have to do their own time-consuming “reverse engineering” of their own demo kit, whereas such kits are usually provided to save development time. This also leads to potential dangers for users of the demo kit who are unaware that the unit comes with default passwords, continues to broadcast an unencrypted demo network despite joining an access point and could be a network relay vector into a secure network. Even the advice of being able to just “remove power” from the hub without any shutdown sequence seems misguided, especially as there is no publicly available software image to restore from if the included microSD card becomes corrupted.

At the end of the day, a demo kit is supposed to be something that impresses - something that shows off the technology of a company in its best light, perhaps pushing the boundaries in some way. Unfortunately, in the case of the SDAWIR03, it seems this is not the case as the design of the kit has several noteworthy deficiencies. The first is the inability of the kit to take advantage of the full temperature resolution the HS3001 sensor has to offer by ignoring the LSB from the sensor entirely. The second would be the flow sensor’s tendency to create spikes in reading during zero flow conditions, which comprises as much as 8% of the read values, which is not what I would consider normal. Thirdly, it seems the radio antenna design of the kit is highly sub-optimal, with a range of just 4m achieved which is below that of Wi-Fi despite the link budget calculations suggesting they should be similar or better. This would lead to a (mis)understanding that one may need many more nodes to cover the same area, making their 6LoWPAN modules appear unattractive. The build quality of the hub’s “hat” PCB was also quite poor with a misaligned drill layer. As a minor point, the user interface does have a few typos including the name of their sensor (H3001 instead of HS3001) and sensor “caputre” service.

In addition, while the modules themselves are capable of legal operation in many 915/920MHz band countries, the coding chooses just one channel (906MHz) which is illegal in most non-American countries, limiting the appeal of the kit. Attempts to remedy this by altering the code result in broken web interfaces and a discovery that the cube firmware is restricted to just two channels (one in each locale) for battery optimisation reasons. As a result, the module is not able to fully demonstrate its flexibility in this regard either.

A closer look at the power consumption characteristics appears to show the design may not even make use of the most energy-saving states, with a measured quiescent current draw about 1mA which is considered fairly high. The active time also appears to be longer than absolutely necessary, waiting 35ms for a temperature sensor conversion that is claimed to be complete in 17ms by the datasheet. The addition of bright indicator LEDs also adds to current draw, thus even the battery life achieved of close to nine-days is probably far short of what the module is capable of.

As a result, in my opinion, the SDAWIR03 does not meet my expectations of what a demo kit should be and is probably a poor option for those interested in any of the components or technologies. For those interested in the ZWIR4512, perhaps they should choose the ZWIR4512-KIT which is a full development board package consisting of three nodes with full documentation of schematics, protocol information and software. In this way, there is full liberty in the configuration and performance optimisation, as the SDAWIR03 is not convenient to perform modifications, measurements or development with. For those interested in the sensors themselves, they could perhaps just buy them individually and prototype them with any microcontroller they intend to use as the target platform – this way they are not limited by the accuracy and sample rate limitations of the kit. One may perhaps think that the kit is suitable for those interested in cloud-based data acquisition using AWS, however, the lack of clear documentation on how the software works and can be customised leaves this as only a “pretty demo” that doesn’t do much to short-cut your development time or add value to your design.

But more than this, I think it’s important to consider the heritage of the ZWIR4512. It was already on the market in 15^th April 2013, making the module six years old, still carrying the ZMDI branding when they were acquired by IDT in 2015 who were themselves acquired by Renesas in 2018. Being an “older” device potentially puts it at risk of discontinuation which would result in re-engineering costs for designs and potential interoperability issues as they migrate to another module. While there are not many 6LoWPAN modules around, one prominent unit is newer (introduced 2018), smaller, cheaper and with wider band support and a higher performance microcontroller which almost makes it a no-brainer (at least on paper as I have not evaluated its performance in person, nor received any equipment using this particular module). It is also worth remembering that other options exist including using other 802.15.4-compliant RF modules with a software stack running on a microcontroller. This latter approach may require more engineering effort, but opens up many more options.