iltis42 / xcvario Goto Github PK

192.168.0.X is the most frequently used subnet of home WiFi router. When I connect xcvario in OTA mode, browsing 192.168.0.1 goes to the WiFi router. I need another IP address on OTA mode such as 192.168.1.1.

I couldn't find corresponding code even searching it for a day. If someone gives me a hint, I am going to create a pull request.

With height units selected as feet, the airfield elevation adjustment increments by +/-5m instead of +/-5 feet

Suggested changes in SetupMenu.cpp:

String elev_unit = "m";

// int step = 1;
float step = 1.0;
if( alt_unit.get() == 1 ){ // ft
// step = 5;
step = 5.0/Units::meters2feet(1);
}

float elevp = elevation.get();
if( alt_unit.get() == 0 ){ // m
	u = "m";
	p->ucg->printf("%4d %s ", (int)(elevp+0.5), u.c_str() );
}
else {
	u = "ft";

// elevp = elevp*3.28084;
elevp = Units::meters2feet(elevp);
p->ucg->printf("%4d %s ", ((int)((elevp+2.5)/5))*5, u.c_str() );
}
// p->ucg->printf("%4d %s ", (int)(elevp+0.5), u.c_str() );

Picture for schematic understanding only

Adding a transparent speed and altitude tape in airliner style on AHRS page would help to ease instrument scan in case of an possible escape from anunintentionally ifr scenario.
Soeed left side, altitude on the right.

Describe the bug
Current procedure for firmware updates, requires you to download the firmware file with a 3rd party device. Then upload it via browser to the vario meter.

Expected behavior
Option 1:

