In this blog post, I will be focusing on the documentation supplied with the SDAWIR03 and the set-up process. Note that I will not be covering the Amazon AWS Cloud side of operations as I don’t currently have an account with them (and don’t wish to), but also as my RoadTest application clearly excluded this on the account that other more experienced software-developers would cover it.
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. The user manual generally consists of directed instructions, but very little in the way of explanation of how things work or how to accomplish some of the claims in the document – e.g. “The Cube can be expanded to operate with other 3.3V I2C capable sensors” but how? The manual also makes some rather poor suggestions, claiming that it’s fine to remove power from the hub without any special commands (which, in my experience, is not the best way to work with a Linux-based SBC).
There is also no publicly available schematic and the design of the cube does not appear to lend itself to easy testing or evaluation of key module and sensor parameters. While it may be a demonstration kit, it makes evaluation of the module and sensors less convenient than it could be. Furthermore, there is no documentation on the software provided in terms of adapting it to end user applications, what modules are involved and how they work together. There also seems to be no image to download to restore the microSD card, so it’s probably best to image the card prior to first use in case it is damaged. Additional information is said to be available on request but has not been furnished to me at this time. As a result, I think the benefit to purchasers of the kit is more limited than it could otherwise be.
This is a little disappointing for a kit that retails for AU$293.78 + GST from element14, which I would consider rather expensive. I suppose once you realise the FS2012 sensor on its own for AU$146.21 + GST and the HS3001 costs AU$9.34 + GST, it doesn’t seem as big of an expense, but it’s still not cheap.
There is additional documentation available for the ZWIR4512 module, but the majority of the information about programming and development relate to the ZWIR4512-KIT which is a development kit that is perhaps better suited to those looking to develop with the module than the SDAWIR03. Some of the information requires registration of an IDT account, which is a slight inconvenience. Datasheets are also available for the HS3001 and FS2012 sensors, although the datasheets seem a little light on content.
As a result, I am not sure exactly to whom the SDAWIR03 is pitched at. 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. Finally, 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.
Setup Process and Basic Operation
The setup process begins with plugging the power supply into the wall and the hub into the power supply, waiting three minutes for the system to complete the boot-up process. At this time, an unencrypted Wi-Fi network named ISG-Demo will appear.
Once joining the network with a computer or mobile device, navigating to http://demo.isg will load the home page. As the unit has never been set-up, we are prompted to select either EU or US region. Note that there are only two selections (more about this in the Radio Testing section). Applying this setting can take half-a-minute or so.
By now, you reach the home screen, which is likely to be blank, as follows.
This is because no sensor cube has registered with the base. The other menus are accessible by hovering over the top.
Plugging in another power supply into the wall and plugging it into the cube with the power source set to USB will allow the sensor to connect and data plotting will commence. The sensor graphs can be zoomed in and out with the scroll wheel, with a maximum plot time of 600 seconds.
Interesting to see that they even have the model number of their own humidity and temperature sensor wrong - it should be HS3001 rather than H3001.
Toggling to the second page on the Sensor View shows the list of events.
The sensor settings can be configured using the cog button, which allows for renaming the sensor and setting the transmission policies for USB and battery operation. When operating by battery, the plug icon is replaced by a battery icon.
The Network Configuration page shows the network connection status and allows you to configure a connection to a Wi-Fi network with internet access. This is necessary for the AWS system to work and also allows for accessing the HTML pages via your own network.
Finally, there is the AWS configuration page which is used if testing the AWS capabilities. As this review is not concerned with the AWS functionality, this page was not used.
Of note is that connecting the hub to a display and keyboard/mouse does not provide much that couldn’t otherwise be done via the Wi-Fi. The unit boots into a plain graphical desktop with no special IDT-specific programs installed that I could see. There is an installation of NodeRED but there is no flow pre-configured. Use of the device head-less is all that is necessary – there is really no need to attach a display or keyboard/mouse.
Testing & Modification
One of the advantages of 6LoWPAN is its “transparent” IP-based nature. In order to test this, I decided to try pinging the sensor. Initially, this did not succeed as it turns out that the radio needs to be in “always on” mode (e.g. powered via USB) for this to happen and the ping needs to be addressed to the IPv6 address with the link identifier appended (%zwir0).
I thought I’d run a nmap scan of the Raspberry Pi hub just to see what was running:
PORT STATE SERVICE VERSION
22/tcp open ssh (protocol 2.0)
53/tcp open domain dnsmasq 2.76
80/tcp open http Apache httpd 2.4.25 ((Raspbian))
111/tcp open rpcbind 2-4 (RPC #100000)
8888/tcp open sun-answerbook?
18081/tcp open unknown
43998/tcp open unknown
43999/tcp open unknown
53/udp open domain dnsmasq 2.76
111/udp open rpcbind 2-4 (RPC #100000)
123/udp open ntp NTP v4 (unsynchronized)
It seems there are quite a few services running, some of which are not entirely obvious. Use of port 18081, 43998 and 43999 are not known.
It seems that autobahn-python is used to serve the data as a Websockets server running on port 8888.
Care should be taken with the services running, as the SSH still uses the Raspberry Pi default credentials.
This seems particularly dangerous, as even after joining the unit to my personal Wi-Fi, the unencrypted ISG-Demo continued to be broadcast and could still be accessed. If the SSH credentials were not changed, there is a potential for the system to become a network relay. I suggest changing /etc/hostapd.conf from the illustrated defaults to add a password.
With the provided HTML interface, there is not much that can be done with the data as a plot of only the previous 600 seconds of data can be made. As a result, I decided it would be worth exploring how to export the data from the sensor. This led me to find a number of important programs in /usr/local/bin/isg including the main sensor-capture program. By modifying the sensor-capture Python program, I added a UDP output of the raw sensor JSON to my desktop allowing me to capture the data from the demo kit without using the Amazon AWS connection.
Modifications will require a restart of the service with sudo service sensor-capture restart, although if you made a mistake, the service may not be able to start resulting in an error displaying in the HTML interface. Instead, it may be worthwhile to run the process interactively in the terminal so that exceptions are printed. Note that the word "capture" is misspelt in this error message.
Channel configurations were discovered to be stored in /etc/default/zwir-conf-ch although modifications did result in problems as the cube firmware appears to have a limitation of two pre-selected channels and the hub software would not accept the region as having been set. Web interface files were found in /var/www and executables in /usr/lib/cgi-bin. There are also some unrelated libraries in the home folder. Modifications are at your own risk as IDT do not provide any publicly available restore image. Not having any documentation in this regard has cost a number of hours of experimentation to attempt to understand what is being done.
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.
This blog is part of the IDT SDAWIR Wireless Flow Rate, Humidity and Temperature Sensing Evaluation Kit RoadTest