-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
NMEA PLARS: add support for switching between Circling & Cruise flight mode #8
Comments
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? |
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. 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? 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. |
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 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. |
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
The text was updated successfully, but these errors were encountered: