APRS Default Parser (Vicinity plot by default) 20 April 2008 --------------------------------------------------------------------- The objective of APRS was to give everyone a clear view of all HAM radio activity around them as evidenced by monitoring packets. As the years go on, I am frustrated by the inconsistent handing of APRS packets by the variety of follow-on APRS client applications. To help writers, the following pseudo-english-code is how AX.25 packets are supposed to be parsed. When done properly, a single packet heard (no matter what the format, and no matter what the application) should be sufficient to place that station in the APRS system. The following fundmamental information should be captured about the sender: 1) His callsign 2) His operating path 3) His approximate location 4) What was in his last packet. It is this capture everything-you-can about any packet that I fear has been overlooked in many follow-on applications. The following top level parser should be the basis of all APRS programs: An APRS station (or any station heard on an APRS channel or on any channel for that matter) needs only three basic storage variables. - His last position - His last Status - His last PATH Messages, are treated differently since any station can have any number of outstanding messages. And there can be bulletins, acks and so forth. The last category is Queries which do not require any storage variable. THE APRS PARSER: Simplistically, An APRS parser only has to look for four fundamental packet types in this order: DOES CALLSIGN/SSID EXIST IN MY DATA BASE? IF NO THEN Create this callsign in my data base Create a NULL POSITION Create a NULL STATUS Create a NULL PATH (if not retained with position) END IF CONTINUE PROCESSING THIS PACKET: SAVE PATH in PATH variable (this is updated on every packet) IF a position THEN save in POSITION variable If a STATUS then save in STATUS variable IF a message (or ack) THEN go process messages, etc... IF a Query THEN go process and respond ... ELSE IF NONE OF THE ABOVE, THEN DO THE FOLLOWING 'This is what is inconsistent and overlooked in some clients... If POSIION is still NULL Then assign VICINITY POSIT IF STATUS is NULL or not real-status, then put THIS packet there END END Using the above top-level parser then assures that no one will be invisible to the APRS network as long as at least one packet has been heard from that station of any kind. From this packet, we can infer the following important information: 1) Makes him known to the APRS system 2) Makes his path known 3) Saves his last packet (in status if he has not sent an APRS status) 4) Places him somewhere on earth based on our best estimate of his position based on the Vicinity Plotting algorithm. VICINITY PLOTTING: Vicinity Plotting is the name given for making the best estimate of a station's position in the absence of any other specific position information from that station. Usually, every station, on the first packet heard, is assigned a "vicinity plot" until it is overwritten by more precise position information generated by that station. The following algorithm is used on any packet that has been received from any station and a valid APRS position has not yet been received: IF first digi in PATH (DIGI1*) is in this data base THEN - Take DIGI1's LAT/LON to DDMM.__ (1 mile ambiguity) Randomise the TENTHS digit of LAT & LON - Use AMBIGUOUS Symbol (\.) (a big question mark) - insert "Vicinity plot" in the POSITION remarks field - Use this postion to replace the NULL posit ELSEIF heard direct by IGate (,qAo,IGATE), THEN - Do same as above based on IGate's callsign ELSE (heard direct by this station) THEN - Do the same as above based on own-stations position SPECIAL CASE: However, if system is listening on a non-local channel such as HF or the internet, then it is better to process the staion using the APRS global CALLSIGN LOOKUP table: - Use my DXCALLS.DAT file that gives LAT/LON for all Call Prefixes - Assign LAT/LONG only to nearest DEGREE. - Randomise the "tenths Minute" digit - Use DX SPOT SYMBOL (\d) - Insert POSIT TEXT: "UNKNOWN POSIT BY CALLSIGN LOOKUP" - Replace NULL posit with this posit OR YOU CAN create a random position in a box in the atlantic or in a separate window, that lists these unknowns or any-other way you want to handle it. But get them into your system so you can have a place to put their most recent packet and can "find them" if needed. END These vicinity plots and DX spots at least make sure the station is recognized in APRS and has been localized as best we can. POSITION LISTS will clearly show "vicinity plot" or "CALLSIGN PREFIX" STATUS LISTS will show his last packet MAPS will show a symbol for all such stations somehow. The original concept was as follows: - Within 1 mile of some digipeaters (or igates), there will be some QUESTION MARK Symbols indicating that some vicinity plot stations are in that area. They do NOT show any callsigns. They only show a call if CLICKED. But if any other process in the application program searches for that station, then the map will zoom to that QUESTION MARK symbol as the best guess of this system as to where he is. In response to this QUERY, then the callsign can be shown on this one view. The reason for callsign supression is because we do not want the casual viewer to see a callsign on a map unless the posit is valid. But these VICINITY PLOTs (with suppressed callsigns) do mark the digipeater that heard him last if we are LOOKING for him. Now of course, you do not need to do it exactly this way, as long as a single packet heard from any station, at least makes him 1) exist in the application 2) Have a captured PATH 3) Have an estimated posit 4) hold the last packet as status until replaced by STATUS Bob, Wb4APR