Analyzing audio with a Arduino isn't very simple for someone that just
wants to get data from a TI-84, and other devices, via a 3.5mm jack.
If you just want to communicate with a device like a TI-84 that uses a 3.5mm jack as just a connector for some type of serial interface, this shouldn't be too hard (although most of the helpful links online are dead.)
I don't know much about the TI-84 protocol, but since you wanted a basic tutorial, I'm guessing you may need some help with Arduino serial communication. Arduino Serial is a great place to start, and LadyAda has a good serial introduction.
Here is an image that shows you to make the connection, (I'm not sure if any level converters are needed, but you can read the link below.)
And the code and discussion can be found here: Arduino to TI Calculator Linking Routines
PS: I don't want to use a modem like this, I to learn and make it not
communicate only with iOS/Android devices.
I think the board you quoted is basically a level converter, converting 3.3volt signal to 5volt arduino, and vice versa. Also it said it was a 4 conductor cable so it is different than the TI-84 cable, I believe the TI's is only a 3 conductor.
Links:
The 3 headphone buttons you referred to do not pass information digitally, but are being signaled electronically using change of resistance, as explained here: How do volume control headphones work?
In the case of the headphone buttons, you can say information about pressed buttons is being passed "out-of-band" - it doesn't occupy the audio in or out channels (except maybe for the moments of time a button is depressed).
The answer by "cagrigurleyuk" above is incorrect, in addition to being incomplete.
Yes, the Shannon-Hartley Theorem places the upper bound of bit rate that may be losslessly transferred within a given bandwidth, at a given SNR.
The quantization noise for a digitized channel is modeled as a SNR of \$2^Q\$ (where Q is the amount of resolution bits), in which case \$B\cdot\log_2 \left( 1+SNR \right)\cong B\cdot Q\ \$, so for the numbers mentioned above (20kHz bandwidth and 12bits), the theoretical upper bound would be 240kbps (not 500kbps).
In reality, you actually have a bit more bandwidth (up to 24kHz, for a sample rate of 48kHz), and less quantization noise (as the maximal resolution is often 16 bits), but you do need to take into account more noise sources on the line that lower the total SNR (the worst noise source probably being the amplifier).
Finally, the number originating from Shannon-Hartley Theorem is, again, just a theoretical upper bound.
The actual bitrate you can achieve is a function of the modulation and encoding schemes you use, which themselves are a function of the program's efficiency, and the processing power that is available to you (due to realtime limitations). The processing power and the program's efficiency are unknown to us, which is why we can't really fully answer this question. Also unknown are the capabilities of your buttons, or transmitters.
I can give you some pointers, though:
- With a proper design of communication protocol, the buttons probably need not send data while they are not being depressed, so you are actually theoretically limited by the amount of buttons pressed at once, rather than the amount of total buttons. E.g., your average keyboard has hundred-something keys, but only uses a transfer rate of around 12kbps.
- The spectral efficiency (a figure of how many bps of throughput you can cram per a Hz of bandwidth) of various digital modulation (or keying) methods are listed in a table in page 17 of this PDF file, for your reference. The higher the spectral efficiency, the more complex the algorithm would be, which would accordingly require more processing power for realtime performance.
Best Answer
It shouldn't be too hard to solve this problem in a way which is fairly platform-agnostic and flexible across the possible variations of your application need.
First, you need to find a circuit for injecting an audio signal into the headset jack; as headsets with wide compatibility (iphone, most android devices, and probably more) are available on the market, this is clearly possible. I believe it has been covered here before.
Then you need a means of data transmission which is easy to implement, and which is fairly immune to variations in the phone model, components, temperature, etc.
Trying to send an analog voltage level directly would likely not be - the phone (or at least input circuit you use) will likely block DC, and even if it does not you have a hard time knowing the precise gain on the phone's input circuit.
So something which encodes information over time is probably going to work better. A simple solution would be a voltage-to-frequency converter, or voltage-controlled audio oscillator. By producing a tone with a frequency proportional to your signal, and then measuring the strongest frequency in software on the phone, you'll have a fairly reliable system. It will be somewhat subject to the accuracy of your modulator though - for example, if you hack something up with a 555 it may depend on non-precision capacitors whose value varies from example to example and over temperature.
Another option to look at would be a digital modem - for example frequency shift keying. You could simply pull the specs for a 300 baud telephone modem and approximate such a signal with a square wave output from a little processor such as an ATtiny, PIC, MSP430, etc, using the processor's ADC to read the sensor and come up with a number you want to encode. If you don't need to take measurements very quickly, you could lower the baud rate still further and make the decoder easier to write.
In summary, by modulating some aspect of the signal such as frequency which is less subject to device-to-device variation, you can build a system which will be fairly universal - only requiring that you create a build of your demodulator software which can be linked into the structure of a basic audio record-to-buffer type application in the SDK of each type of phone you want to support.