News:

Precision Simulator update 10.173 (24 February 2024) is now available.
Navburo update 13 (23 November 2022) is now available.
NG FMC and More is released.

Main Menu

Timing of FMC wind data uplink simulation

Started by Hardy Heinlin, Sat, 3 Nov 2018 16:06

Hardy Heinlin

Good evening,

I want to increase the precision of the FMC wind data uplink simulation for the case when the automatic METAR download feature is active.

As usual, the forecast office simulation takes wind & OAT probes in the planet weather model at the tropopause (data is variable by waypoint location). It then interpolates the data at each route waypoint for one OAT altitude and 4 wind altitudes. The OAT altitude and the lowest wind altitude will be interpolated with the surface wind & OAT data.

In the existing PSX versions, the surface wind & OAT data for this feature more or less disagrees with the actual ground data at these waypoints. Therefore the ground data related interpolations are accordingly randomized.

In the next version this feature will scan the last downloaded METAR world file and take for each waypoint the nearest METAR if that is within 320 nm (else the planet weather's ground data). With this more precise ground data, the ground data related interpolations in the FMC uplink will be more precise as well. Disagreements are still possible because the METARs get updated twice an hour as usual, and the next FMC data uplink may update the disgreement.

In the existing PSX versions, when the uplink data is being loaded into the FMC route, there is an intentional 50 ms delay between each waypoint data injection; one can observe on the RTE DATA page how the "W>" prompts appear one after the other. In a route with 200 waypoints the whole process takes 10 seconds.

I will remove this 50 ms delay in the next version just for the above special case when the automatic METAR download feature is active and the METAR world file is being scanned for each waypoint. These file scans take so long that a route with 200 waypoints may require up to 5 minutes. Hence the time delay need not be simulated anymore; the program alone is already slow enough.

Question:

Are these 5 minutes (for 200 waypoints) too long, i.e. unrealistic?

If this is way too long, I'll have to design a new system where the scan is being performed during the simulated inital data link send/request process which incorporates artificial delays. That way the response may take 5 minutes (for 200 waypoints) and the actual loading may take just 1 millisecond requiring the old artificial 50 ms between each waypoint.


Regards,

|-|ardy

Jeroen Hoppenbrouwers

I feel it is much too long, and I also feel that 200 waypoints is over the top. I would propose to only calculate the data for the next, say, 20 waypoints and then at most, say, 20 waypoints equally distributed over the rest of the route.

My recent 737 MAX FMC play showed that loading a route of about 50 waypoints took about 10 seconds, in which you can follow the RTE page being updated 'live.' The FMC really takes a lot of time as it looks up each fix in turn, and it does not have a power house CPU.


Hoppie

Hardy Heinlin

I agree, a record for each waypoint is not really required. As the delay has been no issue until now, I just didn't need to design a waypoint selection algorithm (it's not trivial if the route contains very irregular leg distances).


|-|ardy


P.S.: Would you say 3 minutes are too long for the time from "sending" to "uplink ready"?

Jeroen Hoppenbrouwers

ACARS can be a bitch. You have to include downlink time, downlink ack time, ground processing time (extensive database lookup and processing), then uplink and uplink ack time. Over VHF it probably takes 30 seconds. Over older SATCOM, easily one minute.

Something like:

0 Sending
5 Sent
30 (receiving)
40 (uplink ready)

feels realistic. Three minutes? I don't think so, but I never flew an airliner... any pilots that have both VHF and oceanic experience?

Concerning data point spacing... for waypoints over an hour flight away, won't you expect at least one update before getting there? This was my main reason for proposing the first 20 and then a lot less density.


Hoppie

Hardy Heinlin

Quote from: Jeroen Hoppenbrouwers on Sat,  3 Nov 2018 19:30
Concerning data point spacing... for waypoints over an hour flight away, won't you expect at least one update before getting there?

The uplink model is not a simulation of a METAR system with 30 minute intervals. It's a simulation of a MET office that uses virtual TAF data to compose an FMC wind data uplink, referring to the internal planet model -- which is a mix of self-generated jetstreams and downloaded METARs. The main part is the jetstream model. The jetstream settings won't change unless the user changes them. TAF data are updated in 6 hour intervals. But if the user won't change the jetstream settings, the virtual TAF data will not change anyway.

In real life, during a 12 hour flight, one or two TAF updates (wind data uplinks) are sufficient.
You should have leg data for at least 6 hours.


|-|ardy

United744

From what I understand, the wind uplink is generally considered too imprecise to worry about (as raw data), and I know many crews who don't even use it. It updates *predictions* but then they are eventually computed based on actuals anyway, and so become increasingly irrelevant much after takeoff.

There are other ways of checking computed data (time, estimated fuel remaining) that are at least or more accurate than those computed off the uplinked wind data to begin with.

Why is it being changed? Is the current method inaccurate regarding data source for computation? You say you're switching from simulated TAF to METAR - why's this?

