ZigBee is a low-power communication system using digital radios. It’s intended to be easier to work with than Bluetooth. Adafruit recently added an adapter board for Digi’s XBee product line and has put together a great how-to to show the devices potential. Using two XBee radios and adapters you can wirelessly program an Arduino board. This would be great if your Arduino was installed in an inaccessible area or maybe it’s over 100feet away from where you’re working. The radios do serial communication just fine. What the how-to covers is getting the reset line working so the Arduino can restart automatically after you program it. Once the radio pair is configured properly, it will pass the RTS line state directly from one device to the other.
Crash IoT Devices Through Protocol Fuzzing
IoT protocols are a relatively unexplored field compared to most PC-exposed protocols – it’s bothersome to need a whole radio setup before you can tinker on something, and often, for low-level experiments, just any radio won’t do. This means there’s quite a bit of security ground to cover. Now, the U-Fuzz toolkit from [asset-group] helps us make up for it.
Unlike fuzzers you might imagine, U-Fuzz doesn’t go in blindly. This toolkit has provisions to parse protocols and fuzz fields meaningfully, which helps because many of devices will discard packets they deem too malformed. With U-Fuzz, you feed it a couple packet captures, help it make some conclusions about packet and protocol structure, and get suggestions on how to crash your devices in ways not yet foreseen.
This allows for basically arbitrary protocol fuzzing, and to demonstrate, we get examples on 5G, CoAP and ZigBee probing alike, with a list of found CVEs to wrap the README up. As Wikipedia often states, this list is incomplete, and you can help by expanding it. Fuzzing is an underestimated tool – it will help you hack ubiquitous wireless protocols, proprietary standards, and smart home hubs alike.
Wireless All The Things!
Neither Tom Nardi nor I are exactly young anymore, and we can both remember a time when joysticks were actually connected with wires to the computer or console, for instance. Back then, even though wireless options were on the market, you’d still want the wired version if it was a reaction-speed game, because wireless links just used to be too slow.
Somehow, in the intervening years, and although we never even really noticed the transition as such, everything has become wireless. And that includes our own hacker projects. Sure, the ESP8266 and other WiFi-capable chips made a big difference, but I still have a soft spot in my heart for the nRF24 chipset, which made at least point-to-point wireless affordable and easy. Others will feel the same about ZigBee, but the point stands: nothing has wires anymore, except to charge back up.
The reason? As this experiment comparing the latency of many different wireless connections bears out, wireless data links have just gotten that good, to the point that the latency in the radio is on par with what you’d get over USB. And the relevant software ecosystems have made it easier to go wireless as well. Except for the extra power requirement, and for cases where you need to move a lot of data, there’s almost no reason that any of your devices need wires anymore.
Are you with us? Will you throw down your chains and go wireless?
Benchmarking Latency Across Common Wireless Links For MCUs
Although factors like bandwidth, power usage, and the number of (kilo)meters reach are important considerations with wireless communication for microcontrollers, latency should be another important factor to pay attention to. This is especially true for projects like controllers where round-trip latency and instant response to an input are essential, but where do you find the latency number in datasheets? This is where [Michael Orenstein] and [Scott] over at Electric UI found a lack of data, especially when taking software stacks into account. In other words, it was time to do some serious benchmarking.
The question to be answered here was specifically how fast a one-way wireless user interaction can be across three levels of payload sizes (12, 128, and 1024 bytes). The effective latency is measured from when the input is provided on the transmitter, and the receiver has processed it and triggered the relevant output pin. The internal latency was also measured by having a range of framework implementations respond to an external interrupt and drive a GPIO pin high. Even this test on an STM32F429 MCU already showed that, for example, the STM32 low-level (LL) framework is much faster than the stm32duino one.
Continue reading “Benchmarking Latency Across Common Wireless Links For MCUs”
802.11ah Wi-Fi HaLOW: The 1 Kilometer WiFi Standard
The 802.11ah WiFi (HaLow) standard is fairly new, having only been introduced in 2017. It’s supposed to fall somewhere between standard WiFi used in domiciles and offices and the longer range but low-bitrate LoRaWAN, ZigBee, and others, with bandwidth measured in megabits per second. In a recent video, [Ben Jeffery] looks at the 802.11ah chipsets available today and some products integrating these.
The primary vendors selling these chipsets are TaiXin Semiconductor (TXW8301), Morse Micro (MM6108), and Newracom (NRC7394), with a range of manufacturers selling modules integrating these. Among the products using these, [Ben] found an Ethernet range extender kit (pictured) that takes 12V input as power, along with Ethernet. Running some distance tests in a quarry showed that 300 meters was no problem getting a strong signal, though adding some trees between the two transceivers did attenuate the signal somewhat.
Another interesting product [Ben] tested is what is essentially an 802.11ah-based WiFi extender, using an 802.11ah link between the server node – with an Ethernet socket – and a client that features a standard 2.4 GHz 802.11n that most WiFi-enabled devices can connect to. Using this, he was able to provide a solid ~10 Mbps link to a cabin near the main house (~10 meters) through two outside walls. What makes 802.11ah so interesting is that it is directly compatible with standard Ethernet and WiFi protocols and uses the 900 MHz spectrum, for which a wide range of alternative antennae exist that can conceivably extend the range even more.
(Thanks to [Keith Olson] for the tip)
Continue reading “802.11ah Wi-Fi HaLOW: The 1 Kilometer WiFi Standard”
Bed Sensors Do More Than You’d Think
Bed sensors do sort of sound like a gimmick — after all, who cares whether someone is occupying the bed? But if you think about it, that information is quite useful from a home automation standpoint. A person could do all sorts of things in this state, from ensuring the overhead lights in the room can’t come on, to turning off other smart devices that are likely not being used while both occupants are sleeping.
[The Home Automation Guy] presents a couple of ways of doing this, but both center around a fairly inexpensive pressure-sensing mat.
In the first method, he connects the pressure mat up to a Zigbee Aqara Leak Sensor, which conveniently has two terminals on the back to accept the wires from the pressure sensor. Then he simply connects it up to a Zigbee-compatible home assistant like the Aqara Hub.
In slightly harder mode, he forgoes the Aqara Leak Sensor and connects the pressure mat up to an ESP32 using a nifty screw terminal dev board. Then he sets up the sensor and all the desired actions in ESPHome. Of course, with an ESP32, it’s easy to add a second pressure mat for [Mrs. The Home Automation Guy]’s side of the bed.
Now, once they’ve both gone off to bed, the house goes into night mode — all the smart plugs, Sonos devices, and other things are powered down, and the alarm system is put into night mode. Be sure to check out the build video after the break.
Wireless Data Connections Through Light
When wired networking or data connections can’t be made, for reasons of distance or practicality, various wireless protocols are available to us. Wi-Fi is among the most common, at least as far as networking personal computers is concerned, but other methods such as LoRa or Zigbee are available when data rates are low and distances great. All of these methods share one thing in common, though: their use of radio waves to send data. Using other parts of the electromagnetic spectrum is not out of the question, though, and [mircemk] demonstrates using light as the medium instead of radio.
Although this isn’t a new technology (“Li-Fi” was first introduced in 2011) it’s not one that we see often. It does have a few benefits though, including high rates of data transmission. In this system, [mircemk] is using an LED to send the information and a solar cell as the receiver. The LED is connected to a simple analog modulator circuit, which takes an audio signal as its input and sends the data to the light. The solar cell sends its data, with the help of a capacitor, straight to the aux input on a radio which is used to convert the signal back to audio.
Some of the other perks of a system like this are seen here as well. The audio is clear even as the light source and solar cell are separated at a fairly significant distance, perhaps ten meters or so. This might not seem like a lot compared to Wi-Fi, but another perk shown is that this method can be used within existing lighting systems since the modulation is not detectable by the human eye. Outside of a home or office setting, systems like these can also be used to send data much greater distances as well, as long as the LED is replaced with a laser.
