Since introducing peer-to-peer data-over-sound solutions in 2010, Chirp set and continues to raise the bar for data-over-sound technology, with industry-defining standards. Our focus on performance, robustness, and reliability is unparalleled.
From a small team of research scientists and academics at UCL, London, to an international mix of world class PhDs, post-docs, and engineers. Core research in audio DSP, telecommunications, machine learning, and embedded engineering is at the heart of what we do. With over 500 published papers, the research from our team speaks for itself.
Our patented algorithms allow data to be transmitted using sound in the harshest environments. We hold 14 data-over-sound related patents (4 granted) dating back to 2010, covering our custom modulation scheme, dereverberation, noise reduction, and multi-environment optimisation.
Chirp is a communications system based on data-over-sound that is packaged as a suite of SDKs. Chirp is not an app or website - we do not produce consumer-facing technology. Our SDKs are packages of code that can be embedded in our partner’s products and services to enable them to exchange data wirelessly using sound. We support all major platforms, and our SDKs are designed to enable simple integration of a wireless communication system for a wide range of applications.
Chirp’s data-over-sound solution enables the exchange of data between devices. The data is encoded into a series of audible or inaudible tones to form a “sonic barcode”. This encoded data is sent over air, to a receiving device, or group of devices, where the data is then decoded.
As with any device-to-device communication system, a Chirp system comprises of a transmitter, channel, and receiver.
Chirp uses Frequency Shift Keying (FSK) for its modulation scheme, due to its robustness to the multipath propagation present in real-world acoustics, compared to schemes such as Phase Shift Keying (PSK) or Amplitude Shift Keying (ASK). For spectral efficiency, Chirp uses an M-ary FSK scheme, encoding input symbols as one of M unique frequencies. Each symbol is modulated by an amplitude envelope to prevent discontinuities, with a guard interval between symbols to reduce the impact of reflections and reverberation at the decoding stage.
As with other data transmission protocols, the message can include specific sequences to indicate the start and expected length of a message and to establish timing and synchronisation, as well as additional bytes for Reed-Solomon Forward Error Correction (FEC) error detection and CRC error detection. Encoding a Chirp signal in this manner is a lightweight process in terms of memory and CPU, requiring only the generation of error correction symbols and sinusoidal oscillator synthesis.
Our proprietary decoding system is able to overcome many of the challenges typically associated with data-over-sound systems. As one might expect, a great deal of our IP and research focus are based around systems for decoding and processing audio signals. The basic processing in the decoder involves:
Once encoded, messages are transmitted through a medium (usually the air, but also telephone lines or other communication channels). Chirp’s technology is typically used in challenging acoustic environments, with potentially high levels of background noise, for example from crowded city streets, busy cafes, or noisy domestic environments containing music, television and people talking over each other. In addition to background interference, we know that audio is particularly susceptible to distortion from the acoustic environment in terms of reverberation, bringing with it issues of resonance, phase cancellation, and comb filtering effects.
At Chirp, 7 years of research focus and the resultant IP has enabled us to build robust audio based communications systems that overcome these challenges to perform reliably in a wide range of acoustic environments. Of the existing data-over-sound solutions on the market, the main differentiator for Chirp is this reliability and robustness of the internal decoding technology.
The Chirp SDKs provide platform-specific wrappers for the core encoding and decoding functionality. The core functionality is first wrapped in the Chirp C-SDK. The C-SDK provides a common interface for all the other platform SDKs such as iOS, Android, Python, etc. The C-SDK can also be used as an SDK itself (e.g. for embedded devices), however it does not include any functionality for handling platform-dependent audio I/O layers - this is typically handled in the platform-specific SDKs (e.g. iOS, Android etc.).
Our standard protocols are tested to perform at >99% reliability under normal operating conditions. This level of performance can be maintained under particularly challenging acoustic conditions (e.g. with low signal-to-noise ratios and sub-optimal transducers), however reliability is ultimately a function of range and data rate.
One can expect reliable transmission from 1cm to 100m, subject to data rate requirements. This has been demonstrated and stress-tested in acoustically extreme environments, including nuclear power stations with upwards of 100dB(A) of background noise, across ranges exceeding 100m.
But don’t just take our word for it - our technology is the only data-over-sound solution that has been independently tested by an internationally renowned acoustic research centre, and proven to work in extremely challenging acoustic environments such as nuclear power stations
At Chirp, we work closely with our users to understand their business and application-specific needs. We are able to design bespoke protocols that meet individual requirements for range, reliability, and data rates, based on your operating conditions and use case. Get in touch for more info.
Sign up to our newsletter to get Chirp news delivered straight to your inbox.