Chirp has come a long way since we first encountered the start-up, exhibiting a way to use audio bursts to transmit data between toys for children. We could see the potential for the technology in RF-constrained environments, and after an initial deal with energy supplier EDF, Chirp has made headway in the sector. Now, it has announced a new software developers’ kit (SDK) for ARM’s Cortex-M4 and Cortex-M7 microcontroller (MCU) platforms, which brings the technology to the lowest-power silicon to date.
Wireless Watch’s sister service, Rethink IoT, 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 customer using the ARM design would take a software licence from Chirp to use its protocol. The fee is per-device, 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.
Nesfield said that Chirp had long had the inhouse ability to run its audio engine on low power chips, which led to it reaching out to ARM. The SDK means that anyone buying ARM licences, 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 protocols such as WiFi or Bluetooth.
He added that a future move to a hardware approach, based on performance-optimized ASIC chips, might be possible, but the current software-only approach is the priority, as a means to cover the existing silicon platforms in the market and accelerate uptake.
He also cited the 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. This is especially a concern in any application that will feature voice processing, where there is a risk of replicating parts of the signal chain found in an existing audio front end.
As for market competition, Nesfield said there is always a concern that one of the big players could enter the market – possibly Google or Amazon, since data-over-sound would be a value-add for their smart speaker and smart home platforms. There are also other options now, including an open source option from Robert Rypula available on GitHub.
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, but for Chirp, there is a significant benefit in the listening equipment having to get within audible range of the Chirp-enabled devices.
He added 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. The firm recommends security best practices that should be layered on top, which allows the SDK to remain transparent. But the SDK isn’t translating messages, nor knowing their contents, and is simply converting bytes into audio chirps, whether those bytes have been encrypted or not.
For future plans, Nesfield says that the start-up is still focused on growth and proliferation, rather than profit. With 10 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.