Thought GNU Radio was just for radio? Think again. [Chris] has been hard at work turning the signal generation and analysis of the best tool for software defined radio into a networking device for speakers and a microphone.
The setup uses GNU Radio to generate a carrier signal whose frequency is modulated with a data stream. With this modulated signal piped over a laptop’s speakers, [Chris] is able to send UDP packets across his desk using nothing but sound.
[Chris] had recently used a similar technique to transmit data via audio with GNU Radio, but this latest build is a vast improvement; this is now a duplex networking, meaning two computers can transmit and receive at the same time.
In the end, [Chris] created a strange, obsolete device called a “modem”. It’s not exactly fast; sending ‘Hello World’ takes quite a bit of time, as you can see in the video below.
Kickstart it, nao!
Not only that, but there is tons of systems to do this via really noisy paths that ham radio operators have used for decades.
Look at how you use low bitrate packet. if you are messing about in the same room that is quiet, just use the paket radio libraries out there. then you can even have them repeat from pc to pc automatically if they cant hear each other.
I demoed just that at a hamfest 10 years ago with 5 laptops spread out across a room.
Google ‘minimodem’, this does exactly that. I have used it before (over telephone line) with great succes.
Good job making the modem in Gnuradio. We have done a school project where we implemented OFDM over sound, it also worked quite good with high bitrates, but one has to be careful to put the speaker volume very low to reduce non-linearities.
I dont see anything novel here. I was sending pictures between my android phones with sound! See slow scan television [http://en.wikipedia.org/wiki/Slow-scan_television]
Damn guys, does nothing impress you? You must need blood splashed on your faces to keep you from yawning. Anyway, I thought it was a pretty cool project and learned some things reading about it.
If you notice, the disses are always followed by brags. Apparently, in order to brag about their own project they have to bring another one down.
About half the time you can tell the brags are bogus. Some people here seem to have a PHD in Science Fiction.
In this case, though, the “idea” obviously isn’t new (as Brian pointed out), but the implementation is indeed new.
Actually, even the implementation isn’t new — underwater devices have used this for years now. What *IS* cool, though, is how *accessible* this technology is now. I have it on good authority from friends who are divers that ultrasound-based communications devices are really quite expensive. But, if this can be made to run on a Raspberry Pi, for example, or a heavily optimized version on a high-speed Arduino or MSP430-based device, that’s a game-changer.
We make ultrasound (and audible) communications equipment for subsea (for anything more than a few tens of metres, it’s the only way to communicate wirelessly). Our equipment, like most companies, has been a software defined radio for over 15 years, albeit with proprietary code rather than gnuradio.
Unfortunately, the Pi or Arduino aren’t so much of a game-changer as you’d hope. The products are more expensive than a modem or wi-fi dongle, but that’s not due to the processing part, it’s a tiny fraction of the cost. The processor will usually be less than 1% of the purchase cost of the components, and in turn the purchase cost of the components may be only 10% of the cost of the shipped product. We can do the processing on something like a Pi, but it wouldn’t make the product any cheaper.
The big cost items are the batteries, the acoustic transducer (a piezoelectric loudspeaker/microphone which will produce enough power to transmit data 10km or more) and the pressure housing- the metal box that keeps the water out and the air inside, especially at several thousand metres water depth! Even an inexpensive simple 2-pin connector which will survive at these depths will cost a handful of Raspberry Pi’s.
The other big cost is the engineering, a proof of concept like [Chris]’s is relatively easy to develop (especially now with gnuradio, but kudos to [Chris] for actually going ahead and doing it!), but we turn that into a product which has to work without fail when lives and/or huge costs can be at stake. That takes a lot of work, and for some niche products, there may only be a handful of customers each year in the world, so that cost doesn’t get spread out so much as you’d hope!
it’s been done a million times in a million ways for many decades, so sorry but people just have a chance to mention it because it is true.
Really? A million times in the past someone has created a full duplex transmission of data using audio by using the GnuRadio to redirect what was intended to output to RTL-SDR and instead output to audio in a million different ways?
Wow. I never realized that!
And if so, what was the point of the bragging?
Malware does this already :-) http://arstechnica.com/security/2013/10/meet-badbios-the-mysterious-mac-and-pc-malware-that-jumps-airgaps/
Yeah. No. Not buying that crap at all.
Ever tried sticking a calculator near a an am radio whilst pressing the keys.
I always thought that early apple laptops had a magnesium chassis to reduce emi transmissions to sensitive medical equipment and vice versa. If only Barnaby Jack were still alive.
Nothing new… FSK, AX25, etc.
However, duplex I’m fairly certain is.
Use something faster like FSK and implement full duplex and we could have something quite interesting, not to mention twice as fast as current radio modems.
Full duplex was common in old telephone modems, though.
True, but to my knowledge it hasn’t been over radio.
I’ve used tcp/ip over AX25 radio and while it works it’s only half duplex.
Waiting for tcp traffic on both ends really slows it down.
Single-frequency, full duplex will never happen for ham radio because of RX overload. Even with a duplexer, the receiver sensitivity will drop significantly while the transmitter is sending. To work around this, you’d need two radios, each tuned to different frequencies (like a VHF repeater), and that’s rather expensive.
I bought my son a new Furby for Christmas (worst… decision… ever!). It communicates with the iPad in this same manner, I believe. It’s silent to me (the communication, not the Furby), though my 12 year old niece can hear it.
It’d be cool for someone to reverse engineer this (strictly by the sound, not the iPad app). If you could walk into a toy store and play some custom “inaudible” sounds to make all their Furby’s fart in unison — awesome!
Been featured on hackaday:
http://hackaday.com/2013/01/28/reverse-engineering-the-furby/
This one’s more thorough IMO:
http://poppopret.org/2013/12/18/reverse-engineering-a-furby/
Radio’s pretty sweet, good work.
Cool, thanks for the links! I suppose I’ll let my son keep the toy now. I was beginning to think it was a mechanical turk [for ants — it needs to be at least three times bigger!].
Someone’s already done it:
http://hackaday.com/2013/01/28/reverse-engineering-the-furby/
gnuradio is really cool, I use it with my rtlsdr. For something like this article, you could try (ubuntu/debian users):
sudo apt-get install soundmodem
Made use of it many years ago while running a BBS over AX.25, soundcard and VHF radio. Also with VOX with a simple rectifier to activate the PTT using just the audio output.
Nice implementation w/ GNURadio. AFSK modulation gets back to the old modem days… It’s still used today though from #HAM Radio Operators in the APRS and AX.25.
Not only has this been done, but it’s been incorporated into a virus…
http://arstechnica.com/security/2013/10/meet-badbios-the-mysterious-mac-and-pc-malware-that-jumps-airgaps/
ISTR the problem with that is your “target” machine isn’t listening for coded audio to start with, so will just ignore it. Unless you’ve programmed it to do so. In which case you may as well program the payload in while you’re doing it.
In the end, as the article you point to mentions, it’s thought to be a hoax, with no decent reporting, or apparently any data at all.
A less fundamentally-obvious problem would be getting any sort of bandwidth through audio through air. You’d have to use very low data rates in very obviously audible frequencies. There’s only a couple of KHz up to the 22KHz a PC soundcard can reproduce, that’s above human-audible, and the variously crappy speakers and mics most PCs are equipped with wouldn’t do much of a job of picking it up.
Over radio, I’m sure you’d get the expected rate predicted by Shannon etc, using the state-of-the-art audio modem technology we all abandoned last century.
A good use for this “modem” technology might be a competitor to NFC. Unlike NFC, audio I/O is almost universal on general purpose computing equipment made within the last 15 years or so. 22.05kHz is nicely half the sample rate of CD audio and also ultrasonic, making it inaudible. And unlike NFC, it can (obviously) be carried on existing audio wiring and “broadcast” with existing audio equipment.
22.5KHz is barely ultrasonic, and still subject to plenty of noise. You can’t easily increase signal strength to beat the noise, without using a lot of battery power and sending wildlife mental. There’s also plenty of potential for interference between units, and s the issue of it being easily intercepted. NFC has a different set of abilities and problems, and they’re working on those.
Maybe it could have some narrow use with certain apps on phones, to exchange names and addresses, or stuff like Pokemon or other games stuff.
Should you ever need to transfer files between two airgapped laptops (airgapping usually means that external USB devices are also banned), use RFSM2400. It’s based on a robust military HF “waveform” as they call it, and it has built-in mail and file server. I’ve successfully used it even in noisy outdoor environments, but it’s best when the computers are inside and right next to each other.
Still, if you can install the software to start with…
Software modems were well established in the late 1990s, with the “Winmodems” that made up basically all internal modems. When I bought my modem I deliberately got an external 28.8 (fastest speed there was at the time, with it’s own CPU) to be sure it wouldn’t falter on my barely-adequate CPU. Eventually I got an internal 56K when they were a few quid each, on a machine with plenty of spare CPU.
Winmodems were basically just another DAC / ADC added into the same chip that did the onboard sound, for many PCs. For others, the DAC / ADC were on a card with very little else, just a couple of analogue components. Indeed on a few laptops you couldn’t use sound and the modem at the same time, they dual-purposed the one set.
The drivers contained all the code that ran on the PC’s CPU to convert data into waveforms to feed to the DAC, and the same the other way. They got up to 56Kbps, the limit of phone lines. Pretty sure Linux supported them eventually, so there must be quite a bit of software for this hanging round in kernels somewhere. Wonder what it’d take to extend the data rate / frequency range for better connections? Might be something good to apply when you’ve something too rugged for normal networking to run across.