302 wind calculation

On Mar 25, 11:04*pm, Darryl Ramm wrote:

The 302 can be very good with wind just with straight straight flight
with changes in direction of +/- 30 degree or so.

That's BS.

My $0.02. I have a sample of one, but it has been extensively tested,
TAS output verified, pneumatic sources are from triple probe, not
shared, no leaks. It does not come close to being able to do what you
claim.

My pda does better vector wind calc using 302 data.

On a ridge, forget about updates, they don't happen.

Never *EVER* use the 303 relative wind indicator. It does not update
for ground track changes, it only updates when it gets a wind update
(huge oversight). On one memorable flight, I saw the relative wind
indicator 180 degrees wrong for a 65 mile run down a ridge in 12 knots
of wind. One smooth 360 turn at a 30 second or so rate will always
get a good vector wind.

Other major gotcha of 302 is lack of header for N-number. You'll
discover how much fun that can be when you submit a badge or record
flight with an electronic declaration.

As long as these flaws are understood, 302 is otherwise a very good
instrument. All it needs to be truly excellent is a firmware fix or
two. Unfortunately, I don't think that's in the cards.

-Evan Ludeman / T8

On Mar 26, 4:59*am, T8 wrote:
On Mar 25, 11:04*pm, Darryl Ramm wrote:

The 302 can be very good with wind just with straight straight flight
with changes in direction of +/- 30 degree or so.

That's BS.

My $0.02. *I have a sample of one, but it has been extensively tested,
TAS output verified, pneumatic sources are from triple probe, not
shared, no leaks. *It does not come close to being able to do what you
claim.

My pda does better vector wind calc using 302 data.

On a ridge, forget about updates, they don't happen.

Never *EVER* use the 303 relative wind indicator. *It does not update
for ground track changes, it only updates when it gets a wind update
(huge oversight). *On one memorable flight, I saw the relative wind
indicator 180 degrees wrong for a 65 mile run down a ridge in 12 knots
of wind. *One smooth 360 turn at a 30 second or so rate will always
get a good vector wind.

Other major gotcha of 302 is lack of header for N-number. *You'll
discover how much fun that can be when you submit a badge or record
flight with an electronic declaration.

As long as these flaws are understood, 302 is otherwise a very good
instrument. *All it needs to be truly excellent is a firmware fix or
two. *Unfortunately, I don't think that's in the cards.

-Evan Ludeman / T8

Evan, just a suggestion, but before calling somebody else's post
bull**** maybe you ought to read it carefully and maybe know a little
more about what you are talking about. But hey, that's just a
suggestion.

It was not by accident I mentioned the need for a +/- 30 degree
change. But I'll try to be clearer, that is a +/- 30 degree change of
track, ie. change direction 30 degrees either side of a steady track.
That is the change that triggers the 302 to recalculate it's track/TAS
based wind calculations. If you have not been able to get a 303 to
display updated wind vectors by doing a = +/- 30 degree zig zag then
you are doing something wrong or have a faulty unit. I frequently do
these zig zags when exploring our local blue convergence lines to see
what side of the convergence I am on. With weak wind you need to do
more of a zig zag or take a turn to get really accurate wind but the
302 will try to give wind with a +/- 30 degree track change.

If you are flying straight along a ridge and don't have enough of
these heading changes within enough of a short time then the 302 will
not update its internal wind vector, it will update it's HW/TW
component data. That is expected. The wind calculations, need for +/-
30 degree track changes and data presented on the 303 is briefly
described in the 303 manual.

PDA based soaring software (like SeeYou Mobile and Winpilot Pro (not
Standard)) that calculates wind vectors based on track and TAS data
passed from the 302 may well show wind vector data and changes to that
with less of a heading change. Obviously basic trigonometry applies
and the implied errors get much larger if this is being calculated on
very small track changes. One thing I worry about with some soaring
software is it displays wind data aged over a long time. For example
if you take a couple of turns while on tow or a couple of thermals
before connecting to ridge lift, or even the turns to position to join
a ridge allows the software to make a wind calculation (which may or
may not be that accurate). You then go bombing along a ridge then for
100 miles without a significant enough turns (within short enough time
span) to actually be able to mathematically calculate the wind
properly but the software keeps the wind pointing much in the same
direction as before but with some changes that may well be just noise,
but a pilot might well be fooled into thinking "gee my PDA is better
here since it is updating the vector". Basic trigonometry just makes
this hard to do unless there is a significant track change within a
short time period.

