openvario / meta-openvario Goto Github PK

The font in the InfoBoxes, particularly the label and the comment are awfully small.
I've been looking around in the source but can't find anything.
The font scaling on the map window works as expected.
Does anybody have an idea??

BTW: a screenshot function would be so nice. ;-)

I'd like to be able to support the use of two WiFi networks simultaneously. I am using a Stratux which provides AHRS, ADS-B In, and GPS through its own WiFi network (192.168.10.x) , and I'd also like to be able to access the Internet through my phone's hotspot (192.168.1.x and everything else). When I put in two WiFi dongles, both are seen and identified as wlan0 and wlan1 on ifconfig, but I'm not sure how to access these individually through connman.

Apparently there was an option to run Tophat or LK8000 instead of XCSoar. We only ship XCSoar right now. We might want to ship these, but I'm not sure in which form.

Heads up.
Please inspect this PR:
XCSoar/XCSoar#367

I fixed sentences for POV,C,WL and POV,C,BU and I hope I didn't break anything.

connman-ncurses is a friendlier way to configure wifi. It was shipped with the original image, so many users expect it to be present.

The workaround is to use connmanctl, the command line version of it.

I use a self compiled new image with XCSoar 7.0_preview 15. I disabled variod because of testing vario sound of my FreeVario.

Sound for airspace warning dosen't work. I only have a strange sound.
Warnings.mp3.zip

I like to test with stable version, but there is no menu Audio-Vario or Audio in general.

Hi guys.
Using @kedder backlight brightness file I added a simple menu to control it from "Settings" menu.
It is only a minor enhancement.

At the moment the 4,3" RGB is not supported.

• Add display support in DTS file
• Add color swap patch for uboot and kernel

The documentation
https://www.openvario.org/doku.php?id=projects:series_00:software:nmea
says POV,C,RPO and POV,C,IPO are used to send polar information from XCSoar to variod.
Looking at the C-code, nmea_parser.c in particular it is looking for POV,C,POL
This is inconsistent with the documentation and - even worse - XCSoar never sent a POV,C,POL sentence. XCSoar always sent POV,C,RPO and POV,C,IPO sentence, which were never understood by variod.

How do we resolve it?

BTW: I'm implementing the counterpart to XCSoar/XCSoar#378
In particular the to get the relevant current settings of XCSoar (MacCready, wing load,
polar, polar degradation). variod can do this at any time, especially upon restart to sync up with XCSoar’s settings.

According to @mihu-ov, touch screen calibration and rotation doesn't work in 20067.

touch works, but calibration / rotation matrix not activated?

