💾 Archived View for station.martinrue.com › tm85 › 00457d8dcf4444e68eb0aa43f91f5068 captured on 2024-06-16 at 13:32:56. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2024-05-12)

➡️ Next capture (2024-07-09)

🚧 View Differences

-=-=-=-=-=-=-

👽 tm85

I want to make software for transmitting binary data over 3.5mm audio cables, but I'm not sure where to begin. Does anyone here have signal processing experience? .. or otherwise have ideas as to how I might interpret a high-sample-rate two-tone signal with potential noise?

2 months ago

Actions

👋 Join Station

11 Replies

👽 istvan

Also since you are designing the protocol you can test lots of things to find the sweet spot.

Eg transmitting 7-bit data with a checksum bit, or transmit 15 bytes and a checksum byte?

You need to build in some degree of error checking into your communication protocol and have a way for the client to tell the host to re-send the last packet. How much of your bandwidth is dedicated to that will depend on the wire, the length of the run, and ambient interference. · 2 months ago

👽 istvan

Can improve error rate with ferrite block on each end and choosing wire with a shielded, coiled ground.

Just solder the wire run onto 3.5mm stereo connectors. · 2 months ago

👽 justyb

I mean, if you really wanted, you can always toss something like a W65C51S and use charge pumps (or related chips like MAX232) to bring it up to RS-232 levels. A TRS jack could then be tx/rx/ground.

Which then you're just doing a serial port on 3.5mm audio cable. Again, you just have to watch for maximum bandwidth issues for given lengths of cable, the voltages on the wire, etc. But it doesn't HAVE TO be beeps and boops transmitted on audio cable. You can have digital serial data going across. · 2 months ago

👽 justyb

As @istvan has indicated, you do not need to have an analog signal it can be a digital signal no DAC/ADC required. Just UART on both ends. You can look at this thread (https://stackoverflow.com/questions/2181476/bandwidth-from-headphone-microphone-jack) to look at a discussion about what kind of bandwidth you might get.

Biggest thing is that the more you try to squeeze out, the more error correction/signal processing you're going to need. So if you want to keep it simple, you'll aim for low bandwidth utilization. But you can build it up as complex as you like up to the maximum the media allows for. · 2 months ago

https://stackoverflow.com/questions/2181476/bandwidth-from-headphone-microphone-jack

👽 istvan

You aren’t transmitting audio. Stop thinking audio cables have to carry audio. The headphone cable is just a three conductor cable between two modem devices. Wires can carry HIGH or LOW, 1 or 0. Unless you are trying to send an analog signal, which wouldn’t be digital anymore. If you can give clearer example of what you want to do maybe I can point you to something useful. What controller will you have on each end? Atmel or ARM microcontroller or something? · 2 months ago

👽 tm85

@ditheez Looking for a bit more speed than Morse could do - one of my goals is decent IP over aux audioo That said, Morse is very resistant against loss and could be a good fallback transport · 2 months ago

👽 tm85

@istvan Thanks for the wisdom, though I'm stuck a bit more fundamentally than that. What's a reliable way to interpret audio as a data stream? The tones won't always be 100% clean and there will be errors · 2 months ago

👽 istvan

You're asking to make a digital modem. It's not especially difficult. The main thing is just designing a handshake so the recieving device understand what speed the transmitting device is sending its data at. Then you just read HIGH or LOW off the line at the agreed upon rate. These are your bits. · 2 months ago

👽 ditheez

Made me think of Morse code. · 2 months ago

👽 tm85

My physical setup: given computer A and B, an aux cable runs from A's LINE OUT to B's LINE IN, and another from B's LINE OUT to A's LINE IN. · 2 months ago

👽 tm85

I've explored minimodem, and in concept it's what I need. However, it's missing a few things I want: 1) C or Rust or Py API/bindings, 2) full duplex communication, and 3) multiple carriers · 2 months ago