APRS attempts to dead reckon all moving objects to their estimated current positions based on elapsed time since the last position report. Not only is this automatic tool very valuable, a OPTIONAL version of APRS has been written to permit objects to follow a given course by dead reckoning, instead of just a straight line. For planned events, such as marathons and 10K runs, this allows APRS to track the lead and tail runners without even using GPS!
But before getting into this path following mode, there are some important concepts using normal DRing that APRS users must understand:
DEMONSTRATION: Run APRSdr, and zoom into the Washington DC map at 3853 and 07703 to a range of 1 or 2 miles. INPUT-ADD an object anywhere on the purple course, and give it a SPEED of say 9 kts. Next call up the P-LIST, hook the object and select FOLLOW. Go back to the map and watch the object move once a minute.. APRSdr will only do the DR if the user has entered his V#. In order to have APRSdr handle more than ONE object, it must also be validated with a DF/DR number too. To the left of the map screen, a trouble- shooting aid will appear as follows:
OBJ= LEADER MAP= 0 Shows which of the 4 loaded maps is LOCKED (0 to 3) NMP= 835 Total number of map points in the file End= 586 End point of purple course 1st= 583 First or current point to begin search for course Leg= 583 Current point (LEG) found on the course New= 584 New leg if past endpointThis display aid will only display the last object processed. If several are on the same schedule, then only the last will be seen.
HOW IT WORKS: First, when APRSdr loads the current map, it will remember the location of the beginning of the LAST purple line in the file. Presumably this is the race course added to an APRS map. When you place an object on the map, the course will be scanned starting at this point, looking for a line segment near your object. It does this via rectangles drawn with the line segment as the diagonal. This means that 45 degree lines will have a big nearly square rectangle, while vertical and horizontal lines will have vanishingly narrow search ranges. TO solve this problem for vertical and horizontal lines, APRS adds and subtracts 1 form both ends to broaden the rectangle. Once it finds a matching segment, it remembers that segment for each different object. Look at the following 4 segment race course.
2 - - - - - - - - - - - - - - - - *---------------- | * | * | | * | * | | * | * | | * | - - - - - - - * 3 | * | | *| | * | | * | | * | | * | 1 * - - - - - - - - - - - - - - - - | * | Start | * | | * | Finish | * | - - - - - - - - - - - - - - - - - - - |* | 5 * * * * * * * * * * * * * * - - - - - - - - - - - - - - - - - - - - - - - | 4Knowing the segment and its angle, once every N minutes (set via the alt-SETUP-POSRATE command) APRS will DR the object along the same azimuth as the given line segment and transmit the new position. Its new position will be compared to the edges of the rectangle at the end point of that line segment. If the predicted position is beyond the edge of the rectangle, then it will be moved to that end point. When this is done, the segment number for that object is incremented by one so that on the next DR, the AZIMUTH of the next line sement will be used. This process continues throughout the event. Whenever the end point of the complete course is reached, the velocity is set to zero so that no further DR occurs. Actually truncating each leg at the end point would result in lost time on each leg. This is corrected by having the comparison made to plus AND minus 50% of the dead reckoned distance from the end point. This way, sometimes the object is moved AHEAD to the end point, and some times it is moved BACK to the end point. In the long run, these two effects should balance out.
At any time, if the dead reckoned object gets ahead or behind schedule, you may hook the object and move the cursor to the newest reported position and hit INSert key to update its position. When you hit the INSert key, the remembered segment number is zeroed and a scan is performed again to find the nearest leg of the course. This works fine except for the case where the course intersects itself, backtracks, or re-traces some segments. In these instances, the location of the object may be within several overlapping segment rectangles. Only the first will be identified by the scan. APRS solves this problem by giving the user the opportunity to indicate that the 1st, 2nd or 3rd segment should be used. The prompt assumes the 1st leg, so that a default (ENTER) response will work most of the time, but if it is the 2nd or 3rd time through an area, the user can so indicate.
When you move an object with the HOOK-INSert method, you don't need to enter the COURSE, it will be derived by the path- following routine (if found). If the course of the object as shown on the map does NOT align itself with the course, then the course was NOT found for some reason...
CAUTIONS: This is a complex process and should be monitored closely. The operator should be completely familiar with this process and the following cautions.
1) Since Dead reckoning is only done on a minute by minute basis, the OBJ-UPLINK period (using alt-SETUP-POSRATE) should never be set less than 60 seconds.
2) This one minute increment causes a secondary consideration on the length of each leg on a course. If the legs are shorter than one minute, then errors will build up since it still takes a minimum of one minute increment to go from the starting point of a segment to the end point. In some cases, this is unavoidable in order to have the course match the tight turns in a city environment. By anticipating these delays, a good operator can work around them by increasing the speed, or updating the position manually in such a labrynth. If you want precision detail, draw the streets in fine detail, but overlay the race course in cruder longer segments. Zoom into WASHDC.map to see a real our marathon..
3) When you HOOK-INSert-MOVE to correct the position of an object, the PATH-FOLLOWING algorithm only derives the AZIMUTH from the nearest line segment, it does not correct the position. In other words, if you place the object 200 yards to the right of the path, then it will be dead-reckoned with approximately that same offset until it gets to the perpindiculars marking the end point..
3) In order to resolve the rectangles around line segments, draw the maps with enough resolution (pixels per degree) so that even the shortest line segments are more than just one pixel between end points.
4) Since this entire scenario is based on the course drawn in purple on the current map display, it would not work if you ever leave the given map. For this reason, as soon as you mark a station for FOLLOWING, the present map is locked. Obviously, before you FIRST hook an OBJECT on the P list, and mark if for FOLLOWING, you MUST have displayed the MAP at least once. If you UNLOCK the map, the objects will be UN-MARKED for FOLLOWING.
5) The purple COURSE does not have to be the last FEATURE in a map file, but only the LAST such purple feature will be used as the course. This means after laying out your course using MAPFIX, you can add other things without messing up the DR function.
WARNING! Since APRS now puts its MAPLISTS in the MAPLISTS directory, and APRSdr doesnt know this, you will have to move a copy of your needed MAPLIST.xxx to your APRS directory for APRS to work!