Quietnet: Chat client that works over near-ultrasonic sound | Hacker News Reader

Quietnet: Chat client that works over near-ultrasonic sound

github.com

151 pointsluu64 comments

I'm glad people are realizing that radio waves aren't the only ways to send signals around a room.

I really want someone to make a wireless, powerless keyboard where every key's click is tuned to a slightly different sound.

Keylogging by acoustic emanations is a well researched technique, I just think it could be a feature if we made the keyboard right. https://www.schneier.com/blog/archives/2005/09/snooping_on_t...

Interestingly, some early wireless TV remotes used sound this way. The battery-free remotes would strike a tone when a button was pressed, and carefully tuned forks in the TV set would resonate in response, triggering the remote function.

http://www.tvhistory.tv/1957_Zentih_Ad-Remote1.JPG

There are also reasons they stopped using it in the first place[1]:

Some problems with this method were that the receiver could be triggered accidentally by naturally occurring noises, and some people could hear the piercing ultrasonic signals. There was an incident in which a toy xylophone changed the channels on such sets because some of the overtones from the xylophone matched the remote's ultrasonic frequency.

While each specific problem could be worked around with modern methods, it looks like a technique reserved for situations where you don't have a better option.

[1] http://en.wikipedia.org/wiki/Remote_control#Television_remot...

I don't see why DTMF https://en.wikipedia.org/wiki/Dual-tone_multi-frequency_sign... couldn't have solved this pretty easily without adding too much complexity. I've seen those remotes before and they usually only had about three buttons on them. Still pointless, but I think this would have worked.

We had a tv like this growing up. Whenever the dog would run through the room, his tags would jingle and change the channel. It was funny, too, because the tv channel changer was this rotary dial that was motorized. When you changed the channel, the little dial on the tv would click and spin around.

Until you get crumbs under the keys...

EDIT: "a wireless, powerless keyboard where every key's click is tuned to a slightly different sound" hang on, like a piano?

Heh, I just visualized my laptop keyboard transposed onto an 88 key piano, and then tried to imagine what a typical vim session would sound like on it...

Obviously Emacs sessions would sound better, as Emacs already is set up to use chords...

Funny :)

As long as you hit middle C1 on every chord regardless of whether or not it's a duff chord or not...

At least with vi, you can play one fingered and make an acceptable tune ;)

Sure Douglas Hofstadter could write a book about that...

This must be done.

Many MIDI virtual keyboard apps provide a mapping to the PC keyboard. Install one of those, (e.g. apt-get install vkeybd), plus a softsynth (e.g. ZynAddSubFX). Done.

> hang on, like a piano

Starbucks is about to get a lot noisier. :)

I think tones in our hearing range would be a bad idea. From what I remember of my music theory class, our brains (through either nature or nurture) don't like discordant sounds like that for a long time. In fact, I believe it's been used as a torture device in the past, although I'm guessing it wasn't just a weird jumble of notes in that case.

I don't think I'd be very good at programming in any case.

Click noises have no real tone character so could probably work. My keyboard already makes those anyway.

True, but as you alluded to yourself, those aren't really 'tones'. The parent was talking about a keyboard that sounded like a piano.

Would be great, until you had more than one in a room - what a mess that would be.

Are there limitations on the number of possible sounds? If not, each keyboard could use a unique set of sounds.

There is no limit on the number of sounds if you want every keyboard to cost as much as a handmade finely tuned professional musical instrument.

No, but the more sounds you use, the more precise everything has to be. Just think of a machine that recognizes blue, red, and yellow as compared to a machine that recognizes all 24-bit colors. Aside from everything else, how on earth would you calibrate the sensor?

You could do something like keep the frequency offset between keys constant for all keyboards, but add some way of shifting the frequency of all of the keys by the same amount. It seems feasible to me, but I have no expertise in the area. The difficulty could prohibit an infinite set of configurations, but it could easily allow for a small set of configurations for cases when a few keyboards are in close proximity.

It would be trivial to use the same synth hardware and warp the oscillator that drives the overall synth by a couple ppm higher or lower.

It would be a lot easier to encode at the message layer.

