home *** CD-ROM | disk | FTP | other *** search
/ High Voltage Shareware / high1.zip / high1 / DIR18 / APRS307B.ZIP / README.RPT < prev    next >
Text File  |  1993-12-10  |  11KB  |  173 lines

  1.               AUTOMATIC PACKET REPORTING SYSTEM DIGIPEATERS
  2.  
  3.      To satisfy the objective of instantaneous response, APRS stations are
  4. designed to begin operating without any prior knowledge of the network.  For
  5. this reason, all APRS stations are initialized with the digi alias of RELAY
  6. and to send all UI frames via the path of RELAY.  With this form of generic
  7. alias callsign (RELAY) and wildcard digipeating (RELAY), a mobile, or new
  8. station on the air does not have to know anything about the network in advance,
  9. but to simply turn on his computer to be seen by adjacent nodes.  After 10
  10. minutes and his map begins to show the location of all stations and digipeaters
  11. on frequency, he can customize his outgoing Unproto path to specific
  12. digipeaters to cover his intended area.  It is important in any APRS network
  13. to avoid using the wildcard addressing except when required to minimize
  14. unnecessary QRM on frequency.  Finally in APRS version 3.07, I have
  15. added the DIGIPEATER LIST command so that you can easily see what digipeater
  16. paths that other stations are using.  The minimizing of wildcard addressing
  17. and multiple repeats when not needed is the key to an effecient APRS network.
  18.  
  19.      Although digipeaters work poorly for AX.25 level 2 connections, they are
  20. ideal for APRS operation using UI frames only.  In the Washington DC area and
  21. Chesapeake Bay area, we are establishing a network of WIDE area DIGI's on the
  22. simplex packet frequency of 145.79.  This frequency is for Keyboard QSO's and
  23. all UI frame applications.  Even leaving Personal mail boxes on the frequency
  24. is welcome, since mail is posted at keyboard rates and is read off-the-air by
  25. the mailbox owner without QRM.  The normal CONNECTED operation of BBS's,
  26. mail forwarding, file transfers, TCP-IP and DX clusters are discouraged!
  27.  
  28. WILDCARD DIGIPEATING:  To make these WIDE area digipeaters respond to mobiles
  29. and new stations, all wide area digipeaters have the same alias of WIDE in
  30. addition to their normal FCC callsign.  This second generic alias of WIDE
  31. adds tremendous flexibility to APRS networks by significantly extending the
  32. ranges for wildcard digipeating using well situated permanent digipeaters.
  33. These wide area Digi's are spaced several tens of miles apart so that they
  34. are not too close, but that they can hit their adjacent other WIDE digi's. 
  35. Assuming WIDE area digipeaters are about 30 to 50 miles apart it is very easy
  36. to select an UNPROTO path prior to a road trip which will assure that your
  37. location packets will always get back to your home area.  The following example
  38. shows a string of digipeaters along the east coast.  The HAM calls of SOUTH and
  39. NORTH are used for clarity.
  40.  
  41. CALL:   NORTH-3    NORTH-2    NORTH-1   HOME-0    SOUTH-1   SOUTH-2   SOUTH-3
  42. ALIAS:   WIDE       WIDE       WIDE     RELAY     WIDE      WIDE      WIDE
  43.  
  44.     If the mobile is going south for the day, and will be operating in the
  45. vicinity of SOUTH-3 digipeater, the operator can preset his UNPROTO path to be
  46. via WIDE,SOUTH-2,WIDE.  Notice that not only will his packets make it back to
  47. home from the area of SOUTH-3, but also from the area of SOUTH-1 since SOUTH-1
  48. will also respond to the first WIDE in the list.  Similarly, stations in the
  49. vicinity of SOUTH-3 are alerted to his movements as he leaves home, since the
  50. WIDE,SOUTH-2,WIDE specification is symetrical.  If he set the UNPROTO path to
  51. SOUTH-3,SOUTH-2,SOUTH-1 in the usual manner, he would not be tracked at his
  52. home until he actually arrived at his destination.  As you can see, having the
  53. flexibility to alternate the generic alias's of RELAY or WIDE with other
  54. known sites gives a good degree of flexibility without having to change the
  55. UNPROTO path while on the road.  Using the three digipeater string, he can
  56. wander up to 150 miles in his planned direction and still be tracked by the
  57. XYL.  If he has no idea where he is going, he can always use the path of
  58. WIDE,WIDE or even WIDE,WIDE,WIDE and go anywhere, but with greater QRM on the
  59. channel.  Yes there are multiple collisions, and repeats, but the packet does
  60. get out to the third tier!
  61.  
  62. PREEMPTIVE DIGIPEATING:   The ultimate APRS digipeater configuration is to have
  63. modified TNC-2 digipeater code so that any digipeater hearing a UI frame with
  64. its callsign anywhere in the UNPROTO path will pause for a reasonable time and
  65. then digipeat the packet as long as it was not previously digipeated by any
  66. stations earlier in the list.  This way, to always report your movements back
  67. home, you always place digipeaters in your UNPROTO command in the reverse
  68. order of your travels.  Your packets will be digipeated back to your home area
  69. as you enter each new digipeater in your direction of travel.  For example, if
  70. you live in the vicinity of DIGI-1 below and routinely travel in the direction
  71. out to and including DIGI-3.
  72.  
  73.  
  74.      DIGI-1    DIGI-2    DIGI-3    etc
  75.  
  76.      If we can get TAPR to modify the code, the mobile could specify the
  77. UNPROTO path of VIA DIGI-3,DIGI-2,DIGI-1 in order to be tracked anywhere all
  78. the way out to the area of DIGI-3.  If only DIGI-1 hears the packet, it will
  79. pre-emptively digipeat the packet and set its digipeat flag.  If DIGI-2 also
  80. hears the original packet, DIGI-2 will pause for P seconds to see if DIGI-1
  81. repeats it.  If so, it does nothing, since DIGI-1 follows it in the list.  If
  82. not, after P seconds, it digipeats the packet for DIGI-1 to subsequently
  83. further digipeat in the normal manner.  Similarly, DIGI-3 pauses for 2*P
  84. seconds to see if DIGI-2 digipeated the UI frame.  If so, it does nothing.  If
  85. not, after the 2*P seconds, it digipeats the packet.  Even if the packet pauses
  86. and comparisons are not performed, (to simplify the code) the worst case is that
  87. N duplicates will arrive at the destination for all N digipeaters that
  88. simultaneously heard the original UI frame.  Since these are UI frames, any
  89. pauses in the network for the comparisons suggested, are not significant.  The
  90. extra code to do the pauses and comparisions only protects against duplicates
  91. when two digipeaters hear the same original packet, and might not be worth the
  92. extra code.
  93.  
  94.      This algorithm works perfectly well in reverse.  If a mobile desires to
  95. announce his progress forward in the direction of his travel he can specify
  96. the digipeaters in the forward direction.  Then using this algorithm, all of
  97. his packets will be repeated in the forward direction, no matter where he is
  98. along his route, but not in the backward direction.
  99.  
  100.      Until we get new UI forwarding algorithms in standard TNC's, however,
  101. the general aliases of WIDE and RELAY will do nicely.  If fixed, known
  102. digipeaters are available, even with the generic alias of WIDE, it is best
  103. for fixed APRS stations to use the digipeaters unique callsign instead of
  104. alias to avoid any ambiguity.  Also avoiding the wildcard addresses except
  105. when necessary, significantly reduces QRM on the channel.
  106.  
  107. TheNET CONSIDERATIONS:  I now understand that G8BPQ TheNET code for the
  108. DataEngine includes a DIGIon command that if set to 255 will permit
  109. Digipeating of UI frames only.  Hopefully, other TheNET writers will include
  110. a UI frame only digipeat command.  The problem, however, is that since the
  111. digipeat ALIAS is the same as the NODE alias, you cannot operate more than
  112. one NODE with the ALIAS of WIDE or it will totally screw up the NODE
  113. functions.  We are asking John to consider permitting another ALIAS for UI
  114. frames only.
  115.   
  116.      Since NODES are so much smarter than digipeating, the ultimate solution
  117. is to have the NODES do all UI frame routing.  The APRS station simply sends
  118. his UI frame TO APRS VIA HOME;  Any NODE hearing that transmission that has
  119. knowledge of the route to HOME, will send the single packet via the NODE
  120. network (internode, level 4) to the HOME node!  When it arrives at the HOME
  121. node, it is transmitted once as a UI frame.  With this arrangement, a mobile
  122. only has to specify his one intended destination, no matter where he travels!
  123.  
  124.      P.S.  It would also be helpful if the INITIAL node hearing his level 2 UI
  125. frame also digipeated it locally once so that the local area would also see
  126. his position.  This could be made a user option, as follows:  If the
  127. node had the generic WIDE alias for UI frames only, then the initial report
  128. would be digipeated locally in the normal manner.   The first NON-WIDE field
  129. would then be assumed to  be the ULTIMATE HOME node destination to be forwarded
  130. through the network.  This way the mobile could decide whether he wanted to
  131. be repeated locally (including WIDE), or just forwarded only...  To complete
  132. this algorithm, NODES hearing the digipeated UI frame off of a WIDE digi,
  133. should NOT enter the packet into the network, because MANY nodes will probably
  134. hear the digipeated packet and only the first one should be repsonsible for
  135. doing the level 4 routing..
  136.  
  137.      Finally, since I hope to build a region area Tracking network, the node
  138. should also permit the SYSOP to turn off all other level 4 routing!  If we put
  139. up a fully connected network of APRS nodes for tracking, we will soon be
  140. swamped by all of the BBS and other file forwarding junk, and the network will
  141. be defeated.  (of course, if this was included in all NODES, then we would not
  142. need a dedicated tracking network, since APRS position reports could transit
  143. all networks!)  Time will tell.  These few paragraphs were primarily written
  144. to the NODE CODE writers such as John G8BPQ etc.  But are included here in
  145. general distribution for all to read.
  146.  
  147.      As of version 2.12, APRS now has a special command (Shift-F1) that sets
  148. ones own station to the ALIAS of WIDE vice RELAY.  This is so that an APRS
  149. station that is well situated, can serve as a WIDE digipeater.  This special
  150. command is used to override the automatic TNC initialization routine that
  151. always sets APRS TNC's to the generic alias of RELAY.  This command should be
  152. used with caution and with the understanding of all stations on the net.  Too
  153. many WIDE's and too close together causes too much QRM.  The command has to be
  154. used each time APRS is run, since the initialization routine will always reset
  155. your alias to RELAY.  Also, if you use the Shift-F1 command, your symbol will
  156. be set as a digipeater and the word WIDE will be installed in your POSIT
  157. comment field so that your station will show up on all screens in green.  This
  158. color (showing you as WIDE) will be lost, however, if you have a weather
  159. station hooked up to COM2, since it re-writes the POSIT string every few
  160. minutes.
  161.  
  162. SEE README.HF for setting up your UNPROTO path for HF and HF/VHF gateways..
  163.  
  164.  
  165. FINAL NEWS FLASH:  PACCOM has included a GPS ON command in all version 3.1
  166. firmware for thier TNC's.  This command permits their TNC to take the NMEA-0183
  167. output of any GPS device and place the GPS position data in the TNC Beacon
  168. text.  With this capability, anyone can build a GPS tracking device for APRS
  169. with nothing but a GPS and a PACCOM TNC.  See the README.GPS file.  Hopefully
  170. PACCOM and other manufacturers will then begin to work on the digipeater
  171. and TheNET routing solutions for UI position reports!
  172.  
  173.