Turnpoint coordinate format

[Andy[_1_]]

Special thanks to John Leibacher for TP Exchange in general, and for
his assistance at very short notice with creating files for an ASA
club contest remote site.

While working on the file preparation I was surprised to find that
some Cambridge format (DAT) files on TP exchange use deg:min:sec
format and some use deg:min.decmin format.

I tried to find an official definition of the Cambrige DAT format but
could not. The closest I found was this from the GPS NAV manual:

"The GPS-NAV also shows Latitude and Longitude in the Degrees and
Decimal minutes format rather than Degrees, Minutes, and Seconds
format. Here is an example of each format:
DD MM.MMM => 44 07.620
DD MM SS => 44 07 37
To change from seconds to decimal minutes, divide seconds by 60 and
multiply by 100. If your reference source for coordinates uses the
archaic marine DD MM SS notation, press the FORMAT command at the top
of the screen. Voila! Now enter coordinates in the alternate format.
Pressing the FORMAT key again changes the entry to DD MM.MMM as used
by the Cambridge GPS-NAV."

Even the SSA rules do not appear to specify the format except to say
it is Cambridge DAT format.

So does anyone know where I can find the DAT file definition and does
it specify the acceptable coordinate formats.

I asked John about the differences in formats and was told it just
depends on what the data originator provides. TP exchange does not
enforce a coordinate format standard.

Are there any Nav systems that will barf, or worse provide misleading
TP position, if provided an unexpected coordinate format or do they
all happily convert whatever they are fed?



Andy (GY)

[Darryl Ramm]

On Jun 8, 2:16*pm, Andy > wrote:
> Special thanks to John Leibacher for TP Exchange in general, and for
> his assistance at very short notice with creating files for an ASA
> club contest remote site.
>
> While working on the file preparation I was surprised to find that
> some Cambridge format (DAT) files on TP exchange use deg:min:sec
> format and some use deg:min.decmin format.
>
> I tried to find an official definition of the Cambrige DAT format but
> could not. *The closest I found was this from the GPS NAV manual:
>
> "The GPS-NAV also shows Latitude and Longitude in the Degrees and
> Decimal minutes format rather than Degrees, Minutes, and Seconds
> format. Here is an example of each format:
> DD MM.MMM => 44 07.620
> DD MM SS => 44 07 37
> To change from seconds to decimal minutes, divide seconds by 60 and
> multiply by 100. If your reference source for coordinates uses the
> archaic marine DD MM SS notation, press the FORMAT command at the top
> of the screen. Voila! Now enter coordinates in the alternate format.
> Pressing the FORMAT key again changes the entry to DD MM.MMM as used
> by the Cambridge GPS-NAV."
>
> Even the SSA rules do not appear to specify the format except to say
> it is Cambridge DAT format.
>
> So does anyone know where I can find the DAT file definition and does
> it specify the acceptable coordinate formats.
>
> I asked John about the differences in formats and was told it just
> depends on what the data originator provides. TP exchange does not
> enforce a coordinate format standard.
>
> Are there any Nav systems that will barf, or worse provide misleading
> TP position, if provided an unexpected coordinate format or do they
> all happily convert whatever they are fed?
>
> Andy (GY)

I've always thought the documentaiton with WinPilot was pretty useful
for explaing the .DAT format. See Appendix A.2. User waypoint file and
ignore the optional parameters. See the WinPilot user's guide
available at www.winpilot.com.
I think since Winpilot supported both minutes and seconds and minute
decimal notation a lot of other software will as well. I have
suspicious that originally Cambridge only supported decimal minutes
since they do insist in places that is what their want.

In terms of "Nav systems barfing" remember it is often not the flight
recorder/computer that is reading the .DAT file. That goes to some
intermediate software that uploads that .DAT file to the flight
recorder. For the perversely curious that protocol is well specified
in the 302 Dataport User's Guide avaible on the Cambride web site (on
the 300 series product page).

And to be a bit illogical the Cambridge 303 Display user manual does
talk about the .DAT text file format and claims that the formats have
to be decimal minutes. See Section 3.3. And we know the manual is
lying about the waypoints being stored in the 303 anyhow, nice attempt
at a marketing spin guys.

Seems to me like decimal minutes is the safest way to go unless you
find out for sure elsewhere.

Darryl

[Andy[_1_]]

On Jun 8, 11:21*pm, Darryl Ramm > wrote:
>
> Seems to me like decimal minutes is the safest way to go unless you
> find out for sure elsewhere.

I'm a bit surprised this didn't provoke more interest. If a
navigation system accepts a control point specified in deg mm ss
format and interprets it as deg mm.mmm format the worst case error
would appear to be when ss is 59. This would potentially be
interpreted as .590 min. The error is .590 vs .983 or 0.39 minutes.
That's easily enough error to miss the one mile radius of a control
point.

I'll try to do some experimenting but would welcome feedback from
users of Cambridge DAT files as to what format is required for their
system.

TP exchange appears to produce some end user files in deg mm.sss
format even when the Cambridge DAT files are deg mm ss so it's
probablly not a major change to have DAT files always use deg mm.mmm
format. No reason to ask for a change though if there really isn't a
problem.

Perhaps the only thing that matters is that the scoring software and
the pilot's nav system handle the format in the same way.

Andy

[ZL]

Andy wrote:
> On Jun 8, 11:21 pm, Darryl Ramm > wrote:
>> Seems to me like decimal minutes is the safest way to go unless you
>> find out for sure elsewhere.
>
> I'm a bit surprised this didn't provoke more interest. If a
> navigation system accepts a control point specified in deg mm ss
> format and interprets it as deg mm.mmm format the worst case error
> would appear to be when ss is 59. This would potentially be
> interpreted as .590 min. The error is .590 vs .983 or 0.39 minutes.
> That's easily enough error to miss the one mile radius of a control
> point.
>
> I'll try to do some experimenting but would welcome feedback from
> users of Cambridge DAT files as to what format is required for their
> system.
>
> TP exchange appears to produce some end user files in deg mm.sss
> format even when the Cambridge DAT files are deg mm ss so it's
> probablly not a major change to have DAT files always use deg mm.mmm
> format. No reason to ask for a change though if there really isn't a
> problem.
>
> Perhaps the only thing that matters is that the scoring software and
> the pilot's nav system handle the format in the same way.
>
> Andy

The original Cambridge GPS Utility software from the mid 90's could do
both. It could export either format and import either format. It could
also use feet or meters for elevation. CAI AeroExplorer loads both
correctly. The WinPilot variant of the *.dat file standard allows both.
Thats probably the de facto standard, that both are OK.

I couldn't find any formal definition of the CAI *.dat format. The
actual data stream loaded into the FR does not directly match any *.dat
format so the software must have some smarts. Given that, you may find
some variability in how the "standard" is implemented by the various
software tools available to load CAI FRs.

-Dave

[Andy[_1_]]

On Jun 9, 4:30*pm, Andy > wrote:

that should have read

TP exchange appears to produce some end user files in deg mm.mmm
format......

[John Leibacher]

On Jun 10, 6:21*am, Andy > wrote:
> On Jun 9, 4:30*pm, Andy > wrote:
>
> that should have read
>
> TP exchange appears to produce some end user files in deg mm.mmm
> format......


Yes, some vendors only accept d:m:s, such as Zander, Tasknav, etc... ,
and others, such as OziExplorer, only d, so if user provides in d:m
the coordinates get transformed. It's not a problem. The default is
d:m:s for the WSTX, to minimize rounding errors, but we can accomodate
anything - including radians...

John L