All soaring and Condor related posts

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

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.

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:

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:

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!

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.

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

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:

frank@frank-Precision-M6700:~$ socat UDP:localhost:4353 TCP4:192.168.1.161:5555

1	frank@frank-Precision-M6700:~$ socat UDP:localhost:4353 TCP4:192.168.1.161:5555

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 I

1 Reply

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