iltis42 / XCFlarmView

High contrast Flarm Traffic display with small size sunlight readable ~20x60 mm (1.47 inch) LCD, or larger display with 2.4 inch
GNU General Public License v3.0
2 stars 2 forks source link

Climb rate indication for competition flying #5

Open ZanderPeter opened 2 weeks ago

ZanderPeter commented 2 weeks ago

Hi! I'm looking for an update which would help when flying competitions. I'd like to see the climb rate of the other gliders which are circling. To keep the display readable my idea is to change the colors of the circling gliders, for example:

green: climb rate is >0.5 higher than my climb rate yellow (or any other color): climb rate is >0.5 lower than my climb rate blue: almost the same climb rate

This could help a lot when deciding which gaggle to join without having to select different targets to check the climb rates.

iltis42 commented 2 weeks ago

1) In XCFlarmView traffic display, the color's are taken ATM as they carry the danger level so green color means safe, white color means close (look out to see target), and red/white color means alert (take action to avoid), and the blue color is not visible in bright sunlight. 2) Another problem to be solved first is that the your own climb rate is not available from Flarm that uses its own proprietary total energy algorithm but provides this info only for other gliders. 3) An i see the aspect that just altering the color for anyone climbing better than 0.5 m/s than yourself won't help to see the one who climbs 3 m/s better.

ZanderPeter commented 2 weeks ago

Thanks for the quick reply Eckhard! Colors for collision avoidance have a higher priority for sure. I can also accept the two arguments with the own climb rate and that you won't find the mega climb rates just by highlighting gliders with a higher climb rate. Maybe it could be an approach to just highlight gliders with "outstanding" climb rates with a different design such as a ring around the glider or something like that when the climb rate is higher than a climb rate which could be set in the menu or even better dynamically set by an average climb rate in the last 30 minutes or so.

DanD222 commented 2 weeks ago

I would be happy with two colours with user-configurable thresholds, so one could set a colour band for >0.5 m/s for example, and another one for >2m/s.

I would mark “danger” with a circle perhaps, as having lots of circles to indicate climb rates would lead to clutter I believe.

(I would also love to be able to mark a team mate, which could be done with a rectangle perhaps)

iltis42 commented 2 weeks ago

One question, are you talking about the 1.4 or the 2.4 inch display? Guess both have different potentials as of more buttons avail. Regarding: "so one could set a colour band for >0.5 m/s for example, and another one for >2m/s." See (2) in my initial comment. Regarding: "mark “danger” with a circle " and "outstanding" climb rates with a different design such as a ring around the glider": The circle is taken for the ID selected. Regarding: "mark a team mate": Good idea, maybe a bit creepy with a single button on the 1.4 inch, short press/long press is already taken, maybe a double click as an option?

An idea could be to display the best climber(s) within the Flarm range (usually something like 5 km), together with a number corresponding to the m/s climbing, something XCSoar does for all targets once they don't have stealth mode enabled. Note that the climb rates are somehow a bit fuzzy, IMHO a bit undercompensated. Often i see high performance gliders pulling into a thermal with 2,3 even 4 m/s for a couple of seconds, then dropping to 1.5 m/s (maybe someone can confirm the finding ?). Guess the Flarm's TEK model takes a standard class model and no water, meanwhile if its an 18m ship with high wingload pulling 100 m (even more) out of its kinetic enery. That means that you might think the glider beside you catched the better thermal and you start shifting your circle to the new center and both end up with 0.9 m/s while before you had already 2.2 m/s. So just highlighting may confuse more that it helps. My current approach using those numbers in the XCSoar is to wait maybe one full circle until this gets stable, and then decide.

DanD222 commented 2 weeks ago

Good points.

Regarding the colour bands, I meant the absolute climb values as reported by Flarm, to avoid the issue of not knowing my own climb values, like you say in (2) in your initial comment. This would still provide valuable information about climb rates of others around you.

Regarding the initial vs stable climb rates, what comes to mind is perhaps have the target symbol be opaque coloured the first 30-60 seconds of their climb, and then become solid coloured after this period.

Regarding the buttons, ideally I'd like to see a dual rotary encoder with a push button on both displays ;) (I like the option of being able to navigate to the previous target without having to cycle through the targets again, and also a separate control for zoom) But, working with what we have, I think a double click is a good option to mark a target as a team mate.

Setting the thermal climb bands with a single button would mean a lot of clicks if the increments are 0.1 m/s, but still be possible I think. If the defaults were set to say 0.5 m/s and 1.5 m/s then this would save the user a few clicks as opposed to setting the climb rates from zero. After say 5 m/s, the climb rate threshold would start from 0 again.

So what remains an open point I think is how to differentiate marking danger from a good climb rate. Perhaps a thick red circle around the target with an X through it over the target?

It would probably be good to have both colour schemes available, for those who want a simpler traffic awareness display, and a competition mode for those interested in seeing the climb rates of others around them?

DanD222 commented 2 weeks ago

Thinking further about the danger vs climb rate differentiation, if there was to be a separate "competition mode", then this could have its own colour scheme, for example:

So the red = danger would be consistent with the as-is state (and there should be no need to do things like put Xs over target symbols).