[aprssig] DTMF-Paging Gateway to APRS

Bob Bruninga bruninga at usna.edu
Sun Jan 25 21:26:52 EST 2009


> Can someone define EXACTLY what this 
> gadget needs to do?  I've already 
> got DTMF decoder code written for the 
> HCS08, I'm just not clear what needs 
> to be done.  This is a duplex device 
> that sends and receives DTMF on one 
> channel and sends and receives APRS 
> messages on another?

Yes, basically.  This APRS<=>DTMF paging gateway is just a subset of the original APRStt gateway which used DTMF for user input and speech for output back to the user.

But since these thousands of TH78's and FT51's already have a text display then we don't need the voice synthesis.  We just send APRS text data to the paging screen of those existing radios using the paging protocol: www.aprs.org/FT51-TH78.html

The entire APRStt spec which is APRS-to-voice and DTMF-to-APRS has been detailed since 2001 in my APRStt docs, but this DTMF paging subset is much easier.  for Phase one there is only one DTMF user input and only a few Paging outputs as follows:

PHASE 1:
First, lets name this system as the DTMF-Paging Gateway to separate it from the full APRStt spec.

USER INPUT:  There is only one user input.  That is the users callsign stored in DTMF memory 1.  See www.aprs.org/APRStt.html to see how this one key is expanded to a full APRS packet on receipt by the FT51/TH78 gateway.

APRS=>PAGING OUTPUT:  There are only a few immediate outputs in this phase one implementation.  Recognize that the paging system requires a 3 digit address.  For APRS this paging address is "000" for all general APRS traffic.  For directed messages to a single station, the 3 digit address is simply the stations callsign suffix encoded as digits.  APR for example is 277.

Here are the conversions from the APRS channel to the DTMF paging channel.  All transmissions are to the group call of 000 unless noted:

1) Any APRS user, station, object heard direct or 1 hop only on the APRS channel by the gateway will cause the gateway to send two or more 6 byte fields as:
   A. CALLSIGN: CCCCCC
   B. POSITION: ZZZ MM  (az & range to GATEWAY)
   C. Frequency if it exists FFFFFF
   D. remaining commment text in sextets

Smart-word-wrapping is desired to maximize the use of the sextets, and avoid splitting words where possible.

2) Any FREQUENCY object heard on the APRS channel will transmit on the Paging channel two 6-byte fields:
   A. the frequency FFF.FFFMHz  as "FFFFFF"
   B. the Tone Tnnn as "Tnnn"

3) Any bulletin heard within one hop on the APRS channel will be converted to these sextets:
   A.  CCCCCC - the senders call
   B.  BLN#   - The bulletin number
   C.  AAAAAA - the text of the bulletin
   D.  BBBBBB - in sextets, etc

4) Any Messages heard on the APRS channel directed to any station with the suffix of XYZ will be sent as a page on the DTMF paging channel to the paging address of ### which is the DTMF hash of the callsign suffix.  For now, these are not stored, but are simply repeated each time the APRS packet is seen.

ANYWAY I will work very closely with any volunteer to finalize the details of this spec for optimum compatibility with existing and future APRS.

For example, how to shove a CCCCCC-SS callsign down into 6 bytes:

If no SSID, use full call.
If 5 byte call and 1 digit SSID, then combine to CCCCCS
if 4 byte call and 2 digit SSID, then combine to CCCCSS
any other combo, then drop the PREFIX bytes to fit.

>>> What we really need is someone to take 
>>> on the simple task of a PIC converter 
>>> to convert APRS messages to DTMF PAGING 
>>> text messages so that those dozens of 
>>> THOUSANDS of existing amateur radio 
>>> DTMF paging HT's can be used to receive 
>>> and send APRS messages.  

Bob, WB4APR




More information about the aprssig mailing list