61–70 of 81 posts
With this headline, I cannot hear anything in my head except “the dial-up noise.” TCP over sound was how I used to connect to the Internet…
Clever, an audio soft-modem. Was there a reason to not implement this as an actual modem with a frequency band assigned to either channel and then to run SLIP or PPP over it?
Difficulty level, probably. I'd love to see both and also one that can survive over GSM audio (is that even possible?)
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
Earlier quoted context omitted.
That's a distinction without a difference. If another family member picked up the phone while you were dialed up, they certainly heard it.
That's why it was just for monitoring - you could hear, but the communication itself was not done via sound.
Earlier quoted context omitted.
Yup, a company I co-founded http://chirp.io has been using this technique (well, MFSK) to share data over the air, between mobile and embedded devices for a while now. Easy to describe, hard to do robustly.
I'm curious, did you selected audible frequencies (1760hz-10.5khz) because there were the only ones technically feasible with the current popular mics/speakers or because you actually wanted users to hear the data? 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 hardwa…
If you'd like to know more, we have trial SDKs you can goof around with. Feel free to give the technology a spin.
Slightly unrelated but curious; have there been any attempts to transfer data as sound? I don't mean sound converted to electricity, or to represent 0s and 1s, but using a specific frequency range to represent 1, another range to represent 2, another for 3... I don't know the terms for these things. Using vibrations instead of electrons to transmit data over a wire? Do creatures like dolphins do this?
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.
Earlier quoted context omitted.
Not sure if this is what you meant, but Chromecast's guest mode will pair using ultrasound. The guy who worked on it has some code using the WebAudio API on github and his linked blog: https://github.com/borismus/sonicnet.js
No there was an article on here several months ago that I couldn't find when searching where someone wrote a PoC for the transmission of data via near-ultrasonic sounds from a computer speaker and microphone. I don't think it was this [1] one, but it shows the concept being used. 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…
Earlier quoted context omitted.
Difficulty level, probably. I'd love to see both and also one that can survive over GSM audio (is that even possible?)
There's dialup over GSM. Though those modems does this by piping data through a software modem and then onto the GSM channel, however it requests a clear channel, so no transcoding is done by the network or the phone (the lossy GSM codecs arn't suitable for this) GPRS made that pretty much obsolete though.
I've been working on something similar[1] for a few years. Don't forget that you can use tun/tap devices to avoid re-implementing TCP/IP, and to gain interoperability with OS services! [1] https://github.com/piannucci/blurt/tree/master/blurt_py_8021...
Interesting, I had looked around for similar libraries when I started but didn't find many. It looks like ours differ in terms of FEC and configurability. What throughput does your modem get?
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.