The metar realwx controller checks every 60 seconds for a station
reporting
metar and loads that data if the station id has changed since the last
check.
It also rechecks the metar every 15 minutes for the unchanged station.
Okay, so every 60 seconds, the controller
* determines what the
On Nov 15, Guy Brand wrote:
So I ran the metar command from the CLI to see what it told. That gives
the same result for this particular airport. I was using git revision
0917a5e0. Upgrading to the current git revision 5bb247d4 also shows the
same result. I haven't found another airport for
But would it be possible to accept old data, just not time going
backwards. I feel any METAR data is better than none, so perhaps;
1. accept any any valid METAR data, log warning message if it is old,
2. don't update METAR data if the date is older than current METAR date,
log severe
If I check the METAR data for LFST using another program (AeroWeather on
the iPhone for example or the metar utility for debian from the
http://packages.debian.org/unstable/utils/metar package), I receive
correct METAR data for LFST. So METAR fetching in FlightGear is wrong.
FlightGear uses
On Nov 16, Torsten Dreyer wrote:
FlightGear uses NOAA as a data source for METAR. The url to fetch the data is
http://weather.noaa.gov/pub/data/observations/metar/stations/.txt where
xxx is the ICAO 4-Letter code of the airport in uppercase. We simply rely on
the NOAA data - if the
On Tue, 2010-11-16 at 17:52 +0100, Torsten Dreyer wrote:
If I check the METAR data for LFST using another program (AeroWeather on
the iPhone for example or the metar utility for debian from the
http://packages.debian.org/unstable/utils/metar package), I receive
correct METAR data for LFST.
Hello
Today I noticed this on the terminal:
NoaaMetarRealWxController::fetchMetar(): dropping outdated METAR 2010/11/12
16:00 LFST 121600Z 19009KT 170V230 BKN030 13/09 Q1004 NOSIG
NoaaMetarRealWxController::fetchMetar(): dropping outdated METAR 2010/11/12
16:00 LFST 121600Z 19009KT
Guy Brand wrote:
Today I noticed this on the terminal:
NoaaMetarRealWxController::fetchMetar(): dropping outdated METAR 2010/11/12
16:00 LFST 121600Z [...]
These are three days old. Current (almost) METAR looks like this:
jive: 21:25:32 ~ metar LFST
LFST 152000Z AUTO 34003KT 320V020
2010/11/12 16:00 LFST 121600Z 19009KT 170V230 BKN030 13/09 Q1004
NOSIG
So I ran the metar command from the CLI to see what it told. That gives
the same result for this particular airport. I was using git revision
0917a5e0. Upgrading to the current git revision 5bb247d4 also shows the
Unfortunately this means METAR is broken (probably permanently) for
all previous FG versions now...
As a follow-up to the METAR issue: there actually is a workaround for
FG 1.9.x and 2.0 - by using a proxy server. The requests sent by FG to
a configured proxy server are fine. And the actual
On 05 Nov 2010, at 20:37, ThorstenB wrote:
Anyway, what are the plans for the next FG release?
Hi Thorsten,
I have a gut feeling we might just have chatted about this; but anyways, after
December 15 (approximately), My immediate workload is settling down a bit, and
hoping that we may
On 7 Nov 2010, at 18:58, Durk Talsma wrote:
I have a gut feeling we might just have chatted about this; but anyways,
after December 15 (approximately), My immediate workload is settling down a
bit, and hoping that we may pull a build off of the hudson machine, it should
be too hard to
On Sun, 7 Nov 2010, James Turner wrote:
On 7 Nov 2010, at 18:58, Durk Talsma wrote:
I have a gut feeling we might just have chatted about this; but anyways,
after December 15 (approximately), My immediate workload is settling down a
bit, and hoping that we may pull a build off of the
- Gene Buckle a écrit :
Fred, is there any advantage to using VS2010 to build the Windows
binaries with over the VS2008 compiler? I don't follow the C++ side of the
house so I don't know of any compiler improvements that FG would benefit
from.
I'd stick to VS2008 until the next fg
Thanks.
I think it is pretty inconsiderate of the NOAA to change this two days
before our largest flightsim event worldwide :-D
But as you pointed out, METAR will have stopped working for older
releases too. Which is even worse.
m
Op 05-11-10 20:37, ThorstenB schreef:
That was a problem
Hello,
to avoid this happen again in the future:
Is it possible to add a metar-server functionality to the mpservers? If
the NOAA protocol / access changes we only have to modify the mpservers,
not the clients?
Maik
m schrieb am 06.11.2010 09:30:
Thanks.
I think it is pretty inconsiderate
On 6 Nov 2010, at 08:46, Maik Justus wrote:
to avoid this happen again in the future:
Is it possible to add a metar-server functionality to the mpservers? If
the NOAA protocol / access changes we only have to modify the mpservers,
not the clients?
Just to be clear, NOAA aren't being
Hmmm
Something is not quite right yet. I have recompiled simgear and fgfs. I
had METAR info this morning, but now after a restart, it says NIL again.
Intermittend... Is METAR info read on more than one place?
m
--
The
Funny,
I disabled METAR for global weather in the GUI and later set it to Live
Data again, and now it is collecting METAR info again... without restarting.
m
Op 06-11-10 12:09, fiers...@zonnet.nl schreef:
Hmmm
Something is not quite right yet. I have recompiled simgear and fgfs. I
had
On Saturday 06 November 2010 03:51:28 James Turner wrote:
On 6 Nov 2010, at 08:46, Maik Justus wrote:
to avoid this happen again in the future:
Is it possible to add a metar-server functionality to the mpservers? If
the NOAA protocol / access changes we only have to modify the mpservers,
On Sat, 6 Nov 2010 12:23:33 -0600, Ron wrote in message
201011061223.33277.w...@jentronics.com:
I looked at the NOAA site last night.
http://weather.noaa.gov/pub/data/observations/metar/stations/
There are some seriously old metar files mixed in there!
Recompiled all very early this morning.
I have just noticed that in global weather, there is no METAR data.
METAR source is set to live data.
In the METAR data box I read 'NIL'.
Something broke the METAR updates?
m
On 5 Nov 2010, at 08:16, fiers...@zonnet.nl wrote:
Recompiled all very early this morning.
I have just noticed that in global weather, there is no METAR data.
METAR source is set to live data.
In the METAR data box I read 'NIL'.
Something broke the METAR updates?
Torsten has been
On Fri, 2010-11-05 at 09:54 +, James Turner wrote:
On 5 Nov 2010, at 08:16, fiers...@zonnet.nl wrote:
Recompiled all very early this morning.
I have just noticed that in global weather, there is no METAR data.
METAR source is set to live data.
In the METAR data box I read 'NIL'.
Another option would be that the metar server is
unavailable ..
checking, jup:
metar EHAM
ERROR: no metar data available from
at
http://weather.noaa.gov/pub/data/observations/metar/stations/EHAM.TXT
I guess the same, I run a older GIT from early Octobre, and METAR worked two
days
On Friday 05 November 2010 10:21, Heiko Schulz wrote:
Another option would be that the metar server is
unavailable ..
checking, jup:
metar EHAM
ERROR: no metar data available from
at
http://weather.noaa.gov/pub/data/observations/metar/stations/EHAM.TXT
I guess the same, I run a
John Denker wrote:
On 05/24/2009 02:58 AM, Torsten Dreyer wrote in part:
Step #2
Add an option --metar=
- this implies --disable-real-weather-fetch and set scenario to METAR
- make the metar string editable in the weather_scenario dialog
This option needs some changes in the logic of
On 12/20/2009 12:54 PM, Stuart Buchanan wrote:
I believe
--metar= 012345Z 0KT 99SM CLR 59/M01 A2992
is a correct and useful example ... but somebody should double
check.
Thanks for the example - I'll include it in the docs. My only comment is that
I thought the temperature was
As a separate issue: With rare exceptions, the largest visibility
you will see reported in a metar is 10SM (in the US) or (meters,
elsewhere).
This is a problem for real-weather fetch, because the _reported_
visibility can be significantly less than the _real_ visibility.
I have tried to
* Peter Brown -- Sunday 20 December 2009:
IMHO there is no choice other than the bold solution- anything reported as
10SM = unlimited, and 9.99 and less is actual.
And so guaranteeing the lowest possible frame rate? Sounds like a truly bad
idea. The whole thing has been discussed before.
its a way to weed out the gamer...
Just thoughts I'm sure were considered before.
Peter Brown
--Original Message--
From: Melchior FRANZ
To: flightgear-devel@lists.sourceforge.net
ReplyTo: FlightGear developers discussions
Subject: Re: [Flightgear-devel] --metar and --enable-real-weather
I had looked at some research papers at that time, which were about
estimating visibility from other, measurable factors. I stopped when
Thomas announced his solution. My original idea was a simple formula,
based on the idea that:
- visibility is derived from humidity (high humidity - low
: Melchior FRANZ
To: flightgear-devel@lists.sourceforge.net
ReplyTo: FlightGear developers discussions
Subject: Re: [Flightgear-devel] --metar and --enable-real-weather-fetch
Sent: Dec 20, 2009 5:18 PM
I had looked at some research papers at that time, which were about
estimating visibility from
On 05/24/2009 02:58 AM, Torsten Dreyer wrote in part:
Step #2
Add an option --metar=arbitrary handcoded METAR
- this implies --disable-real-weather-fetch and set scenario to METAR
- make the metar string editable in the weather_scenario dialog
This option needs some changes in the logic of
John Denker wrote:
I have some basic questions about the --metar command-line
option.
AFAICT the getstart.pdf manual doesn't mention this option.
That's correct - we've still to complete the updates to the manual
for the upcoming release. However, it's on my TODO list.
If you want to
On Sun, Dec 13, 2009 at 10:16 AM, Stuart Buchanan
stuart_d_bucha...@yahoo.co.uk wrote:
A I recall, Torsten implemented that feature. There was a
description of it on the -dev list a couple of months back,
but I've been unable to locate it myself in the archive.
Here you go:
I have some basic questions about the --metar command-line
option.
AFAICT the getstart.pdf manual doesn't mention this option.
The --verbose --help message mentions the option, and
implies that it takes an argument ... but doesn't say
anything about the syntax or semantics of the argument.
I
2009/2/19 Torsten Dreyer tors...@t3r.de:
Comments welcome.
All works fine, thank you very much for this feature.
From now long-range flights got new level of realism.
--
---
WBR, Vadym.
--
Open Source Business
Hi,
as a proof of concept, I have a little hack that provides live wind aloft data
for FlightGear. A draft can be found here:
http://wiki.flightgear.org/index.php/Howto:_Fetch_live_aloft_data
Comments welcome.
Torsten
I wrote :
Csaba wrote:
On Fri, Dec 19, 2008 at 11:38 PM, Stuart Buchanan wrote:
The patch below backs out that change. Unfortunately this means the change
to the cloud coverage due to changing METAR will not be reflected in the
3D
clouds
(2D clouds are unaffected).
You're right.
That's why I have implemented quickly a smooth changement
precipitations.
I think that the changement should be refactoring.
Mostly for wind...
Regards,
Le vendredi 19 décembre 2008 à 14:35 -0600, Curtis Olson a écrit :
I just did a cross country flight with the latest CVS
I just did a cross country flight with the latest CVS cloud/weather/metar
changes and I noticed that the weather interpolation that smoothed out
abrubt changes to wind and clouds when a new METAR report comes in seems to
have now been lost. We are back to abrubt wind and cloud changes. I
haven't
Curt wrote:
I just did a cross country flight with the latest CVS cloud/weather/metar
changes and I noticed that the weather interpolation that smoothed out
abrubt changes to wind and clouds when a new METAR report comes
in seems to have now been lost. We are back to abrubt wind and cloud
On Fri, Dec 19, 2008 at 11:38 PM, Stuart Buchanan
stuart_d_bucha...@yahoo.co.uk wrote:
The patch below backs out that change. Unfortunately this means the change
to the cloud coverage due to changing METAR will not be reflected in the 3D
clouds
(2D clouds are unaffected). Unfortunately I
Csaba wrote:
On Fri, Dec 19, 2008 at 11:38 PM, Stuart Buchanan wrote:
The patch below backs out that change. Unfortunately this means the change
to the cloud coverage due to changing METAR will not be reflected in the 3D
clouds
(2D clouds are unaffected). Unfortunately I don't think it
On Fri, 2008-12-19 at 23:30 +, Stuart Buchanan wrote:
Csaba wrote:
On Fri, Dec 19, 2008 at 11:38 PM, Stuart Buchanan wrote:
The patch below backs out that change. Unfortunately this means the change
to the cloud coverage due to changing METAR will not be reflected in the
3D
I wrote:
Subject:
Hi All,
Attached is a very small patch that fixes the issue reported by Martin where
--prop:/environment/weather-scenario=METAR had no effect.
I think this is a pretty safe patch that should be included in the release.
-Stuart
Sorry for the lack of subject.
Hi,
I've been discussing with Japanese FlightGear users about METAR update failure
on 1.0.0.
It seems that METAR update fails when BIOS time is set to local time (JST, GMT+
9) on Windows (and probably on Linux).
According to windows users, launching fgfs with --log-level=warn outputs
METAR
48 matches
Mail list logo