One thing to do here is play with your particular setup and try to see
what is really happening. If you get a chance in some location to pull
a circle then see what the wind updates to. Know how to reset the PDA
software wind calculation. If you think the PDA is calculating wind
well without significant turns try clobbering the wind data in the PDA
and wait and see what it comes back with when it recalculates. (No I'm
not suggesting playing with your PDA while bombing along a ridge).
This is a good test for my earlier concern about some software not
being aggressive enough aging out old data. Of course in many ridge
situations the wind may blow predominantly and strongly from one
direction so not aging out that old data and continuing to display it
(with some level of random noise added) makes it look like the PDA
software is doing a great job, even though it may well really not have
enough raw data to be able to calculate what the wind is doing.

Some computers do have magnetometers or optional magnetometers to read
heading data and try to calculate wind direction without any turns at
all. The LX-7000 is one example. I've never flown with one, but I have
heard some anecdotal reports from people that they were not that
impressed with the wind calculations, say over what they were used to
from an SN-10 or C302/PDA software. It would be interesting if others
have comments on wind calculations from magnetometer based systems. In
principle at least, the magnetometer approach is the right way to go
if you want wind calculations for turn-free ridge soaring situations.

A question to the original poster, and one that commonly causes
confusion, is where are you looking at the 302 "wind data". On a 303
display? Or on a PDA? And if on a PDA what software are you using?

