|Long Range Wi-Fi With Just Software|
|Written by Harry Fairhead|
|Saturday, 26 October 2019|
Researchers have developed a software-only way of extending the range of standard Wi-Fi. Don't get too excited, the transmission rate is far too slow for Netflix, but it could still be useful for sensor networks.
Wi-Fi is everywhere and it seems to be that a radio transmitter and receiver in every device is too good to ignore. But, and we all know this, the range of Wi-Fi is limited. Get a little too far from the access point and the data rate drops and then finally the device drops off the network. The reason is that Wi-Fi is a complex protocol and it requires good signal strength to work at all.
There are a lot of situations where a lower data rate would be acceptable if the range could be increased. There are hardware implementations of long-range, low-power radio links, such as loRa, but they need special hardware and hence cost more. A group of researchers from Brigham Young University, Washington University and the University of Utah set themselves the challenge of implementing a long-range communication method using nothing but standard Wi-Fi hardware and some special software. They also included the condition that the new method shouldn't disrupt the normal operation of the Wi-Fi. This is a difficult set of conditions and exactly how they did it might inspire you to think of your own modification or application.
For the transmitters they tried out a Raspberry Pi and an ESP8266, but they found that the timing variation on the Pi was too great for their intended methods and so settled on the ESP8266. This was attributed to the fact that the Pi was running a full Linux and this caused the program to be interrupted by other threads. It is a shame that the team didn't try some of the standard techniques to make sure a thread runs uninterrupted on a Pi - by giving it a core to itself or by using Earliest Deadline First scheduling. As I explain in Raspberry Pi IoT in C, the Pi's timing variation is real, but also easy to minimize. Details of the scheduling required are currently in Applying C For The IoT With Linux.
After settling on the ESP8266, the team led by Phil Lundrigan were able to use the published Wi-Fi API to send beacon frames. These are standard Wi-Fi frames and are ignored by Wi-Fi devices close enough to receive them.
The idea is not that the beacon frames are carrying data - they are the data. Think of this as a sort of upmarket Morse code. A beacon frame is sent to represent a one and an absence of a beacon frame is a zero. A code and a known pseudo random number are sent as intermittent beacon frames to make it easy to identify the frame sequence using correlation.
OK, that's the transmitter worked out, now what about the receiver? This used an off-the-shelf access point (AP) but using the open source DD-WRT firmware. This doesn't count as a hardware modification because it's easy and widely supported.
How does the receiver make use of the beacon frames?
The transmitter is assumed to be too far away for the AP to receive any frames from it so direct detection of the beacon frame is out of the question. Instead what happens is that the standard API facility to measure the noise background is used. When the remote transmitter is sending a beacon frame this isn't picked up strongly enough to be decoded and treated as a signal. Instead it simply increases the background noise. By looking for changes in the background noise and the known pseudo random pattern, the receiver can confirm that the transmitter is on the air and it can even extract a little data, although with data rates of around 0.5 bits per second, not a great deal but it could be enough.
Distances are typically 100 to 250 meters depending on the terrain and obstacles. The technique is called ONPC, On-Off Noise Power Communication, and it turns the usual communications paradigm on its head - the noise is the message!
The team implemented a Stayin' Alive system using the technique which enabled them to determine that a remote sensor was still functioning even though Wi-Fi connection had been lost for a while.
The only downside is that I can't locate the team's code. Let's hope they put it up on Github. This is an idea that could almost certainly be developed.
or email your comment to: firstname.lastname@example.org
|Last Updated ( Saturday, 26 October 2019 )|