If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#1
|
|||
|
|||
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 |
#2
|
|||
|
|||
302 wind calculation
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 |
#3
|
|||
|
|||
302 wind calculation
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 |
#4
|
|||
|
|||
302 wind calculation
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. |
#5
|
|||
|
|||
302 wind calculation
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 |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
302 wind calculation | AK | Soaring | 21 | April 3rd 10 01:27 PM |
302 wind calculation | 5Z | Soaring | 1 | March 26th 10 11:56 AM |
302 wind calculation | Darryl Ramm | Soaring | 0 | March 26th 10 03:04 AM |
302 wind calculation | AK | Soaring | 0 | March 26th 10 02:47 AM |
Vector Wind, Relative Wind calculation C 302/303 | [email protected] | Soaring | 2 | December 9th 08 07:23 PM |