@linuxianer99, @mihu-ov, how about releasing a new preview image (after merging #93)? There were a bunch of good improvements since the last release.

Right now, as @mihu-ov pointed out, there is no password for root user in default image.

I expect many users will enable wifi on their openvarios. Having internet-facing device with unprotected root access is probably not the brightest of ideas (if we don't want openvarios to accidentally start mining bitcoins or something like that).

Should we set it to something hardcoded, like openvario for simple protection against bots and recommend users changing it immediately? Something more sophisticated?

in warrior branch opkg config to update from usbstick is missing

Users are reporting that 7" Texim display doesn't work with the recent (20067) image.

Here's a video of non-working image: https://drive.google.com/open?id=1qQbzZW6G60sZAgtfYW7ZHiwC8yZA5LGY

Apparently 7" Texim has different resolution (800x480) than PixelQi one (1024x600). So devicetree files we provide are obviously wrong. U-boot configuration is also wrong.

We need to pick the right timings from old fex file.

See recipes-kernel/linux/linux-mainline/openvario-7-CH070.dts, recipes-bsp/u-boot/files/openvario-7-CH070/openvario_defconfig.

When I do opkg update, I get error:

root@openvario-57-lvds:~# opkg update
Downloading http://ftp.openvario.org/feed-warrior/all/Packages.gz.
Updated source 'remote-all'.
Downloading http://ftp.openvario.org/feed-warrior/armv7vet2hf-neon/Packages.gz.
Updated source 'remote-armv7vet2hf-neon'.
Downloading http://ftp.openvario.org/feed-warrior/openvario_57_lvds/Packages.gz.
Collected errors:
 * opkg_download_backend: Failed to download http://ftp.openvario.org/feed-warrior/openvario_57_lvds/Packages.gz, wget returned 8.

This happens because Packages.gz file is missing from http://ftp.openvario.org/feed-warrior/openvario_57_lvds.

Please provide that file.

Hi there!

Thank you for creating this great hard- and software combination! A friend bought an openvario from SteFly and I helped him to get it working properly, especially with the software, and also that was the reason why I also bought a used one for myself now ;-)

Anyways, the creation of the USB thumb drive for file up-/download as described here could be done easier: Why not provide a way directly from the openvario menu to format the drive properly, when a drive is inserted and not mountable? I've already found the script files here and think this could be a nice place to put such a drive formatting tool.

Do you agree with this idea, or are there already other developments active in this way? Would it be OK for you when I do a pull request in some time, when I'm ready to experiment with my own OV device?

Hi guys, I've fixed a misnomer in the Menu scripts to allow file download from OV to USB and added an option to delete all igc stored files.
Also added a Spanish language option to the menu.
Works OK with previous OV buildsystem, now it seems it does not mount USB drives.
If you'd like to have a look to the scripts please, I issued a pull request from my branch.
Let me see if I can figure out why USB seems not to mount.

Regards.

Vario sound is reported to be broken by several users:

variod sound output broken

The audio was odd. It may have been that things were just incorrectly configured, but my original image, the audio seems very normal compared to a vario. This seemed like it was modulated with a low frequency square wave. I.e. it would just cut in and out constantly.

This gives an idea how it sounds like: https://drive.google.com/file/d/1qQbzZW6G60sZAgtfYW7ZHiwC8yZA5LGY/view

SSH access works (tested with Bitvise SSH and Windows Power Shell) but I get no SFTP access.
Error message is

[email protected]'s password:
sh: /usr/libexec/sftp-server: No such file or directory
Received message too long 2037998963

Since XCSoar/XCSoar#363 with the fix by @roeles got merged into XCSoar mainline, there is no reason to ship XCSoar 7.0-preview12 anymore. Screen rotation should work on most recent XCSoar master.

This basically means that openvario-image and openvario-image-testing becoming identical.

With that in mind, what do you think would be the most sensible way to deal with it:

1. Just drop openvario-image-testing and have one image variant to ship with the latest XCSoar from master
2. Ship latest stable 6.8x with openvario-image and bleeding edge with openvario-image-testing
3. Ship latest stable 6.8x with openvario-image and drop openvario-image-testing, but allow to opkg install latest version of XCSoar for those who wish the latest features.
4. Any other option?

Thoughts? Opinions?

Now that I have a GPS source connected to the test H/W I notice that polar strings are being sent out twice per second. This is how it looks like when I tap the TX line:

<15:28:01> $POV,C,RPO,0.002916,-0.176400,3.422314x51
<15:28:01> $POV,C,IPO,0.003168,-0.176400,3.150000x4C
<15:28:01> $POV,C,RPO,0.002916,-0.176400,3.422314x51
<15:28:01> $POV,C,IPO,0.003168,-0.176400,3.150000x4C
<15:28:02> $POV,C,RPO,0.002916,-0.176400,3.422314x51
<15:28:02> $POV,C,IPO,0.003168,-0.176400,3.150000x4C
<15:28:02> $POV,C,RPO,0.002916,-0.176400,3.422314x51
<15:28:02> $POV,C,IPO,0.003168,-0.176400,3.150000x4C
<15:28:03> $POV,C,RPO,0.002916,-0.176400,3.422314x51
<15:28:03> $POV,C,IPO,0.003168,-0.176400,3.150000x4C
<15:28:03> $POV,C,RPO,0.002916,-0.176400,3.422314x51
<15:28:03> $POV,C,IPO,0.003168,-0.176400,3.150000x4C
<15:28:04> $POV,C,RPO,0.002916,-0.176400,3.422314x51
<15:28:04> $POV,C,IPO,0.003168,-0.176400,3.150000x4C
<15:28:04> $POV,C,RPO,0.002916,-0.176400,3.422314x51
<15:28:04> $POV,C,IPO,0.003168,-0.176400,3.150000x4C
<15:28:05> $POV,C,RPO,0.002916,-0.176400,3.422314x51
<15:28:05> $POV,C,IPO,0.003168,-0.176400,3.150000x4C

The timestamp at the beginning of each line is generated by the terminal tool. (I had to replace the star by a x before the checksum at end of each sentence.)
What you see are polar strings for Real (RPO) and Ideal (IPO) polar.

Now when looking at the code which generates this:
Device/Driver/OpenVario.cpp line 53 and on it becomes obvious why this happens.
The function is called OpenVarioDevice::OnCalculatedUpdate
And it seems as if really does what it says it does: being called OnCalculatedUpdate.
So every time a GPS fix is received the position slightly changes. And every change in position seem to trigger a call to OnCalculatedUpdate .
But obviously the polar doesn't change every time the geo position changes.

I'd like to fix this and that's why I'm writing this message. I see 2 ways to fix it and I'd like to get your thoughts on it:

1. quick and dirty: remember the last polar and send the string only if one of the coefficients has changed
2. register a function which is more appropriate for the purpose

I can do 1 easily. I'd prefer to do 2 but I don't know how.
Any idea?
Any thoughts??

Everybody knows dropbox and it is great for file synchronization across devices. However it has several drawbacks:

• It is a commercial project, and will probably not allow us to redistribute its binaries
• These days they only allow 3 synchronized devices per account on a free plan
• Only allow to sync one folder: ~/Dropbox

There's a better alternative though: syncthing, which is a peer-to-peer file synchronization program.

• It is fully open-source
• No limitation on number of devices
• Has clients for android, linux, windows and macos
• Works without internet (local network is enough)
• It allows to synchronize any number of folders on your system

By a lucky coincidence, XCSoar runs on android phones too. If we share ~/.xcsoar directory between openvario and the phone, this effectively would allow us to implement this workflow:

• While at home, you configure your xcsoar on your phone the way you like it - pick navboxes, screens, settings, etc; download maps, airspaces, waypoints.
• You arrive at the airfield, go to the briefing and enter today's task to your phone
• You turn on your Openvario, tether internet from your phone and all your configuration and current task gets transferred to Openvario (in a matter of seconds).
• You just launch xcsoar and fly today's task
• After you land, your flight log automatically gets synced back to your phone (and/or a folder in a club' computer, if you want), so you can just go home and analyze it, without dealing with usb sticks.

I'm not aware of such a feature for any of commercial flight computers, so we might even get some envy from their proud owners :)

And I think it should not be super difficult to get it on the openvario image. What do you think?

According to @mihu-ov,

USB tethering: connect a smartphone to OV with a USB cable, select USB tethering on the phone, OV has internet connection over the smartphone. At least that´s how it used to work on the old image. Very convenient as no WiFi setup and no entering / storage of passwords is required.
Top

Newer kernel build system relies on rsync utility (to install header files), but it is missing in linuxianer99/ovbuild docker image.

@linuxianer99, please add rsync to the docker image and publish it on docker hub.

using linuxianer99/ovbuild docker container to build image, each time i try to re-run build i got a the same error :
ERROR: ExpansionError during parsing /workdir/poky/meta-openvario/recipes-apps/variod/variod-testing_git.bb

full error Traceback -> build-error.txt

Openvario menu has "system information" view (System -> Information) that has missing data right now. We need to either remove data that is not relevevant anymore or populate the values.

I installed the last self compiled image from yesterday where touchscreen is working. If I choose NMEA Device at menu, I can select device with up and down (rotary encoder at the right hand side), but I can't choose edit, monitor, reconnect etc. (rotary encoder at the left hand side). At other menu options right and left with this encoder works. With the old image everything works fine.

Hello,
first of all, big respect to the development done in the last few weeks. I'am really happy to see new progress for the openvario and can hopefully get in to it soon. Also I like that all of this is now happening on Github. I installed the new image to a 7" stefly OV yesterday and it's working fine, but I get some problems with the vario sound.
We mute the vario and then it wasn't possible to unmute it again, only a restarted solved this issue. But now we aren't able to mute the sound again. Is this happened to anyone before?
I will try to reproduce this with a fresh install tomorrow, but maybe someone has a idea so far.
Also it wasn't possible in the past to get the sounds of xcsoar (like warnings and other stuff), is this now possible with the new sound library? Would be awesome.
So, big thanks to everyone and stay healthy.

Hi guys, Is there a way to turn off the backlight before the cubieboard shuts down?
My image shows a strange fading screen on shutdown. If the backlight was off it would not show.
It is something similar to what happened at satrtup before @kedder fixed the logo sequence.

Thanks!

Image built from current warrior branch seems to be stable enough for public testing. Please publish new images and make a public announcement.

@linuxianer99, do you need any assistance with that?

According to several reports, it is pretty easy to lose the active xcsoar profile by switching off the power supply. Repruducing is pretty simple:

1. Run XCSoar
2. Change something in the settings
3. Exit XCSoar
4. Turn the power off (without using Power Off menu)
5. Turn power back on

After the system boots, XCSoar will start unconfigured, with all-white UI without any map. This happens because ~/.xcsoar/openvario.prf became of 0 bytes length.

I noticed periodic (every 5-10 seconds) blips in my vario sitting on the ground. The blips were on the order of .3-.7 m/s in both directions. The problem seems to depend on which image I am using (20193 vs 20126) but it doesn't depend on sensord is being used as I tried different versions of sensord on both versions. It works correctly on 20126, but not 20193. I've had the SD card with 20126 on it for a while, so its possible that I needed to do something to 20193 that I did on 20126 but forgot to do on 20193. I can try flashing a new copy of 20126 and see what the behavior is.

I do not believe the blips are real, and I never saw the blips on 20126, only 20193 even though wind conditions were similar. There is some movement on 20126 but it is rarely, if ever more than +/- .1m/s.

Anyone got any thoughts on this?

I've built openvario-image-testing and the previous version of the openvario-image.
Now openvario-image-testing builds but the latest version of XCSoar fails to compile.
Error states:

g++: error: unrecognized command line option ‘-fmacro-prefix-map=/home/mariano/ov-image/poky/build/tmp/work/armv7vet2hf-neon-ovlinux-linux-gnueabi/xcsoar/6.8.12-r0=/usr/src/debug/xcsoar/6.8.12-r0’
build/host.mk:23: recipe for target 'output/host/tools/GenerateSineTables.o' failed
| make: *** [output/host/tools/GenerateSineTables.o] Error 1 

Using Debian Stretch 9.12.

Hi guys, I added the Spanish option to the main menu.

Created a linked PR.

I am trying to modify xcsoar to debug issues I'm having with AHRS.

I modified LevilAHRS_G.cpp in:
/poky/build/tmp/work/armv7vet2hf-neon-ovlinux-linux-gnueabi/xcsoar-testing/git-r12/package/usr/src/debug/xcsoar-testing/git-r12/git/src/Device/Driver 4

However, I cannot for the life of me figure out how to rebuild the executable which I assume is in:
/poky/build/tmp/work/armv7vet2hf-neon-ovlinux-linux-gnueabi/xcsoar-testing/git-r12/package/opt/XCSoar

The times I've been successful at rebuilding using bitbake -f -c compile xcsoar-testing or something similar it seems to overwrite the source code directory and so no change is actually made.

Is there a trick to recompiling xcsoar?

This issue is originally reported by @bomilkar on #71, but taken out as a separate one here.

When using XCSoar on a very high zoom levels (500km across the map), XCSoar may perform very poorly: does not react to control inputs, or react with significant delay, refresh frame rate will also drop (to 1 frame per several seconds). In some extreme cases reboot is required to restore the control.

What is known so far about the issue:

• It seems to be triggerred by a very large airspace file. When airspace rendering is disabled in xcsoar, performance regression on high zoom levels is not apparent. Smaller airspace file (covering smaller areas, or having less objects) also produces less impact on performance
• The issue manifests itself only when XCSoar receives NMEA input and constantly has to update the screen.
• CPU usage goes to 100%
• XCSoar will recover from this condition if user manages to zoom the map in or remove NMEA input (e.g. by physically disconnecting the attached devices)

Reproducing

Reproducing the issue is fairly easy:

• Download the sample xcsoar datadir. It contains the big map of central europe and airspace file covering most of central europe as well.
• Run XCSoar and start replay of 2020-05-18_09-30.nmea file
• Zoom out the map to maximum 500km range

General slowdown, CPU usage growth and input lag will be apparent.

Workarounds

The best possible workaround so far is to use smaller airspace file.

Possible solutions

1. Patch XCSoar to limit allowed zoom level to lower values (e.g. 250km). Not ideal, because that would affect users who are not experiencing the issue. OTOH, easy to implement

In 2 of 3 flights with the new image (version 20130 for 7" Texim) I experienced a system freeze which I had never seen with the old image in 300+ hours of flight time. I tried 2 different SD-Cards (with the same image): no difference.

My configuration:
SteFly system with adapterboard, without sensorboard
FLARM on ttyS1, e-vario on ttyS2 ($POV,E,0.58,P,944.33,Q,570.83*1E sentences 2 per second)
sensord and variod disabled with systemctl disable
SteFly stick control, no touch screen

The symptoms:
Acouple of hours into the flight I see that cursor movements (stick control in mouse mode) are getting sluggish (slow reaction). Especially on busy maps, like zoom out to 50km or more.
When moving the mouse on a zoomed-out map the system freezes, meaning no more (visible) map updates, many InfoBoxes still update, but not all. Barometric altitude freezes, for instance.
I leave it alone for ~10 minutes, keeps frozen. Power cycle is the only way to get it going again.
When I end XCSoar after the flight I see a lot of stuff on the screen for a split second before the OpenVario menu takes over the screen again. (I'll change start_xcsoar to capture this "stuff", hoping it reviles something.)
One other thing, which may be unrelated: I find it impossible to "point&click" on the map to get to the details of an airport. That was never a problem with the old image. To some extend it might be related to the "sluggishness" of the cursor movement, but even when it's spot on it doesn't want to pick the airport it is pointing to. I wonder if the "internal pointer on the map" points to the same place as on the screen.
I have the CPU-Load InfoBox open. It seems to update even if the map is frozen. CPU load is reported between 20% and 30% even in freeze. (But the InfoBox may only report user CPU, not system.)

@linuxianer99 , @kedder I think this requires attention. Whoever works/worked on the OS should be alerted. In my humble opinion the system is not usable for the "normal" pilot unless this is fixed.
I have logs from XCSoar both IGC and NMEA which I can make available if that helps. As soon as I have changed ovmenu-ng.sh to capture stderr and stdout from xcsoar I'll supply these, too. Next flight tomorrw :-) :-)

Hi guys. Yesterday I pluged my GPS to TTyS3 and it did not connect at all. It works on TTyS1 and TTyS2. TTyS3 works with Armstrong image.
Do you know if someone else is having the same issue?
Do these ports get enabled with cubieborard2-cubiescreen.fex file?

XCSoar langauge stays English after changing it through Openvario menu (and restarting the system, as suggested). Tested on openvario-image-testing.

Issue is reported on redmine by Dirk Jung: https://www.openvario.org/redmine/boards/3/topics/1829

opkg feed for openvario_7_CH070 variant is missing https://ftp.openvario.org/feed-warrior/. This will result in errors when trying to use opkg on this openvario flavor.

Please upload respective packages to the server.

• Use github actions to trigger a build on pushed tag
• Create automated release notes based on tags/milestones
• Do a matrix build for all screen size and testing/stable images
• Publish all artifacts in github repo

I have tested four different USB to serial converters with image 20067 and found some issues.

1. The first USB2serial that is plugged in an USB hub is shown by lsusb command, a second one is not shown until the first one is removed.
2. Dmesg shows that the devices are enumerated but no device drivers are loaded and no ttyUSBx devices are created (even for the first device listed by lsusb).
3. ls /dev/tty* (and hence the selection list in XCSoar) shows a lot of tty* devices but probably only ttyS0 to ttyS3 (the four serial ports) are real while the rest clutter up the selection lisk. I think we had the same issue in the old image until it was solved.

Hi guys, I've compiled the latest versions of Warrior and tested them in my OV.
Both images compiled.
OV image still has the sound issue in my case.
Don't know what may I be doing wrong. Perhaps it's version of Variod is not updated to pulseaudio?
OV testing sound is working OK with a few quirks I've noticed.
Changing between STF and Vario mode seems rather random. You need to press several times the S or the V key to make it change. The STF mode and Vario mode labels show timely on screen.
It looks like a communication issue between Variod and XCSoar.
I have sensors in my OV so I can help Mihu with the testing. If some kind of logging is helpful you only need to ask. I have a 5.7 texim unit built.

Thanks a lot for all the hard work and kind regards.

I know that real Linux pros use vim but for the average user trying to modify config files nano would be much easier to use. We had it in the old image but it is not included in 20067.

Dan Meyer aka LibelleDriver wrote on forum:

When using the new Beta image, I'm not seeing my USB GPS receiver. Using the old image it was showing up as ttyACM0, but now it's not there. Is there some configuration I have to do in order for the OS to see it?

lsusb gives the following output:

Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 005: ID 1546:01a8 U-Blox AG [u-blox 8]
Bus 001 Device 004: ID 1c4f:0002 SiGma Micro Keyboard TRACER Gamma Ivory
Bus 001 Device 003: ID 148f:5370 Ralink Technology, Corp. RT5370 Wireless Adapter
Bus 001 Device 002: ID 1a40:0101 Terminus Technology Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

It seems CONFIG_USB_ACM is missing in kernel build config.

@kedder : When should we build the next preview release ?
What do you think ??

I will also build an image for CH-070 in this cycle ..

One of the major issues with XCSoar on current warrior branch is inability to rotate the screen to match the device orientation. XCSoar runs under linux framebuffer device and doesn't react to its DisplayOrientation configuration option, always running in landscape mode.

Possible solutions I can see:

1. Switch back to old kernel-3.4 with proprietary mali drivers (known-to-work configuration)
2. Run xcsoar under xorg where it should be (is it?) possible to rotate the screen on Xorg level.

Is there any other option here?

I'm hearing an intermittent warble in my audio. In fact, there appears to be a few different types of warble. I'm running kedder's test release, the problem is not in my "original" version.

https://drive.google.com/file/d/1FsxFNGcUYk_g-gh0v_DCaI--quW0yQlE/view?usp=sharing