TopWare Tools/TOOLS.iso/tools/top1483/gepackt.exe/README.MCM

Text File | 1993-11-20 | 5.4 KB | 84 lines

README.MCM               SUMMARY OF GPS Packet at MC Marathon

Whew! Its over!  14,000 runners Plus family and spectators at the Marine Corps
Marathon!  Here are the immediate lessons learned today:  1) MC chase vehicles
(HumVees) were not identified nor available until 45 minutes before start, to
install 3 GPS-packet tracking devices!  A) Mag mounts dont stick to ragtops
or Aluminum, B) HumVees run on 28 Volts, C) battery jumper between two 12 volt
batteries is sealed on both batteries in tuna fish size can of grease under
passenger seat, C) clearance between Battery posts and seat is less than 1/4
inch!  Last one was finished 1.5 minutes before the starting Howitzer fired!
(30 feet away!)  Then I was stuck there while 14,000 mobbed past me!

    Finally got back to Comm tent to see that all three vehicles were tracking
and showing up beautifully on the PC screen running APRS software.  The rest
of the event went beautifully, with all three vehicles (Lead handicapped, Lead
runner, and Tail-end-Charlie) transmitting their GPS position once a minute.
Even the MC comm folks would sneak into the HAM tent to see where things
"really" were.  Here are the real lessons learned for the APRS software:

   1) The automatic Dead-Reckoning was a nuisance.  For each minute that the
PC clock was off of GPS time, the actual position of the reported vehicle was
projected almost 1000 feet ahead of actual position.  Never a problem with
other events that covered tens or hundreds of miles, but all 26 miles of the
MC marathon all overlap circuitously within a 2 mile range of the center!  If
a vehicle position is off by 1/2 mile (my pc was 3 minutes off) the dead
reckoning really screws up the presentation.  I finally shut down for 30
seconds and reset the PC clock!  (Dead Reckoning is now an on/off option in
version 2.13)

   2) Downed runners and medical reports soon filled the screen.  Although
APRS position reports are reported less and less often, they are still
reported at least once every 10 miutes and once an object appears on a screen,
there is no APRS mechanism for the originator of an object to delete the
object from all screens when it is no longer valid.  Two things are needed.
First, old objects need to fade out of the system, and the originator of an
object needs a "DELETE" function to remove his objects from all screens.
(An order of magnitude reduction in redundant packets was implemented in ARPS
version 2.13 by improving the timing algorithms to apply to each object,
instead of all objects from one station.)

   3) APRS performs much better than normal packet for realtime tracking,
object and position reporting and operator conversing, but straight packet is
far better in the classical packet applications, such as passing patient lists
to hospitals.  We had a separate medical packet link which performed that
function admirably.  A single APRS net could not possibly "do everything" at
an event of 14,000 runners (at 1200 baud anyway).  Separate APRS nets on
separate frequencies for separate functions could be built into an impressive
"TACTICAL" network system.  (P.S. The voice operators were absolutely
outstanding and professional.  HAM radio (voice) was THE primary dispatch
authority for all ambulances)

   4) In the MAIN COMM tent with 4 two meter nets (plus other bands) there was
very little QRM.  All APRS packet stations at all checkpoints were mandated
to operate with only 1 watt.  A central digipeater on a building more than a
Mile away from all other stations ran 15 watts and all packets went via this
WIDE area digipeater.  The only packet QRM heard in the main COMM tent was
about once every 10 minutes or so when a magic combination of all rigs resulted
in one packet intermodding down on to one of the other nets.  This orccurred
so infrequently that no one was concerned. (Whew!)

   5) The APRS message mode is great for operator-to-operator notes, comments
and queries, but do NOT plan on using it to pass significant amounts of
traffic. ACK times were often minutes or more.  Oh yes, all of this was
done on the 145.79 APRS frequency and so the channel was not only handling
the packet load of the 9 Marathon APRS stations but ALSO the Point-to-point
packet link AND over 2 dozen other non-participating APRS stations in the
region!.  Since APRS was pretty well saturating the frequency, the point-to-
point packet link moved to another frequency for passing most of their
traffic.  (An improvement in individual message line timing was also made in
version 2.13 which significantly reduces QRM)

    6) The complete event is captured in the MARINES.hst file and can be re-
played to see how it went.  To make sense out of it all, play back for only
one mobile at a time, and definately turn Callsigns off.  WB4APR-9 was the
lead Handicapped vehicle (started 15 minutes or so before all runners), W3ADO-9
was the lead runner, and MOBILE-9 was Tail-end-Charlie.  Statistically, we did
very well.  W3ADO-9 was turned on at 0827 but did not move until 0902.  It was
removed from the vehicle at about 1127.  Transmitting at once a minute, there
should have been 145 posits transmitted.  We counted about 115 in the file.
The missing packets could have been either colisions, or bad GPS fixes (masked
by buildings) so that the same posit was transmitted more than once (and
therefore filtered out as a dupe by APRS.  The result omputes to almost an 80%
success rate!)