APRStt Callsign Processing Routines 19 May 08 ---------------------------------------------------------------------- For full info: http://www.ew.usna.edu/~bruninga/aprstt.html USER CALLSIGN DTMF ENTRY: Please see the USER ENTRY web page that describes how the user enters his DTMF callsign. The page is http://www.ew.usna.edu/~bruninga/aprs/aprstt-user.html Basically the format for a callsign that the user stores in a DTMF memory is: ##AcccccccccccKD Where ## always begins an APRStt burst (kind of a PREP key) Where A indicates a callsign will follow Where cccccccc is the callsign using text messaging technique Where K is a checksum to minimize errors Where D signals the end with the "D" (or OK) key CALLSIGN-SSID: By default, an APRStt callsign will be assigned an SSID of -12 so that these callsigns are easily destinguished from other callsigns from the same station on the air. Exmaple WB4APR: ##A9220427A770D (checksum 30 = "0" SHORTCUT: Once you have identified with your full callsign, you can make subsequent transmissions with only the right three characters (or numbers) of your callsign. So for me it would be "APR" and that would spell out in DTMF as a callsign as: ##A27A773D (checksum 23 = 3) The APRStt engine will decode that to "APR" and scan its list of active APRStt users and to a RIGHT-END-MATCH. If there is a match, then that is sufficient. If there is a conflict, then additional characters are needed, but still right justified. APRStt PROCESSING: OK, that is how the USER identifices himself. THe rest of this text file describes what the APRStt processing does to convert that call sign in to APRS information for transmitting onto the APRS channel To setup any APRStt system, the repeater (or other APRStt) processor needs to be configured with some basic information. Since the output of the APRStt engine is an APRS object each time a new DTMF "CCCCCC" callsign identification comes in, all the SYSOP has to do is set up a template for that basic OBJECT packet that will go out on APRS. There are two forms of the outgoing APRStt packet, depending on whether it is generated as an APRS OBJECT for transmission by a hardware TNC, or can be generated directly in KISS mode to a KISS TNC or directly into the internet. The following are the two representations: OBJECT FORMAT: (includes the TNC header. (it line wraps here, to fit) SYSOP>APTT00,WIDE1-1:;CCCCCC-12*111111zDDMM.AAN?DDDMM.BBW= FFF.FFFMHz Tnnn Rxxm 777777 To send this packet out through a TNC, the TNC is already configured with its SYSOP callsign and the UNPROTO PATH of APTT00 VIA WIDE1-1. Then the serial data beginning with the semicolon is sent to the TNC in CONVERSE mode where it is transmitted. KISS FORMAT: (displayed as it would be received in TAPR2 format) This format would be used if the APRStt processor is able to generate its own original packet complete with a new header for every packet. This is what would be sent over TCPIP to the global APRS-Internet system (APRS-IS) if a network connection is in place (such as Echolink nodes). CCCCCC-12>APTT00,WIDE1-1:!DDMM.AAN?DDDMM.BBW=FFF.FFFMHz Tnnn Rxxm 777777 Where CCCCCC is DTMF decoded callsign. (-12 is the default) Where DDMM.AA is Latitude of the APRStt engine (see notes on AA) Where ? is OVERLAY character chosen by the DTMF user Where DDDMM.BB is Longitude of the APRStt engine (see note on BB) Where = is APRS symbol for APRStt users Where FFF.FFFMHz is freqeucny of this APRStt engine Where Tnnn is tone (or Toff, or anything else) Where Rxxm is useable range in miles (Rxxk in km) Where 7777777 are 7 additional available bytes MAP PLACEMENT: It is important to note that the LATITUDE (and maybe longitude) will be randomized in Tenths of a minute for all the different DTMF users. This will tend to make a LIST of these objects and callsigns on any APRS map display at the local scale. Some APRStt repeaters may want this list to be to the East. Some may want it to the WEST, or North, or South or in any of the quadrants around the repeater. The SYSOP should carefuly consider where to place this LIST display as an area within a mile of his repeater where he normally does not expect to see any other APRS activity. This way the map list does not sit on top of anything important. Here is an example of how an EASTERN list would show on the map: * WB4APR-12 * KB3GLF-12 * W3ADO-12 R 147.105-tt * AB3XYZ-12 * KK3ABC-12 Notice how the Repeater FREQUENCY object itself is at the basic LAT/LONG but then the added users are placed above and below by a tenth of a minute (or about a 10th of a mile). LATITUDE.AA DIGITS: In APRS, repeater objects do not need to be placed on the APRS map very precisely, since they cover many miles range. So SYSOPS can be creative in the placement of their repeater object to force the list to be wherever it would be the least obtrusive on the map. By choosing a DDMM.5_ as the position of the repeater FREQUENCY object, this simplifies the code for using the other tenths of latitude for the random DTMF users. 6,7,8,9 above and 4,3,2,1,0 below. Notice that the HUNDREDTHS digit will always be a SPACE character which represents less precision in an APRS posit. LONGITUDE.BB DIGITS: Similarly, the SYSOP chooses his first B digit to best locate where he wants the Repeater object and hence the list to be. As APRStt catches on and the number of active users near a repeater grows to more than 10, then the first LONGITUDE may have to be incremented or decremented a mile to allow for additional columns of callsigns on the map. BUT it is doubtful this will ever be needed. Because as long as the list contains the last 10, and overwrites the oldest ones, then they may no longer be transmitted, but they will be retained in the APRS system for DAYS. So for now, lets just go with a limit of 10. Choose the TENTHS B digit and always let the second HUNDREDTHS B byte be a SPACE. This preserves the ambiguity of the data. MEMORY REQUIREMENTS: The APRStt processor has to have a memory bank for as many DTMF users that are active per hour. After a DTMF user has not been identified for more than an hour, then he should fade from the map like all other APRS users that are inactive. Lets just use 10 for now as a starting point. The FIELDS that must be kept are: CALL,S,X,L,T,P Where CALL is is 6 character callsign Where S is the SSID (defaults to -12) Where X is the overlay SYMBOL character he has chosen Where L is the last LATITUDE digit you used for him Where T is a single byte Timer down counter Where P is a next-period digit PROCESSING FLOW CHART: THe following pseudo code describes the processing required but the APRStt process: NEW DTMF user report comes in... Scan above list of last 10 calls heard. Is old call? then: Set his Timer to 0 and Period to 1 and reuse his LAT goto * TRANSMIT routine... Is NEW call? then: Add him in place of the OLDEST call (biggest P) Re-use this oldest one's LAT digit Set his Timer to 0 and Period to 1. goto * TRANSMIT routine... TRANSMIT ROUTINE: Transmit the packet. Double the P period and set T = P. TIMING: Once every minute decrement the TIMER digit of all 10 memories. If any are 0, then TX them and DOUBLE their P and set their Timer to their new P. Notice this is the same * TRANSMIT ROUTINE above. It is what you do every minute. The combination of TIMER byte and PERIOD BYTE is what makes the APRStt engine Transmit new stations immediately, and then decay the Period longer and longer as time progresses. So for a new station, the next packet will be a minute later, then 2 min later, then 4 min later, then 8 min later, then 16 min later, then 32 minutes later etc until P equals 64. LIST MAINTENANCE: Also every minute you check for any values of P that are greater than 64. These you eliminate AND preferably do a LIST clean up. If you forced the repeater location to be at a latitude ending in .5, then here is a suggested algorithm. If the eliminated station's Latitude byte is greater than 5, then you scan the list for the largest Latitude Byte, and MOVE his data to this cleared position. If the eliminated station's byte is less than 5, then you scan for the lowest Latitude byte and move him to this vacated position. CLEAN LISTS: The idea is to keep the list closest to the repeater's basic position so that the list is concise. As the popularity of this system grows, this algorithm may need to get smarter to handle more rows and columns. But by eliminating any calls that are older than an hour, the list will usually be small. Or just keep it at 10 and then it simply always shows the 10 most recent users. But still if they are older than an hour, they should not be transmitted. The older ones remain with the global APRS system for 10 DAYS. DTMF CALLSIGN FORMAT: --------------------------------------------- The proposed format for the DTMF callsign is: ##AcccccccccccccccKD where # is a pre-key to alert the repeater controller to get ready Where A is the key used to indicate a callsign Where ccccccccccc is the callsign using normal text messaging Where K is a check sum digit Where D is the termination byte. The encoding of the "cccc" uses the multiple-key press technique to spell out callsigns. FOr example, D is the 3 key, E is 33, and F u=is 333. But if two such keys are in a row, then the "A" key must be used as a separator. SO the sequence DEF would require 3A33A333. Numerals are usually four presses. SO the callsign numeral 6 would require 6666 to properly encode. However, for this callsign decoder we are proposing a shortcut for the digit in the callsign. That is the "0" key. Instead of using 6666 to encode "6" we can use 06 instead. The "0" will always mean to use the next digit as an actual digit. To use a "0" itself in a callsign, would also require the leading "0" such as "00". This saves two bytes which is important for some calls while trying to get them into a 16 bytes DTMF memory. ANTI-FALSING: The text messaging spells out many letters with several multiple key presses of the same buttons, and this can be problematic during mobile flutter. Further, if the leading format characters #A are missed, then the repeater controller could interpret subsequent digits as a command. To avoid this, two special features are involved: 1) There are two ## keys used to improve the likelyhood of detection 2) The repeater controller will block out all commands during the three seconds following the detection of at least one of the # keys. 3) The extra leading # key will be ignored if received. 4) A checksum digit on the end must match the computed checksum APRStt REPEATER IDENTIFICATION: ----------------------------------- All of the above syntax is related to how the USER packets are generated. In addition to those packets the following additional packet has to be sent out once every 10 minutes to put the APRStt repeater or node on the map too: ;FFF.FFFtt*111111zDDMM.5_NRDDDMM.m_W= Tnnn Rxxm Net 9pm T 777777 Where FFF.FFF is the repeater frequency. The LAT/LONG are the same as used by the User packets, except this one is not randomised but always remains in the same LATITUDE location. Notice that the HUNDREDTHS of LAT and LONG are SPACES (not _ as shown here). As before the "Tnnn and Rxxm" are the tone and range. Then you can have a TEN byte field showing the weekly net times, etc. And after that are an additional 7 bytes of brag text if desired. Additional text can be used, but nothing after the 777777 will be seen on other D700 mobiles and nothing after the Rxxm will be seen by D7 HT users. For more detail on how these FREQUENCY OBJECTS are made and desired formats, see: http://www.ew.usna.edu/~bruninga/localinfo.html In this case the symbol is the same APRStt symbol, but with an R overlay showing it is the REPEATER. TNC CONFIGURATION: In order to send the above OBJECT format over the air, a TNC needs to be connected to the APRStt engine's serial port. The TNC should be placed into CONVERSE mode, so that anything coming out the serial port will be immediately transmitted onto 144.39 in North America. Besides making sure the TNC is in CONVERSE mode, there are only 2 other settings required: MYCALL - The sysops or repeaters callsign UNPROTO APTT00 VIA WIDE1-1 Do not set any BText or other beacons. Your APRStt code is now doing all of that. CHECKING THE SYSTEM: At any time, you can see how the APRS system is parsing your data by using the following URL: http://map.findu.com/FFF.FFF* This will find your FFF.FFF repeater object and the * will let you see if anyone else is using your same frequency (any where else in the world). You need to choose the 2 bytes on the end of your FFF.FFFxx to be unique in the world in order to have your repeater always show up at the same spot and not be replaced by someone else's identical FFF.FFF repeater. In the above example, I used "tt" as these two additional bytes since the first person on each frequency can grab those and force everyone else to find soemthing else to use. Tell your DTMF users to find themselves at the same URL: http://map.findu.com/CCCCCC* where CCCCCC is their callsign, and the * again is a wildcard to make it easier to see all of their APRS applications. Bob, WB4APR