The Sound of Silence: The Obscure Black Magic of Network Transmission
Last week I interviewed an Android engineer from Russia. A real geek — he had done deep reverse engineering on the binary format of Office files (not the later XML format). At Yandex he had worked in product rather than as an engineer — in his own words, Yandex’s bar for engineers was too high, he tried three times and failed all three, so he had to settle for product. Of course, this article isn’t about this guy, but about a product made by AliveCor, the company he now works for.
It’s a medical product (Electrocardiography, EKG) that monitors heart rate to predict potential disease risks (such as stroke). It consists of a small piece of hardware (a sensor) and an app on your phone. The basic principle: open the app, press two fingers from each hand onto the sensor for about 30 seconds, and the sensor sends your real-time heart rate to the phone; the app then uses a pre-generated machine-learning model (just a few megabytes to a few tens of megabytes) from the server to predict potential heart conditions. I gave it a try, and unsurprisingly, my heart is perfectly normal (applause here, please).
From a software perspective, the principle behind this product isn’t complicated; what’s complicated is the sample analysis and screening, the selection and tuning of machine-learning algorithms, and the construction of the model. As for the app itself, its implementation isn’t especially hard either — what’s hard is how to transmit information from the sensor to the phone. As you can see from the image, the sensor is very thin and small: its thickness barely exceeds that of a slim, flat coin-cell battery, and its overall size is just a tad bigger than the area covered by four fingers pressed on a table.
My first reaction was that it used a chip like the electric imp. I introduced it long ago in an article about the Lockitron; its website is electricimp.com — go look at its tech spec if you’re interested. On a PCB the size of an SD card, it implements an entire WiFi protocol stack. Unfortunately, the interviewee answered “no.” I probed further with Bluetooth and ZigBee — also no. He said they use a proprietary protocol that runs directly on the transport layer, requiring no connection setup; the sensor one-way broadcasts the heart-rate information it detects to its surroundings, so battery standby can last up to 12 months. But he couldn’t disclose the specifics.
After the interview, still curious, I explored AliveCor’s website further but didn’t find much useful information. Rereading my earlier article on the electric imp, it suddenly occurred to me: could it be using a technology similar to blinkUp?
We know that exchanging information (configuration data, say) over short distances between IoT devices without relying on existing complex technologies is a hard problem. Take the electric imp: this chip gives IoT devices simple, reliable WiFi connectivity, letting them connect to the internet and receive and process commands from the cloud — very powerful. Yet before it can work, getting the SSID and password of the network it needs to join into the chip is a big problem. IoT devices generally lack input/output systems like a keyboard and mouse; voice control is still in its early days and expensive, and adding a voice-control chip just for a one-time configuration is not worth it. So electric imp developed blinkUp, which uses visible light to exchange information. In fact, using visible light to transmit information has a very long history — the beacon towers of antiquity, the semaphore flags of today, traffic lights all use visible light. BlinkUp encodes digitized information (such as WiFi SSID / password) into the flickering of a phone screen; the electric imp chip receives this flickering signal, decodes it, and recovers the original data. It looks rather clumsy, but it works reasonably well in practice.
However, while using the AliveCor sensor, I didn’t see any similar signal-transmission mechanism.
If it’s not light, then what other channel could broadcast information from the device and be received normally by a phone? The answer I could think of is sound. Phones have microphones that can pick up ambient sound, and it isn’t hard for the sensor to emit sound either — just add a chip that supports audio encoding. The problem is, during use I didn’t hear any sound either. Could it be some kind of ultrasound?
Following this line of thought, I googled “encode info in sound” and quickly found the product Chirp, and from there similar competitors: LISNR and Google Tone.
On its “how chirp works” page, Chirp says:
There are lots of different ways to embed and extract meaning from a piece of sound. Chirp uses audio data encoding — or modulation/demodulation. Data is encoded into a series of pitches and tones on the sending device, and decoded on the receiving device.
Its further description also mentions inaudible ultrasound. The advantage of ultrasound is that human ears can’t hear it, so it produces no noise, making it convenient for devices to “whisper” to each other.
Looking back, this technology isn’t really new — before the broadband era came the modem era. The 9.6k/14.4k/28.8k/56k “cats” (the Chinese slang for modems) “modulated” digital information into analog signals, transmitted them over a phone line to the other end of the network, and at the same time “demodulated” incoming analog signals back into digital information. And the analog signals traveling over the phone line are sound-wave signals — early internet users probably still remember the chaotic, unpleasant dial-up sounds when connecting. The difference is that modems work on the internet; for the sake of generality, they only handle the physical and link layers, while the network and transport layers are handled by IP and TCP/UDP. In AliveCor’s scenario, on the other hand, a Chirp-like technology works all the way from the physical layer up to the transport layer.
Since products like Chirp haven’t disclosed their implementation principles in any further detail, let me hazard a guess:
Physical layer: the chip converts the signal to be sent into sound waves and broadcasts them into the surroundings. At this layer, you need to decide whether the signal gets converted into audible sound or ultrasound.
Link layer: the start and end of a data frame need some kind of delineation, plus error tolerance. Let’s draw an analogy with Ethernet:
An Ethernet frame has a preamble and an SFD (start frame delimiter). The preamble tells the receiver that a new frame is about to begin, and the SFD marks the official start of the frame’s data. After that come the Ethernet header and payload, and finally the FCS (frame check sequence), which is used for CRC checking.
For AliveCor’s use case, the leading preamble + SFD and the trailing FCS of an Ethernet frame are both very necessary, while the header’s src MAC / dst MAC / type are decided as needed. The src MAC can be the sensor’s own serial number or device ID; the dst MAC isn’t even needed, because sound only supports one-way broadcast. The type field is optional — for extensibility’s sake, you might keep a byte or two.
Network layer: the use case doesn’t need routing or forwarding support.
Transport layer: there’s not much need for multiple channels between a pair of devices, so you can just transmit the payload directly.
As for data encryption, that’s entirely a matter for the application layer, which has full control.
By this reasoning, AliveCor’s complete solution might look something like this:
- The sensor integrates the audio-processing chip described above. When fingers press down, the sensor wakes from standby and starts working — encoding the collected heartbeat information into ultrasound and broadcasting it out (the information may be lightly encrypted, or not encrypted at all, since this scenario is relatively private and secure, and sound’s coverage is only a few meters).
- The app on the phone must stay open so it can keep listening for and decoding the signals coming through the microphone. Once a frame’s preamble / SFD is detected, the decoded data that follows is heartbeat data; if the check passes, record it; otherwise skip it. AliveCor asks for 30 seconds of finger pressure — you don’t actually need to sample for that long, but given that the sensor and the app aren’t necessarily synchronized, some data may be lost at the start, and bad packets may occur during transmission (say, from various other ultrasonic interference, though the odds should be very, very small), the app needs to collect more data than is actually needed.
- When fingers stop pressing, the broadcast stops. The sensor goes into standby to save power.
Using sound for short-range information transmission has many applications in the IoT world, such as initial pairing between devices, payments, identity verification (e.g., ticket validation), and so on. Payments and identity verification have other mature technologies, but the initial-connection scenario still has vast potential. Take AirPlay: typing in a code every time you connect is a pain; if sound could transfer the password directly from the Apple TV to the iPhone, the user experience would be greatly enhanced. When a guest comes over and needs the guest WiFi password, two phones beep at each other and the password is transferred, saving manual typing. When WeChat sends a contact card, or an official account logs in, instead of scanning a QR code, you could transmit the information directly through sound and let the machines handle it automatically, eliminating the manual “scanning” step. And the initial provisioning of IoT devices at scale can also be distributed by sound, like a “gossip” protocol: one device “reads” the configuration to its neighbors, and it propagates onward until everyone is initialized.
