Show HN: TCP/UDP over sound
github.com
github.com
In this case, I assume they can beat the old modem bandwidth by cramming modulation in more ranges of frequency, with no need to adhering to the frequency range of the voice phone line.
I think one was used in the film War Games, but can't recall clearly.
https://de.wikipedia.org/wiki/Akustikkoppler#/media/File:Acu...
I had one for my C-64.
Can you further explain the difference in your example? I assume you mean that the bulk of the dial-up data was sent over non-audible ranges? Ie, we couldn't hear the actual data transfering, but we could hear the monitoring tones?
Sound is different of audio signal.
Audio signal is whatever way you arrange to represent signals in the audio range of frequencies and, usually, dynamic rang. Sound is a physical phenomenon caused by variation of pressure on air that we can listen to.
So, the transfer was usually done by audio signals, transmitted electrically via copper wire (and, sometimes, magnetic coupling in some modems). You could, of course, convert these audio signals to sound by picking up the phone (or wiring the modem to the sound card), but this was just for you to listen to. The communication was not depended on sound itself.
[1] https://github.com/piannucci/blurt/tree/master/blurt_py_8021...
What throughput does your modem get?
Can you expand on your question? I think I understand what you're saying but I don't quite see what it would accomplish.
And this is an "actual" modem, whatever that means. If you mean an IETF/RFC modem spec, there are many reasons. Those specs are focused on narrowband POTS limitations, which we don't face over a less-restricted channel. Implementing those features might be interesting from a vintage perspective but would require substantial work to achieve compatibility for relatively little gain.
> over a non-traditional eth,
> in this case sound
The app would listen to the call, decode the sound via FFT and display the resultant data as a web page. I found decent results by increasing the pitch variance between notes. The interesting thing about GSM/low-quality audio is that, since quality is known, it might be possible to account for it in a more specific way.
The idea was to provide a means of internet access on a device with no mobile data plan.
Of course, the worst case scenario is just sending everything as DTMF tones, but getting a tweet out would take like an hour
GPRS made that pretty much obsolete though.
If someone wants to play with lower bandwidth data (text, basic file transfer) over sound, it's a pretty active area in the world of amateur radio. You can download the open-source program fldigi (http://www.w1hkj.com/modes/index.htm) on 2 computers, point speakers and microphones at each other, and try sending text (or files/images). The "flmsg" program will send pre-formatted stanzas which get converted into standard forms.
That being said, doing things like TCP/IP and other data is rather difficult on radio, mainly due to the duplex requirements and frequency spacing. But in pure audio, much more possible.
After some time spent tuning and with some forward error correction, the reliability is good and it's not too harsh on the ears. Response from beta testers has been pretty positive.
It should not be possible to exceed the carrier's CSD rate over the link, but it's an interesting way of circumventing their billing.
I don't think you'll be able to achieve speeds faster than GPRS, but it's useful nevertheless.
I can imagine some interesting potential applications, including weird ones.
However it is technically trivial to encode "hidden" data at inaudible frequencies (>25 kHz) along with a song/whatever in the audible range and recover the data with a high pass filter. You would have to explain, however, the need for >48kHz sample rate.
Another, stealthier option would be to encode information in the background noise of a recording, but this would require more complex encoding/filtering techniques.
[1] https://en.wikipedia.org/wiki/Minimum-shift_keying#Gaussian_...
Maybe I'm misintepreting the OP's work and not realising how it differs in some subtle way? I get that they've put TCP/UDP over it, but is there something else I'm oblivious to?
Also, I meant BadBIOS [2], not Flame.
[1]: https://www.anfractuosity.com/projects/ultrasound-via-a-lapt... [2]: https://en.wikipedia.org/wiki/BadBIOS
[1] Ars Coverage: http://arstechnica.com/security/2013/12/scientist-developed-...
[2] Paper: http://www.jocm.us/uploadfile/2013/1125/20131125103803901.pd...
Using vibrations instead of electrons to transmit data over a wire?
Do creatures like dolphins do this?
https://en.wikipedia.org/wiki/Frequency-shift_keying#Audio_F...
(The 0 and 1 version is binary audio FSK, but you could also choose to have more frequency levels, such as 4 or 10 or 20 different levels.)
People studying this don't usually distinguish between whether the waves are emitted into space as audio or whether they're encoded as electricity. The main reason for that is that we have devices (speakers and microphones) that convert directly between audio and electricity in both directions, so the design of a system that uses a wave represented as electric signals and a system that uses a wave represented as sound is "equivalent" in some way (even if they face somewhat different practical considerations, like different kinds of background noise).
Edit: oh, there's a more detailed Wikipedia article on non-binary FSK, called "multiple FSK".
https://en.wikipedia.org/wiki/Multiple_frequency-shift_keyin...
It gives some examples of practical applications of this (again, not distinguishing fundamentally between what kind of waves you use).
http://www.pushclicktouch.com/blog/?p=107
They didn't even need batteries, since they were purely mechanical.
http://www.aquasent.com/acoustic-modems/
A place I worked at in the early 2000's used these in custom-designed acoustic telemetry systems deployed in the ocean (I don't remember which company we bought them from - the website I linked to is just an example of the type of device, but it is very similar). The system needed a way of communicating with devices that were dropped into the ocean and typical radio waves don't travel well in sea water. Acoustic modems were used instead, as sound travels well in water.
Frequency-shift keying?
Easy to describe, hard to do robustly.
I have played with minimodem to do this (FSK) and while cool, it is an unpleasant noise. I managed to transmit at inaudible frequencies but certainly it was very very unreliable with normal consumer hardware.
If you'd like to know more, we have trial SDKs you can goof around with. Feel free to give the technology a spin.
Edit: wow, the ultrasonic thing is really cool. Imagine putting that in mobile apps and having them communicate "silently" over the air!
I recommend running the receiver on a non-mobile device if you try this. Unfortunately running a receiver smoothly from a mobile browser is fairly difficult.
Wow, what about ad networks abusing this for cross-domain cross-tab communications?!?
I considered the cross-tab case but couldn't think of an obvious way to implement that. They'd have to get mic permissions, at any rate