CHIRP Interview

Devised by a team of acoustics and communications experts at University College London, Chirp is a sonic barcode that allows data and content to be encoded and transmitted between a wide variety of audio devices. This data-over-audio innovation allows content to be transmitted and decoded even when devices are in offline mode, offering an exciting potential bridge between the Internet of Things and offline devices, via what has been termed ‘The Internet of Sound’.

Initially marketed as an IoS and Android peer to peer app, Chirp has evolved into a sophisticated suite of Software Development Kits (SDKs), helping it to find application in a wide variety of global platforms. We spoke to Chirp’s Chief Technology Officer James Nesfield to find out more...

In a nutshell, how does Chirp work?

Chirps works by coding data as a series of pitches of notes, which are then transferred as sound to any device within range. We initially developed the idea back in 2011 at University College London. Since then it’s evolved considerably as we’ve commercialised and productised our initial prototype. What we offer today is a suite of SDKs that other businesses can easily embed into their products and services.

Chirp has been referred to as the Internet of Sound. How can Chirp enable the Internet of Things?

Almost any device that already has a speaker or a microphone is capable of transmitting or receiving data as sound. Not all of these devices are currently able to join the IoT revolution though. Data-over-audio is one of the few technologies that can enable interactions between legacy equipment using sound as a kind of lowest common denominator. As an extreme example it enables sending a message from a vinyl record playing on your grandfather’s old record player to your latest iPhone 7. The ubiquity of sound in the physical world - and the fact that these interactions can take place offline - makes it a great match for the disparate range of devices which make up the Internet of Things.

Give us some examples of how Chirp has been adopted by businesses...

I’ll talk about two that we’re particularly proud of because they’re in very different sectors...

The Indian minibus and taxi service SHUTTL has been using Chirp to validate the tickets of customers using their services. They’d previously relied on manual validation and QR codes, but both of these solutions were failing the speed test during peak times. Chirp enables passengers to validate at the touch of a button, sending their ticket data to the driver’s device more or less instantly.

We also recently launched a collaboration with the US gaming and media company Activision, who are using Chirp technology in their Skylanders Imaginators game. A key element of the game involves creating customised characters and sharing them over multiple platforms, including tablet and mobile. Because the primary audience is young children, there were numerous issues surrounding security, internet access and account ID mechanics. Chirp allows players to share their character data from tablet to mobile without having to physically connect their devices, connect to the wider internet or login to an account. Even if a device is in airplane mode, the characters can be transferred.

What are Chirp’s possible applications in the future?

We’re currently broadening our product portfolio so that we can incorporate as many different platforms as possible. This doesn’t just apply to different form factors but also to different generations of devices – from large stationary hardware to mobile handsets. When we have SDKs to allow all of these devices to communicate and connect, we’re going to see some very interesting projects coming out of it.

Tell us about the journey Chirp has taken from conception to successful startup business?

At the time we were first developing Chirp, the thinking was that we would package it as a consumer-facing app. For the first year, we did exactly that – we had an IoS and android app that was used primarily for sharing images, sound and video. This was very successful and achieved millions of downloads plus excellent coverage.

However, in 2015 we started to take a different approach, which was to move from a consumer-facing app to a business-to-business model. This was a case of recognising a bigger opportunity – if we could move away from relying solely on our own app and help to integrate the technology across various different sectors, we could increase the rate of adoption for Data Over Sound, which is ultimately our company’s goal. The past 12 months have been all about validating that change of direction, and we feel that the recent successes we’ve enjoyed have gone a long way towards doing that.

Tell us about the audio protocols you provide?

We offer a standard protocol that’s able to send up to 50 bits of data, which we give away on our website. For larger partners we’re able to modify our products to best suit their needs. For example, in Activision’s case, there’s a lot of data to send – purely in terms of the number of customisations that you can make to the characters in the game. We took that challenge and modified the protocol so that they were able to send about 20 times more data than our standard product can achieve.

What are some of the biggest challenges you’ve faced while developing and marketing Chirp?

Data over sound as a concept isn’t new – it was widely used in old modems and phone lines, for example. The challenge we faced with Chirp was that we were specifically optimising for the noisy, messy, chaotic real world. You can’t necessarily anticipate all of the different acoustics or noise sources that might have the potential to disrupt the service, so we’ve put a lot of hard work into ensuring that Chirp is just as effective in heavy traffic, in the same room as a blaring TV or in a cathedral as it is in a quiet office or lab environment.

Chirp began life as a customer facing app that allowed users to transfer data files between devices using sound.

James Nesfield is the Chief Technology Officer for Chirp.

What has your most rewarding moment to date been?

Proving that we could send the large pieces of data required by Activision was a big moment for us, particularly after we received so much positive feedback after the launch. We were looking at something around twenty times larger than our standard product, and though we were confident when we started, we didn’t know definitively that it could be done. The fact that we were able to not only demonstrate that capability but launch it as part of a game that has millions of players around the world was a wonderful achievement.

Have you approached other IoT brands and devices – such as Raspberry Pi and Arduino - with a view to incorporating Chirp into their products?

We already offer an Arduino SDK, and for Raspberry Pi we’ve got a compatible Python SDK, plus an Android SDK that could be run on the Raspberry Pi with a bit of hacking. We’re also actively working on further SDKs for native support for a range of devices including the Pi, but not limited to those platforms. We’re expecting to launch a number of new releases in the near future. Also, our core engine is written in C making it straightforwardly portable to a very wide range of devices - generally we’re being market led in this area.

What are the security considerations when transferring data using Chirp?

In some ways, transferring data through sound is a double-edged sword. Any device within earshot can hear the data and decode it, but of course what that data means to the device is where the security considerations come into play.

Our primary focus as a company is on getting the data successfully transmitted from device A to device B, or to a number of devices - rather than security per se. How security gets looped into that process is controlled by the third party application developer who can manage it in a way that suits their security architecture and product requirements. What we tend to see is a mechanic by which both device A & B agree on what data needs to be sent, and if any outside device overhears the data, it’s simply meaningless - usually this is accomplished using TOTP or encrypted payload.

Where do you see Chirp twelve months from now?

Twelve months from now we’d like to be offering a much broader product portfolio and hopefully seeing some interesting cross-platform, cross-architecture use cases coming out of that expansion. We’re really pleased that we’re beginning to see Chirp applied across a wide variety of receptors, and this shows no sign of slowing down. We purposefully keep the SDKs very flexible rather than optimising specifically for any one sector. Often, this results in applications in areas that we’d never even considered.

Why do you think Chirp has been successful when so many tech start-ups fail?

We really do have a world class team that’s both small and highly specialised. I think that allows us a certain flexibility that we can also apply to our product portfolio. It’s really important that we can be adaptable to market demand, and the fact that our SDKs are compatible across so many different sectors really works in our favour in terms of being able to take advantage of opportunities, no matter what direction they may come from.

Do you think the Internet of Sound has a role to play in the IoT revolution? Join the conversation in our case study on the element14 community.