And to answer Andy's (9B) question the 302 does the wind calculations.
The 303 is needed to display the 302's internal wind calculations, but
they are also available via the dataport API (doc available on
Cambridge's web site) whether or not a 303 is present. Some home grown
and maybe other software does pull that internal wind calculations out
of the 302. SeeYou and WinPilot Pro base their wind calculations on
the TAS data from the 302 or from circle drift when thermaling, they
do not use the 302 internally calculated wind vector data. WinPilot
Advanced only uses circle drift so can't update wind data with heading
changes without circling. If you have a C302 I think you really want
Winpilot Pro not Advanced.

I fly with a Cambridge 302 and 303, the 303 is a handy backup to my
PDA running SeeYou Mobile, including for it's wind display of the
wind, but like all things it helps to know what is going on behind the
scenes.

---

My new friend Evan gets a bit off-topic in his reply about the "lack
of header for N-number", so I'll comment on that as well.

There is no "N-number" field supported in the IGC file format.
Cambridge just cannot add one even if they wanted to--or if they tried
to add a proprietary IGC record it would not apply to FAI badges and
records. All flight recorders have a GLIDER ID field and that is where
in the USA for badges and records you are supposed to enter the
gliders N-number. From the Cambridge PDA utility you enter the ID
field in the "Edit Glider ID and Polar" page. This is proper use of
IGC terminology on the part of Cambridge, it's not the CONTEST ID,
it's the GLIDER ID. Unfortunately elsewhere in their documntation
Cambridge does call this Contest ID and some other utilities may well
call this "Contest ID" but that's the fault of those software authors
not Cambridge. The IGC file format does support an optional CONTEST ID
field, the C302 does not support that AFAIK. You can see your GLIDER
ID in the header of a C302 IGC file it looks like this "HFGIDGLIDERID:
26DX" (that's my glider's "n-number").

If Evan is comparing the C302 to other flight computers that appear to
have an "N-number" and "Contest ID" field, then those flight recorders
are writing that data to the "GLIDER ID" and optional "CONTEST ID"
field whereas the C302 uses the "GLIDER ID" field only. Maybe Evan
meant that he wanted Cambdridge to add a CONTEST ID field?

Pilots in the USA have a convention of entering their contest ID in
the GLIDER ID field. Judy and others have tried to promote the recent
tightening of requirements from the IGC that this really must be a
GLIDER ID (i.e. N-number in the USA) and not a CONTEST ID issued to a
pilot. While I think the IGC harshness on the interpretation is a bit
silly, I don't think Cambridge can be blamed in any way for this
situation. The requirements for electronic declarations is clearly
explained in Sporting Code 3 Annex C. Including a note that this is
the unique aircraft ID not a pilot contest number. Unfortunately
badges and records involve reading the rules carefully, and this
GLIDER ID issues is explained in black and white right there. The IGC
specifically allows the NAC to overlook these kinds of errors for
silver and gold badges (and I understand that Judy will do this).


Darryl

On Mar 26, 1:45*pm, Darryl Ramm wrote:
[snip]

It's not a question of clarity: you were perfectly clear. And it's
clearly BS. The 302 is very clunky in the vector wind department
compared to even the GPSNav/LNav combo in its final evolution.

The ID code was put in there by the inventors of the secure flight
recorder for contest scoring. Originally (GPSNav) it was limited to 3
characters. It was always intended to be the CN and at a contest
*should* be the CN. This makes the scorer's life a bit easier and
published flight logs easier to sort through.

Having the glider ID in an e-declaration adds nothing by way of
security, verification or convenience to a badge flight log, but is
required by the IGC for its own inscrutable reasons. The OO attests
to the ID of pilot and sailplane on the application form, of course.
But the point w.r.t. Cambridge is that since the registration number
*is* required for a valid e-declaration, Cambridge ought to be a
little more specific in their software about what that ID ought to be
and they aren't and they won't any time soon because no one there does
software (at least as of last time I checked). Yes it was OT to the
OP. However it is relevant to my assessment of the 302 which is "good
hardware, software needs updating".

-Evan Ludeman / T8

On Mar 26, 1:45*pm, Darryl Ramm wrote:
On Mar 26, 4:59*am, T8 wrote:





On Mar 25, 11:04*pm, Darryl Ramm wrote:

The 302 can be very good with wind just with straight straight flight
with changes in direction of +/- 30 degree or so.

That's BS.

My $0.02. *I have a sample of one, but it has been extensively tested,
TAS output verified, pneumatic sources are from triple probe, not
shared, no leaks. *It does not come close to being able to do what you
claim.

My pda does better vector wind calc using 302 data.

On a ridge, forget about updates, they don't happen.

Never *EVER* use the 303 relative wind indicator. *It does not update
for ground track changes, it only updates when it gets a wind update
(huge oversight). *On one memorable flight, I saw the relative wind
indicator 180 degrees wrong for a 65 mile run down a ridge in 12 knots
of wind. *One smooth 360 turn at a 30 second or so rate will always
get a good vector wind.

Other major gotcha of 302 is lack of header for N-number. *You'll
discover how much fun that can be when you submit a badge or record
flight with an electronic declaration.

As long as these flaws are understood, 302 is otherwise a very good
instrument. *All it needs to be truly excellent is a firmware fix or
two. *Unfortunately, I don't think that's in the cards.

-Evan Ludeman / T8

Evan, just a suggestion, but before calling somebody else's post
bull**** maybe you ought to read it carefully and maybe know a little
more about what you are talking about. But hey, that's just a
suggestion.

It was not by accident I mentioned the need for a +/- 30 degree
change. But I'll try to be clearer, that is a +/- 30 degree change of
track, ie. change direction 30 degrees either side of a steady track.
That is the change that triggers the 302 to recalculate it's track/TAS
based wind calculations. If you have not been able to get a 303 to
display updated wind vectors by doing a = +/- 30 degree zig zag then
you are doing something wrong or have a faulty unit. I frequently do
these zig zags when exploring our local blue convergence lines to see
what side of the convergence I am on. With weak wind you need to do
more of a zig zag or take a turn to get really accurate wind but the
302 will try to give wind with a +/- 30 degree track change.

If you are flying straight along a ridge and don't have enough of
these heading changes within enough of a short time then the 302 will
not update its internal wind vector, it will update it's HW/TW
component data. That is expected. The wind calculations, need for +/-
30 degree track changes and data presented on the 303 is briefly
described in the 303 manual.

PDA based soaring software (like SeeYou Mobile and Winpilot Pro (not
Standard)) that calculates wind vectors based on track and TAS data
passed from the 302 may well show wind vector data and changes to that
with less of a heading change. Obviously basic trigonometry applies
and the implied errors get much larger if this is being calculated on
very small track changes. One thing I worry about with some soaring
software is it displays wind data aged over a long time. For example
if you take a couple of turns while on tow or a couple of thermals
before connecting to ridge lift, or even the turns to position to join
a ridge allows the software to make a wind calculation (which may or
may not be that accurate). You then go bombing along a ridge then for
100 miles without a significant enough turns (within short enough time
span) to actually be able to mathematically calculate the wind
properly but the software keeps the wind pointing much in the same
direction as before but with some changes that may well be just noise,
but a pilot might well be fooled into thinking "gee my PDA is better
here since it is updating the vector". Basic trigonometry just makes
this hard to do unless there is a significant track change within a
short time period.

One thing to do here is play with your particular setup and try to see
what is really happening. If you get a chance in some location to pull
a circle then see what the wind updates to. Know how to reset the PDA
software wind calculation. If you think the PDA is calculating wind
well without significant turns try clobbering the wind data in the PDA
and wait and see what it comes back with when it recalculates. (No I'm
not suggesting playing with your PDA while bombing along a ridge).
This is a good test for my earlier concern about some software not
being aggressive enough aging out old data. Of course in many ridge
situations the wind may blow predominantly and strongly from one
direction so not aging out that old data and continuing to display it
(with some level of random noise added) makes it look like the PDA
software is doing a great job, even though it may well really not have
enough raw data to be able to calculate what the wind is doing.

Some computers do have magnetometers or optional magnetometers to read
heading data and try to calculate wind direction without any turns at
all. The LX-7000 is one example. I've never flown with one, but I have
heard some anecdotal reports from people that they were not that
impressed with the wind calculations, say over what they were used to
from an SN-10 or C302/PDA software. It would be interesting if others
have comments on wind calculations from magnetometer based systems. In
principle at least, the magnetometer approach is the right way to go
if you want wind calculations for turn-free ridge soaring situations.

A question to the original poster, and one that commonly causes
confusion, is where are you looking at the 302 "wind data". On a 303
display? Or on a PDA? And if on a PDA what software are you using?

And to answer Andy's (9B) question the 302 does the wind calculations.
The 303 is needed to display the 302's internal wind calculations, but
they are also available via the dataport API (doc available on
Cambridge's web site) whether or not a 303 is present. Some home grown
and maybe other software does pull that internal wind calculations out
of the 302. SeeYou and WinPilot Pro base their wind calculations on
the TAS data from the 302 or from circle drift when thermaling, they
do not use the 302 internally calculated wind vector data. WinPilot
Advanced only uses circle drift so can't update wind data with heading
changes without circling. If you have a C302 I think you really want
Winpilot Pro not Advanced.

I fly with a Cambridge 302 and 303, the 303 is a handy backup to my
PDA running SeeYou Mobile, including for it's wind display of the
wind, but like all things it helps to know what is going on behind the
scenes.

---

My new friend Evan gets a bit off-topic in his reply about the "lack
of header for N-number", so I'll comment on that as well.

There is no "N-number" field supported in the IGC file format.
Cambridge just cannot add one even if they wanted to--or if they tried
to add a proprietary IGC record it would not apply to FAI badges and
records. All flight recorders have a GLIDER ID field and that is where
in the USA for badges and records you are supposed to enter the
gliders N-number. From the Cambridge PDA utility you enter the ID
field in the "Edit Glider ID and Polar" page. This is proper use of
IGC terminology on the part of Cambridge, it's not the CONTEST ID,
it's the GLIDER ID. Unfortunately elsewhere in their documntation
Cambridge does call this Contest ID and some other utilities may well
call this "Contest ID" but that's the fault of those software authors
not Cambridge. The IGC file format does support an optional CONTEST ID
field, the C302 does not support that AFAIK. You can see your GLIDER
ID in the header of a C302 IGC file it looks like this "HFGIDGLIDERID:
26DX" (that's my glider's "n-number").

If Evan is comparing the C302 to other flight computers that appear to
have an "N-number" and "Contest ID" field, then those flight recorders
are writing that data to the "GLIDER ID" and optional "CONTEST ID"
field whereas the C302 uses the "GLIDER ID" field only. Maybe Evan
meant that he wanted Cambdridge to add a CONTEST ID field?

Pilots in the USA have a convention of entering their contest ID in
the GLIDER ID field. Judy and others have tried to promote the recent
tightening of requirements from the IGC that this really must be a
GLIDER ID (i.e. N-number in the USA) and not a CONTEST ID issued to a
pilot. While I think the IGC harshness on the interpretation is a bit
silly, I don't think Cambridge can be blamed in any way for this
situation. The requirements for electronic declarations is clearly
explained in Sporting Code 3 Annex C. Including a note that this is
the unique aircraft ID not a pilot contest number. Unfortunately
badges and records involve reading the rules carefully, and this
GLIDER ID issues is explained in black and white right there. The IGC
specifically allows the NAC to overlook these kinds of errors for
silver and gold badges (and I understand that Judy will do this).

Darryl- Hide quoted text -

- Show quoted text -

Darryl,

I intend to buy a ClearNav unit which is only able to integrate with a
302. ClearNav uses 302 wind data and it does not use TAS from any
other instrument to help with wind calculation. ClearNav also
calculates wind during circling but this is not a great option on a
ridge. I am debating if I should buy the 302 or wait for another
variometer to come along that is going to integrate with the ClearNav.

On Mar 26, 6:10*pm, AK wrote:
On Mar 26, 1:45*pm, Darryl Ramm wrote:



On Mar 26, 4:59*am, T8 wrote:

On Mar 25, 11:04*pm, Darryl Ramm wrote:

The 302 can be very good with wind just with straight straight flight
with changes in direction of +/- 30 degree or so.

That's BS.

My $0.02. *I have a sample of one, but it has been extensively tested,
TAS output verified, pneumatic sources are from triple probe, not
shared, no leaks. *It does not come close to being able to do what you
claim.

My pda does better vector wind calc using 302 data.

On a ridge, forget about updates, they don't happen.

Never *EVER* use the 303 relative wind indicator. *It does not update
for ground track changes, it only updates when it gets a wind update
(huge oversight). *On one memorable flight, I saw the relative wind
indicator 180 degrees wrong for a 65 mile run down a ridge in 12 knots
of wind. *One smooth 360 turn at a 30 second or so rate will always
get a good vector wind.

Other major gotcha of 302 is lack of header for N-number. *You'll
discover how much fun that can be when you submit a badge or record
flight with an electronic declaration.

As long as these flaws are understood, 302 is otherwise a very good
instrument. *All it needs to be truly excellent is a firmware fix or
two. *Unfortunately, I don't think that's in the cards.

-Evan Ludeman / T8

Evan, just a suggestion, but before calling somebody else's post
bull**** maybe you ought to read it carefully and maybe know a little
more about what you are talking about. But hey, that's just a
suggestion.

It was not by accident I mentioned the need for a +/- 30 degree
change. But I'll try to be clearer, that is a +/- 30 degree change of
track, ie. change direction 30 degrees either side of a steady track.
That is the change that triggers the 302 to recalculate it's track/TAS
based wind calculations. If you have not been able to get a 303 to
display updated wind vectors by doing a = +/- 30 degree zig zag then
you are doing something wrong or have a faulty unit. I frequently do
these zig zags when exploring our local blue convergence lines to see
what side of the convergence I am on. With weak wind you need to do
more of a zig zag or take a turn to get really accurate wind but the
302 will try to give wind with a +/- 30 degree track change.

If you are flying straight along a ridge and don't have enough of
these heading changes within enough of a short time then the 302 will
not update its internal wind vector, it will update it's HW/TW
component data. That is expected. The wind calculations, need for +/-
30 degree track changes and data presented on the 303 is briefly
described in the 303 manual.

PDA based soaring software (like SeeYou Mobile and Winpilot Pro (not
Standard)) that calculates wind vectors based on track and TAS data
passed from the 302 may well show wind vector data and changes to that
with less of a heading change. Obviously basic trigonometry applies
and the implied errors get much larger if this is being calculated on
very small track changes. One thing I worry about with some soaring
software is it displays wind data aged over a long time. For example
if you take a couple of turns while on tow or a couple of thermals
before connecting to ridge lift, or even the turns to position to join
a ridge allows the software to make a wind calculation (which may or
may not be that accurate). You then go bombing along a ridge then for
100 miles without a significant enough turns (within short enough time
span) to actually be able to mathematically calculate the wind
properly but the software keeps the wind pointing much in the same
direction as before but with some changes that may well be just noise,
but a pilot might well be fooled into thinking "gee my PDA is better
here since it is updating the vector". Basic trigonometry just makes
this hard to do unless there is a significant track change within a
short time period.

One thing to do here is play with your particular setup and try to see
what is really happening. If you get a chance in some location to pull
a circle then see what the wind updates to. Know how to reset the PDA
software wind calculation. If you think the PDA is calculating wind
well without significant turns try clobbering the wind data in the PDA
and wait and see what it comes back with when it recalculates. (No I'm
not suggesting playing with your PDA while bombing along a ridge).
This is a good test for my earlier concern about some software not
being aggressive enough aging out old data. Of course in many ridge
situations the wind may blow predominantly and strongly from one
direction so not aging out that old data and continuing to display it
(with some level of random noise added) makes it look like the PDA
software is doing a great job, even though it may well really not have
enough raw data to be able to calculate what the wind is doing.

Some computers do have magnetometers or optional magnetometers to read
heading data and try to calculate wind direction without any turns at
all. The LX-7000 is one example. I've never flown with one, but I have
heard some anecdotal reports from people that they were not that
impressed with the wind calculations, say over what they were used to
from an SN-10 or C302/PDA software. It would be interesting if others
have comments on wind calculations from magnetometer based systems. In
principle at least, the magnetometer approach is the right way to go
if you want wind calculations for turn-free ridge soaring situations.

A question to the original poster, and one that commonly causes
confusion, is where are you looking at the 302 "wind data". On a 303
display? Or on a PDA? And if on a PDA what software are you using?

And to answer Andy's (9B) question the 302 does the wind calculations.
The 303 is needed to display the 302's internal wind calculations, but
they are also available via the dataport API (doc available on
Cambridge's web site) whether or not a 303 is present. Some home grown
and maybe other software does pull that internal wind calculations out
of the 302. SeeYou and WinPilot Pro base their wind calculations on
the TAS data from the 302 or from circle drift when thermaling, they
do not use the 302 internally calculated wind vector data. WinPilot
Advanced only uses circle drift so can't update wind data with heading
changes without circling. If you have a C302 I think you really want
Winpilot Pro not Advanced.

I fly with a Cambridge 302 and 303, the 303 is a handy backup to my
PDA running SeeYou Mobile, including for it's wind display of the
wind, but like all things it helps to know what is going on behind the
scenes.

---

My new friend Evan gets a bit off-topic in his reply about the "lack
of header for N-number", so I'll comment on that as well.

There is no "N-number" field supported in the IGC file format.
Cambridge just cannot add one even if they wanted to--or if they tried
to add a proprietary IGC record it would not apply to FAI badges and
records. All flight recorders have a GLIDER ID field and that is where
in the USA for badges and records you are supposed to enter the
gliders N-number. From the Cambridge PDA utility you enter the ID
field in the "Edit Glider ID and Polar" page. This is proper use of
IGC terminology on the part of Cambridge, it's not the CONTEST ID,
it's the GLIDER ID. Unfortunately elsewhere in their documntation
Cambridge does call this Contest ID and some other utilities may well
call this "Contest ID" but that's the fault of those software authors
not Cambridge. The IGC file format does support an optional CONTEST ID
field, the C302 does not support that AFAIK. You can see your GLIDER
ID in the header of a C302 IGC file it looks like this "HFGIDGLIDERID:
26DX" (that's my glider's "n-number").

If Evan is comparing the C302 to other flight computers that appear to
have an "N-number" and "Contest ID" field, then those flight recorders
are writing that data to the "GLIDER ID" and optional "CONTEST ID"
field whereas the C302 uses the "GLIDER ID" field only. Maybe Evan
meant that he wanted Cambdridge to add a CONTEST ID field?

Pilots in the USA have a convention of entering their contest ID in
the GLIDER ID field. Judy and others have tried to promote the recent
tightening of requirements from the IGC that this really must be a
GLIDER ID (i.e. N-number in the USA) and not a CONTEST ID issued to a
pilot. While I think the IGC harshness on the interpretation is a bit
silly, I don't think Cambridge can be blamed in any way for this
situation. The requirements for electronic declarations is clearly
explained in Sporting Code 3 Annex C. Including a note that this is
the unique aircraft ID not a pilot contest number. Unfortunately
badges and records involve reading the rules carefully, and this
GLIDER ID issues is explained in black and white right there. The IGC
specifically allows the NAC to overlook these kinds of errors for
silver and gold badges (and I understand that Judy will do this).

Darryl- Hide quoted text -

- Show quoted text -

Darryl,

I intend to buy a ClearNav unit which is only able to integrate with a
302. ClearNav uses 302 wind data and it does not use TAS from any
other instrument to help with wind calculation. ClearNav also
calculates wind during circling but this is not a great option on a
ridge. I am debating if I should buy the 302 or wait for another
variometer to come along that is going to integrate with the ClearNav.

It is my understanding that the ClearNav does use the Cambridge 302
internally calculated wind data, so essentially what you see is the
same as you see on a C303 display (well you could tell the ClearNav to
ignore that and just use circling wind but that does not make much
sense). I guess that says we expect Dave Ellis et al. to do the wind
calculation also inside the upcoming NK vario.

I've only flown with a ClearNav once it was talking the wind from a
C302 in wave and thermal and I did not notice any problem with the
wind calculations at all, but then I'm happy with the basic C302/303
wind data and I don't expect any difference just because it's driving
the ClearNav. But one flight is not much of a test (hint Kemp - I need
more time in your ASH-25). I've also flown a lot with an SN-10 but I
am a SeeYou Mobile addict and prefer driving that from a C302 which is
an IGC logger, and which will pass the TAS data that the SN-10 won't.

I've brought two C302+303+PDA with SeeYou Mobile combinations in the
last few years to equip two gliders and would happily buy a C302 again
today. I suffered through some flight log/memory corruption problems
with the C302 but was an early tester of Cambridge's new memory chip
and have had no problems in over a year with the new chip installed. I
had a pointer hand fall off one vario which was fixed free and traced
to a glue problem at the factory. I like their stepper motor driven
mechanical display. And I like the fact they are US based and you can
get easy service/repairs here. However like you I might also be
willing to see what Dave Ellis and the rest of the NK team do with
their own vario. If I was in the market now I'd talk more to NK about
what they have coming--your could ask them about the differences
expected between the C302 and NK vario wind calculations with ridge
type situations. Those guys know the insides of both instruments
better than anybody else.

I don't spend time running ridges but I play with wind calculations in
wave. If you really are running ridges and want highly accurate wind
data from a computer, I expect few of these systems really will be
able to deliver reliable data with slow/infrequent track changes. And
again the danger is some computers/PDA software might seem like they
do great wind calculations but in long ridge situations with few fast
track changes the systems just may not mathematically have accurate
enough data to possibly do this. It may take a lot of playing to know
if a system is really accurate or just lucky. With a C302 you do have
to do those = +/- 30 degree track changes to trigger the wind update.
Or like Tom (5Z) says maybe turn more (that will give more accurate
data especially with light winds).

Hope that helps a little.

Darryl