Monthly Archives: January 2024

Trying my Hand at XCSoar Program Development

Long ago and far away, back when I was doing a lot of real-life soaring, I was heavily involved in the development of the ClearNav flight computer/navigator and I’d like to think I made it better than when I first started working with it. Among other things, I helped develop the thermalling assistant in ClearNav, and also helped port that functionality to XCSoar.

Now, many years late, I am no longer doing real-life soaring, but I’m once again starting to fly in virtual soaring races using the Condor2 soaring simulator. As a part of that, I have been attempting to use the XCSoar flight computer/navigation assistant as an external adjunct to the in-sim Condor flight computer. In particular, Condor2’s flight computer has no capability to support AAT/TAT tasks, so using an external PNA (Personal Navigation Assistant) that does support AAT/TAT tasks makes sense. To facilitate this effort, Condor2 can output GPS NMEA sentences to an external device.

I have nice dual-24″ monitor setup at home, so my initial thought was to run Condor2 on one monitor, and the PC version of XC on the other. This actually works, but with a big ‘gotcha’ – when Condor is running, it captures the mouse and keyboard input, and won’t let it go unless you use ‘ALT-TAB’ to switch to another running program. This means that if you wish make an adjustment in XCSoar, you have to ALT-TAB out of Condor2 and into XCSoar, make whatever adjustments, and then ALT-TAB back to Condor2 – more than a little bit messy. In addition, while ‘away’ from Condor2, it is continuing to fly along without pilot input – maybe OK for a flatland task, but definitely bad for one’s (simulated) health in gnarly terrain.

So, my next idea was to buy a cheap Android device and run XCSoar on it, connected to Condor2 on my PC via Bluetooth. I found a really nice PRITOM M10 10 inch tablet with 2 GB RAM, 32 GB internal storage on Amazon for about $50USD, and figured out how to get NMEA data to it using Bluetooth – nice!

Then I constructed a small AAT/TAT task in Condor2’s default Slovenia scenery, loaded the same task into the M10, and flew it multiple times to see if I could figure out how to best use XCSoar to optimize navigation through both defined areas. This worked really well, but I ran into some problems with the XCSoar software. At least in the Android version, the ‘AAT Time’ and ‘AAT Delta Time’ readouts blanked out several times during the tests, rendering XCSoar pretty much useless for AAT/TAT tasks (see this post for all the gory details).

The above experience led me to think about looking through the source code to see if I could find out why these AAT-related values were going missing. Way back in the day I had done this once before when I ported the ClearNav thermalling assistant algorithm to XCSoar, but that time I didn’t know enough about Github repos and pull requests to do it the right way – I had to throw myself on the mercy of the other developers to make it happen. Since I’m now retired and not flying in real-life anymore, I have a bit more time, so I decided to give it a go.

I started by reading though the XCS Developer Manual, where I found that the primary development platform for XCSoar is Linux, and I haven’t played in Linux-land since my days as IT manager at The Ohio State University ElectroScience Lab a couple of decades ago. Nevertheless, I had an old Dell Precision M6700 15″ ‘desktop replacement’ laptop hanging around doing nothing, so I dug it out and installed Ubuntu 12.4 LTS on it. I chose Ubuntu because it was reportedly easier to use by beginners, and known to install OK on my laptop model. Installation was pretty easy, and using the information in the developer’s manual I was able to clone the Github repo, install the required packages, and actually get the default UNIX version of XCSoar compiled and running on my Ubuntu laptop – yay!

With XCSoar running on my laptop, I decided to try running the same AAT/TAT test task with Condor2 GPS NMEA sentences connected to XCSoar on my Linux laptop using VSPE on my windows box to connect Condor2 to a TCP port, and ‘socat’ on the Linux box to create a bridge between TCP and UDP ports. Then in XCSoar I set ‘Device A’ to point to the UDP port created by socat. Amazingly, this all worked! (See this post for the details). With this setup I ran the test AAT, but the ‘AAT Time’ and ‘AAT Delta Time’ values stayed rock-solid through the entire task – yikes!

This result led me to believe that maybe I could just abandon the Android M10 and just use XCSoar on my Linux box to fly AAT tasks. However, when I actually tried this on a Condor2 race, the Linux box version of XCSoar kept dropping GPS inputs – don’t know why.

So, I decided to see if I could compile XCSoar for Android on the Linux box and ‘side-load’ it onto my M10 Android tablet. If this worked, then I could instrument the code on my Linux box, run it on my M10, and maybe figure out why the AAT Time/AAT Delta Time data was getting corrupted. After all, how hard could it be – I had already cloned the source repo and gotten the UNIX target to compile properly? As it turned out – “Pretty Darned Hard!”

I was stumbling around on the XCSoar developer’s forum, trying to figure out why compiling for Android wasn’t working, when Ronald Niederhagen took pity on me and sent me a direct email with some suggestions. The foremost of those was, ‘Install Debian’ and your life will be easier’. Although I had noticed some references to Debian on some of the development steps, I hadn’t paid much attention to it – after all, all Linux installation are all the same, right? Wrong.

