NMEA PLARS: add support for switching between Circling & Cruise flight mode

[MaxBaex]

This feature is required so synchronize the flight mode between OpenSoar (XCSOAR) and the Larus devices.

Protocol suggestion from my side is:
FM == FlightMode:

$PLARS,L,FM,CIcs CI == Circling
$PLARS,L,FM,CRcs CR == Cruise

The XCSOAR LX and Vega drivers support controlling the flight mode. Examples can be found here:
Line 58 https://github.com/XCSoar/XCSoar/blob/master/src/Device/Driver/Vega/Parser.cpp
Line 272 https://github.com/XCSoar/XCSoar/blob/master/src/Device/Driver/LX/Parser.cpp

[Simsys]

We would be happy to exchange further information. However, I have not yet fully understood this. What should be switched by whom and how?

So far, the interactions go in both directions. Changes to XCSoar are passed on to the frontend and changes to the frontend are passed on to XCSoar.

XCSoar also determines whether it is circling or flying straight ahead. Should this be overwritten by the front end? Or should this also be possible in the other direction? How do you set the direction if necessary?

So far I have only seen this information in the “legacy version” of the CAN bus, in which the sensor box tells me which mode it is in. In my opinion, however, this function is not very sophisticated. There is an intermediate state that has to be taken into account. Under no circumstances can this be passed on 1 to 1. In addition, a sensible data point would have to be defined in the new format.

By “is available in the CAN bus” do you mean this function (Vario Mode Control)? That is something else. This is about whether the front end should switch automatically or manually between MacCready (target drive) and Vario. This function is already used in the two-seater between the two front ends at the front and rear, as they have to work synchronously. Otherwise the sound will not match the display in case of doubt.

Mode vario / set speed is different from circling / straight flight.

We should define and implement extensions “as a block” and not in small steps. This will be easier to accept from the point of view of the XCSoar project. Are there any other ideas?

[Simsys]

Definition VarioModeControl https://github.com/larus-breeze/doc_larus/blob/master/documentation/can_details/object_directory/vario_display.md#id-0x682-set-system-wide-config-item

[degeflija]

How clever algorithms in either the sensor or the frontend are, on when to apply CRUISE mode, when to apply CLIMB mode, there will always be situations where the pilot does not like the automatic choice : Especially while flying along a ridge or when flying in wave. The automatic algo says CRUISE, the pilot prefers CLIMB.
This is when by user interaction I switch the frontend to CLIMB, and I expect XCSoar to follow suit.
As of today, I have to force XCSoar to CLIMB by command.
I certainly do not want the algo of XCSoar overwrite the mode in the frontend,
so in this case the info flow in unidirectional.
And I certainly wont let the sensor decide which mode to fly in the front end. or XCSoar. Klaus explicitly told me, the sensor mode is not usable in the frontend. This is why I have build my own algo to switch modes. And that works fine.
In 80 % of cases, my algo and XCSoar change the mode more or less at the same point in flight. The manual interaction here is rarely need, but absolutely needed.

As far as I understand the sensor, the sensor based climb-cruise-mode only governs the way, wind is averaged and forwarded to the frontend and to XCSoar.

XCSoar also determines whether it is circling or flying straight ahead. Should this be overwritten by the front end?
-> YES
Or should this also be possible in the other direction?
-> NO
How do you set the direction if necessary?
-> Is not neccessary.

Mode vario / set speed is different from circling / straight flight. ??????????????????? Unclear, Please explain.

As far as I know XCSoar protocol of VEGA already contains this function. See Maxens Mail.

[MaxBaex]

I agree that XCSoar shall not control the Frontend - Flight - Mode. The Frontend shall control XCSoar. Within XCSoar it is currently not possible to manually switch the mode. This is handled automatically as described here:

https://download.xcsoar.org/releases/7.42/XCSoar-manual.pdf page 74
XCSoar automatically detects the difference between circling Flight
and cruising Flight. Circling is enabled when the glider turns (typically
three quarters of a turn). After about 30 seconds of straight line Flight the software will switch from circling to cruise mode. Hence,
the switch is based on a simple condition.

The Frontend Mode "Vario <-> Set Speed" is similar but not identically to Circling <=> Cruise Mode as in XCSoar this state is also used to change Map and Infobox settings. I think that very rarely it happens that the pilot wants the Larus Frontend - Vario Mode to gain altitude quickly but at the same time also see the XCSoar Infoboxset from Cruise Mode. In most use cases it would IMHO be helpful to connect the Larus Frontend mode "Vario <-> Set Speed" with the XCSoar CIRCLING and CRUISE state. I thus opt for connecting the CAN-Bus settings (vario_mode_control u8: 0 Vario, 1 SpeedToFly, 2 Auto) with the NMEA sentences $PLARS,L,FM,CIcs CI == Circling $PLARS,L,FM,CRcs CR == Cruise to our NMEA Protocol.

Implementing the Larus driver in XCSoar shall upon receive switch between SwitchState::FlightMode::CRUISE and SwitchState::FlightMode::CIRCLING.