Chirp produces a suite of software products dedicated to sending data acoustically, broadcast over the air.
Our standard ‘off-the-shelf’ products all adhere to the same protocols— the set of acoustic and data encoding parameters which define a chirp and allow devices to both send and receive data in an interoperable way. The data encoding parameters include properties such as the amount of data and error correction that should be included in each transmission, while the acoustic parameters describe properties such as the constituent pitches and duration of the chirp.
Our standard audio protocols…
Here is an example of a standard chirp — the sound you hear represents an identifier which tells the listening iPhone which picture to display.
The sound you hear in the video above can be interpreted by any device or application which has Chirp technology embedded. It contains 50 bits of information and is incredibly robust against background noise. Whilst the protocol in the above video is audible, we also offer an inaudible ultrasonic protocol which sends 32 bits of information.
Our standard audible protocol contains frequencies in the range of about 2kHz and 11kHz — this range was chosen because it works particularly well being broadcast and received by consumer electronic audio hardware, such as the transducers we have in our mobile phones — as these are optimised for the transmission of music and the human voice which occupy the same frequency ranges. Positioning our standard audible protocol in the centre of this range allows us to take advantage of these broad performance gains and optimisations for free.
These two ‘standard’ protocols, audible and inaudible, allow our partners to quickly develop products or services which take advantage of their interoperability and broad interaction capabilities. The data encoding and acoustic parameters for our standard protocols were chosen to maximise the flexibility of their use across a very wide range of use cases, so we chose configurations which suit many different applications.
Cup & String Telco International
Typically, once a product has integrated the standard protocol and proved the use case using our technology, there remains an opportunity to optimise the protocol characteristics to better fit specific requirements of a particular project.
This is the point at which we work alongside a partner to develop data payload and acoustic characteristics which are tailored to their product’s unique demands. For example, we have worked with partners who needed to send much more than the 50 bit payload capability of our standard SDKs, as well as those whose use case prioritised the shortest overall chirp duration — some almost 10 times shorter than our standard protocol.
To illustrate our capabilities in this area of customising protocol to fit extreme use cases, we set ourselves a challenge via an imagined partner: ‘Cup & String Telco International’ - producers of the world’s most lightweight communication equipment.
However, the Cup & String use case is no normal scenario for audio transmission — it represents a very restricted channel in terms of its frequency bandwidth and signal-to-noise ratio. As you might be able to remember from playing with a similar setup at some point, the audio coming from the cup at the receiver’s end sounds very ‘muffled’ or ‘dull’ — i.e. it sounds like the person on the other end is talking through a barrier such as a pillow or similar.
This dullness is caused directly by the loss of high frequencies during transmission — they are less efficient when traveling down the string, and also lose significantly more energy during the transition between air and solid at each end of the apparatus.
So, how can we optimise our protocol for transmission down the Cup & String Telco International v1.0? The first thing we do is design a protocol which does not include any higher frequencies. Our standard audio protocol’s lowest frequency is 1760Hz — the Cup Audio Protocol’s highest frequency is around 1000Hz.
We also lengthened the duration of each note to help with note detection in such a noisy channel, and reduced the amount of data in each chirp in order to keep the overall length of the chirp sensible.
The spectrogram below shows both protocols side by side— the standard protocol is above (with its higher frequencies), the Cup Audio Protocol underneath (with its lower frequencies and longer notes).
Did it work?
It worked exceedingly well, even with these basic initial customisations (lower frequencies, longer notes).
As a quick test, we took the equipment outside with a simple listening app which flashed the screen green when it heard a chirp using the Cup Audio Protocol.
We started at a modest volume that could be heard by the person clearly at the sending position (it’s likely that at this initial level there was some significant ‘bleed’ — a direct path to the receiver without going through the string). Then we started turning down the volume…
In the end, we successfully got to the point where data could be transmitted reliably at volume levels low enough that the people holding the cups could not hear any of the audio being broadcast from the sending device.
We also got quite a lot of strange looks from passersby.
Beyond cups & string
This test was obviously a fun experiment for us, but it illustrates the process of optimisation that we regularly go through with our partners as they integrate Chirp’s technology across a wide variety of use cases. The adaptations mentioned here for this particular experiment are only the beginning of a very sophisticated set of tools which allows us to optimise precisely in even the most challenging acoustic environments.
Because of the diversity of application areas where our technology is being applied, we often work with our partners to design custom audio protocols bespoke to their product’s requirements.
Often our standard protocols allow engineers to develop proof-of-concept Chirp integrations using our ‘off-the-shelf’ SDKs, which then illustrates the opportunity for further performance improvements. These gains are then achieved working in collaboration with each partner to develop a custom protocol with its acoustics and data encoding parameters tuned precisely for their particular application.