Technically this is DSL over webaudio as it's transmitting signal levels and then interpreting them directly. If you wanted to encode the audio in the serial you would use a tonal system like frequency shift keying or phase shift keying.
So if you want to take this experiment one step further, consider doing FSK or PSK audio and add a non-return-to-zero (or NRZ) serial protocol. With NRZ the clock is actually embedded in the prototcol so with a software implementation of a phase locked loop you can recover the clock and data signal and reliably transmit from two different clock domains. (the article depends on you being able to hit one of the known baudrates accurately enough for the serial code to recognize it.)
Then for extra credit you can embed multiple frequencies in your tones, so that instead of sending ones and zeros you're actually sending 2 or 4 bit equivalent bauds. Then you can have fun doing a quick FFT on the receiving end and clock recovery to pull out multiple bits and the clock.
FWIW, the path goes very very very far down the rabbit hole.
And learning the difference between clock recovery and self clocking is always fun too right? The cool thing about NRZ is that it was commonly used in Floppies and tape drives so there are lots of circuits to look at and get a feel for how it works.
Somewhat related to this, several years ago I have successfully used FSK[0] to transfer data[1][2] from an AVR microcontroller to iPhone through its headphone jack.
I'd like to see one like this that works through the free air -- it so much more compatible with the spirit of the age where people are even resentful of putting a power cord into a laptop or phone.
The old 300 baud did, and at that data rate you can transmit a 19 character URL in 0.5s or for that matter a 128-bit UUID/GUID.
This is the same principle as DEX. Just with a speaker / mic setup instead of some sort of rs232 cable with 1/4" jack. What would be interesting is if you could use a sonic range below what humans can hear and still be effective with an open speaker / mic setup? Lights, hvac type controls would be very doable.
Not really. The human ear can perceive down to 20Hz, and below that, you can't perceive it actively, but the subconscious starts playing weird tricks [1]. Plus, you'd be limited to X Hz/2 bits per second. Your better bet is getting something to drive an occasional chirp at 20k hz or so, which would be imperceptible to most people.
This is really cool and something I've wondered about doing too. Has anyone gotten an entire GCC toolchain to 'compile' to JS using a tool like emscripten? It would be pretty neat to be able to compile AVR firmware and send it to an Arduino's bootloader right from the browser.
Something a little easier and perhaps a bit less hacky IMHO is the web audio MIDI standard. You can make certain AVRs (the 32u4 in the Arduino Leonardo) look like USB devices, including a USB midi device. Then just have a web page that uses the new web audio & MIDI APIs to send data directly to the 32u4 as MIDI messages. No need to convert to audio, etc.
You wouldn't need any changes to the AVR side to do that, because the bootloader doesn't need anything special other than a reboot to get it into programming mode. However, if you've got an android device, the easiest, most reliable, way to program it would be to get a $3 usb otg dongle and just plugging your arduino into that. There are tons of free apps that will burn a new program on from there.
> You wouldn't need any changes to the AVR side to do that, because the bootloader doesn't need anything special other than a reboot to get it into programming mode.
Then you AFAIK need an additional chip for the programming. Which e.g. the Arduino has, but you'd not necessarily add to your own design.
> However, if you've got an android device, the easiest, most reliable, way to program it would be to get a $3 usb otg dongle and just plugging your arduino into that. There are tons of free apps that will burn a new program on from there.
+ "there is an android app for that" is exactly the thing you can avoid with such a setup, once WebAudio is reliable enough you just can distribute a link to your users and they don't need any third-party software, you don't need to maintain documentation for it, ... Having seen quite a few support discussions for DIY projects that distributed pre-programmed chips this would be useful in some cases.
No additional chip needed. With the USB Serial chip, the only special thing programming does is it's got one of the unused lines on the usb serial chip, RTS IIRC, hooked up to drive the reset pin low. The bootloader that the Arduino uses listens on the serial port for a magic number on bootup to enter into programming mode, no special chip needed.
With the webaudio setup, I guess that's fair enough. For being absolutely foolproof being able to say to go to a specific webpage and then press play on tape is something we've been doing for a while. I personally prefer USB/Serial programming, but that's possibly just me having dealt with too many hand-me-down radios with scratchy headphone jacks over the years.
As cool as this is, it does seem to take the protocols-within-protocols trend to a farcical extreme. The stack for this is:
Upgraded Phone System (As opposed to POTS.)
Internet Protocol
TCP/BSDSockets
WebSockets
WebAudio
A final layer so that you can emulate a POTS over WebAudio.
That's not really any fault of the authors, I'm just curious how many layers we're going to stack up before we start unwinding the coil for performance reasons.
Once the javascript is loaded into the phone via web browser, my understanding is that the only steps left is direct connection to audio jack from the web page that is loaded into the browser.
Certainly there are implications that this data (once generated by the browser) could be retransmitted over the web to some remote hardware, but it's not critical to get this to work.
Before that, MPLS: IPv6-in-IPv4 over PPPoE over HDLC over MPLS over an Ethernet VLAN inside a service provider's VLAN (Q-in-Q) over MPLS CSC to another ISP halfway across the country to ...
So if you want to take this experiment one step further, consider doing FSK or PSK audio and add a non-return-to-zero (or NRZ) serial protocol. With NRZ the clock is actually embedded in the prototcol so with a software implementation of a phase locked loop you can recover the clock and data signal and reliably transmit from two different clock domains. (the article depends on you being able to hit one of the known baudrates accurately enough for the serial code to recognize it.)
Then for extra credit you can embed multiple frequencies in your tones, so that instead of sending ones and zeros you're actually sending 2 or 4 bit equivalent bauds. Then you can have fun doing a quick FFT on the receiving end and clock recovery to pull out multiple bits and the clock.
FWIW, the path goes very very very far down the rabbit hole.