lidar532

Hi Peter, I just found the following documentation regarding the fs2004 timing in the netpipes document: Perhaps it will help. Best regards, Wayne

Hi Pete, Thanks for making the change! I'll give it a try and see how much difference it makes. That sounds excellent. With the original version I could see that the actual delta-time was not a specific interval and did not agree with the delta-distance because my computed cross-track velocity jumped around quite a bit which means either the time and/or distance was inaccurate. I'm hoping that the added precision in lat/lon and the added time estimates will reduce the cross track velocity and ground speed jitter. If it does, then the simulator will be a valuable tool for refining the nav software. I will let you know and I'll include some screen shots. Thanks so much for making the changes. Best regards, Wayne

Hi Peter, Would it be possible to set the number of digitis to the right of the decimal in the INI file for GPSout? Then it couldn't foul up any thing that relied on exactly 4 dights. The data I sent in the original post was captured from an actual "survey grade" GPS receiver. I've seen the number if digits vary from 4 to 5 and 6 depending on the quality of the given GPS receiver. I've never had any problem feeding our high precision GPGGA data to lots of different programs. In real life, I'm using the system on an aircraft, a Cessna 310 twin, which is being operated at ~55 meters/second or roughly 110 mph. At 55 meters/second the plane only moves 5.5 meters between 10Hz GPS samples or 18.04 feet forward. The actual GPS receiver we use easliy gives us a stable noise free "ground track" with a precision on the order of 0.05 degrees in the computed graound track. The digits define the precision, or granularity, of the lat/lon data. The smaller the steps, the higher the precision and the smoother things operate. INternally fs2004 much be pretty precise because one doesn't get the feeling that it's moving in steps of several feet at a time. Hopefully letting the user specify the precision would do the trick. That's too bad... Maybe just setting the time field of the NMEA time from the computer system clock would be jitter-free enough. My software doesn't like NMEA GGA records that have exactly the same time value in them. It drives the computations that depend on delta-time crazy. On Linux one can call "fime" and get mililsecond time and I'm certain windoze has virtually the same call. There are many functions to format the time as well and I know they exist in the MS win world as well. Hopefullly when Fs2004 called GPSout, GPSout could then grab the time from the system and patch it into the output record. It would certainly have plenty of jitter, bu thats' not a problem at all because the "delta-time" from the last measurement would probably be more reasonable. It would certainly be a different time for each record. I've seen some recent low end GPS receivers that actually don't try to deliver NMEA records exactly on the second. The Holux units are good examples. The measurement time drifts all over the place, but the delta-time is good enough. GPSout is really a nice program and thanks for providing it. I was about to try to use the "netpipe" stuff to grab the data and generate the NMEA string, but your program is much nicer than what I would have written. Best regards, Wayne It wouldn't be the precision of the Lat Long but the lack of any precision in the timing. Expecting your data to be precisely every 100 mSecs apart when it can take longer to do a process switch or suffer a delay through thread timings is possibly a little bit optimistic I'm afraid. Regards, Pete

Hi Peter, Would it be possible to adjust the precision of the lat/lon values output from "GPSout" from the current 4-digit fraction to 6-digits, and also fix the time-of-day to show fractional seconds of the day? As it is now, the fractional part of the seconds is always ".00". I've setup GPSout to operate at a 10Hz rate to match our actual gps receiver. The receiver is a "survey grade" GPS (Ashtech Z-Eurocard) and my navigation is a custom program I wrote a few years ago. It's designed for aerial survey applications and allows the pilot to fly within a few metres of the selected flightline. The high update rate (10Hz) is important for such precision flight. My program uses the lat/lon and time from the GGA string to compute the flight track, the ground speed in knots and metres/second and also the cross-track velocity. For the cross-track velocity and ground speed to function properly the time-of-day must be correctly paired with the lat/lon so delta-Time and the computed delta-distance can be determined. I hope fs2004 has enough internal precision to support more digits in the lat/lon values. Best regards, W. Wright I've included some sample data from our actual Ashtech Z-Eurocard receiver below: $GPGGA,210214.20,3913.903086,N,07524.167737,W,1,08,01.0,00355.056,M,-035.128,M,,*5A $GPGGA,210214.30,3913.899989,N,07524.167553,W,1,08,01.0,00355.086,M,-035.128,M,,*52 $GPGGA,210214.40,3913.896892,N,07524.167369,W,1,08,01.0,00355.119,M,-035.128,M,,*59 $GPGGA,210214.50,3913.893794,N,07524.167183,W,1,08,01.0,00355.149,M,-035.128,M,,*57 $GPGGA,210214.60,3913.890698,N,07524.166995,W,1,08,01.0,00355.177,M,-035.128,M,,*59 $GPGGA,210214.70,3913.887602,N,07524.166806,W,1,08,01.0,00355.201,M,-035.128,M,,*54 $GPGGA,210214.80,3913.884505,N,07524.166615,W,1,08,01.0,00355.223,M,-035.128,M,,*50 $GPGGA,210214.90,3913.881409,N,07524.166422,W,1,08,01.0,00355.247,M,-035.128,M,,*5D $GPGGA,210215.00,3913.878312,N,07524.166227,W,1,08,01.0,00355.259,M,-035.128,M,,*52 $GPGGA,210215.10,3913.875216,N,07524.166031,W,1,08,01.0,00355.260,M,-035.129,M,,*55 $GPGGA,210215.20,3913.872119,N,07524.165831,W,1,08,01.0,00355.248,M,-035.129,M,,*5C $GPGGA,210215.40,3913.865924,N,07524.165422,W,1,08,01.0,00355.220,M,-035.129,M,,*5A $GPGGA,210215.50,3913.862826,N,07524.165211,W,1,08,01.0,00355.199,M,-035.129,M,,*58 $GPGGA,210215.60,3913.859727,N,07524.164997,W,1,08,01.0,00355.179,M,-035.129,M,,*57