You are all talking around a FDMA spread spectrum implementation and I'm saying a CDMA would be a lot simpler to implement...

CDMA? Are we still talking about unpowered keyboards that send keypresses with the audible sound of the key striking the board?

CDMA is a neat scheme, but a single mechanical keypress generating a series of bits (at least 8) sounds awfully complex.

It looks like it would interoperate with standard amateur radio PSK-31 software if you set the ham radio software to 19043 Hz (instead of more typical 500-2000 or so Hz)

Over the last 15 years or so there have been a lot of PSK-31 software interfaces, so there's probably one that appeals to everyone.

I would imagine other modulation schemes would work in the ultrasound range, if you wanted to try SSTV or RTTY or perhaps a bidirectional error correcting protocol. AX.25 would be amusing and linux has kernel support and softmodem support if you can convince it to run at 20 KHz.

If you've got the bandwidth for Olivia and other modern modes I'd try those... I've made QSOs on HF where there is no discernible signal on the waterfall, works down to very low SNR. So you could get better range / lower error rate with a wider band / slower / more modern modulation method.

I would imagine doppler shift and multipath interference would be an interesting problem.

Do you mean the sound waves would generate radio waves somehow, or are you thinking of the speaker generating EM interference as well? How strong would you expect that to be?

No, just audio. If PSK-31 modulation works, Olivia will work better.

Should be called Furby chat ,because: http://poppopret.org/2013/12/18/reverse-engineering-a-furby/

Definitely in no way a unique idea. Also that article is awesome.

New computer security system: owning a dog

Hacking the soundcape: How to own the dog?

A webapp using the Web Audio API adopting the same sort of approach: http://smus.com/ultrasonic-networking/

That's really cool! I used the web audio stuff to get real time audio data for interactive visualizations when I did a 5 minute demo of quietnet, the code is available (but might be a pain to get running): https://github.com/katee/quietnet-presentation

