{"_id":"576d42354bcd290e00428954","__v":0,"category":{"_id":"576d42354bcd290e00428942","version":"576d42354bcd290e00428941","project":"56a526d4e7a1622b0024fae4","__v":0,"sync":{"url":"","isSync":false},"reference":false,"createdAt":"2016-01-24T19:32:37.467Z","from_sync":false,"order":0,"slug":"documentation","title":"Our Technology"},"version":{"_id":"576d42354bcd290e00428941","project":"56a526d4e7a1622b0024fae4","__v":1,"createdAt":"2016-06-24T14:22:45.076Z","releaseDate":"2016-06-24T14:22:45.076Z","categories":["576d42354bcd290e00428942","576d42354bcd290e00428943","576d42354bcd290e00428944","576d42354bcd290e00428945","576d42354bcd290e00428946","576d42354bcd290e00428947"],"is_deprecated":false,"is_hidden":false,"is_beta":false,"is_stable":true,"codename":"","version_clean":"2.0.0","version":"2"},"user":"56bc6af27c91881900089bac","parentDoc":null,"project":"56a526d4e7a1622b0024fae4","updates":[],"next":{"pages":[],"description":""},"createdAt":"2016-02-11T11:24:48.655Z","link_external":false,"link_url":"","githubsync":"","sync_unique":"","hidden":false,"api":{"settings":"","results":{"codes":[]},"auth":"required","params":[],"url":""},"isReference":false,"order":1,"body":"Chirp is a platform to send data over sound: it is intended as a way for many kinds of device to communicate over the air.\n\nAny device with a speaker can emit a chirp, and any sufficiently powerful device with a microphone can decode a chirp. It has been initially made available as a free application for iOS. The system has been designed for extension into many use-cases where it would be impractical to use existing network technologies.\n\nThe technology underlying Chirp is made up of two parts:\n\n * an **audio protocol**, which encodes a sequence of characters as a series of pitched tones\n * a **network API**, which stores an arbitrary data structure and assigns it a unique `shortcode` of ten characters.\n\nA receiving device needs to be able to track and decode successive pitches with error correction. Our decoding algorithms are the result of several years' research effort, make them robust against noise, whilst also efficient to implement on devices with limited DSP capabilities.\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"The Audio Protocol\"\n}\n[/block]\nThe Chirp audio protocol was designed to be friendly. That is: simple to implement.\n\nIt has an alphabet of 32 characters `[0-9, a-v]` mapped to 32 pitches a semitone apart.\n\n```0 = 1760hz 1 = 1864hz … v = 10.5khz```\n\nAn entire chirp is a sequence of 20 pure tones of 87.2ms each. The first 2 tones are a common ‘front door’ pair – \"hj\" –  to indicate to a device that the following tones are a chirp shortcode; the next 10 tones represent the 10-character payload. The final 8 tones are Reed-Solomon error correction characters.\n\n`[FD] [SHORTCODE] [ERROR-C]`\n\nWith 5-bits per character and 10 characters per chirp, our total address space is 50 bits. Error correction means that Chirp transmissions are resilient to noise. A code can be reconstituted when over 25% of it is missing or misheard.\n\n\n### Playing a chirp\n\nA sending, or encoding device needs only to be able to emit a series of sine tones between 1.7kHz and 10.5kHz with accurate timing.\n\n### Hearing a chirp\n\nA receiving, or decoding device needs to be able to track and decode successive pitches with error correction. The result of a significant research effort to make it robust against noise, whilst also implemented efficiently on devices with limited DSP capabilities.\n\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"The Network Layer\"\n}\n[/block]\nAn inherent limitation of any data-over-audio protocol is its limited transmission rate. The Chirp network layer allows applications to share larger pieces of data without writing a single extra line of code.\n\n To send larger amounts of data, we have built a RESTful network infrastructure which allows arbitrary pieces of data to be associated with Chirp shortcodes. \n\nFor example, a sending device can upload a photo to the cloud, and then use our SDK to associate its url, filename, and other metadata with a Chirp shortcode identifier. This shortcode identifier is then sent over the air. \n\nA receiving device hears the shortcode identifier over its microphone, and our SDK then delivers the associated data to your application.","excerpt":"A brief overview of the individual components of our service and how these work together.","slug":"chirp-technology-overview","type":"basic","title":"Chirp Technology Overview"}

Chirp Technology Overview

A brief overview of the individual components of our service and how these work together.

Chirp is a platform to send data over sound: it is intended as a way for many kinds of device to communicate over the air. Any device with a speaker can emit a chirp, and any sufficiently powerful device with a microphone can decode a chirp. It has been initially made available as a free application for iOS. The system has been designed for extension into many use-cases where it would be impractical to use existing network technologies. The technology underlying Chirp is made up of two parts: * an **audio protocol**, which encodes a sequence of characters as a series of pitched tones * a **network API**, which stores an arbitrary data structure and assigns it a unique `shortcode` of ten characters. A receiving device needs to be able to track and decode successive pitches with error correction. Our decoding algorithms are the result of several years' research effort, make them robust against noise, whilst also efficient to implement on devices with limited DSP capabilities. [block:api-header] { "type": "basic", "title": "The Audio Protocol" } [/block] The Chirp audio protocol was designed to be friendly. That is: simple to implement. It has an alphabet of 32 characters `[0-9, a-v]` mapped to 32 pitches a semitone apart. ```0 = 1760hz 1 = 1864hz … v = 10.5khz``` An entire chirp is a sequence of 20 pure tones of 87.2ms each. The first 2 tones are a common ‘front door’ pair – "hj" – to indicate to a device that the following tones are a chirp shortcode; the next 10 tones represent the 10-character payload. The final 8 tones are Reed-Solomon error correction characters. `[FD] [SHORTCODE] [ERROR-C]` With 5-bits per character and 10 characters per chirp, our total address space is 50 bits. Error correction means that Chirp transmissions are resilient to noise. A code can be reconstituted when over 25% of it is missing or misheard. ### Playing a chirp A sending, or encoding device needs only to be able to emit a series of sine tones between 1.7kHz and 10.5kHz with accurate timing. ### Hearing a chirp A receiving, or decoding device needs to be able to track and decode successive pitches with error correction. The result of a significant research effort to make it robust against noise, whilst also implemented efficiently on devices with limited DSP capabilities. [block:api-header] { "type": "basic", "title": "The Network Layer" } [/block] An inherent limitation of any data-over-audio protocol is its limited transmission rate. The Chirp network layer allows applications to share larger pieces of data without writing a single extra line of code. To send larger amounts of data, we have built a RESTful network infrastructure which allows arbitrary pieces of data to be associated with Chirp shortcodes. For example, a sending device can upload a photo to the cloud, and then use our SDK to associate its url, filename, and other metadata with a Chirp shortcode identifier. This shortcode identifier is then sent over the air. A receiving device hears the shortcode identifier over its microphone, and our SDK then delivers the associated data to your application.