We’ve all been there: after assessing a problem and thinking about a solution, we immediately rush to pursue the first that comes to mind, only to later find that there was a vastly simpler alternative. Thankfully, developing an obscure solution, though sometimes frustrating at the time, does tend to make a good Hackaday post. This time it was [David Wehr] and AudioSerial: a simple way of outputting raw serial data over the audio port of an Android phone. Though [David] could have easily used USB OTG for this project, many microcontrollers don’t have the USB-to-TTL capabilities of his Arduino – so this wasn’t entirely in vain.
At first, it seemed like a simple task: any respectable phone’s DAC should have a sample rate of at least 44.1kHz. [David] used Oboe, a high performance C++ library for Android audio apps, to create the required waveform. The 8-bit data chunks he sent can only make up 256 unique messages, so he pre-generated them. However, the DAC tried to be clever and do some interpolation with the signal – great for audio, not so much for digital waveforms. You can see the warped signal in blue compared to what it should be in orange. To fix this, an op-amp comparator was used to clean up the signal, as well as boosting it to the required voltage.
Prefer your Arduino connections wireless? Check out this smartphone-controlled periodic table of elements, or this wireless robotic hand.
I guess this would work for inputting a raw serial data/uart stream into the phone as well. If the input is AC-coupled each transition of the data would be read as a short negative or positive pulse returning to a middle value that would be easy to decode…
sure, but uart itself does not have any requirement to have a zero DC level (i.e. equal number of ones and zeros over time). So it would work for short messages, but not long ones. Since analog circuits are already used, a better method would be to send a sine with small amplitude for zero and a sine with larger amplitude for one. That way there is always zero dc.
Or use FSK, like they did in the early home computer cassette recording systems.
https://en.wikipedia.org/wiki/Frequency-shift_keying
Ideal application for Manchester encoding.
But… Then we don’t have a plain and simple UART as the sender in the other end.
It can be done, if you don’t mind (at least) tenfold bit rate reduction.
If you set the uart to 8,N,1, than you know that long strings of back-to-back characters will have a 10 between the characters, so you can use that to form tones and vice versa.
E.g. series of 0x55s (it is LSB first, remember?) should produce continuous tone of frequency equal to half of bitrate, and series of 0xF0s should produce continuous tone of frequency equal to 1/10th of bitrate.
Let’s say one character time of lower frequency is symbol “1” (idle, for proper synchronization of receiving UARTs) and one character time of higher frequency is “0”. Now you can have the communication session start with unspecified minimal number of ones as preamble, followed by perhaps a single zero, and then the data may begin. I think it would be a good thing to put some rule for bit-stuffing, to break long runs of high-frequency bits, because otherwise receiving UARTs may lose the count where the character (a “bit”) begins.
Now if the audio inputs and outputs are band limited to max 20kHz, the maximum baud rate will be one tenth of double of that (aka one fifth), or 4kbps. One standard bit rate close to a match is 38400, which will produce tones at 3.84 kHz and 19.2 kHz, with symbol rate of 3840 bps. You can’t surf over that, but a chat, or some simple control, could work.
Or you could limit the available symbols over UART to just those that have proper DC.
Again, only for long messages without breaks in between. If you just want to send some command every now and then, it will work.
https://hackaday.com/2010/11/10/android-talks-pulsewave/ Here’s a good schematic for it and an android app with source code :)
Burkhard had taken this one step further and has FLASHED the chips via the Internet using audio – just for the Tiny13 and the 2313 for now as of the way they are programmed. Is something similar possible for the Arduino as well? https://www.amazon.co.uk/Cheepit-Sparrow-Programming-Mobile-Phone-ebook/dp/B074G54KRR/ref=asap_bc?ie=UTF8
Some similar work has been done by [Gordon Williams] for the Espruino platform monts ago. https://www.espruino.com/Headphone
Re-inventing the modem. Imagine a world where the best you could do 300 Baud because that’s just how Low-Fidelity that phone system was.
You haven’t seen 10 Baud settings, youngster?
Nope. About 100 baud with an effective 1 cps rate. Hellschreiber fax.
Or the 50 baud GPS…
The only 10 baud I’ve heard off was the deep space probes or Mars rovers. (docx)
Also, don’t forget the Tagsu, a programmable avr over audio…
http://tagsu.io/about
I think it’s the long Finnish winters that explain their creativity.
I wouldn’t count on USB OTG support. I just finished working on a project with (cheap) mediatek/allwinner android tablets where they stripped out OTG support. That said my phone did have it and so did a tablet from Lenovo.
i was playing with some modulation/demodulation techniques for CW and PSK and made pairs for both in js with the WebAudio API. Not perfect, code is messy, but it works. It can send and receive at about 200 bps in BPSK mode between 2 browsers, tested it with my android phone and firefox on desktop and works fine, even at close to inaudible frequencies.
https://labs.thygate.com/cw-psk-mod-demod/
might need to enable Stereo Mix in windows to make it work between 2 browser tabs.
The distorted waveform is very similar to floppy disk flux reversal signals. The MFM encoding makes sure the phase locked loop stays in sync while still being able to squeeze in a lot of data.
Here’s a capture I did on the rigol DS1054z over ethernet into my application. The top two traces are the digital flux reversal signals after processing using my own software filters (first one) and the floppy drive own digital read output. The bottom is the analogue flux reversal signal directly captured from the drive head.
http://www.makercentral.net/media/FloppyControl/Flux.png
Is it possible to do it without wires, by using microphone and speaker system ?
you made a modem