使用超声波传输数据
Yamaha InfoSound< /a> 和 ShopKick 应用程序 使用允许使用超声波传输数据的技术。即播放现代手机（iOS、Android）可以接收到的听不见的信号（>18kHz）。
此类技术使用的方法是什么？他们使用什么样的调制？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
我发现这种方法有几个问题。首先，18kHz 并不是听不见的。许多人听不到它，尤其是随着年龄的增长，但我知道我当然可以（我定期进行与工作相关的听力测试）。此外，大多数手机的 A/D 转换器上都有不同的低通滤波器，并且许多设备，尤其是较旧的 Android 设备（我亲眼目睹过这种情况），会过滤 16 kHz 左右以下的所有内容。因此，不保证您的应用程序可以在任何硬件上运行。 iPhone应该能够做到这一点。
就调制而言，它实际上可以是任何东西，但我肯定会排除AM。就音量而言，声音的鲁棒性几乎为零。如果我要实现类似的功能，我会选择 FSK。我认为 PSK 会由于声学反射等原因而失败。困难在于您正在非常窄的带宽内进行非鲁棒的能量传输。我当然不怀疑它可以实现，但我不认为这样的事情被证明是可靠的。恕我直言，就是这样。
更新：现在我想了一下，如果您不传输任何数据，而只是传输一些短信号，那么简单的开关可以使用单音调。
I see several problems with this approach. First, 18kHz is not inaudible. Many people cannot hear it, especially as they age, but I know I certainly can (I do regular hearing tests, work-related). Also, most phones have different low-pass filters on their A/D converters, and many devices, especially older Android ones (I've personally seen that happen), filter everything below 16 kHz or so. Your app therefore is not guaranteed to work on any hardware. The iPhone should probably be able to do it.
In terms of modulation, it could be anything really, but I would definitely rule out AM. Sound has next to zero robustness when it comes to volume. If I were to implement something like that, I would go with FSK. I would think that PSK would fail due to acoustic reflections and such. The difficulty is that you're working with non-robust energy transfer within a very narrow bandwidth. I certainly do not doubt that it can be achieved, but I don't see something like this proving reliable. Just IMHO, that is.
Update: Now that i think about it, a plain on-off would work with a single tone if you're not transferring any data, just some short signals.
不能说 Yamaha InfoSound 和 ShopKick，但我们在项目中使用的是频率调制的变体：载波的频率由数字二进制信号调制，其中 0 和 1 分别对应于 17 kHz 和 18 kHz。至于解调器，我们尝试了外差式。您可以在这里找到更多详细信息：http://rnd.azoft.com /mobile-app-transering-data-using-ultrasound/
Can't say for Yamaha InfoSound and ShopKick, but what we used in our project was a variation of frequency modulation: the frequency of the carrier is modulated by a digital binary signal, where 0 and 1 correspond to 17 kHz and 18 kHz respectively. As for demodulator, we tried heterodyne. More details you could find here: http://rnd.azoft.com/mobile-app-transering-data-using-ultrasound/
超声波并没有什么特别之处，其原理与通过调制解调器传输数据相同，因此任何数字调制 原则上是可行的。您只有特定的频段（18khz 以上）和一些实际的要求（我猜介质非常不可靠），建议使用低比特率的简单鲁棒方案。
There's nothing special in being ultrasound, the principle is the same as data transmission through a modem, so any digital modulation is -in principle- feasible. You only have a specific frequency band (above 18khz) and some practical requisites (the medium is very unreliable, I guess) that suggest to use a simple-robust scheme with low-bit rate.
我不知道他们是如何做到的，但这就是我的做法：
如果它是一个字符串，那么请确保它不是很长的字符串（越长错误概率越高）。假设我们正在处理 ASCII 代码的重要部分，即最多 127 个字符，那么您需要的只是每个字符 7 位。将此字符转换为位并使用 QFSK 调制这些位（有多种调制可供选择，基于频移的调制已被证明是我尝试过的传统调制中最稳健的...我创建了自己的调制此用例的方案）。选择 18.5、19、19.5 和 20 kHz 的载波频率（如果您想在设计中做到数学上的严格，请选择能够确保符号转换时的正交性和相位连续性的频率值，如果不能的话，这是一个很好的解决方法避免突然的符号转换是将符号乘以相同大小的窗口，例如 Gaussian 或 Bartlet ）。根据我的经验，您可以在 17.5 到 20.5 kHz 的范围内移动这个值（如果您降低它会开始打扰使用您的应用程序的人，如果您提高平均类型麦克风频率响应将削弱您的传输并引起不必要的错误） 。
在接收器端实现相关或匹配滤波器接收器（FFT 接收器也可以工作，特别是零填充接收器，但它可能会慢一点，我不推荐 Goertzel，因为多普勒效应或扬声器麦克风导致频移非线性可能会影响您的接收）。一旦您收到比特流，用它们创建字符，您将恢复您的消息
如果您遇到太多广播错误，请尝试为每个符号选择更多的样本或带通滤波每个频率值，然后再将它们提供给解调器，使用有时，BCH 或 Reed Solomon 等纠错码是确保无差错通信的唯一方法。
每个人总是忘记谈论的一个话题是同步（在接收端知道传输何时开始），您必须在这里发挥创造力并使用大量电话进行大量测试，然后才能得出实际的检测阈值适用于所有情况，请注意，这也可能取决于距离。
如果您不熟悉这些主题，我会推荐几本好书：
Fuqin Xiong 的《数字调制技术》
、BERNARD 的《数字通信基础知识和应用》 SKLAR数字通信
John G. Proakis 的
I don't know how they do it but this is how I do it:
If it is a string then make sure it's not a long one (the longer the higher is the error probability ). Lets assume we're working with the vital part of the ASCII code, namely up to character number 127, then all you need is 7 bits per character. Transform this character into bits and modulate those bits using QFSK (there are several modulations to choose from, frequency shift based ones have turned out to be the most robust I've tried from the conventional ones... I've created my own modulation scheme for this use case). Select the carrier frequencies as 18.5,19,19.5, and 20 kHz (if you want to be mathematically strict in your design, select frequency values that assure you both orthogonality and phase continuity at symbol transitions, if you can't, a good workaround to avoid abrupt symbols transitions is to multiply your symbols by a window of the same size, eg. a Gaussian or Bartlet ). In my experience you can move this values in the range from 17.5 to 20.5 kHz (if you go lower it will start to bother people using your app, if you go higher the average type microphone frequency response will attenuate your transmission and induce unwanted errors).
On the receiver side implement a correlation or matched filter receiver (an FFT receiver works as well, specially a zero padded one but it might be a little bit slower, I wouldn't recommend Goertzel because frequency shift due to Doppler effect or speaker-microphone non-linearities could affect your reception). Once you have received the bit stream make characters with them and you will recover your message
If you face too many broadcasting errors, try selecting a higher amount of samples per symbol or band-pass filtering each frequency value before giving them to the demodulator, using an error correction code such as BCH or Reed Solomon is sometimes the only way to assure an error free communication.
One topic everybody always forgets to talk about is synchronization (to know on the receiver side when the transmission has begun), you have to be creative here and make a lot a tests with a lot of phones before you can derive an actual detection threshold that works on all, notice that this might also be distance dependent
If you are unfamiliar with these subjects I would recommend a couple of great books:
Digital Modulation Techniques from Fuqin Xiong
DIGITAL COMMUNICATIONS Fundamentals and Applications from BERNARD SKLAR
Digital Communications from John G. Proakis
您可能会幸运地使用我为基于声音的调制解调器创建的库，libquiet。它为您提供了一些可供使用的配置文件，包括频谱内容高于 19kHz 的慢速“超声波耳语”配置文件。该库是用 C 编写的，但需要一些工作才能与 iOS 交互。
You might have luck with a library I created for sound-based modems, libquiet. It gives you a handful of profiles to work from, including a slow "Ultrasonic whisper" profile with spectral content above 19kHz. The library is written in C but would require some work to interface with iOS.