I don't know how other guys do it, but this is how I see it.... I estimate the bug factor mainly by looking at the leading edge, if it is very bugged I just worsen the profile some per cents (3-5). I sometimes try to look how final altitude corresponds to current glide, but (as stated below) it is almost impossible to deduce anything.
I also start a bit lower value to "correct" the fact, that the glider probably isn't in the same condition it was from the factory (or that it wasn't probably the best specimen even when it left the factory) as an additional small "safety factor". Normally 96-98 %. I am quite certain that it is impossible in any reliable way to calculate the estimated bug factor from the performance because the lift & sink during the glide very much exceeds the bugs factor. A good glide gives L/D well over 100 and a bad sink may put 40+ standard glider to 1:10 - seen that, just and just got home :/ (well a bit of rain helped the sink though). The bugs normally wouldn't make you lose more than a few points in L/D. As a corollary, it is much better used time to try optimize the glide than the software settings :) hannu On 5.1.2011 17:15, martin.kopp...@gmx.de wrote: > Am 05.01.2011 um 13:57 schrieb Hannu Niemi:I know it's the latter, as per the > manual. > Still, that's hard to estimate. > I wonder how you guys do that? > Do you check your sink rate at a given speed? > I usually don't deal with it at all, I just add an estimate to the arrival > safety height ... > > Just thinking loud here: > Could an overall performance degradation be automatically estimated from the > average flight data over a given time interval? > Could this be used as a proposal for bug setting? > Or could we maybe set an estimated bugging rate for the day for XCS to > include in the calculations and only hit a "Bugwiper" button when we have > wiped them off? Flying low would increase the bug build up rate, while flying > high would add less, of course. > > Viele Grüße, > Martin > > > ------------------------------------------------------------------------------ > Learn how Oracle Real Application Clusters (RAC) One Node allows customers > to consolidate database storage, standardize their database environment, and, > should the need arise, upgrade to a full multi-node Oracle RAC database > without downtime or disruption > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > Xcsoar-user mailing list > Xcsoar-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/xcsoar-user ------------------------------------------------------------------------------ Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ Xcsoar-user mailing list Xcsoar-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xcsoar-user