So, I went off into a side project for replacing Ubuntu with Debian on my Dell laptop. Once I got that part accomplished, Ronald sent me the following instructions:

The first ‘make’ command above ran successfully, and I was able to launch XCSoar on my Linux Debian laptop with no problem. However, the second ‘make’ command to compile XCSoar for Android failed miserably – ouch!

When I reported this result to Ronald, his reply was:

Ronald’s first sentence — “You are not far from success” was pretty heart-warming. I have done a LOT of programming over a half-century of engineering, and I was well aware how easily projects of this nature can spiral out of control, so ‘hearing’ such encouragement from such an obviously competent source was a life-saver.

Anyway, I ran the command to install the Java jre, confirmed success with the ‘which command, and then re-ran the ‘install-android-tools.sh’ script. This time it completed OK, so then I ran the ‘make -j4 TARGET=ANDROID command. This time it seemed to complete OK, but no corresponding *apk file was generated.

When I reported this to Ronald, he asked me to re-run the compile, but this time redirect both the normal (i.e. stdout) and the error (i.e. stderr) outputs to files and send them to him. OK, so I resurrected (with the help of Google) my 20-year old memories of how to redirect to files in Linux, got the job done, and sent them off to Ronald. In no time at all, Ronald sent back the following:

I had no idea what ‘javac’ was (other than a suspicion it was java-related). When I ran the ‘which’ command on my box it came up blank, so obviously Ronald was on the right track. After a couple more back-and-forths, Ronald said:

I ran the install, and FINALLY I was able to get the XCSoar Android version installed:

With more help from Google, I was finally able to get XCSoar ‘side-loaded’ to the M10. As it turned out, the trick was to copy the *.apk file to my Google Drive site, and then use ‘Drive’ on the M10 to ‘install’ the app. Basically the process is:

  • Copy the *.apk file from my Linux laptop to my Google Drive site
  • Uninstall XCSoar from the M10 by dragging the icon to the trashcan
  • Use ‘Files->Drive’ to access my Google Drive account from the M10
  • Double-click on the *.apk file in Google Drive
  • Select ‘install’ on the resulting dialog.

Here is a short video showing the process:

Installing a fresh Android version of XCSoar on my Android M10 tablet

So now, Thanks to Ronald Niederhagen, I’m all set for XCSoar development. In the meantime, however, the original reason I wanted to get into XCSoar development (disappearing AAT infobox data) seems to have — disappeared. Not to worry though, as I have lately gotten some other ideas for XCSoar ‘improvements’ 😉

A last thought on this subject from a septuagenarian engineer/programmer, I appreciate how much time and effort Ronald put into helping a noob along. Ronald didn’t know me from Adam, and yet he took the time to help. He didn’t know that I’m a 75-year old broke-down engineer, ex-pilot, (ex – everything, for that matter!), and I don’t know anything about him, either. Heck, Ronald could be a 12-year old kid with acne programming in his parents’ basement wearing pajamas, but in this case he was clearly the teacher and I was clearly the student. It’s pretty cool when the internet and free discourse facilitate this kind of international (and maybe intergenerational) collaboration.

Stay Tuned,

Frank

XCSoar Soaring Computer AAT Task Study, Part III

Posted 29 January 2024

This post is the third installment of my continuing attempt to learn how to use the XCSoar soaring flight computer to successfully navigate AAT/TAT tasks. Although I am using the Condor2 soaring flight simulator for this purpose, the results should be perfectly applicable to real-life AAT/TAT task navigation as well.

The experimental setup for this and previous test flights is an Android M10 tablet connected via Bluetooth to my Win10 PC running Condor2. I created a small task in the default Slovenia scenery as shown below:

And I loaded this same scenery and task into XCSoar, and started flying the task

I am using the latest version of XCSoar, compiled from source code on my Linux box and then ‘side-loaded’ to the M10 Android tablet, as shown below

Latest version of XCSoar

In response to some comments regarding an earlier test run, this time I made sure I had the proper glide polar selected for the plane (ASW-28-15) to be flown in Condor. Here’s the polar plot in Condor:

And here is the tabular information for the ASW28-15 polar in XCSoar

Another issue from the last run was that I had not selected a MC value for the flight, just accepting the default value of 1.0. There was some concern that using this value caused XCSoar to use a very low achieved speed value for task completion calculations. For this run, I selected an initial MC value of 5.0 (although I changed it a couple of times during the task in an attempt to determine the effect of the user-selected MC value on task parameters).

The next photo shows the situation just after starting the task.

Just after start

