I am looking for a way to get my phone to output a TTL level signal, up to about 1200 baud. Any suggestions?

The only thing I can think of is using an audio output with a square wave signal, and then amplifying it. Is that workable? Anything better?

  • 8
    \$\begingroup\$ It is called a modem. \$\endgroup\$ – Oldfart Dec 18 '19 at 17:19
  • 1
    \$\begingroup\$ TC Electronic's TonePrint uses phone audio to excite the electric guitar strings to transmit settings to their TonePrint amplifiers. Electric Imp flash the phone's screen to transfer IP configuration to their IOT devices. \$\endgroup\$ – Transistor Dec 18 '19 at 17:20
  • 1
    \$\begingroup\$ you used "cellphone". Is this about transmitting data over an telephony channel, or are you just looking to add a GPIO to your smartphone? \$\endgroup\$ – Marcus Müller Dec 18 '19 at 17:41
  • 1
    \$\begingroup\$ Some phones include digital interfaces. Mine does, for example, and they include a module I can buy to design and wire up a custom circuit that can be operated from the phone, as well. The interface is documented. But I think you need to address the comments here (and answers) and clarify your question a bit more, too. You didn't write much and, so far, haven't responded what's in discussion here and now. \$\endgroup\$ – jonk Dec 18 '19 at 19:10
  • \$\begingroup\$ @MarcusMüller Like I said, I want a TTL level signal from my phone. It can be GPIO (somehow...), USB/Bluetooth addon (possibly), audio out. The data to be transmitted over the TTL link originates in the phone. The TTL link then controls other electronic interfaces \$\endgroup\$ – Dirk Bruere Dec 19 '19 at 9:35

Use a non-linear amplifier to get TTL levels, in the form of a comparator with it's threshold set a the mid-point of the audio waveform level. Possible devices might include an LM360.

This won't work for frequencies near zero, as audio output will likely stay close to the threshold and near the noise floor, producing garbage. But will work for a high enough minimum toggle rate.

If you need to get a TTL output toggling at any frequencies from 0 to 1200 Hz, then another strategy is to output a much higher frequency audio signal (say 12 kHz) for the duration of your TTL high, and use a bandpass filter on the output to filter and detect this tone (diode + cap, similar to a AM crystal radio detector) before the TTL output comparator (with its threshold set above the zero-output noise floor and below the bandpass filter ripple).

If you output a lower frequency, say 2400 Hz, to indicate TTL high, another possibility is to use an Arduino chip, audio to ADC input, and measure the time between threshold crossing to detect the tone frequency needed to output a high level on another IO pin. But this lower audio frequency will limit the minimum duration of your TTL pulse transitions (and quantize them in time).

A higher audio frequency will also quantize the TTL output in time, but at a higher time resolution. So an appropriate USB audio DAC might allow very high audio signaling frequencies by supporting a sample rate of 96k or 192k. This would likely provide even better time resolution for your TTL output than signaling via USB (OTG) serial or ethernet packets, as a streaming real time audio driver on a mobile device (RemoteIO on iOS) has much more deterministic latency than either the USB or the network stack drivers on the mobile OS.

  • 3
    \$\begingroup\$ The real question is if the path is AC coupled before you can get at it. If it is, that imposes some rules on the sorts of raw patterns that can be sent - avoiding bit patterns which produce a DC component is one strategy, using audio FSK another. \$\endgroup\$ – Chris Stratton Dec 18 '19 at 19:10

a way to get my phone to output a TTL level signal

I assume that this is just about adding a TTL output to a smartphone, not about transmitting data through a telephony channel, since you're not mentioning that anywhere.

The only thing I can think of is using an audio output […] Anything better?

Modern phones have a USB on the go port, meaning that they can act as host to USB devices. For example, USB-to-serial (TTL) adapters. So, plug one of these into your phone, and write an app that has access to USB and interfaces with that adapter. Usually, if you're using one of the more popular USB-to-serial adapters, it will be known to the Linux kernel on an android phone, and unless the manufacturer stripped out that kernel module, you'll see it appear as /dev/ttyUSBx, and can just be dealt with like on any other Linux machine.

Same would be possible via bluetooth, since that has a general-purpose serial profile, too.

Other options include:

  • Blink the LED from software. Photodiode or -transistor, bam.
  • send out bluetooth LE beacons with the desired bit sequence as payload and pick them up with a BLE-enabled microcontroller board.
  • display a "bar code" on your phone with say 17 bars, and place phototransistors on top of each bar, add a 16-bit parallel-in-serial-out shift register, each parallel input one photodiode, clock with the 17th.
  • \$\begingroup\$ some phones have USB OTG. In practice it has a lot of problems even when supported, for example you start running down the battery. And once no longer new the cable may not make glitch-free connection if the phone is being handled. \$\endgroup\$ – Chris Stratton Dec 18 '19 at 19:09
  • \$\begingroup\$ @ChrisStratton that connector blues applies to every connector that might be in the signal chain, and charging, too, so I'd argue that this is a fairly well-"accepted" problem... I've not used a phone without USB OTG in quite some time, but you're right, that's not a universal feature. Re: power consumption: a well-behaved USB controller should use negligible power when idling away. \$\endgroup\$ – Marcus Müller Dec 18 '19 at 19:16
  • \$\begingroup\$ In practice, compact USB connectors are far flakier than many others. In terms of power, the phone itself is likely being active, which may mean that the unified port needs to be used as a power input to the system, which conflicts with OTG expect in the case of special modes and cabling supported by a few devices. \$\endgroup\$ – Chris Stratton Dec 18 '19 at 19:46
  • \$\begingroup\$ @ChrisStratton yeah, that "can you charge while in use" consideration is a very valid one, but would honestly make one wonder why it has to be a phone and not, say, a single board computer with TTL-capable GPIOs (and a separate modem, if necessary). \$\endgroup\$ – Marcus Müller Dec 18 '19 at 19:47
  • \$\begingroup\$ On an iPhone, blinking the flash or the display will limit your TTL toggle rate to 60 Hz (the display refresh rate). BLE has even worse time quantization. MIDI over BLE is slightly better, but nowhere near 1200 baud. \$\endgroup\$ – hotpaw2 Dec 18 '19 at 20:33

That is how computers and synthesizers saved data to cassette tapes back in the day. Some had analog audio interface to work with normal cassette recorders, and the ones that had TTL interface just had a similar analog interface stage in the tape deck. You don't even need amplification. Just AC couple the signal and feed it to a comparator circuit, preferably one that has some hysteresis built into it.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.