[aprssig] APRSTT from GPS
andrewemt at hotmail.com
Thu Aug 8 16:10:00 EDT 2013
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
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
> 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).
aprssig mailing list
aprssig at tapr.org
Sent from my Verizon Wireless BlackBerry
More information about the aprssig