Limitation of the NMEA data stream generated by Condor Soaring Simulator, for use with XCSoar

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Limitation of the NMEA data stream generated by Condor Soaring Simulator, for use with XCSoar

DPLuigi
This post was updated on .
In order to better understand the limitation of NMEA data provided to XCSoar by Condor,  I used a HyperTerminal session on a Windows XP PC.  The settings used for HyperTerminal were bits per second =4800, Data bits=8, Parity=none, Stop bits=1, Flow control hardware).

A user flight plan for flight was chosen with a taking off at Hockenheim, Germany, in the Hahweide SouthWest Germany 1.08 scenery, (see Sky-Race 2008/2009 Day #12, sky-race.com for further details).

From Condor flight menu:
location: 49.19.008N   008.31.002E, 95m (MSL).
Date June 21, 2009
Time: 12h15min (local time?).

In Condor Simulation as displayed in external view (which was enabled):
Altitude: 96m
Heading: 140 deg
49.19.096N   008.30.906E
Time: 12H15min

In XCSoar:
GPS altitude: 48m
Local Time: 12.15
Sunset time:  15.28
with UTC offset=0 and GPS Time=ON.


Here is the very first frame received by HyperTerminal, with a set a three sentences:
$GPGGA,121500.003,4919.0952,N,00830.9040,E,1,12,10,95.7,M,,,,,0000*3D

$GPRMC,121500.003,A,4919.0952,N,00830.9040,E,0.00,140.00,,,,*23

$LXWP0,Y,0.0,95.7,0.00,,,,,,140,247,22.5*40

In order to decode the information from this first frame of GPS NMEA data sent by Condor, I used the the information found on this page and related link:
http://www.gpsinformation.org/dale/nmea.htm

Note that I did not find the details for the LXWP0 a WP0 sentence which might be proprietary (i.e. what is this LX device, Colibri?).  If anyone can forward me a link to understand the data description for this WP0 sentence, thank you in advance.

It is clear that two variables used by XCSoar are missing.  The Height of geoid (MSL) above WGS84 ellipsoid and the date are missing (i.e. empty fields in RGGA and RMC sentences).

It seems that could explain the GPS Height and Sunset discrepancies reported on the forum.

However, as John Wharington pointed out, these are limitations of Condor are typical of XCSoar intended uses for real-life pilots.

On Feb 21, 2009; 08:04pm, John Wharington-2 wrote:
John Wharington-2 wrote
Remember that XCSoar is primarily driven by the needs of real-life pilots rather than Condor, and the constraints/drivers from Condor may not be appropriate for XCSoar's primary function.

Condor itself is "guilty" of not having everything neatly organized; for example the ballast setting is not saved in the .fpl file.
I thought that besides researching how to improve the synergy between Condor and XCSoar, the Condor flight simulator users might want to know about these limitations and their implications, at least to be aware of the GPS height error.  I hope this useful to others since this was very confusing to me.

For further details please read below.

Thank you,
Donat

Decode of selected position sentences
The most important NMEA sentences include the GGA which provides the current Fix data, the RMC which provides the minimum gps sentences information, and the GSA which provides the Satellite status data.
GGA - essential fix data which provide 3D location and accuracy data.
 $GPGGA,123519,4807.038,N,01131.000,E,1,08,0.9,545.4,M,46.9,M,,*47

Where:
     GGA          Global Positioning System Fix Data
     123519       Fix taken at 12:35:19 UTC
     4807.038,N   Latitude 48 deg 07.038' N
     01131.000,E  Longitude 11 deg 31.000' E
     1            Fix quality: 0 = invalid
                               1 = GPS fix (SPS)
                               2 = DGPS fix
                               3 = PPS fix
                               4 = Real Time Kinematic
                               5 = Float RTK
                               6 = estimated (dead reckoning) (2.3 feature)
                               7 = Manual input mode
                               8 = Simulation mode
     08           Number of satellites being tracked
     0.9          Horizontal dilution of position
     545.4,M      Altitude, Meters, above mean sea level
     46.9,M       Height of geoid (mean sea level) above WGS84
                      ellipsoid
     (empty field) time in seconds since last DGPS update
     (empty field) DGPS station ID number
     *47          the checksum data, always begins with *
If the height of geoid is missing then the altitude should be suspect. Some non-standard implementations report altitude with respect to the ellipsoid rather than geoid altitude. Some units do not report negative altitudes at all. This is the only sentence that reports altitude.

It follows the first sentences from CONDOR NMEA frame corresponds to:
$GPGGA,121500.003,4919.0952,N,00830.9040,E,1,12,10,95.7,M,,,,,0000*3D
GPS fix data
12h15min00.003s
49 deg 19.0952' N
08 deg 30.9040' E
Fix quality is 1= GPS fix (SPS)
12 satellites being tracked
Horizontal dilution of position is 10
Altitude (MSL) is 95.7m
Height of geoid (MSL) above WGS84 ellipsoid is missing/empty field
time in seconds since last DGPS update (empty field)
DGPS station ID number (empty field) OR 0000
Checksum data is *3D


RMC - NMEA has its own version of essential gps pvt (position, velocity, time) data. It is called RMC, The Recommended Minimum, which will look similar to:
$GPRMC,123519,A,4807.038,N,01131.000,E,022.4,084.4,230394,003.1,W*6A

Where:
     RMC          Recommended Minimum sentence C
     123519       Fix taken at 12:35:19 UTC
     A            Status A=active or V=Void.
     4807.038,N   Latitude 48 deg 07.038' N
     01131.000,E  Longitude 11 deg 31.000' E
     022.4        Speed over the ground in knots
     084.4        Track angle in degrees True
     230394       Date - 23rd of March 1994
     003.1,W      Magnetic Variation
     *6A          The checksum data, always begins with *
Note that, as of the 2.3 release of NMEA, there is a new field in the RMC sentence at the end just prior to the checksum. For more information on this field see here.
It follows that the interpretation of the RMC Recommended Minimum sentence for the first NMEA frame emitted by Condor's GPS is:
$GPRMC,121500.003,A,4919.0952,N,00830.9040,E,0.00,140.00,,,,*23

Fix taken at 12h 15min 000.003s
Status A=active
Latitude: 49 deg 19.0952' N
Longitude: 08 deg 30.9040' E
Speed over ground (in knot): 0,00,
True Track angle: 140 deg.
Date: missing/empty field
Magnetic variation: missing/empty(fields)
Checksum data: *23


No information found yet to understand WP0 sentence from LX device.
$LXWP0,Y,0.0,95.7,0.00,,,,,,140,247,22.5*40
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Limitation of the NMEA data stream generated by Condor Flight simulator, for use with XCSoar

hplx
DPLuigi wrote
No information found yet to understand WP0 sentence from LX device.
$LXWP0,Y,0.0,95.7,0.00,,,,,,140,247,22.5*40
$LXWP0 is output for WinPilot. More information may be on winpilot.com?

hplx
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Limitation of the NMEA data stream generated by Condor Flight simulator, for use with XCSoar

hplx
DPLuigi wrote
No information found yet to understand WP0 sentence from LX device.
$LXWP0,Y,0.0,95.7,0.00,,,,,,140,247,22.5*40
$LXWP0,Y,222.3,1665.5,1.71,,,,,,239,174,10.1
0 loger_stored (Y/N)
1 IAS (kph)
2 baroaltitude (m)
3 vario (m/s)
4-8 unknown
9 heading of plane
10 windcourse (deg)
11 windspeed (kph)
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Limitation of the NMEA data stream generated by Condor Flight simulator, for use with XCSoar

DPLuigi
This post was updated on .
Thanks a lot for the info,

I did come across a mention of LX/Filser device with LXWP_ output and history of changes from SoarPilot but no definition of the sentence LXWP0 itself anywere on their site or any related manufacturers sites or available LX instrument manuals I checked.  I just did another search to find the definition of the remaining 4-5 fields missing in the sentence.  NO luck but I found out a comment on a post that the LX/Filser proprietary sentence is hard to obtain from the manufacturer, and programmers could (try to) contact him directly and probably need a non-disclosure agreement (NDA).

Here is from Soarinpilot:
http://www.soaringpilot.org/dokuwiki/doku.php/soarpilot/lx_colibri_filser_connection

From Condor Product description:
http://www.condorsoaring.com/about.htm
Also
Real-time NMEA output
    * Real-time NMEA output trough serial port.
    * GPGGA, GPRMC and LXWP0 sentences are supported (the set can be expanded if needed).

NMEA is a standard communication protocol for transferring navigational data (position, speed, heading, bearing, etc.).
Today, every GPS hardware features NMEA output to communicate with handheld devices or laptops trough serial port. Condor uses this protocol to enable you to use your own handheld devices and software for navigation.
And from the Condor changes saves in the readme.txt:
Changes in v1.0.9 (August 29, 2006): LXWP0 NMEA sentence now correctly uses heading instead of track.

Changes in v1.0.5 (October 18, 2005): Added LXWP0 sentence. At the moment only 1 update per second instead of possible 6 per second. If it will show that this is unacceptable the update time will be increased.

Changes in v1.0.3 (June 30, 2005):  Added LXWP0 sentence to NMEA output.

Thanks to HPLX for the sentence description and thanks also to John Wharrington for forwarding me a post I missed:
http://www.nabble.com/LXWP0-Sentences-tt9384120.html#a9384120

hplx wrote
$LXWP0,Y,222.3,1665.5,1.71,,,,,,239,174,10.1
0 loger_stored (Y/N)
1 IAS (kph)
2 baroaltitude (m)
3 vario (m/s)
4-8 unknown
9 heading of plane
10 windcourse (deg)
11 windspeed (kph)
12 Data Checksum starting *
So from the example extracted from the very first frame
$LXWP0,Y,0.0,95.7,0.00,,,,,,140,247,22.5*40
logger_stored Y
IAS=0.0km/h  (glider was on the ground, ready for take-off.  We might check speed unit just to make sure it is Km/h and not m/s)
barometric altitude=95.7~96m  (great it is consistent with Condor now)
Vario=0.00 m/s (on the ground, no moving)
5 empty fields
Glider heading=140 deg
Wind direction = 247 deg (- to 247deg)
Wind Speed = 22.5km/h
Data check sum=*40
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Limitation of the NMEA data stream generated by Condor Flight simulator, for use with XCSoar

DPLuigi
This post was updated on .
Update:

A bug report (#126) has been submitted to address issues related with the handling by XCSoar of Condor NMEA's stream when it is missing height of geoid and date.

Following John Wharington's suggestion, I thought I'd try out the LX device in the XCSoar menu 8/Devices - it works.  
John Wharington-2 wrote
There is already an LX device which works fine with Condor --- and it
does use all of the parameters, except for wind, which XCSoar itself
calculates.  Why the logic of not using the LX wind from Condor?
Because 1) this is cheating and 2) it is a great way to ensure that
XCSoar's wind estimate is good.  In other words, it makes the
combination of Condor + XCSoar closer to what you would get in real
life.
 

