Replies: 6 comments
-
CPU-wise, the terrain renderer is ten thousand times more expensive (or so). You are right, CPU is not a problem at all - and never was. Even those old iPaqs could have done that easily. |
Beta Was this translation helpful? Give feedback.
-
Yes i agree, crunching two more terms for S2F should no longer be a problem. Almost any embedded system comes nowadays with a hardware floating point unit doing addition, multiplication or division incredibly fast, such as 150 nanoseconds. |
Beta Was this translation helpful? Give feedback.
-
Computing 4th order sink is easy. But the inverse problem (computing 4th order MacCready STF) is hard. With the quadratic model, you can immediately solve for the speed that corresponds to a given value of sink by using the quadratic formula everyone learns in grade school. XCSoar does that now. But for a higher order model, you must hunt for a solution iteratively. That is also a trivial CPU load, unless you do it frequently. So, how often does auto-MacCready update? And how many other calculations also need this result? Task optimizer, maybe? And how fast is the the CPU? Many people run XCSoar on very old hardware. If the CPU burden is too high, an intermediate solution might be to have multiple quadratic models, one for low speed, one intermediate speeds, and one for high speed. The speed ranges can overlap. The solver would pick the model that is most nearly centered on the sink rate value, and then solve for the speed using the quadratic equation code in XCSoar today. Unfortunately, with multiple models, when a small change in the sink value causes the solver to switch models, there is likely to be a discontinuity in the computed speed. So, this would not be my first choice. It would be better to find ways to reduced the CPU load of the iterative solution. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
In the end we want a STF that is useful for cruise and final glide. |
Beta Was this translation helpful? Give feedback.
-
Why bother with polars and poor approximations like this at all? Why
not just a lookup table of the speed/sink every 5 kph?
…On Fri, May 17, 2024 at 11:57 AM Philipp Wollschlegel ***@***.***> wrote:
In the end we want a STF that is useful for cruise and final glide.
I think we have to look at the mc value's rate of change and see whether those are realistic.
You can only so and so fast correct a speed that is displayed to you. Say 10km per second.
Potentially also use a longer period of time to assess the current air-mass, for example 10 seconds.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
Certainly not a new idea. What are the pros and cons to this. CPU horsepower would certainly not be the barrier any more. Just a simple pic to illustrate the obvious advantage.
The lower speed and as well the typical kink at about beyond best l/d speeds are captured. A s2f optimizer should not recommend nonsense below min speed any more, as well as be more considerate on high speeds.
I did a rough google search without any good findings to literature on this topic.
Thx
Beta Was this translation helpful? Give feedback.
All reactions