In this blog, I will look at the characteristics of the radio emissions from the IDT ZWIR4512 6LoWPAN modules. For testing, the module region has been set to US with 10 channels as this is seemed most appropriate for Australia where ISM operation in the 915-928MHz band is permitted. The EU region has just 1 channel with an extra 4 extension channels in the 868MHz band, which is not legal for use in Australia and thus was not tested. No other regions are offered by the IDT SDAWIR03 kit at this time. Spectrum analysis was performed with a Tektronix RSA306 Real-Time Spectrum Analyser with a N to BNC adapter and dipole antenna.
Radio Range Testing
The first thing I wanted to know was the range of the SDAWIR03’s sensor cube. Starting with the hub in a fixed indoor location and the cube right above it, I moved the sensor cube away in 1m increments noting the reported RSSI until the cube lost connection with the hub.
Rather disappointingly, the cube only achieved 4m of distance before dropping out. This is despite being radio-quiet in the band of operation (noted later). The theoretical sensitivity of the module ranges from -101dBm to -110dBm depending on operating region and modulation. This suggests that perhaps 5m would be possible assuming BPSK was used with very little link margin remaining.
This level of range is particularly disappointing, as this is even less than what Wi-Fi or even Bluetooth regularly offers. As a result, to reach equivalent coverage with this design will require many more nodes operating in a mesh.
I suspect IDT’s design may be at fault here, as the radios are capable of 10±3dBm output (which is less than but close to the 17-30dBm if most Wi-Fi cards). Considering the sensitivity is about 10dB better than Wi-Fi, and the better propagation characteristics of the 915MHz-band in general, we would expect the difference in transmission power to be largely mitigated and the range to favour the sub-GHz devices.
This is very much backed-up by the measurements. At zero meters, the RSSI was -50dBm which suggests that there was a loss of 60dB between the transmitting cube and the receiving hub already. With Wi-Fi devices in the same situation, I’ve measured -12dBm which is a loss of closer to 29dB. This suggests to me that there is something sub-optimal regarding the antenna design which is either causing the hub to be rather “deaf”, or causing the cube to transmit poorly. This could be due to poor antenna geometry, PCB-to-PCB variations, incorrect impedance matching, metal labels near the antenna, amongst other variables.
Emission Characteristics
Wanting to understand the sort of signal that was being emitted from the ZWIR4512, I set the spectrum analyser to view the relatively-quiet 915Mhz band.
It was determined that the cube and hub were operating on 906MHz. With the report rate set to 2000ms intervals, the recorded transmission burst interval times were slightly longer, at 2216ms on average.
It appears that each report consisted of two radio bursts was about 15-18ms in length, spaced apart by around 24ms.
When viewed on a 2MHz span, it seems that the signal occupies roughly half, or about 1MHz of bandwidth judging by eye. The Occupied Bandwidth module suggests the 99% power is contained within 800kHz, and 3dB bandwidth is 362kHz, but this may not be too accurate due to the spiky nature of the signal.
Channel Support
Unfortunately, even after several reboots of the cube and hub, the system was not persuaded to change channels. The unit remained on 906MHz which is a problem as operation on this frequency is illegal in Australia as it is part of the commercial mobile telephone service (CMTS) band. Looking at the spectrum analyser, the band is rather quiet and seemingly not used, but it may be an uplink channel thus quietness is to be expected and continued operation of the ZWIR4512 module in this configuration may degrade the communications quality for mobile phone users. This is unlikely due to low transmission power, but to avoid inconveniencing others and potential litigation, it’s important to use only frequencies you are licensed to use and adhere to the license conditions.
It was determined that through /etc/default/zwir-conf-ch that the operating channel could be set for the zwir-tap service. The modulation and power could be set in zwir-tap but I'm not certain they are adhered to.
Changing this value did appear to do something – namely it seemed to break the IDT HTML interface as now it became confused about the region.
Instead, I found it easier just to stop all the zwir-tap services, and invoke the zwir-tap program manually, requesting a channel number on the command line. Here, it is visible that the channel has been changed and the hub is now on a legal frequency. Unfortunately, the hub did not follow which is contrary to what the manual had stated.
Using the peak-hold feature of the spectrum analyser and stepping through the supported channels, it can be seen that the channels start at 906MHz and are spaced by 2MHz with a total of 10 channels.
Through enquiry with the manufacturer, it appears that the cube firmware is configured to scan just two channels, one in each region, to save battery life in case of loss of contact with a hub. Unfortunately, their choice of channel makes it illegal to operate the SDAWIR03 kit in many countries including Australia despite the ZWIR4512 module being capable of operating at the correct frequencies and power levels. This is very unfortunate and limits the appeal of the SDAWIR03 kit to those in the EU and US (North America, Mexico, Brazil) regions only.
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.
Conclusion
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.
---
This blog is part of the IDT SDAWIR Wireless Flow Rate, Humidity and Temperature Sensing Evaluation Kit RoadTest
Top Comments