Jamie,

I think you may be mixing apples and oranges here. For the near term, I
think most folks are focused on self-contained GPS units, e.g. the Garmin76.
In this case, the navigation and logging functions are co-located. I've
personally sat on the deck after flying and paged through someone's Garmin
trace (Garmin 12, I think) to validate to my satisfaction that the person
did what they said they did. So, imagine the following (simple)
instruction sheet for OO validation:

1. Review any existing track logs prior to takeoff noting date/time stamps
(simple to do - OO doesn't need to know how to navigate the functions; owner
of the unit shows him/her). This is to show tht there is nothing "fishy"
prior to takeoff, eg. a post-stamped track log created at home (though I
believe that the Garmin upload interface automatically wipes out timestamps,
but anyway).

2. Immediately upon landing, OO reviews log file using UI of GPS unit to
validate timestamps, basic continuity, turnpoints, etc. The OO doesn't need
to know how do navigate the features; the pilot simply walks him/her through
it. Again, the units themselves facilitate this, so it is still
self-contained. You can zoom in on turnpoints, check altitude profile,
etc. RIGHT FROM THE COTS UNIT. As far as I am concerned this is an INCREASE
in security over my existing "secure" Cambridge unit. In other words, you
can validate prior to connecting any external computer that the file is
intact.

3. Download the file. Best case, the OO observes the dowload of trace
same day right on the airfield while keeping the COTS unit in his posession.
Second best is that the pilot hands over the unit to the OO who downloads
the trace later that night or next day. Third best is that the OO takes a
few key data points from the UI and notes them down, then allows the pilot
to take control of the unit and dowload from home. For almost all badges,
the main issues a a) When/how high did the pilot release from tow b) how
low/high did he get (for altitude gains, airspace incursion) c) did he land
along the way and d) did he accomplish the claimed turnpoint(s). All of
these require only a few points to be validated.

If we ever trusted the OO to do his or her job in the past, then we need to
hold that assumption constant. Given that, only the truly talented and
somewhat deranged individual would be able to pass the above tests. Forget
about the technical complexity of accomplishing an upload in flight. The
trick would be to create a file a day or two in advance that accurately
mirrors the actual conditions on the day of the flight. If we truly
believed an individual was cheating, comparison to other local flights or
even something as simple as reviewing estimated wind drift versus
observations would tip the OO off. Again, that's certainly an option to be
written into the rules.

Regards,
Erik Mann

p.s. A slightly used Garmin76 listed on eBay right now for $150. Checked
for Volkslogger and Cambridge, didn't find any :-))



"Jamie Denton" wrote in
message ...

If I want to learn how to interface with some garmin
gps from my pc, I can google for the specification
of the garmin interace and slap together some C code
to upload a trace or otherwise fiddle with my logger
unit. As for procedures, the potential problem is
that, with a COTS logger (say for example an iPaq with
winpilot or some other hypothetical approved software),
who is to say the person flying hasn't downloaded to
their iPaq a little utility (no doubt disguised as
a calculator ;-) ) to emulate the serial port and
feed in a rubbish NMEA feed? The OO would need to have
seen the iPaq being hard resest and all new software
installed to be able to guarentee no additional software
is installed... Not an easy task.