[Joerg Ewald]

Hi Emre

sorry for the late response, I didn’t see your post just until now. The main requirement for an instrument to be accepted are:

1. It must be able to produce a signed (with G record) IGC file
2. It must use a standard plug for track download, like Mini-USB or something like that
3. The device should support the USB filesystem schema, so that the files can be downloaded directly, without having to install any drivers on the score-keeper’s computer.
4. It would be nice if the device allowed getting the device’s serial number the same way. A read-only file somewhere in the file system would be great.
5. The manufacturer supplies the software to validate the G-Record.
6. The device must store GPS altitude values in the IGC file. If possible, it should also store barometric altitude data.

I think that’s pretty much it

Cheers
Joerg

[Joerg Ewald]

I’d like to resurrect this thread, since it has become an issue again in some competitions. Let’s figure out what’s going on, and how to design a good solution.

Rafa Lopez sent me the track of the “flight” he mentions above. Here is what I found:

The pilot landed at 20:41:46 (all times UTC)
Less than a minute later, at 20:42:42, he started running towards the ESS cylinder, which was at that time 270m away.
He reached the cylinder at 20:45:01, turned around, walked a couple more steps until 20:45:26, then turned off the GPS.

So in total he ran 270m in 2:19, giving him an average speed of 1.94 m/s or 6.99 km/h.
Between landing and entering ESS, he spent 3:15 on the ground, covered 270m, giving him an average speed of 1.23 m/s or 4.42 km/h

So far the facts. Now why did FS not detect that? Simply because the offending pilot was “too fast”:

FS uses a sliding 4-minutes-window across the track, and calculates the average speed for each window. Once this speed drops below 1 m/s (3.6 km/h), the assumption is that the pilot has landed and the remainder of the track is no longer considered.

During the last 4 minutes of the track we’re looking at here, the average speed was 1.90 m/s (6.84 km/h). So no landing is detected, the entire track is used for scoring.

From the comments in the code I can see that originally, the intention was to make the threshold at 1.5 m/s or 5.4 km/h. For some reason this was later changed to 1 m/s (3.6 km/h) – probably because some slow-flying paragliders were wrongly considered landed.

We could fine-tune this by increasing the threshold, and decreasing the window-size, to say 3 minutes and 1.25 m/s, but there is always a risk of false positives, slow-flying pilots who are considered landed.

Does anybody have an idea how else to do the landing-detection? Include altitude in the mix? Again the danger is that a soaring pilot, pinned to a cliff, may be wrongly considered as landed.

On a slightly bigger scale, I feel that the score keeper must be given the option to overrule a detected landing and tell FS to use the rest of the track as well. That will require some bigger changes, but should make the whole process easier.

Rafa’s scenario can be avoided by not giving 80% of time and arrival points to pilots who make ESS but not goal. In FAI Category 1 Paragliding comps, as well as the PWC, you always must reach goal to get any time (and arrival) points. Somebody running 270m to cross the goal line would certainly be more obvious than doing the same for a 2km ESS.

Looking forward to your input
Joerg

[Joerg Ewald]

The way “walking pilot” detection works currently in FS: If the average speed over the last five track points drops below 3.6 km/h, it is assumed that the pilot has stopped flying, and track evaluation ends there. All of you who have seen problems with walking pilots not being detected, could you please send me the track log and if possible also the corresponding FSDB file?

thanks
Joerg
Chairman of CIVL’s Software Working Group

[Joerg Ewald]

Hello aletomei

Thanks for the feedback. I’m not sure there is an easy solution to this. I know some people managed to run FS under Linux using Mono.

In general, FS in its current state is only intended to run under Windows. This is also the only environment we’ll be able to test new version with, at least for now. For the future, we have plans to create a version that can run on Linux or Mac OS X machines, but we have some other features we’d like to implement first.

Maybe running Windows in a virtual machine under Linux would be an option for you?

Joerg

[Joerg Ewald]

Here the results he’s referring to:

Attachments:

You must be logged in to view attached files.

[Author]

Posts