In my last run I noticed the time display was way off – like 7hrs off. So this time I added both ‘local’ and ‘UTC’ info blocks to the bottom of the cruise info set. As can be seen in the above image, the start took place at 12:03 UTC, and the local time is shown as 8:03(pm?). This is clearly wrong. I believe XCSoar is mis-interpreting the time information imbedded in the NMEA stream (or Condor2 isn’t properly converting the time in the NMEA stream from local to UTC). I looked at a representative NMEA ‘GPGGA’ string from Condor2, and it appears Condor is the culprit; I see ‘$gpgga,120235,…’, where the ‘120235’ value is supposed to be UTC, but is clearly local time – oops!

The AAT Time and AAT dt values look reasonable here, although I am suspicious that the dt value is so close to zero. What speed and distance values are being used to produce this result? If the ‘AAT Dtgt’ value (50.4) is used for the distance, and the ‘AATVtgt’ value (60.5mph) is used for speed, the result is 49.98 min, which is very close to the displayed ‘AATdt’ of 3min 48 sec. I checked this again about 3 min into the flight, and this time AATdtgt = 54.6, AATVtgt = 65.5mph ==> 50.01min ETE ==> AATdt of 5.01 min vs the displayed AAT delta of 4.75min.

After about 5 min, I figured out how to bring the Status page up, as shown below:

Status page, about 5 min after start

There are a lot of different values here, but I don’t understand most of them.

  • Assigned task time and Estimated task time – those are understandable and reasonable
  • Remaining time. I think this is strictly the ‘AAT Time’ value, counting down min by min
  • Task distance: probably the same as AATDtgt – the distance around the target points as currently placed.
  • Remaining distance: No clue
  • Speed estimated: No clue
  • Speed average: Probably just what it says – distance-made-good/time-since-start
  • MacCready: Self explanatory
  • AAT range: Shown as -19% here, so I believe that means both remaining targets are slightly in front of their respective centers.
  • Speed remaining: No clue. Maybe the distance remaining (AATdtgt?) divided by the time remaining? 49.5mi / 65mph ==>45.6min, so this is probably correct
  • Achieved MacCready, Achieved speed, Cruise efficiency: No clue

Shortly after this I launched the ‘Target Show’ utility, and stepped through the targets, as shown in the screenshots below:

Show Targets display for KURJIV area
Show Targets display for JAVORJEV

The values shown in the above pages for KURJIV & JAVROJEV seem reasonable, but I’m not sure where the ‘V rem’ value comes from.

Also, I note that the ‘Delta T’ value isn’t color-coded like it is for the ‘AAT delta time’ InfoBox. I think this is a mistake; if you color-code it in one place, you should color-code it in all places

The next two screenshots show the situation about midway through the KURJIV area

I still don’t understand much of the data shown on the ‘Status’ page, and now I note that the ‘Remaining time’ value on the Status page is not the same as the ‘AAT time’ value on the map display. The difference between these two times is (38-33’23 = 4’37) is close to the sum of the ‘AAT time’ and ‘AAT delta time’ values.

I turned in the KURJIV area shortly after passing the KURJIV center point. When I did, I somehow managed to disable all the InfoBox displays – yikes!

The case of the missing InfoBoxes!

