Your browser is not supported. Please update it.

5 April 2019

Chirp gets Arm microcontroller win, for low-power data-over-sound

Chirp has come a long way since we first encountered the startup, exhibiting a way to use audio bursts to transmit data between toys for kids. We could see the potential for the technology in RF-constrained environments, such as Chirp’s win with EDF’ and in the years since, Chirp has made headway in the sector. Now, it has announced a new SDK for Arm’s Cortex-M4 and Cortex-M7 microcontroller platform, which brings the technology to the lowest-power silicon to date.

We spoke to CEO James Nesfield about the announcement, and to catch up with happenings at the firm. Nesfield said that there have been some technical optimizations with the protocol to ensure it runs on the lower-power chips, and that R&D is still active on that point. Nesfield stressed that the ubiquity of hardware support is very important, and so Chirp needs SDKs for all devices. To this end, Arm’s MCUs are a key step. There’s a whitepaper available, outlining the project.

In terms of the business model, the end-customer that is using the Arm design would then take a software license from Chirp to use its protocol. The fee is per-device, and is not usage-based, as Nesfield said that approach would greatly complicate the cost structure. Seeing as all communication would be local, between the two devices in question, it would also be rather difficult for Chirp to pursue a per-message fee.

We asked how the Arm SDK came to be, and Nesfield said that Chirp had long had the in-house ability to run its audio engine on low-power chips. This led to Chirp reaching out to Arm to see if there was interest in cooperation, finding that there was. The SDK means that anyone buying Arm licenses, or Arm-based chips from vendors, would be able to run the Chirp stack out of the box, without having to negotiate network carriage deals with local network operators, or installing LAN protocols such as WiFi or Bluetooth.

We probed, asking whether there were other chip designs in the works. Nesfield mentioned that there was interest from DSP vendors, prompting us to ask whether Qualcomm and CEVA were in the mix. Nesfield wouldn’t say, but it did sound like we were on to something.

Nesfield did clarify that sending messages using the Chirp stack is very straightforward, but that the receiving element is trickier and more computationally intensive, meaning that the new Cortex-M chips are more likely to be found in the end-devices, rather than the gateway units.

We asked whether Chirp was exploring ASICs, as a way to create a dedicated silicon design to wring the most power-performance out of the stack – an evolutionary trend in many software-based processing tasks. Nesfield said that a future move to a hardware approach is something that certainly is possible, the current software-only approach is a priority, as a means to cover the existing silicon platforms in the market.

He also cited tension between creating an audio-processing chip for Chirp and the other audio-focused elements in the rest of the device. There’s a danger that these capabilities could end up overlapping, wasteful in design terms, or see Chirp competing with partners – never a good look. This is especially a concern in any application that will feature voice processing, we are told, where you could end up replicating parts of the signal chain found in an existing audio front-end.

As for market competition, Nesfield said there was always a concern that one of the big players could stroll in and scupper the plan. Google and Amazon are of particular concern, given their interest in promoting their Alexa and Assistant, as well as Echo and Home, platforms – where data-over-sound would be a pretty straightforward value-add for the feature-set.

Nesfield that there have been copycats (likely referring to Lisnr or CUE Audio, but there’s an open source option from Robert Rypula available on GitHub too), but that as Chirp had pioneered the field in 2011, it is the most mature and most proven choice on the market.

As for security, Nesfield says this is a topic that consistently comes up in his discussions. He stresses that all wireless communications can be overheard with the right equipment, and for Chirp in particular, there’s a significant benefit in the listening equipment having to get within audible range of the Chirp-enabled devices.

Nesfield also stressed that Chirp is focused solely on the Transport layer of the stack, and so isn’t implementing security features such as encryption in the SDK, as that falls outside Transport. It recommends security best practices that should be layered on top, with Nesfield saying that this approach allows its SDK to remain transparent. The SDK isn’t translating messages, nor knowing their contents, and is simply converting bytes into audio chirps – whether those bytes have been cryptographic ally scrambled or not.

For future plans, Nesfield says that the startup is still focused on growth and proliferation, rather than profit. With ten staff, Chirp is focusing on ways to become another tool in the value chain, and to this end, is exploring making its technology more open. Nesfield says that private ownership is the best vehicle for the technology at the moment, when we asked if an IPO might be on the horizon.