On Sep 29, 2:59*pm, Darryl Ramm wrote:
On Sep 29, 10:49*am, "
wrote:





Dave - Good luck trying to convince people this was a good decision.
It just appears to be contrary to how others interpret the meaning of
"L" and "A". This is not how I believe all Cambridge products have
used an "L" and "A" attributes, certainly not the C302/303 and I think
older Cambridge devices. With Cambridge effectively defining the
standard for this why was if felt necessary to use the reverse
interpretation that "A" does not imply "L"?

What makes you think Cambridge is defining the standard? *I find the
SN10 format easy and simple to use. *As far as using the A or L to
figure out what kind of airport/landing area the waypoint is - all you
have to do is hit the help button and call up the waypoint description
- then you get all the data about it, including runway length, width,
freqs, etc! *Take a look at the data contained in the CAI format
compared to the NDB format, and you will see the advantage of the
SN10s format.

Kirk
66

Happy SN10 user - who wouldn't use a Cambridge to fill an empty hole
in my panel!

It has nothing to do with whether you like one instrument over
another. Cambridge was here first, and they provided a data format for
their instrument which have widely been used by others. *Dave Ellis et
al. got the whole IGC recorder business started, they proved (in World
level contests) that it was workable, etc. The Cambridge .DAT format
consequently *is* the defacto standard, e.g. it is kind of intrinsic
to Winscore in the USA. Cambridge have an "L" and an "A" waypoint (err
"landpoint") attribute with specific meaning. To change that was not a
good choice, at least use a different letter code to avoid the obvious
confusion. While the soaring turnpoint exchange does a good job hiding
differences, this is just the kind of incompatibility that will bite
sooner or later.

Darryl- Hide quoted text -

- Show quoted text -

First doesn't necessarily mean best, just as the best solution isn't
always the one that ends up becoming the standard - (beta max, anyone
- or PC vs Mac?).

The real solution would be to have an IGC-defined format for
turnpoints that would be universally compatible with all FRs and glide
computers - but barring that, one has to understand their equipment,
and GIGO is always a possibility!

Meanwhile, Leibacher's Soaring Turnpoint Exchange does a wonderful job
of managing all the various turpoint formats.

But let's face it - it really boils down to taking the time to make
sure that your data is correct - an essential part of preflight
planning, just like checking the weather and having a current
sectional in the cockpit!

Cheers!

Kirk
66

(Ok, I admit I do kinda like the 302 vario...)