The recent 1.9.0 release of FlightGear has seen the Atlas protocol
take a tiny step backwards, rather than forwards. I guess that's the
nature of software development.
Basically, there are 3 problems:
(1) The most recent patch (1.13) had an omission (my fault)
(2) The previous patch (1.12.2.1) disappeared (CVS problem?)
(3) FlightGear now shows some very strange time behaviour
The first two are easy enough to correct - a patch is attached that
should correct both. The third, though, is rather odd and I don't
understand it. I'd like to know if anyone else has noticed this
behaviour, if it's serious, and how it can be fixed.
Basically, for the first minute or two after starting up, FlightGear
has a wildly fluctuating idea of what "now" is, where "now" is the
time given by globals->get_time_params() (Atlas.cxx uses this to
timestamp its messages). Here's a sample of what got sent on a flight
on December 28, 2008, around 11:55 GMT:
Dec 28, 2008, 11:55:47
Jan 01, 2009, 17:00:00
Dec 28, 2008, 23:30:00
Dec 28, 2008, 11:55:50
Jan 02, 2009, 16:40:00
Jan 02, 2009, 07:35:00
Dec 28, 2008, 11:55:53
Dec 28, 2008, 11:55:54
Dec 28, 2008, 19:25:00
Dec 28, 2008, 11:55:56
Dec 28, 2008, 11:55:57
Dec 30, 2008, 11:05:00
Dec 29, 2008, 01:05:00
Dec 28, 2008, 11:56:00
Dec 28, 2008, 13:50:00
Dec 28, 2008, 11:56:02
Dec 28, 2008, 11:56:03
Dec 28, 2008, 11:56:04
[...]
As you can see, there are some correct time stamps, but others are
not. Some are off by 5 days. This jumping around makes Atlas very
confused. Eventually, after a minute or two, it settles down. It
seems to be independent of airport, aircraft, or time of day settings.
The /sim/time property behaves the same way (it also gets its
information from get_time_params()). So if you want to see this
behaviour in action, just start up FlightGear and watch /sim/time.
What surprises me is that this doesn't break FlightGear. You'd think
with its notion of time jumping around so violently, systems should be
failing left and right. But the clock in the c172p, for example,
ticks along merrily, the sun stays in the same place, ...
I should add as well that this behaviour seems to be new. Previously
when starting up, FlightGear would typically produce one bogus Atlas
message (a position of 0 degrees lat, 0 degrees lon), then settle
down. As far as I recall, it never reported bogus times.
Brian
p.s. Warning to patcher - I haven't tested this patch. I can't
compile FlightGear OS X because I'm running 10.4 and it needs
10.5. Sorry.
To test it, run flightgear with --atlas=file,out,1,sample.text
(this will save the Atlas output to the file 'sample.text'). In
the aircraft, change NAV 1 and NAV 2 (radials and frequencies),
and the ADF (frequency). Quit. Check the file to see if the
$PATLA lines reflect the changes (or just send the file to me and
I'll check it).
73c73
< static SGPropertyNode *nav_freq
---
> static SGPropertyNode *nav1_freq
75c75
< static SGPropertyNode *nav_sel_radial
---
> static SGPropertyNode *nav1_sel_radial
76a77,80
> static SGPropertyNode *nav2_freq
> = fgGetNode("/instrumentation/nav[1]/frequencies/selected-mhz", true);
> static SGPropertyNode *nav2_sel_radial
> = fgGetNode("/instrumentation/nav[1]/radials/selected-deg", true);
141,145c145,149
< nav_freq->getDoubleValue(),
< nav_sel_radial->getDoubleValue(),
< nav_freq->getDoubleValue(),
< nav_sel_radial->getDoubleValue(),
< adf_freq->getDoubleValue() );
---
> nav1_freq->getDoubleValue(),
> nav1_sel_radial->getDoubleValue(),
> nav2_freq->getDoubleValue(),
> nav2_sel_radial->getDoubleValue(),
> adf_freq->getIntValue() );
--
Brian Schack
19 Xǔchāng Street 2F phone: 2381 4727
Taipei 100 fax: 2381 2145
TAIWAN
------------------------------------------------------------------------------
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
