[aprssig] APRSTT from GPS

[Andrew P.]

Uh, minor correction. DTMF only has 8 tones, and the combination of 1 tone from each group of 4 tones is what gives a 4-bit nybble, not an 8-bit byte.

But you could still do this, using two DTMF bursts per byte. Just would take twice as long.

Andrew Pavlin, KA2DDO
------Original Message------
From: Jason KG4WSV
To: aprssig at tapr.org
Sent: Aug 8, 2013 12:22 PM
Subject: Re: [aprssig] APRSTT from GPS


On Wed, Aug 7, 2013 at 5:25 PM, PE1RDW <aprs at pe1rdw.demon.nl> wrote:
> licence does not allow data communication only tone signaling like dtmf 5tvo
> etc.
>
> Would it be feasable to program a MPU to translate the NMEA input to a DTMF


Sure.  I personally wouldn't bother with APRStt, though - the
cell-phone style encoding is too gimmicky to decode easily, and it's
_really_ inefficient bandwidth-wise.

DTMF has 16 tones, which is conveniently 4 bits / half a byte.  2
tones can represent a single byte.

I would take an ASCII representation of an APRS packet (not binary
AX.25, and certainly no bit stuffing) and feed it out as bytes, 2
tones per byte, one tone each for the high and low nybles.  Frame it
up, add a CRC, and send it out.  An example framing would be to use an
NMEA style sentence "$XXXXX,CC*" where XXXXX is a printable APRS
packet.  Byte-stuff to replace any single * or $ with two (avoids
conflict with the framing bytes) and use the standard NMEA CRC
algorithm for "CC".  De-stuff/CRC check on the receiver, feed it out
the serial port, and your APRS app won't know the difference.

I did the math on this method (using DTMF as a modem) a couple of
years ago.  IIRC the data rate was a few hundred bits/second (using
timing from an 8870 DTMF receiver and assuming similar timing
constraints on the transmitter, as best I recall).

-Jason
kg4wsv
_______________________________________________
aprssig mailing list
aprssig at tapr.org
http://www.tapr.org/mailman/listinfo/aprssig


Sent from my Verizon Wireless BlackBerry