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?
Best Answer
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.