• Start the vario in wifi client mode (connects to hotspot)
• Go to the firmware update page
• Download the firmware directly on the device from a well known preconfigured url (https://xcvario.de/firmware/current.fw)

Option 2:

• Extend the XCVario Protocol to allow updating the firmware via remote device (E.g. xcsoar)

It would be great to be able to change the behaviour of the Speed to Fly Switch (Sollfahrtumschalter) in the settings.
Currently the Speed to Fly mode is activated if the switch is closed, but it would be great if one could set it to "Speed to fly if the switch is open" in the settings.

To be honest we just build in the switch with the wrong orientation and are looking for are easy software based solution rather than correcting the orientation of the switch.

My XCV dev device reacts sluggish and not always on the s2f mode switch button. It is setup as push button to toggle the s2f mode.

Steps to reproduce the behavior:
Connect a push button to S1. Setup as s2f toggle. Try to toggle s2f mode.

The circle/arrow icon should change reliable and immediately on every button press.

The non reliable switch seems to be present since the serial-dev branch got merged.

Two XCVs in Master Client configuration, master has a magnetic heading sensor attached and calibrated. The client does not show the heading, but it would be nice it would.

Describe the bug
XCV and connected XCS exchange MC values. From XCS to XCV does not handle units correctly when set to something else than m/s on XCV side.
E.g. XCS sends MC 1 m/s XCV receives 200feet/min, or 1,9knots when set to knots as unit.

To Reproduce
XCS on e.g. Laptop connected to S2. Setup XCV interface on XCS and change MC manually.

Expected behavior
Show the adjusted same value, or proper converted value on XCV side.

Desktop (please complete the following information):
Linux laptop, XCS compiled from head, XCV compiled from head.

I would love to add aircraft switches such as:

• gear
• air breaks
• canopy lock
• tow hook lock/unlock
• tail dolly sensor
• trim position sensor
• water lever
• event for logger

It would be nice to have current weather data in xcsoar, but this is often not possible, because the XCsoar device is connected to xcvarios wifi and can't use GSM/LTE... .

Proposal: If the xcvario hardware had two wifi devices, one, could act as a wifi client and proxy the data from any wifi hotspot to the xcsoar device. I don't know, whether this is possible.
Additional benefit:
The WIFI client could also easily used for software updates, since it is connected to the internet.

Auf der Version 21.0331-18 werden Bugs und Ballast nicht zum Wifi-Client 2. Gerät synchronisiert.

Describe the bug
100l set on XCS become 96l on XCV side.
100l set on XCV become 94l on XCS side.

To Reproduce
Connect an XCS and XCV. Adjust water ballast setting on one or the other side.

Expected behavior
Could be more precise.

Desktop (please complete the following information):
Linux laptop and XCS & XCV from head.

Switching on my two seater setup the temperature does show on the client only as "--°". no temperature.

I would expect the same temp value as on the master device.

XCV Versions 22.0824-23

The issue resolved with the first temp change. Then the new value gets propagated. Would be just nice to have it propagated even after booting up the devices.

The s2f switching setup for a two seater use case offer a lot of options. One basic principle is, that the vario's s2f switch status attribute offers a bidirectional synchronization, as well as being propagated and influenced by other smart devices connected by NMEA (using the CAI !g extensions).
Now setup's are imaginable where the two varios (pilots) disagree on the favored s2f mode. Fine, that should be possible.
We ran into the situation that with such a setup the s2f mode started to toggle ca once a second on both varios. It is reproducible on the ground as well as in flight.

Steps to reproduce the behavior:

1. CAN master vario s2f setup to connected switch
2. CAN slave vario s2f setup "auto speed"
3. glider on the ground
4. s2f switch cruise

Principle the expectation is that the master, front vario follows the switch position, the rear follows the setup auto speed to switch s2f mode.

What happens is:
https://user-images.githubusercontent.com/415029/162902984-77d015b5-c0b2-48a5-a71e-5aa99345611f.mp4

xcv firmware rev.: 22.0410

Proposed solution: Only allow the s2f mode change from a secondary vario, when "external" is chosen as input for the s2f mode change.

The ESP32S3 has become a fairly ubiquitous chip, with a lot of incredibly cost effective bare and featureful boards available. For development purposes, it would be nice to be able to explore some of these.

Unfortunately, the currently supported SDK (4.3) does not support the S3. This SDK is over 2 years old, it would be nice to bump it to at least 4.4 (where the S3 first appears) or, even better, something in the v5 domain.

This might be as easy as updating the instructions at https://github.com/iltis42/XCVario/blob/master/README.txt, but even if that compiled immediately it would still be necessary to test against a live target.

Update

According to #238 (comment), with compilers >4.3 there is a show-stopper bug in the I2C stack.

I'd love to add a reed switch for the water lever.

This would then trigger the drain process on xcsoar via xcvario protocol
and automatically decrease the ammount.

In xcsoar we could implement a warning that uses the ETA at the end of a task to notify the pilot to drain the tanks.

The recently aligned setup of weights with XCS should be nicely synched in-between tactical soar computer and vario.
Please provide the NMEA protocol for this.

Any activity that provocs water ballast synch between XCS and XCV still produces the already reported exploded water ballast settings. Eg dumping water results in multiple 1000l of water ballast on either side, XCS or XCV.
Throughout using the badly designed CAI !g NMEA protocol snippets to synch water ballast this issue is still not solved.

To Reproduce
Use the two seater setup, with master and slave XCV connected by CAN. Each XCV connected to XCS with the S2 port.
Steps to reproduce the behavior:

1. Change water ballast setting on one of the four nodes will produce the propagation escalation, or at least a significantly different ballast setting on other nodes.

Expected behavior
Any configuration of water ballast should propagate to all three other nodes, resulting in the same amount of liters ballast on all four nodes.

Versions
XCS 7.23; XCV 2207'ish

Additional context
For the communication with XCS the !g NMEA sentences should be discouraged and a better NMEA protocol put in place.

Second day flying the ridge.
XCVario used to increase familiarity of operation. FLARM function very useful.
FLARM function working. Active a lot the previous day and initially this day.
After approx. 1.5 hours’ notice not ‘seeing’ other gliders on my FLARM radar (XCSoar) or XCVario.
Observe only the GPS LED is lit on the LXNAV FlarmLED+ display. No pulse on TX LED.
Switch XCVario off and on several times (reboot both LXNAV PowerMouse and XCVario).
Condition remains.
Land.
Go home.
Next day investigate.
Power up panel including XCVario and FLARM.
Only the GPS LED is lit on the LXNAV FlarmLED+ display. No pulse on TX LED.
The LXNAV FlarmLED+ display during bootup displays as usual.
Power FLARM directly. Boots up and works! Not what I was expecting.
Reconnect FLARM via XCVario and power.
All working? Also unexpected.
The LXNAV PowerMouse has been working through an LXNAV S100 for some 2 months before swapping out for XCVario.
Puzzled as the connections are power and RS232. Power does not seem to be the issue as both units power up OK. That leaves the RS232 signal.
Puzzled as to root cause.
XCVario firmware was October 2021 (1)
Have now updated OTA to the latest release NOV(1).
See NOV (2) 21.1124-2125 is now available. Will update OTA with this before flying.
Waiting for another opportunity to fly to check.
Work around should the issue reappear. Land. Power FLARM direct.

Master client setup with master setup and equipped with a flap sensor. The client does not show the flap indicator. Would be nice though.

The thing that could work better
The human interface to the AHRS Autozero configuration is not clear, or misleading.

The current experience
By default when activating AHRS the menu shows an entry: AHRS Autozero: Cancel
There is just the on option the change it to "Start", obviously when wings are leveled etc. as the little help text explaines.
But the expectations to what is the further process is unclear and the config menu does not give any clue. How long does it take to complete the zero capture? No progress bar no hint. I let the configuration sit on "Start" and put the wing down after a couple seconds. Talking to Ralph, he decided to switch the config item back to "cancel" before putting the wing down. Obviously we both got lost, the manual does not help on this topic.

Expected behavior
I would like to see a progress (bar) after selecting start. Generally the config item "Autozero" would more suggest a On/Off option. Maybe it is a unhappy combination out of Autoconfiguration On/Off and an initial "on the ground" zero capture, that should not be coupled together at all into one config item. Just guessing here.

Additional context
Observed on 23.0513-21 firmware revision.

Hello, from when we switched to the new eglib the two invertDisplay and setRedBlueTwist are not anymore working and they are just empty stubs..
As i am playing around with the project i had some problems with a touchscreen ILI9341 2.8 inch display (the read bpc one sold on amazon) and also with a super cute 2 inch ips st7789, the ILI was reversed and the ST had bad colors.. clearly the invertDisplay for the ILI and the setRedBlueTwist for the ST did not work anymore.
Last good FW was the one of 14 dec 2021...
I downloaded the source, setup the toolchain and started compiling a trial and error phase, i tried to call the ili9341_SetDisplayInversion but had no luck, so i said goodbye to the hardware 0x21 command and decided to make it software using the inlines.

I had to work on the AdaptUGC.h file adding the missing logic in the stubs and modifing the setColor inline function:

void invertDisplay( bool inv ) {invertDisp=inv;};  	        // solved in grafic layer
void setRedBlueTwist( bool twist ) {twistRB= twist;};   	    // no more needed, type of displays phased out
inline void undoClipRange() { eglib_undoClipRange(eglib);};
// color
inline void setColor( uint8_t idx, uint8_t r, uint8_t g, uint8_t b ) {
		twistRB?
			eglib_SetIndexColor(eglib, idx, invertDisp?~b:b, invertDisp?~g:g, invertDisp?~r:r):
			eglib_SetIndexColor(eglib, idx, invertDisp?~r:r, invertDisp?~g:g, invertDisp?~b:b);
}
inline void setColor( uint8_t r, uint8_t g, uint8_t b ) {
		twistRB?
			eglib_SetIndexColor(eglib, 0, invertDisp?~b:b, invertDisp?~g:g, invertDisp?~r:r):
			eglib_SetIndexColor(eglib, 0, invertDisp?~r:r, invertDisp?~g:g, invertDisp?~b:b);
}	

I also added the two bools at the end in the private section

bool twistRB;
bool invertDisp

I added a zip file with the modified header, please integrate it in the main code i really would be happy.
Ciao

AdaptUGC_h.zip
;

Yesterday, I was on a longer flight using motor.
The XCVario showed permanently 5m/s or more. Which was totally wrong.
Most likely this was because the vario calculates the climb ratio from the compensated nozzle which is influenced by the propeller.

A Flarm with ENL is attached to the vario.
What do you think about an additional mode "ENL Auto" mode for "Electronic Compensation" in setup? This mode, will configur xcvario to use TK compensation, when motor is of, otherwise electronic compensated (or no compensation) will be used?
One can get the information whether the motor is running by reading flarm ENL data.

Describe the bug

Using BLE on XCVario seems to be flaky. The thing is, I don't understand why as it looks like the BLE code comes almost directly from an example sketch from Expressif. When I run the same example sketch inside the Arduino framework, on a separate ESP32 Wemos board, I get a very solid connection.

The debug stream at idf.py -p /dev/tty.usbserial-110 monitor doesn't seem to give any extra information.

Using nRF Connect, I can see that the connection simply times out, with a GATT_ERROR = 133. It works one time out of 10, and it requires a power cycle between each attempt.

Perhaps there's something going wrong with a FreeRTOS task priority?

If I have to change the airfield elevation over 100m and more, it is only possile in single meter steps by turning the rotary switch. I would wish me the following:

o turning the rotary switch slowly, it change the altitude per single meter
o turning the rotary switch fast, it change the altitude per 25 meters

Thanks for your excellent work with XcVario!!!

I found an issue here. It's minor I guess, but if at least the "ugly case" could be resolved somewhen it would be appreciated.

100% reproducible with Software 24.0410

The good case:

I use the $g,w1 and $g,w0 commands to activate/deactivate the gear warning. That works perfectly when always staying on the main page. On the main page $g,w1 will make the alarm appear both accustically and visually and it all persists until the $g,w0 command is received. The procedure can be repeated as desired. Perfect behaviour

The not-so-good case:

If I am on either the g-force or horizon page it looks less good. $g,w1 will activate the alarm accustically and visually. The visual part disappears after approximaty 0.5 seconds. The accustic part remains which is good. $g,w0 will stop the accustic warning. The procedure can be repeated as desired. Since the accustic alarm remains the behaviour is still quite ok albeit somehow unexpected.

The ugly case:

If I switch pages while the alarm is active the gear warning functionality has a complete breakdown. $g,w1 will no longer work until the XcVario is booted. So a Gear-up condition would no long warned of.

Switching pages while the gear alarm is not active has no negative impact
It seems as if it does not matter between what pages (main, g-force, horizon) are switched.

Thanks, Marcel

Describe the bug
After updating to the current version and a successful reboot the student mode was selected.
After reboot the device passes the selftest and allows the selection of an QNH.
When the selection of QNH is confirmed by pressing the button the Vario display appears. There's no movement/change in display content and after 2-3 seconds the speaker produces a constant tone and the device reboots.
To Reproduce
Steps to reproduce the behavior:

1. Enable Student Mode
2. Reboot
3. Select QNH
4. See error

Expected behavior
No crash

Screenshots
None

Additional context
Possible solution: Open the device and flash it again by using the internal USB Port.
Is it maybe possible to disable the student mode using a serial monitor (e.g. Arduino IDE) and send a command?
Or temporarily one line to the code to disable the student mode during startup and afterwards flash the regular firmware?
Is there a better solution than this? Disabling the student mode is not possible because the device doesn't boot completely.

Flap indicator on master and client changes when magnetic heading is changing.

Master client setup equipped with master connected to a magnetic sensor (S2) and setup for flap sensor and magnetic sensor.
Steps to reproduce the behavior:

1. Configure client to also enable the flap indicator
2. Move magnetic sensor
3. See the heading on master reacting properly, no heading indicated on client.
4. See the flap indicator on master and client moving erratic, but in sync.

Would expect the flap indicator not to move, because no sensor is connected.

In double-seater mode, the sound is lost, when switching between target speed and vario or when a Flarm warning appears. Afterwards only the slave can increase the tone again using the rotary wheel.

Since Relaese 24.0229 also in Release 24.410

Really like the design of this unit.
Had trouble calibrating CAN BUS sensor.
Put this down to user error. Re-read manual multiple times.
Completed calibration process incrementally as per manual on the bench. All working.
Switched on and off multiple times on the bench. All good.
Installed in glider the same day.
Switched on and off multiple times on the bench. All good.
Next day ridge flying.
Rigged and powered up panel.
Self-test fails CAN. Compass would fail.
CAN indicator greyed out.
Switched off and on several times. Still failing CAN test.
FLARM working.
Flight is not dependant on XCVario.
Fly. Great ridge day.
Notice while flying the CAN symbol blue at times. Also, at times there is a magnetic direction.
Not sure what the root cause is as XCVario and sensor are new. All connections are good. Cable is a known good cable.
My next step is swap in an RS232 sensor. Cable is 2M.
The issue seems to be with the CAN BUS in the XCVario unit. Not sure if the CAN BUS test bus needs a CAN device connected. The XCVario may have a loopback to test without devices connected. I did not try this last thing.
If I can help investigate this issue, I am comfortable to assist.
Best Regards,
Graham

When selecting the proper flap sensor gpio IO-34, the display stopped updating and the vario rebooted.

Did not manage to reproduce.
Steps to reproduce the behavior:

1. Master & Wifi client setup, both configured to flap enabled.
2. Flap sensor connected to client S2.
3. Enter setup and choose the IO-34, which the sensor is actually connected to.
4. Press the rotary.
5. Vario reboots

Liked to check on if the client would display the flap sensor readout if directly connected. It does actually, when tried a second time.

I would like to see the wingload displayed in the setup menu behind the Ballast setting. The % ballast does not give a clue on which wingload the glider is configured, but as of my understanding that is exactly what you want to achieve: Put the glider to the desired wingload. The display could look like this.
QNH ...
Ballast: 48kg/m^2 (40l)
Bugs. ....

Gear warning and Flarm alert 3 generate only click sound

*To Reproduce
Activate gear warning or Flarm warning simulation

Runing latest (24-0410-1849) release

In my installation (using an external speaker) setting the volume to a level that sink and weak climb rates (say below 1 m/s) are clearly audible high climb rates (4..5 m/s) become uncomfortably loud.

Of course this may depend on the frequency characteristics of my external speaker but may also originate in the frequency-dependent sensitivity of the human ear. I think it would be great with a frequency dependent volume adjustment.

A few thoughts on how this could be achieved (I have not carried out any experiments though):
One could e.g. base upon the A-characteristics used in noise measurements. Using Ra(f) as given in http://www.sengpielaudio.com/BerechnungDerBewertungsfilter.pdf one could set the frequency dependent volume in the form

v(a,f) = v_0 * (1 + a*Ra(f_0)/Ra(f) ) / (1+a)

(v_0 being the volume setting defined by the rotary, 0 <= a is the new proposed adjustment parameter and f_0 the center frequency of the the generator). Setting a=0 reproduces the current behavior v(0,f) = v_0 and also v(a,f_0) = v_0. Higher values of a activate the frequency dependent volume setting where lower frequencies are output at a higher amplitude than higher frequencies up to around 2..3 kHz slightly increasing again at higher frequencies.

With standard settings (center=500 Hz, octaves=2.0) and a=1 one would arive at an (increased) volume level of +43% at 250 Hz and a -16% (decreased) level a 1 kHz, -20% at 2 kHz and 4 kHz (at 8kHz it would rise again to around -10%).

Ra(f) defines the amplitude of the sound. So in theory the above assumes that the volume parameter adjustment should be proportional to the relative amplitude changes. I don't know whether this assumption is correct or not, after all the volume setting is just some parameter of the amplifier logic. So may be one needs another scaling than Ra(f_0)/Ra(f).

Dirk

would you mind to add some notes to help building the project ? I've the espressif toolchain installed (and python3, ninja + deps) but so far any attempt to build the project has failed with compiler errors

ie

/components/I2Cbus/include/i2c.h:88:54: error: 'i2c_config_t' does not name a type; did you mean 'gpio_config_t'?

and, just in case, what is your development platform of choice ? Im on linux and mac but testing on mac atm

thanks in advance

The MC changes on XCS side do not propagate to XCV as they did in the past.

It still does work using BT connectivity. The S2 connection does propagate MC from XCV to XCS and XCVario protocol is Ok.

XCSoar on Android 9
XCV rev 29.12.2021
Serial/USB dongle on OTG Hub plugged to S2

The HUB is also a new change since last time I witnessed things working, but the HUB does work fine for eg USB stick, 5V charge. So I expect a full duplex functionality with the serial dongle.

I'd like to see the change on polar settings on the master automatically being used from a client display. Currently the client need active attention to be setup the same way.
I would rather expect to have the polar setting transferred when registering to the master, even if the client's flash representation of those config items is untouched.

Current Situation:
I have a flarm device connected to xcvario. I don't know the baud rate.
How can I check whether communication xcvario- flarm works?
It is cumbersume to find out the baud rate of the attached flarm.

Proposals:

1. Add a "Flarm status" to the System configuration which shows

• Flarm connection is working (at baud rate xyz)
• GPS data in Flarm available

2. Do automatic selection of baud rate
   Other devices which use flarm data (Rechenknecht) have an automated approach. They check different baud rates automatically and find out the baud rate of the flarm device automatically by checking the common values.9600, 19200...

If this makes sense, I could try to implement it.

The error message is

/home/caz/.espressif/tools/xtensa-esp32-elf/esp-2021r1-8.4.0/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/8.4.0/../../../../xtensa-esp32-elf/bin/ld: esp-idf/ESP32-OTA-Webserver/libESP32-OTA-Webserver.a(MyWiFi.cpp.obj):(.literal._Z17start_dhcp_serverv+0x8): undefined reference to dhcps_set_option_info(unsigned char, void*, unsigned int)' /home/caz/.espressif/tools/xtensa-esp32-elf/esp-2021r1-8.4.0/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/8.4.0/../../../../xtensa-esp32-elf/bin/ld: esp-idf/ESP32-OTA-Webserver/libESP32-OTA-Webserver.a(MyWiFi.cpp.obj):(.literal._Z17start_dhcp_serverv+0xc): undefined reference to dhcps_dns_setserver(ip_addr const*)'
/home/caz/.espressif/tools/xtensa-esp32-elf/esp-2021r1-8.4.0/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/8.4.0/../../../../xtensa-esp32-elf/bin/ld: esp-idf/ESP32-OTA-Webserver/libESP32-OTA-Webserver.a(MyWiFi.cpp.obj): in function start_dhcp_server()': /home/caz/esp/esp-idf/examples/get-started/XCVario/components/ESP32-OTA-Webserver/MyWiFi.cpp:127: undefined reference to dhcps_set_option_info(unsigned char, void*, unsigned int)'
/home/caz/.espressif/tools/xtensa-esp32-elf/esp-2021r1-8.4.0/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/8.4.0/../../../../xtensa-esp32-elf/bin/ld: /home/caz/esp/esp-idf/examples/get-started/XCVario/components/ESP32-OTA-Webserver/MyWiFi.cpp:131: undefined reference to `dhcps_dns_setserver(ip_addr const*)'
collect2: error: ld returned 1 exit status
make[2]: *** [CMakeFiles/sensor.elf.dir/build.make:446: sensor.elf] Error 1
make[1]: *** [CMakeFiles/Makefile2:2133: CMakeFiles/sensor.elf.dir/all] Error 2
make: *** [Makefile:136: all] Error 2
make failed with exit code 2

BTW, thank you for picking my complain about IP address. You change 192.168.0.1 -> 192.168.4.1

Describe the bug
When I add a new glider to the polar, I do not expect it to calculate a weight for me. I prefer to include this information myself, as referenced from the published POH.

However, XCVario calculates the weight by multiplying the wing-loading used during the polar tests, the wing area, and an 80kg offset. https://github.com/iltis42/XCVario/blob/cb9faa019a2baaf9bd6c61f8aef775203d02c482/main/S2F.cpp#L38C22-L38C36

For a SWAG (scientific wild ass guess), an 80kg pilot isn't bad, but it gets into a bit of trouble with TMGs, as there it's not fair to assume polar coordinates come from an empty plane with a single parachute-wearing pilot.

This violates the principle of least surprise, as the user cannot see where the weight is coming from, and it's not clear either when looking in Polars.cpp.

Expected behavior
Weight should either not be automatically calculated (i.e. by including weight into the polars) or the UI should state clearly how the weight value is calculated.

Criticality

Not at all critical. If the maintainers disagree, that's okay, this Issue leaves breadcrumbs for future people who come across this. It would, however, still ideally be documented in the UI. It took quite a few minutes of searching around to find the line of code where weight was calculated.

Some Andoird devices, specifically the nice reflective display eReaders, do not have an own speaker, rather expecting to operate with a connected sound sink.
It would be generally great to have this offered through the XCV that has a speaker, or might be connected to the cockpit speaker system.
Most meaningful warnings like airspace warnings would then be acoustically present also for the designed silent Android devices.

It would be nice to build on existing protocols, even other solution with potential less code footprint would be viable.

After a FLARM alert, volume keeps as defined for the last FLARM traffic alert level and dosen't get restored correctly.
There is no workaround, only option is to disable FLARM alert at all.
The problem is in since the FLARM feature has been implemented.

Describe the bug
A clear and concise description of what the bug is.

To Reproduce
Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: [e.g. iOS]
• Browser [e.g. chrome, safari]
• Version [e.g. 22]

Smartphone (please complete the following information):

• Device: [e.g. iPhone6]
• OS: [e.g. iOS8.1]
• Browser [e.g. stock browser, safari]
• Version [e.g. 22]

Additional context
Add any other context about the problem here.

Glider performance degradation due to bugs and the common way, or at least the xcsoar way, to depict it with a percentae number from 0% up to 50% might be a way to go for most cases, even not very scientific.
I still would like to go with just the "%" sign as unit, like.
Ballast: ...
Bugs: 4%

just skip the repetition of "bugs".

Hi
Very great discovery, i haven't seen your project before. Nice view for the 'red arrow' too and big number look nice. I wonder, can it be possible to change the lcd display as well ? Are you using a special library.. or it's just a matter to simply load a different one and having proper pin connected .. ? I was looking for one with the ST7789s controller.

thanks in advance

As of what i have seen in two seaters it makes much sense to have the client display switching in-between vario and s2f display at the same moment, as it also does not make sense to have vario and s2f tone at the same time blasting through the cockpit.
The latter is nicely implemented, but I would expect that the vario/s2f switching configuration from master would automatically apply for the client device.

QNH and Bugs sync in both directions xcvario-xcsoar without problems.
MC also is ok providing the units are set to m/s but if kts units are selected then there are issues which I think is a unit conversion calculation and/or rounding errors.
Soar to Vario syncs 2 kts to 1.9kts, 3kts to 2.9 kts and so on.
Vario to Soar syncs 1kts to 0.6kts, 2.1 kts to 1.2 kts, 3.1 kts to 1.6 kts and so on.
Ballast soar-vario is also modified 50l to 48l, 60l - 58l 70l -68l and so on.
vario-soar ballast change does not work at all.

Is this a bug in Xcvario or Xcsoar?

XcVario v21.1228-2019
XCsoar v7.21 Andriod 10.0.0.491 Hauwei P30 lite, driver XCvario over BT

The current implementation duplicates code for UL display, what comes around with duplicate effort for maintainability, esp. in the current phase of major display improvements this is not acceptable.
The concept, so far i have understood from the user community is to have QNH value always displayed, what is already in place for the retro display style.
And there is no MC info and S2F bar needed for motorized UL application, what can easily handled by a flag to mask those items from retro display.
Anything we have forgotten ?

Hi,

With Reference of my own glider DG-800S, HB-3436 I believe that the DG800S/18 Polar is correct while DG800S/15 Polar has wrong Reference Wingload:

Realistic (18m):
{ 1390, "DG 800S/18", 29.97, 77.9497, -0.4760, 130.0, -0.9192, 170.0, -1.7786, 150, 11.81}
-> 11.81 * 29.97 = 354kg

Wrong (15m):
{ 1370, "DG 800S/15", 34.93, 92.4983, -0.5834, 130.0, -0.9720, 170.0, -1.6852, 150, 10.68},
-> 10.68 * 34.93 = 373kg

Based on my Glider, Reference Weight 15m should be 8kg less than Reference Weight 18m

Proposal (15m):
(354 - 8) / 10.68 ) = 32.40
{ 1370, "DG 800S/15", 32.40, 92.4983, -0.5834, 130.0, -0.9720, 170.0, -1.6852, 150, 10.68}

Thanks for considering.
Marcel

Just got my two units, they're great. The OTA update for the firmware is just awesome. I notice, as I play around with them on the bench, that there's no debug screen I can find. It would be nice to have a series of debug screens, accessible via a click on the knob, which show various internal datapoints. Things like:

• measured pressure
• measured IMU data
• IMU temperature, setpoint, and self-heating duty cycle
• magnetometer data
• CANbus message ID history
• input pin status
• free heap/stack/flash
• number of corrupted NMEA packets received from external peripherals
• etc...

If this sounds like something you'd like, I'm happy to do most of the lifting here if someone can provide the initial scaffold; e.g. a new UI page, accessible via a knob click, with a single letter of text on it. Once I see how to add one thing, I can abstract that out to adding many things.