I just tested the LX device implemented in XCSoar since 5.1.5 beta 6 with Condor:
http://www.nabble.com/New-XCSoar-stable-release-5.1.6-tt15477926.html#a15477926 

It did provide the H baro (MSL) altitude now l. I am assuming that XCSoar 5.1.9b6 makes use of the vario data and glider speed also (i.e. aircraft dynamics gathered from Condor's LXWP0 sentence), as if the LX data from Condor came from an intelligent vario. Just to make sure I selected Nav by baro altitude=ON in Menu 5/Glide Computer.

Anyhow, a fix will be implemented in a few weeks to address at least the GPS Height erroneous display when using XCSoar with Condor.  Regarding the Sunset, it is not as important and there is some question whether or not Condor uses a proper Sun ephemeris model and might be disabled when XCS is used for Condor.  See below.

John Wharington-2 wrote
Actually regarding Sunset, I am not sure if Condor has a proper sun
ephemeris model, so it may be pointless to even set a date to use for
sunset calculations in XCSoar --- may just be better to disable this
sunset display and warning if it is using the "Condor" device.
Here are two threads from Condor forum about the accuracy of the Sunset time/day light:
http://forum.condorsoaring.com/viewtopic.php?t=5760&highlight=sunset
http://forum.condorsoaring.com/viewtopic.php?t=5752

I will check on this and report in the related thread already started:
http://www.nabble.com/Need-clarification-about-Sunset-time-calculated-with-Sun-Ephemeris-by-XCSoar%2C-when-used-for-Condor-online-flight-simulation.-tt22172716.html#a22172716

Here is the tentative approach that is being considered to improve how XCSoar deals with Condor specific issues.  This would be implemented and beta tested in few weeks since it is not a high priority and all the effort it to get 5.2.2 squared away first.
John Wharington-2 wrote
What I propose doing is copying the "LX" device to create a new device
called "Condor", which when used would allow XCSoar to apply the fixes
to the sunset and altitude offset.
I hope this is helpful for those interested in using XCSoar with Condor Soaring simulator.

Thank you,
Donat
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Limitation of the NMEA data stream generated by Condor Flight simulator, for use with XCSoar

Zadmalck
This post was updated on .
In reply to this post by hplx
Hi all.

thank you very much to everyone for all the useful information to NMEA.

I use this for created a program for Condor, here (french) :
 http://www.condorsim.fr/communaute/topic15737.html

there is something I do not understand :

$LXWP0,Y,222.3,1665.5,1.71,,,,,,239,174,10.1
0 loger_stored (Y/N)
1 IAS (kph)
2 baroaltitude (m)
3 vario (m/s)
4-8 unknown
9 heading of plane
10 windcourse (deg)
11 windspeed (kph)
12 Data Checksum starting *

For field number 10, windcourse, I must subtract the value by 180 if it exceeds 180. I must add 180 to the value if it is less than 180.

to understand because my English is very low:

   if (StringPart (nmea, '', 0) = '$LXWP0') then
      begin
        temp: = StringPart (nmea, ',', 11); // Windcourse raw value (Number 10 + 1)
        Val (temp, value, errorCode); // convert string to number
        if (value> = 180) then
          windcourse: = value - 180
        else
          windcourse: value = + 180;
      end;

Do you know why I have to do that to get the true value of the wind direction at time t?

Thanks for your help.

Best regards.
Loading...