So far, I've found the uplink to be good as it is. The main thing is that cumulatively, the "down route" effect of the wind data being broadly accurate as to be meaningful over, say, the next 1000 NM. I've yet to see anything wildly out. Of course, that is 2 hours ahead of the current position, and if flying near the jet stream or pressure centers, 2 hours can change things quite a bit (beyond mere "rounding errors" in the data).

Hardy Heinlin

Quote from: United744 on Sun, 11 Nov 2018 02:15
Why is it being changed?

It has been changed in version 10.53 and is uploaded already.


Quote from: United744 on Sun, 11 Nov 2018 02:15
Is the current method inaccurate regarding data source for computation?

It was only a bit inaccurate at low altitudes where the ground data are more dominant in the vertical interpolation than the aloft data.


Quote from: United744 on Sun, 11 Nov 2018 02:15
You say you're switching from simulated TAF to METAR - why's this?

There's no such change. The vertical interpolation now simply takes the actual ground data settings into account instead of using raw average values. This is the ground data set on the 7 local weather zone pages and on the planet weather page (ground data outside local zones).

When the automatic zone selection is off, the 7 zones won't change, and so the MET office simulation just needs to scan 8 data records (7 zones + 1 planet). This takes a millisecond.

When the automatic zone selection is on, the 7 zones will change during the flight, and will load data from the big METAR world file, and therefore the MET office simulation has to scan thousands of data records to find the relevant ground data along the route. This takes 30 to 60 seconds. For example, when a waypoint like LAX is in the route, the virtual MET office will first search the METAR station table for the station with the shortest distance to LAX (and will find KLAX, for example), and then scan the two last downloaded METAR world files for the latest KLAX METAR. If no station or data is found, the LAX waypoint will get the ground data of the planet page. -- This is done for each waypoint that is more than 80 nm away from the previous record, and that is closer to a different METAR station (it won't rescan the world file for waypoints that are in the same local zone).

If you fly near the tropopause, the ground data is rather irrelevant. But the 4 reference wind altitudes in the FMC typically include a lower one around 20000 feet. That has a significant ground data portion in its interpolation up to the tropopause.


Regards,

|-|ardy

United744

Ahh I see! Thanks for the explanation!

cagarini

METAR, just as TAF are rather restricted in area, horizontal and vertical.

I don't know how the companies deal with the various sources of meteorological info in order to feed their FMCs with the weather uplinks, but the sources used at the Met Office - we actually have a web service that private and professional pilots can access to help with the flight planning "brief.ipma.pt" (and creates a portfolio of useful information of various types based on a predefined route, with short or wide corridors ) - but and also by at least one weather injector I know well are:

- London and Washington WAFs;
- SIGWX ( from the same centers ) based on the SIGMET from the FIRs that the route will cross;
- Runs of Global and Local area weather models provided by ECMWF and ALADIN or AROME - GCM and LAM, updated every 3 hours here at the Portuguese Aviation Weather Service;
- SYNOP data and TAF / METAR when available, for better fine tunning of the lower levels;
- The forecasters, but also the web page can complement this with Satellite and Radar data;

Hardy, should you be interested, I can provide you access to hour "Self Briefing" online service.

I'm still trying to digest the information you're providing regarding PSX's Global Weather Model and Virtual MetOffices Hardy. It is certainly a rather complex algorythm, and integrating it in the future with data from the OFPs certainly an interesting problem to solve...

P.S.: A big Thank You! to JJ, my great friend and Aviation Meteorologist at IPMA, for the very helpful information he provided.

cagarini

#9
Hardy,

when flying along long segments of a flightplan that aren't near to any stations, and we should have in mind that to that effect, 8km up to 16km ( vicinity of the reporting station ) is the "radius" for a TAF / METAR, and MSA in the vertical ( can be much higher than in Europe in the USA and Canada even in the absence of significant terrain features ), what do you take as a reference for that interpolation ?

For the new "merge" solution based on wind and temp data from OFPs, when users opt for it, up to what distance are you propagating / merging these parsed data with PSX's World grid ?

Hardy Heinlin

Aloft data is modeled by the jet stream system and is different on every place of the virtual earth.

Ground data is modeled by the 7 local zones. These can be fixed by the user, or they can be dynamic by continuously autoselecting the 7 nearest and latest METARs during the flight. For areas outside the 7 local zones the planet's ground data is used.

Data between aloft and ground is interpolated.

The simulated MET office does not create any TAFs. It simulates an FMC wind data uplink package that looks like a real wind data uplink package from a real office sent to a real FMS. In PSX it's just a simulation. The world in PSX is a simulation. The real office would use a collection of real TAFs, and the dispatch officer's name might be Daisy Duck. It's up to the PSX user's imagination whether or not the simulated uplink packages comes from a TAF collection and Daisy Duck.

The MET office simulation takes 3D data probes from the internal weather model at different locations and altitudes. Such a probe is the same probe that the simulated aircraft gets when it is at such a 3D point. It's the same algorithm.

Areas where no METARs exist are typically areas where no airports exist. In such areas your 747 usually flies near the tropopause and therefore the ground data portion in the interpolation is rather irrelevant anyway.

As for the new corridor feature: I'll make a small tutorial when it's finished.


|-|ardy