iOS Serial data over Audio (Mic in)

[xArtx]

Hi Guys,
I'm wondering, for lack of a serial port, if anyone has done,
or experimented with sending serial data through an iPhone audio port?

I have seen the same on an android phone where a connection was made
to a handheld amateur radio for packet data which works quite well,
and am somewhat interested in duplicating that for iOS.

If I could get a head start that would be great
Failing that, I might have to see if I can look at the Android source.
Cheers, Art.

 

[1458279]

I saw a show 'Security Now' that looked into sending data to a computer thru the speaker. IIRC, they proved that it works.

One option is to make it work like the old acoustic modem (coupler). It's not fast by modern standards and very prone to error so the error checking is important.

Example: You send a 'packet' of data, the other side confirms what was sent and resends if it doesn't match. They use CRC (IIRC a type of checksum) to confirm the size.

http://en.wikipedia.org/wiki/Acoustic_coupler

Basically you'd have a universal timer, then send info zeros and ones as noise vs no noise.

So you could send for example, 1 segment per second, it will either be a sound or no sound. Then convert this to digital: 10010111 and this would be a letter or number. This is why it's really slow.

You'd have to play with the time, maybe 8 bits / second as one example.

You could have the tone higher than a voice tone and then you isolate that tone and ignore all others.

Another option is to do a low level speech recognition where you look for several tones/patterns This can be much faster but more work.

You could start with one of the examples like "speak here" that shows a bar graph as you speak, then record a pattern and search for that pattern.

It would basically be a subset of a full speech recognition program.

 

[xArtx]

Thanks for the reply

Unfortunately, I'm not the one setting the standards.
The Android version, I only witnessed for the first time Monday night at a ham radio club.
The modification to the radio does include access to the push to talk button,
so it's possible it can reject and request packets from the transmitting end.

I'll know a lot more detail/theory after the weekend when I visit one of the members that knows about it.
I'm only fairly new to the amateur radio side of things, but it looks like some fun can be had.

 

[1458279]

Thanks for the reply

Unfortunately, I'm not the one setting the standards.
The Android version, I only witnessed for the first time Monday night at a ham radio club.
The modification to the radio does include access to the push to talk button,
so it's possible it can reject and request packets from the transmitting end.

I'll know a lot more detail/theory after the weekend when I visit one of the members that knows about it.
I'm only fairly new to the amateur radio side of things, but it looks like some fun can be had.

Having the ability to send info back is very important. They used to call this Ack/Nck IIRC. It tell the sender to resend if the CRC didn't match up.

You don't have to control the standards, you just have to know what they are. Example, you if they tell you what the speed is and what's going to be sent, you can write a routine to convert back to digital. Most likely they'll have on/off, 0/1 and they'll be in fixed groups with a CRC checksum.

Basically you need to know what the structure of the packet is. Usually it's a header, data, checksum and the header might include the current packet number and total number of packets to be sent.

Your code might start a few timers, one might be when you get the header, and then count the bits and compare to the units of time (sound/no sound compared to time).

If a packet fails to pass the checksum check, they should have a resend command.

It's not going to be fast, but it does work.

 

[firewood]

It's called audio modulation and demodulation, with methods/modes such as FSK, QPSK, PSK31, OFDM, etc. Essentially one device sends a special sequence of special audio tones and the other device detects it. There's plenty of public domain software on how to do such, once you get software access to the mic and speaker, which is fairly easy for iOS apps. You may not even need a handshake if the transmission scheme uses enough forward error correction.

Even old Apple II's (circa 35 year old technology) could send data using the tape cassette audio port (if you are old enough to know what cassette tapes and players looked like).

 

[xArtx]

Even old Apple II's (circa 35 year old technology) could send data using the tape cassette audio port (if you are old enough to know what cassette tapes and players looked like).

Well yes, but for me it was a Sega SC3000H, but I would take a stab that for
an 8K RAM machine, at whatever speed it was running, it was a hardware implementation.

 

[firewood]

The Apple II used a single D-flop for output, and the equivalent of a 1-bit ADC for input, thus requiring a tape format modulation/demodulation scheme that was entirely done in software (6502 timing loops).