Fortunately I managed to get them back in fairly short order by clicking on the ‘Page Show Info’ box, changing it from ‘Auto’ to ‘Hide’ (I must have inadvertently changed this feature from ‘Auto’ to ‘Hide’ earlier. Here’s a short video clip showing the mis-fingering and the re-fingering:

Note that the original ‘mis-fingering’ was me trying to bring up the ‘Status’ page with an ‘S’ gesture on the screen, and somehow got the ‘Hide the InfoBoxes’ option instead -yikes!

At some point between the KURJIV & JAVORJEV areas, I manually changed the MC value from 5 to 1 to see if that impacted the navigation and ETA calculations. AFAICT, it did absolutely nothing. Later I changed it from 1.0 to 9.2kts, and still couldn’t see any difference in the calculation.

Just as I entered the second (JAVROJEV) area, I changed to the ‘Target’ display in the JAVROJEVA area, as shown below:

Just before entering JAVROJEV area. Note that the ‘optimize’ feature is enabled

With ‘optimization’ enabled, XCSoar has adjusted the target point so as to result in a slightly overtime (4min 56 sec) arrival. Next, I manually moved the target point to the very end of the area. This also automatically disabled the ‘optimization’ feature. Within a second or two, the Delta T value changed from 4min 56sec to 12min 3sec, as expected. Then I moved the target to near the start of the area, and Delta T changed to -4min 23sec, as shown in the next two screenshots.

JAVROJEV target moved to back of area, resulting in a projected 12min 9sec over time arrival
JAVROJEV target moved to front of area, resulting in a projected -4min 23sec undertime arrival

I left the target at the front of the area, to see how XCSoar behaved in non-optimization mode. The next screenshot shows the situation just as the glider crosses through the ellipse connected to the manually placed target.

Glider just crossing early-arrival target ellipse

Note that Delta T is now -5min 5sec instead of -4min 23sec, and Vach is now 76.8mph instead of 76.5mph, consistent with the slightly earlier arrival time.

Next I flew on into the JAVROJEV area, still in non-optimized mode. As the glider went past the target ellipse, the Delta T value kept changing in a way consistent with the increased distance and (slightly) increased speed. It appears as if XCSoar is actually moving the calculation target along with the glider, even though the displayed target point isn’t moving. Sort of a ‘shadow’ optimization mode?

In the next screenshot, the glider is just at the point of turning toward home.

Glider just before turning for home

At this point the manually placed target is toward the front of the area, but now XCSoar is showing a +6min 14sec overtime arrival, which should be enough of a margin to avoid an early arrival due to a faster-than-expected final glide

The next screenshot shows the situation just after clicking on the ‘arm turn’ box.

Just after turning for home in JAVROJEV area. Note target no longer visible

The target marker and ellipse which was at the front of the area has now disappeared, and the ETA/ETD calculations now show a 3m 59sec overtime arrival down from 6min 17sec just a few seconds earlier. There is no way the glider or pilot could have caused this 3min 18sec change, so clearly there is something that isn’t quite consistent in XCSoasr’s before and after turn calculations.

At this point, the flight is essentially over. As the next screenshot shows, the flight ended with a slightly (1min 14sec) overtime arrival, as hoped for.

Flight Summary:

This test flight was much more successful than earlier ones, and I now have a reasonable expectation of being able to navigate/manage an AAT/TAT task in Condor without getting myself completely turned inside out. There are still some issues, though:

  • The ‘Time UTC’ and ‘Time loc.’ readouts are completely screwed up, but it’s not XCSoar’s fault. Condor2’s GPS NMEA sentences insert local times into the UTC field, a really bad NoNo. Since Condor knows where it is in whatever task scenery is being used, it must convert local times to UTC times internally, and put the UTC time into the NMEA stream.
  • It is still not clear to me what speed(s) XCSoar uses for arrival time calculations, I think it is using some form of ‘speed made good’ or ‘average speed to date’.
  • I don’t think the MacCready value (or it’s corresponding projected speed) is used at all. At one point I changed the MacCready value from 5.0 to 1.0, then to 9.2, and then back to 5.0 and didn’t notice any significant change in the arrival time calculations.
  • XCSoar has a few minor GUI issues. The ‘delta time readout on the status page doesn’t utilize the same (or any) color code as the ‘AAT delta time’ readout on the main navigation page.
  • When the pilot flies past the target and target ellipse, the target should start moving with the glider. AFAICT, the calculations do that already – it’s just the graphical element that isn’t tracking.
  • At one point I lost all my info boxes, and had no idea how it had happened or how to get them back again. As it turned out, the culprit was my attempt to bring up the ‘Status’ page with an ‘S’ gesture. Not only did XCSoar not recognize my feeble attempt, but it obviously did recognize it as some sort of ‘hide the infoboxes’ gesture – yikes! This seems to be a classic case of symbol interference – literally.

I have included a link to the full video of this flight below, in case someone else would like to reference it for their own research, or to buttress/rebut a claim or opinion from me.

https://drive.google.com/file/d/1CB6CgySUK0nWtdiMIg3LYffm3i57z7wQ/view?usp=sharing

Connect Condor on PC to XCSoar on Linux

Posted 17 January 2024

I recently re-started flying Condor Soaring Simulator after a long absence, and renewed an old interest in using the open-source XCSoar navigation software for external TAT/AAT planning and navigation. XCSoar runs on PC’s, Android phones/tablets, and Linux and is widely used in RL (real-life) and Condor soaring.

I started out by running XCSoar 7.42 on a cheap Android M10 tablet, connected via Bluetooth to Condor running on my Windows 10 PC. Then I created a small AAT task in the default Slovenia scenery and ran a series of test flights to see how XCSoar did. I documented my results in this post and this one.

As a result of my study, I identified some bugs and other issues on the XCSoar forum, and found out that the XCSoar software is actually written in C++ on Linux, and then cross-compiled for the various supported platforms. I’ve done a fair bit of work in C++ and in Linux, so this got me thinking that maybe I could resurrect my old Linux skills and play around with the XCSoar source code a bit. So I dug out my old moth-balled Dell Precision M6700 laptop, loaded up Ubuntu 24.0 LTS, cloned the XCSoar repo, compiled it on my Linux box, and voila! I was in business!

Well, not quite. In order to use Condor on my Windows PC as the test bed for XCSoar software mods, I had to somehow connect Condor’s NMEA output to the NMEA input to the XCSoar program running on my Linux box. This turned out to be non-trivial and involved a lot of web searching, tearing of hair (what little I have left), and gnashing of teeth, but in the words of my Nebraska cousins “We gotter done!”

This post, then is a way of capturing the surprisingly easy (once you know the magic) process of connecting the NMEA output from Condor running on my Win 10 PC to the NMEA input of XCSoar running on my Linux box.

As it turned out, I had already solved (sort of) the first half of the problem, getting NMEA data from Condor out of my Win 10 PC. When I first (re)started playing with XCSoar, I found some posts describing how to connect Condor NMEA ouput to XCSoar running on the same PC, using a nice utility called ‘Virtual Serial Ports Emulator’ (VSPE), and this actually worked very well – except for one tiny little problem; in order to make any adjustments in XCSoar, I had to ALT-TAB out of Condor over to XCSoar, and that meant ‘flying blind’ (literally) while working with XCSoar – not a good thing. I solved this problem by instead route Condor NMEA output to a Bluetooth virtual serial port connected to an Android M10 tablet.

The procedure for connecting Condor on my Win 10 PC to XCSoar running on a Linux box is:

  • Connect Condor NMEA output to a TCP port on the Win 10 Box
  • Use ‘socat’ on the Linux box to connect the Win 10 TCP port to XCSoar

Connect Condor NMEA output to a TCP port on the Win 10 Box:

This connection is composed of two legs, both using VSPE; the first one defines a virtual serial port to which Condor NMEA output can be directed. The second one creates a connection between the virtual serial port defined in the first step to a Win 10 TCP port. The screenshot below shows both these legs.

Any unused COM port number may be defined here. Once this is done, connect Condor NMEA output to this port by going to Setup->Options in Condor, checking the ‘Output NMEA’ box, and then selecting the port number defined above, as shown below:

Use ‘socat’ on the Linux box to connect the Win 10 TCP port to XCSoar:

When I first started this adventure, I found references to the Linux ‘socat’ command while Googling for things like “Connect Linux Box to Win 10 PC”. Then I started reading about ‘socat’ in particular, and although I could understand that ‘socat’ connected two ‘things’ (where a ‘thing’ could be a serial port, a TCP port a UDP port, a website, etc), it wasn’t easy to figure out how to use it for my application. Finally I ran across this tutorial, which guided me through a series of example socat applications.

After playing with the examples for a while, I realized I should be able to use the ‘STDIO’ socat example to connect the already existing TCP port on my Win 10 box to STDIO in a Linux console terminal and watch NMEA data flow through. So I fired up Condor on my PC and selected ‘Free Flight’. In the ‘NOTAM’ tab, I selected the ‘Airborne’ start option (I believe this is the default), and then selected ‘Start Flight’. Condor outputs NMEA sentences even when the glider is suspended in mid-air, waiting to start flying, so this is a convenient way to test connections. Then on my Linux box I opened a terminal window and typed in the command shown at the top of the following image:

Linux ‘socat’ command to connect Condor NMEA output to terminal window

When I executed the command, I started getting NMEA sentences from Condor – yay!!

Now that I verified that I can connect to a Linux terminal window from Condor running on my Win10 PC, the remaining piece is to change the destination from a terminal window to XCSoar’s GPS data input and then configure XCSoar to accept GPS data from that port. To do this I executed the following ‘socat’ command on a terminal window in Linux:

This establishes a connection between a randomly selected UDP port on the Linux box and a TCP port on my PC. The PC TCP port number is the one selected above connecting COM9 to a TCP port, and the UDP port on my Linux box was just a random unused port number.

Then I launched XCSoar on my Linux box and navigated to Config–>Devices, as shown in the following screenshot. Device A is defined as UDP port 4353, the port number selected above.

XCSoar ‘Devices’ page showing connection to Linux UDP port 4353

This establishes the end-to-end connection between Condor running on my Win10 PC to XCSoar running on my Linux box. With this established, XCSoar shows ‘GPS fix’ as the status for Device A, and the main screen shows the glider’s location in the selected scenery, as shown below:

Stay Tuned,

Frank

XCSoar Soaring Computer AAT Task Study, Part II

Posted 14 January 2024

This is the second installment in my study of the XCSoar cross-country race navigation software with respect to its use in AAT/TAT tasks in Condor2. In my last post, I created a small AAT task in Condor and flew it with XCSoar on a Android M10 tablet, connected to my Condor PC via bluetooth. In this installment, I fly the same task, but this time I video’d the entire task and then afterwards picked out screenshots to highlight points of interest during the task.

Before task start

This next shot illustrates a problem I had right at the start. I used my finger to swipe down (hoping to zoom in or out), but instead it froze the XCSoar app. Had to reboot the M10 tablet and go through some other gyrations to get going again. I sure would hate to have this happen just before task opening on a AAT race in Condor.

XCSoar crashed after the ‘swipe down’ gesture

After getting XCSoar back up and reconnected to Condor, I got going with the task again. Here’s a screenshot showing the situation just before exiting the start cylinder

Just before task start. All the data values look OK

Now just after the start

Just after exiting the start cylinder, with the ‘Task Start’ popup visible

Comments:

  • The ‘AAT Time’ value has decreased by 4 sec, which seems OK
  • ‘AAT delta time’ seems a bit odd, as it shows I’m going to arrive early by about 1 minute
  • The AAT Dmax/Dmin and AAT Vmax/Vmin values look consistent. IOW, to consume 45 min covering the min distance of 24.9mi, I need an average speed of 29.9mph (24.9mi / 29.9mph = 0.833hr –> 50min), and for the max dist of 92.9mi I need 111mph (92.9mi/111mph = 0.833hr — 50min). This gives me fair bit of confidence that I have the necessary data to optimize the task.
Just before entering the first turn circle

Comments:

  • All the numbers still look reasonable here. The ‘AAT Time’ has gone down by about 3.5min, and the arrival is still shown as 1:09min (according the documentation, BLUE indicates arrival will be over by at least 5 minutes).

Now, just after entering the first turn circle,

Just after entering the first turn circle

Comments:

  • It was nice to see the ‘In sector, arm advance when ready’ popup show, but I wasn’t entirely sure what it meant.
  • It was also very nice to see that the ‘target’ started following the glider symbol, meaning that I didn’t have to move it manually – yay!
  • I noted that the ‘AAT Dmin’ value changed from 24.9 to 27.4mi, so that sounds right.

Next, I brought up the Task Status page (after a LOT of fumbling), and got this:

Task Status page

Comments:

  • I was amazed by how little information on this page was useful. The only values that I found believable were the ‘Assigned Task Time’, the ‘Speed Average’, and ‘Achieved speed’ values.
  • The ‘Estimated task’ value of 2:47 and the ‘Remaining time’ value of 2:40 makes no sense. Where did they come from?

At about the halfway point something happened (or I did something stupid – AGAIN) and my ‘AAT time and ‘AAT delta time’ values – the very most critical information required for successfully completing an AAT – disappeared, only to return again when I made the the turn toward JAVORJEV. At the time I didn’t notice until well after the fact, so having the entire flight on video really paid dividends – yay! Here’s a short (~ 35 sec) video showing the point at which they disappeared.

watch as the ‘AAT Time’ and ‘AAT delta time’ values disappear, starting at about 22sec

Comments:

  • The two values that disappeared are the whole reason for using an external navigation device to fly AATs in Condor. After they disappeared, I was basically winging it from then on.
  • It is possible that the data disappearance is related in some way to the buttons I was pressing around the same time. The first screen tap happens at 13.35sec into the video clip and the ‘AAT delta time’ value starts going GAGA about 10sec later.

In the next screenshot I’m about 3/4 of the way through the first turn, and thinking about turning around. Since I lost my ‘AAT Time’ & ‘AAT delta time’ readouts I’m flying blind on timing:

About 3/4 through the first turn area

Comments:

  • The only information I have to work with are the Dmin/max and Vmin/max values, and some notion of my average speed. I think it’s around 80-90mph, and as long as it is less than 111mph I’m OK to turn at this point.

The next shot shows the ‘Show Target’ page for this turnpoint

‘Target Show’ page for this turnpoint

Comments:

  • This page shows a value for ‘V ach’ of 70.8mph, which is almost identical to the value shown for ‘AAT Vmin. Assuming I believe this number, and assuming that value will continue to increase because I’ll be ridge running the rest of the task, I should be OK turning here.
  • I have no idea what the ‘ETE’ and ‘Delta T’ values mean on this page – they don’t look consistent with the ‘AAT Vmin/max’ and ‘AAT Dmin/max numbers on the main navigation page. I don’t think there’s any way I can make it back 26 minutes and 39 seconds early, even if my glider suddenly acquire orbital velocity.

The next shot shows the same page, but for the JAVORJEV turn circle, just as I’m getting ready to turn in the KURJIV circle

Comments:

  • Apparently, moving the target position in the KURJIV circle also moves the corresponding one in the JAVORJEV circle – I didn’t expect that. I wonder what happens in a 3, 4, or 5 turn circle AAT – do ALL the targets move in unison?
  • What does the ‘Optimized’ checkbox do?

The next shot shows the situation just as I made the turn for JAVORJEV. Again I didn’t notice this at the time, but my ‘AAT Time’ and ‘AAT delta time’ datablocks returned from the dead. Here’s a short (20sec) video showing the action. Just from the video, it looks like tapping on the ‘Arm turn’ button also resurrected the AAT info boxes.

However, my joy over getting my AAT datablocks back was short-lived. A short time after making the turn, the datablock info disappeared again – for good. This time there were no button pushes to blame. The following short video shows the action

AAT datablock info disappears for the second- and final – time

The next shot shows me just before exiting the first circle on the way to JAVORJEV

Comments:

  • The AAT datablocks are still missing
  • The Target in the JAVORJEV circle is now toward the near side of the circle, so is there some optimization going on in the background?

The next shows my attempt to manually move the JAVORJEV target.

Comments:

  • The ETE & Delta T values look reasonable, and the implication is that I should be able to use up all the time by moving all the way to the back of the JAVORJEV circle
  • However, when I manually move the target to the front of the circle, there is almost NO change in the ETE/Dt values, and the small change that shows is in the wrong direction. Moving the target forward like this should make me way earlier, but the numbers show that I’ll be almost 1 minute LATER than I was before. how can this be?

As shown in the next video, I decided to try the ‘Optimized button to see what it did. This radically changed the target location, and the ETE/Dt values. After a few iterations, it looked like the Optimize function was indeed working properly.

Comments:

  • It takes a while for the optimization to converge. At first, the values for ETE & Dt are WAY off, and then they oscillate back and forth several times before stabilizing on believable numbers.

The last video covers the finish (or NOT-finish, in this case)

Comments:

  • At the start of this clip, XCSoar is in ‘Final Glide’ mode, but switches back to ‘Cruise’ just before entering the finish circle.
  • I was expecting a ‘Task Finished’ notification when I crossed into the circle, but didn’t get one. In fact, AFACT, XCSoar never finished this task at all. I’m sure this was an operator error on my part, but I don’t know what I screwed up – bummer!

XCSoar Soaring Computer AAT Task Study, Part I

Posted 14 January 2024

Among the many ‘EXs’ I claim, one of them is ‘EX-glider racing pilot’, and another is ‘EX author of “Cross-Country Soaring with Condor”, a fairly popular book in the soaring community that explains how to use the Condor Soaring Simulator to learn real-life (RL) cross-country (XC) soaring. Now that I don’t fly RL contests any more, I have decided to start flying XC races again in Condor.

Many Condor racing pilots also fly gliders in RL, and use Condor to help them with XC strategies and tactics, and how to best take advantage of the many XC navigation and racing support computer programs available, and Condor supports this by making GPS location data available to users. One of the most popular programs for this purpose is XCSoar (https://xcsoar.org/). In RL XC racing, one of the most popular task types is the Assigned Area Task (AAT) or Turn Area Task (TAT), where the pilot is free to decide where to turn to the next leg of the task, as long as he is within the bounds of an assigned area. Unfortunately, the Condor soaring simulator’s internal navigation computer doesn’t support this type of task, so the pilot must either just guess where to turn, or use some type of external navigation support.

This post is intended to describe my efforts to use XCSoar for Condor racing, and in particular how to use it for AAT/TAT optimization. To do this, I set up a small AAT task in the default Slovenia scenery, as shown in the screenshots below:

Here’s a screenshot of the task in XCSoar:

And the same task in Condor2

After starting the flight, I would pause Condor2 at progressive points along the task and take a photo of the XCSoar app running on an Android tablet, with the idea that after the task was over, I could go back and make some sense of what XCSoar was telling me throughout the flight (Note that due to the loss of GPS data when Condor2 is paused, the green track line jumps way off screen each time, so you have to ignore the impossibly straight part of the ‘breadcrumb trail’).

The following shot was taken just before exiting the start circle at KAMEN

For some reason, XCSoar thinks that almost 3 minutes have elapsed since I started the task, even though I’m still inside the start cylinder and I haven’t gotten any start notifications

OK, it may be that XCSoar started me when I crossed the circle diameter perpendicular to the task line.  I note that even though the task diagram shows a cylinder with radius of 2mi, is it possible that XCSoar is still triggering on the default start point type (Start Line, 1.8mi wide)?

The next shot (above) shows the situation just after exiting the start cylinder.  Although not shown, I did get a ‘Start’ notification at this point.  Note that the ‘AAT Time’ readout jumped backwards from 42:04 in the previous photo to 44:56 in this one.  The 44:56 number should be the correct one, as I have just exited from the start cylinder.

Note that the ‘AAT delta time’ value doesn’t make any sense to me.  It’s supposed to show ‘Difference between the estimated task time and the AAT minimum time, and if it is colored blue it is supposed to mean that I could turn right there and be assured that I would arrive home so as to be more than 5 minutes over time.  But that can’t possibly be true, as I haven’t even gotten into the first turn area yet – WTF?

The above shot shows the situation just after turning around in the first turn area.  I really wasn’t getting any good information from the data fields I had displayed – just nothing made any sense, so I guessed the turn point based on the AAT time value, which I took to be the AAT time remaining starting from 45:00 minutes and a wild-assed guess about my achieved speed (I guessed I was doing about 1.5 miles/min).  With this guess, and thinking that the remaining distance was between 41.5 and 64.2 miles (assuming I interpreted these values correctly).  The ‘AAT delta time’ readout still seems to be nonsense – or maybe it is really true at this point?

The above photo shows the situation after exiting the first turn area and proceeding towards the JAVORJEV turn area.  The ‘AAT Time’ value seems like it is behaving rationally, but look at the ‘AAT dT’ value  – if true, it should mean I’m going to arrive over 45 minutes LATE, which makes no sense at all.  The ‘AAT Dmax’ value is sort of meaningful, and I take it to mean that I have at most 64.2 miles remaining and 27:19 minutes to cover the distance, or right around 120mph.  If I believe the ‘AAT Dmin’ number, then that works out to about 90mph if I just touch the last area.  The ‘AATDtgt’ now makes sense as well, as the ‘target’ is right on the near edge of the last area, making the ‘Dmin’ and ‘Dtgt’ equal.

The above photo shows the situation about 4 minutes later, just before entering the JAVOR circle. The value of the last three datablocks haven’t changed, which makes sense, but now the ‘AAT dT’ value has changed dramatically again, this time to something a little more reasonable.  Now *I think* it is showing me arriving 4:32 early, but that would mean it should be colored RED, and it clearly isn’t – WTF again!

At this point I thought to look at the task Status page, and discovered that this page seemed to think I was going to arrive 4 minutes over time, not under, so now I’m really lost.  The help in XCSoar says that the ‘AAT delta time’ data block value will be colored BLUE if the expected arrival time for a turn at the present point will be at least 5 minutes OVER time, and RED if it is going to be UNDER time.  However, the actual color of this datablock value is BLACK, and based on the data on the Status page, it looks like BLUE means UNDER time and BLACK means over time.

Also, I saw on this page that my earlier estimate of around 90mph was pretty close to the mark. Armed with this information, and the knowledge that the rest of the task was going to be even faster, I might want to go further into the area than just the minimum.

The above shot is from (I think) the ‘Show Target’ page for the JAVORJEV turn area, after I moved the target from the near edge to well past the center of the area.  I expected this page to tell me what the effect of moving the target would have on the total task time, but AFAICT, the only real values are the 49% distance offset value and the Vach value of 93.1mph  – the ETE of 2h 52min and the Vrem of 16.4mph are clearly garbage.

The above shot shows the situation about a quarter of the way into the JAVORJEV circle.  The ‘AAT time’ value continues to be believable, but now the ‘AAT dT’ value shows me arriving (early?/late?).  After seeing the data from the Status page, I was inclined at this point to think that the BLUE coloring meant ‘early’.  The AAT Dmax value is unchanged as it should be, but now the AAT Dmin and AAT Dtgt values have both increased.  I *think* the AAT Dmin value now shows the total task distance assuming I turn immediately, and the AAT Dtgt value shows it for continuing to the target and then turning. The AAT Time value shows I have about 21 minutes remaining, so I would have to fly well above VNE to arrive just on time If I go to the target, and something like 150 if I were to turn immediately.

The above figure shows the ‘Status’ page on the way back from JAVORJEV to LESCE-BLED.  It has the ‘Assigned task time’ correct, but the ‘Estimated Task Time’ and ‘Remaining time’ are clearly not real.  The Task distance and remaining distance values look OK though.

The above shot shows the situation as I’m coming out of the JAVORJEV area heading home.  The ‘AAT Time’ looks correct, but the ‘AAT dT’ value looks crazy again.  Could it be that the value is actually correct, but now showing arrival 49.11 seconds early? Man, that’s a pretty subtle thing to have to figure out while flying close to the ground at Vne!  If this is correct, then the number should really be formatted as ‘0:49.11’ instead

The above shot shows the situation just after exiting the JAVROJEV area, and now the datablocks have changed to final glide.  Now it looks like I’m going to arrive about 4 minutes early (I’m assuming this is based on my current Vgnd of 115Kt) – bummer!

The last shot before entering the finish circle.  Not quite sure how, but I managed to lose some time on the way back, arriving at 44:03 – a little less than 1 minute early.  I deliberately left the display scale alone during the approach to the finish cylinder, as I wanted to see if the ‘AutoZoom’ feature would work.  It didn’t, but I’m not sure who’s to blame – me or XCSoar.  More investigation needs to be done.

Conclusions:

  • I set up my datablocks for cruise, climb, and FG based mostly on a video I found of a pilot flying an AAT task – I really didn’t have any idea what all the values would really show me.  In retrospect, I’m going to have to spend some more time going through the available datablocks and see if another mix makes more sense.
  • There were some seriously erroneous numbers showing up in some of the datablocks, especially the ‘AAT dTime’ one.  It occurs to me that this might have been due to the way I was pausing the flight and then taking a photo of the XCSoar screen. It might be that the values got screwed up when the GPS signal went away.  I’ll have to redo this flight without pauses (maybe video the entire flight and then just grab frames, or maybe set up my phone on a tripod so I can just press one button?)
  • The XCSoar documentation doesn’t match reality in some places, especially with respect to the ‘AAT dTime’ datablock colors.  The documentation says RED for early, BLUE for late, nothing about BLACK. 

If nothing else, this flight and the subsequent analysis gave me a lot better understanding of XCSoar’s capabilities with respect to AAT task support.  I’m a long way from being comfortable with trusting it to feed me good information in real time, but I’m a lot closer than I was before 😊

Stay tuned,

Frank