Can plastic cups and string send data?

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

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.

Our ‘test’ equipment — the Cup & String Telco International v1.0

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

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 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

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…

green flash means ‘received!’

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.

If you’d like more information about our standard products, or the
possibilities with respect to custom Chirp audio protocols for your
application, product or service — please get in touch with us.

You can also follow our blog to hear more about Chirp and sound technology.