Running fully in the browser with visualizations might make a good teaching tool for digital signal processing (although you'd need better DSP code to demo, mine is not a shining example.)

Can this be accomplished on mobile devices? This could be a clever trick to implement interesting multiplayer games on train rides, airplanes, where wifi is not available.

From a quick research, it seems that iPhones are not able to play ultrasonic sound: "iPhone 4s is rated for 20Hz - 20,000Hz, which means it cannot generate ultrasonic frequencies." - http://stackoverflow.com/questions/10034346/ios-how-to-produ...

Those "ratings" mean the sound will be distortion-free +/- 3dB over that range. You can still make some noise higher or lower than that, it will just be more distorted. I know iPhones support audio formats with at least 96 kHz sample rate, so you should be able to play half that or 48 kHz sounds without too much trouble. It might have some kind of band-pass filter built in, but the ratings won't tell you.

> Those "ratings" mean the sound will be distortion-free +/- 3dB over that range.

No it doesn't. All speaker drivers act as bandpass filters. On the ends of their frequency ranges those +/-3dB points are generally their -3dB points. For most speaker drivers their low frequency cutoff will be caused by the resonance of their motor, dropping off rapidly after that point. The upper frequency limit will be caused by the inductance of their motor's coil with a similar drop off above it.

It's unlikely that the iPhone speaker could reach 48kHz. If you look at expensive high frequency units (tweeters) they'll generally top out at 20-30k. A lot of headphone drivers (which are more similar to what's in the iPhone) barely make it to 20k.

> You can still make some noise higher or lower than that, it will just be more distorted.

Again, nothing about distortion here. A speaker driver will output sound outside of its -3dB points, but, obviously it's going to be much quieter (-3dB is already half as quiet).

Not ultra-sonic but this app sends photos from iPhone to iPhone using the speaker and microphone.

https://itunes.apple.com/us/app/acoustic-picture-transmitter...

Fun to play around with and think of the possibilities of using sensors in unintended ways.

Essentially a modem (with zmodem/sz-rz functionality)?

This operates within that range at 19K, which is well above what most adult humans can hear: https://github.com/Katee/quietnet/blob/master/options.py#L2

That's not to say it would work on an iPhone.

I would suspect those environments to be much too noisy for that to work.

Unless it's noisy at or near the desired communication frequency, it is trivial to isolate the signal and completely mute out the noise.

In this example, at ~19 kHz, a properly configured high-pass filter could easily remove any human-talking sounds.

I'm not worried about humans talking, I'm worried about the ambient noise of the train/plane itself.

Agreed. This particular app starts to fail badly when the AC is on my current room. Airplanes are much, much, worse.

Interesting... I thought the consensus was that these sounds weren't possible to create / detect on typical hardware according to recent discussions about mystery malware spreading through the air? I wonder what percentage of systems would be up to the required specs.

Malware can't spread via ultrasound, but it could certainly communicate via ultrasound. To spread would require that a sound picked up by the microphone would be executable, and in general, that can't happen. (In specific it can, of course; one could build a program to execute things from the microphone on purpose. But generally microphones do not get their input executed, and any hardware that did that would be incredibly, insanely broken. Mind you, I'm not saying that doesn't exist... just that it would be incredibly, insanely broken. Even by the standards of embedded hardware programming.)

Also, I don't think the badBIOS guy claimed it was spreading via ultrasound, that was sort of a generalized misinterpretation in the community.

> In specific it can, of course

Buffer overflow in the microphone driver? I'd love to see that in a Hollywood movie.

Microphone injection reminds of the picture going around with the person who taped a sql injection attack over their license plate to screw with the traffic cams.

link: http://gizmodo.com/5498412/sql-injection-license-plate-hopes...

"surprisingly tinny laptop speakers have a good high-frequency resolution, and are able to deliver a pulse less than 10 cm long."

http://fab.cba.mit.edu/classes/862.13/students/brandon/

No one said that it wasn't possible to use high-frequency sound as a communication vector.

It was the sheer seamlessly interconnected complexity of the entire badBIOS affair that led to skepticism.

ALSA lib pcm.c:2217:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear ALSA lib pcm.c:2217:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe ALSA lib pcm.c:2217:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side bt_audio_service_open: connect() failed: Connection refused (111) bt_audio_service_open: connect() failed: Connection refused (111) bt_audio_service_open: connect() failed: Connection refused (111) bt_audio_service_open: connect() failed: Connection refused (111) ALSA lib pcm_dmix.c:957:(snd_pcm_dmix_open) The dmix plugin supports only playback stream Cannot connect to server socket err = No such file or directory Cannot connect to server request channel jack server is not running or cannot be started

Anyone else got this?

Just installed and tried all the necessary packages, but for some reason it simply doesn't work. Here's a screenshot: http://cl.ly/image/180b0k3X332g

I'm using a retina macbook pro 15 inches

Tried again, this time I get an 'o'. http://cl.ly/image/0e1A2c2i1Y16

It's definitely a toy and a bit dodgy. I wrote up some instructions over here: https://github.com/Katee/quietnet/issues/3#issuecomment-3187...

Basically I only every worked on this until it was at the point where it was working for me on the laptops I was using, it's definitely not robust.

I have a 13in Macbook Pro and the internal speakers were not working for me. However, I plugged in my higher quality headphones and held them up to the speaker and it worked. It might work if you plugged in external speakers.

Are you sending and receiving on the same computer? I feel like that might cause issues. Are you able to use two separate computers to test?

It actually works much better when sending an receiving on the same computer. It's not as fun though.

Now that I've thought about it more, that actually makes a lot of sense. Thanks for the response!

Make sure you are in a quiet room (with the AC off). It worked for me on a Macbook retina, but started to fail when the AC turned on.

I'm getting an invalid syntax error when I try to run the scripts on Windows.

C:\Python33\Scripts\quietnet-master>python listen.py File "listen.py", line 71 print '' ^ SyntaxError: invalid syntax

You are using Python 3.3, but the script is for Python 2.x where print is a built-in rather than a function. Welcome to the fragmented world of Python.

Has anyone tried using this around their dogs?

I don't want to dos my puppy. :(

I can say my cats are fine... :)

In case anyone else is as daft as I was, this will not work for everyone in an everybody-wears-headphones environment.

You can make software use different speakers and other your headphones. iTunes has this in it's interface even (mac anyway).

Somewhere a phreaker is rejoicing

Reply on news.ycombinator.com