Yamaha InfoSound and ShopKick application use technologies that allow to transfer data using ultrasound. That is playing an inaudible signal (>18kHz) that can be picked up by modern mobile phones (iOS, Android).

What is the approach used in such technologies? What kind of modulation they use?

  • 4
    \$\begingroup\$ I can hear 18kHz! Please don't fill the airwaves with more buzzing than there already is! \$\endgroup\$ Commented Jun 6, 2011 at 4:02

4 Answers 4


Passing digital data via ultrasound is a lot more tricky than you might think at first glance. We are doing this in a product currently in field trials, but when we started designing there was very little information about it out there.

Most of the problems come from the fact sound propagates slowly (about 3ms per meter), and it can reflect and echo around a room for a while. We did some experiments and roughly you need to assume any emitted sound will bounce around for 10m worth of propagation or 30ms. This means the protocol has to allow for the receiver picking up duplicate copies of emitted signal and out of order signals up to 30ms. Put another way, imagine anything you send being re-ordered or duplicated unpredictably within a 30ms window.

Another issue is that ultrasound transducers are fairly high Q. They take a few cycles to get going, and then continue ringing a few cycles after there is no more input. Note that new and old data within the 30ms period can also interfere constructively or destructively cycle by cycle. This, together with the propagation mess will make the data rate very low. Stuff like manchester encoding is right out since the carrier can appear to come and go because of interference if anything was emitted in the previous 30ms.

To deal with these issues, we created our own encoding scheme in our system. As far as we could tell, nobody had done this before. I'm not sure, but our customer may have filed a patent on the technique. All data is encoded in the time difference between leading edges of short bursts. I think we send about 8-10 cycles at 40kHz for each burst. 10 cycles is only 250us, and is 80-85mm long propagating thru air. The receiver looks for leading edges of these bursts and records their time. After receiving a burst the receiver shuts down for a little less than 30ms since anything received in that period would just be echos. Data is encoded in the timing between successive bursts. In our system the time difference is in the 30-50ms range. We used a fairly course time quanta resolution of about 2ms due to other reasons inside the receivers I won't go into. Using this method, we can send one of 9 characters between two burst. We have a special character for start of message, and then the values 0-7. In other words, we send 3 bits of information per burst during a message. In our system we only need to send 10 bits of data at a time. We actually send 6 characters per message, the SOM and 5 data characters for a total of 15 bits. We use the additional 5 bits for a CRC checksum.

Our time quanta of about 2ms is longer than it needs to be if you're looking purely at the ultrasound issues. The lower limit comes from the the uncertainty of picking up the leading edge of a burst at the receiver and pathlength changes due to motion. You could probably use a time quanty down to 500us if you are really careful, although we didn't try that.

  • \$\begingroup\$ a detailed description of a workable system (can't imagine it dealing with multi-path). A cell-phone system would be limited to something less than 20 KHz - speaker & microphone response drops rapidly above that. I'd suggest BPSK modulation of the very many modulation schemes available. \$\endgroup\$
    – glen_geek
    Commented Sep 29, 2016 at 16:22

I can tell you data transmission through sound is possible, although it is very hard to achieve higher bitrates or long distances due to echo, multipath and attenuations. I've created a transmission protocol in order to transmit information bits between a PC speaker and a smartphone, or between 2 smartphones. I've implemented a QFSK and 8fsk non-coherent demodulation systems which uses 4/8 frequencies and a 3 kHz bandwidth (frequency spacing varies acordingly). Due to the fact that speakers, microphones and air introduce non-linearities on the carrier wave amplitude, I didn't use amplitud or phase modulations. I'm working in the low ultrasound frequency region between 18 and 22 kHz. From a PC speaker (Creative T6300 5.1 Audio system) I've reached 300 bps of error free payload bits 1 meter away detecting the sound with several types of smartphone microphones. I'm using a BCH error correcting scheme with 1/3 redundancy added (block codes show their highest code gain when redundancy is between 1/2 to 1/3). I couldn't use higher frequencies because all the smartphones I could work with, only supported 48kHz as maximum samplig frequency. I couldn't use the 22-24 kHz frequency region because smartphones microphones have an anti-aliasing filter that atenuates the frequencies over 22 kHz. Not all smartphones worked. I found there where smartphones' microphones that were only designed for recording the human voice spectrum, hence they showed a huge signal atenuation over 10 kHz (mayor components of human voice are in this band). I had to create a calibration algorithm to distinguish between good and bad smartphones' microphones


The approach sounds very simple, and is probably loosely based around the same technology that used to be used on old computers like Spectrums etc to store data on magnetic audio tape - just at a higher frequency.

It is probably frequency modulated binary, with some underlying encoding like Manchester Encoding, or 4B5B encoding. At least, that's how I'd do it if I were going to.


Here are the list of providers due to my research;





  • 1
    \$\begingroup\$ Link only answers don't fit very well in the SE model. If you have anything to add that makes this a valuable answer to a 9 year old question, you should add it, or consider deleting the answer. \$\endgroup\$ Commented Jan 8, 2020 at 16:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.