Say you’ve got a neat gadget you are building. You need to send data to it, but you want to keep it simple. You could add a WiFi interface, but that sucks up power. Bluetooth Low Energy uses less power, but it can get complicated, and it’s overkill if you are just looking to send a small amount of data. If your device has a microphone, there is another way that you might not have considered: ultrasonic communications.
The idea of using sound frequencies above the limit of human hearing has a number of advantages. Most devices already have speakers and microphones capable of sending and receiving ultrasonic signals, so there is no need for extra hardware. Ultrasonic frequencies are beyond the range of human hearing, so they won’t usually be audible. They can also be transmitted alongside standard audio, so they won’t interfere with the function of a media device.
A number of gadgets already use this type of communications. The Google Chromecast HDMI dongle can use it, overlaying an ultrasonic signal on the audio output it sends to the TV. It uses this to pair with a guest device by sending a 4-digit code over ultrasound that authorizes it to join an ad-hoc WiFi network and stream content to it. The idea is that, if the device can’t pick up the ultrasound signal, it probably wasn’t invited to the party.
We reported some time ago on an implementation of ultrasonic data using GNU Radio by [Chris]. His writeup goes into a lot of detail on how he set the system up and shows a simple demo using a laptop speaker and microphone. He used Frequency Shift Keying (FSK) to encode the data into the audio, using a base frequency of 23Khz and sending data in five byte packets.
Since then, [Chris] has expanded his system to create a bi-directional system, where two devices communicate bi-directionally using different frequencies. He also changed the modulation scheme to gaussian frequency shift keying for reliability and even added a virtual driver layer on top, so the connection can transfer TCP/IP traffic. Yup, he built an ultrasonic network connection.
His implementation underlines one of the problems with this type of data transmission, though: It is slow. The speed of the data transmission is limited by the ability of the system to transmit and receive the data, and [Chris] found that he needed to keep it slow to work with cheap microphones and speakers. Specifically, he had to keep the number of samples per symbol used by the GFSK modulation high, giving the receiver more time to spot the frequency shift for each symbol in the data stream. That’s probably because the speaker and microphone aren’t specifically designed for this sort of frequency. The system also requires a preamble before each data packet, which adds to the latency of the connection.
So ultrasonic communications may not be fast, but they are harder to intercept than WiFi or other radio frequency signals. Especially if you aren’t looking for them, which inspired hacker [Kate Murphy] to create Quietnet, a simple Python chat system that uses the PyAudio library to send ultrasonic chat messages. For extra security, the system even allows you to change the carrier frequency, which could be useful if the feds are onto you. Whether overt, covert, or just for simple hardware configuration, ultrasonic communications is something to consider playing around with and adding to your bag of hardware tricks.