We have an extended discussion of how to use ASCAT wind data in our textbook Modern Marine Weather, 3rd ed.

ASCAT Data sources

With internet you can obtain these data in graphic format direct from Ocean Surface Winds Team (OSWT). See below on how to request them by email.

The above source has the attractive property of using the same file name for any specific location, which makes it easier to automate the downloads. We can also see the data from the KNMI Scatterometer Team. The satellites Metop-B and Metop-C (Metop-A has been discontinued) are operated by EUMETSAT and the raw data are provided to both KNMI in the Netherlands to analyze for European agencies and to NOAA/NESDIS for processing here in the US. The basic scatterometer data analysis software used is the same, but each lab has modifications, which may yield slightly different winds occasionally. The valid times of the data should be the same. We have to check yet on the latency—that is, how long does it take each lab to get the data out. The images below compare the two presentations.

Left are two OSWT images, stacked one on top of the other; on the right is one from KNMI. The KNMI images are larger and higher resolution, but the OSWT wind speed data remains easier to read due to the colorbar.


Other ASCAT related resources

ASCAT Manual from EUMET

• Video: Introduction to ASCAT

How to get ASCAT graphic data via Saildocs

Predicting the times of ASCAT (Metop) passes

See also PC program Orbitron, and lizard-tail web page (Metop-B) and (Metop-C). Sat specs at the end here.

See our notes below on how to anticipate when data will be available at various locations.

How to make an auto-updating overlay of ASCAT data in Google Earth. These KML files can also be imported into qtVlm for comparison with model forecasts in grib format.

Loading auto-updating, georeferenced ASCAT data into qtVlm. See notes below on files available.

Frequency of ASCAT data at a specific position

How to get ASCAT winds from Saildocs

LuckGrib excellent tutorial on ASCAT

ASCAT data in Grib format

ASCAT Data in Grib Format — Gone, and Back Again

LuckGrib (Mac or iOS) [coming video: ASCAT in LuckGrib.] LuckGrib has two ASCAT links: one covers the past

Expedition (PC) [coming video: ASCAT in Expedition.]

The above commercial products are the most convenient way to obtain and view ASCAT data in GRIB format, but ASCAT data in NetCDF format can be viewed in the public program Panoply, but it takes a bit of patience, as shown in this video [ASCAT in Panoply].The raw NetCDF data are available at NASA.

At present the fastest way to see this data (meaning nearest time to when the satellite actually went by measuring the winds) at a specific region on earth is to set up the 4 links to get you the graphic data for B, and C both ascending and descending. ASCAT A has been discontinued, and other scatterometer sources have not been dependable.


Ascending pass above; descending pass below. (Satellite tracks curve west as the earth rotates to the east below the polar orbit.)

The valid universal times (UTC, same as GMT) of these maps are listed in small purple numbers at the bottom of the figures. These samples are from a set of passes that span the time period T1 to T2, where T2 = 0414 Sept. 26, 2012, and T1 is 22 hr earlier, which would be T1 = 0614 Sept. 25, 2012. The pass times for these samples (0704, 0845 and 1931, 2111) would therefore all be for Sept. 25.

The 22-hr data sets are updated every hour, so the 2111 pass is the most recent, being (0414 Sept. 26 - 2111 Sept. 25) about 7h 03m old.

Because the individual files as shown above are about 40 kb, it pays to have some way to estimate when the next useful data will be available, else we waste airtime downloading data we already have.

Please check out our free email service we offer for email delivery of near-live ship reports in your vicinity (www.starpath.com/shipreports). Ship reports and ASCAT are the truth meters we need to evaluate all forecasts.

Importance of ASCAT data

These direct wind measurements are the key information needed for weather routing, with a primary use being to evaluate the numerical weather model forecasts. The data are like having thousands of buoys at sea measuring the wind speed and direction, and if a model is to be dependable it should closely match what we see in the buoy measurements.  Also we will periodically see real holes in the wind, or wind shear lines in the ASCAT measurements that are not forecasted in any model. The resolution of the ASCAT data (25 km) is about the same as that of the GFS model (27 km). The expected accuracy of the satellite measurements and that of the model forecasts is about the same, so very roughly ± 2 kts in wind speed and ± 20º in wind direction has to be considered in agreement.

Remember that the final goal of any numerical weather model is not to reproduce all of the specific observations that went into the computation, but rather to create the best overall forecast at all levels of the atmosphere, which almost always involves some compromise in matching the surface data. Thus, even though the ASCAT measurements are key data assimilated into any global model computation, we should not be surprised that we can learn real and significant discrepancies in the model forecast by looking at the same ASCAT data it was looking at, and when these do disagree, it is the measurements that are of course the correct answer.

Unique convenient index to latest ASCAT data

The KML file format is a way to create an interface to a file online that will both fetch the latest version of a file and also georeference it for display in a navigation program. We have made such files for many ASCAT data regions and also have online a prescription for making others. Below is a graphic index to what we have completed so far, July, 2023. These graphic images of the data are typically about 1 orbit (101 min) newer than we can get from grib format solutions. Thus if a satellite goes by a point at 10z we can typically get the graphic image of the ASCAT data by about 12z, but we would not see this data in grib format until about 13 or 14z. The grib data is more convenient if we can use it (ie LuckGrib or Expedition), but it is a bit older when we do get it. The graphic data, on the other hand, can be viewed by any navigator using Google Earth or qtVlm. The content of these files cal also be reformatted to work in OpenCPN, which we present later on.

Each of these named zones in this graphic index have 4 files, Metop B and C, ascending and descending. Samples for San Francisco are listed below. Referring to the times in the index above, this region will have new data at 05:35 and 18:25 UTC, ± 1 hr. Generally in the mid latitudes we get new data 4 times per 24 hr, with occasionally just 3 times. In he samples taken randomly below, we got data at 05:0, 05:49, 18:09 and 19:01.

San Francisco ASCAT B - Ascending.kml 1809

San Francisco ASCAT B - Descending.kml 0543

San Francisco ASCAT C - Ascending.kml 0501

San Francisco ASCAT C - Descending.kml 1901

These files can then be loaded into Google Earth or qtVlm as explained in the demo videos, above. Loading into OpenCPN requires some modifications explained elsewhere.

We will see that ASCAT data are complex patterns to unfold, but after a short discussion of this, we present a simple cookbook approach for using this crucial data underway. First look at the full day's plot of all the passes that were available on 6/26/23.

Here we look at what we call the San Francisco region, noting the nadir gap of missing data below each satellite pass. To help track available data swaths, we name them with the satellite (B or C), the direction of the pass (a or d), and the side of the pass, port or starboard (P or S). Thus a swath named CdS means the starboard side of Metop-C, descending. Below we zoom in on the San Francisco file.

These are the four times there were new ASCAT data on this date in this region, which is typical for the midlatitudes. The nadir gap is marked in yellow. The orbit period is 101 min (1.68 hr) and the earth rotates at 15° of Lon per hr, so in one orbit the earth rotates 1.68x15 = 25.2° of Lon. To get back over the same Lon headed in the same direction would take 360/25.2 = 14.3 hr. But each of the region files spans 15° of Lon, which is just over half an orbit, so we might catch a repeat pass from the same satellite in the opposite direction in less than the 14.3 hr.

A more valuable practical point is B and C are in the same orbit, but on opposite sides, so they are about 50 min apart headed in the same direction. This gives us a simpler way to estimate the next new data pass: the same point on the data swath from B will be followed about 50 min (half an orbit) later, but moved west by about 12.5° ( 50m x 15°/60m). We see, for example, in the left image, the inside edge of CaP at the bottom of the region (30°N) went by at 0501 at Lon 121.3°W. Then 48 min later this same point on the new swath is seen moved west to 133.6°W.

To clarify the concept that there will be new data about 4 times every 24hr: consider the example of San Francisco with valid times of 0525 and 1825 UTC, ± 1 hr, noting that it takes about 2 hr to process the data.

Thus while underway or planning a route across these waters, we would go to Google Earth (or wherever we are looking at the data) at about 0725 or later UTC and download all four passes given. We do not know ahead of time which of the four will bring the new data but most likely two or them will have a swath of new data that will be valid at 0525 ± 1hr. Then again at 2025 or later we would again download all four of the passes and among those will likely be two new data swaths valid at 1825 ± 1hr.

That is in effect a cookbook approach to the data, using our indexes as guides for when to look. We will not get new data between these two periods. We then have to correlate the valid times with the model times and forecasts at hand. In the above example, the 1825 cycle data (1809 and 1901) are ideal in that by the time we can get these 2000 or so, we will also have the 18z model run, or at least in the next hr that will be available, so we are comparing model and measurements almost live, keeping in mind that the h0 forecast of the 18z model run is effectively a surface analysis.

The 0525 cycle data (0501 and 0549 on this date, which will not be the same day to day) the comparison is not as tidy. We could interpolate the h5 and h6 forecasts for comparison, or know that when we get the 06z model run at about 0830z, we will have 0549 to compare it to.

We have also now completed the file set for waters adjacent to the Europe, as shown below.

You can download the set of all ASCAT KML files shown in the graphic indexes above from Starpath_individual_ASCAT_KML_files.zip (1.6 MB), which includes all 46 file sets for US and EU. These are the ones you need to load individually into qtVlm. For use in Google Earth (GE), take those from the link below.

For fast viewing in Google Earth (GE), we made custom KML files that can be just clicked to open in GE, which is the easiest and most versatile way to view the ASCAT data. Once, unzipped, the two files (Europe and North America) can be dragged onto the screen of GE to view them in your temp locations, then save them when you close GE. Get these files at

Starpath_Google_Earth_ASCAT_Files.zip (1.3 MB)


Viewing ASCAT winds in Google Earth on a computer (using the Starpath indexes above)


It is a bit more involved to load these into an iPad or iPhone, but it only has to be done once, as shown in this video:


Viewing ASCAT winds in an iPad or iPhone. The process is the same in Android devices.


Identifying a swath

Sometimes when we see only half of a full swath, the port (P) or starboard (S) side only, it is helpful for forecasting what we see next to know if we are looking at the P or S side. The graphic below is way to resolve that.

Here are two examples

In swath 1 we are seeing just half of the starboard side, so we do not expect to see the counter part on B, it will be too far west. Swath 4 is also starboard side. Swaths 2 and 3 are the port side of the passes. Knowing the side and times, we can make rough estimates of what we see next... or we use an app like Orbitron to compute it for us... or we just go by our cookbook prescription above that will generally do the job without such intricate forecasting.

When we computed the time ranges wherein new data will be available at specific locations, we had to incorporate the swath structure and how close we had to be to the path to get data. That was figured from this diagram that uses the actual height of the satellite and dimensions of the data swaths:

In our computations of the orbit pass times using Oribtron, we thus ruled out all passes that had a satellite height less than 43°. We used the center of the named region to specify the location. Each region is 15° of Lon wide, which is just over 1 orbit period (12.5°) and equal to 1 hour of solar time, this combined with the complex data pattern and two satellites, led to the ±1h time uncertainty. In many cases the time window, however, is not that wide.


the tracks and recent data are at



TLE from


METOP-C  (on day 23.43711512 of 2024)               
1 43689U 18087A   24023.43711512  .00000260  00000+0  13898-3 0  9998 
2 43689  98.7022  84.6684 0003404 127.4288 232.7199 14.21499910270416
METOP-B  (on day 23.39975286 of year 2024)               
1 38771U 12049A   24023.39975286  .00000269  00000+0  14273-3 0  9998 
2 38771  98.6503  83.7519 0001721  95.6811 264.4562 14.21458759588830
Interpret the TLE at  https://en.wikipedia.org/wiki/Two-line_element_set

To get plots of the tracks online or by email request from saildocs, use this form of URL


Where these samples are for Feb 2, 2024, which is the 033rd day of the year. This  has to be figured or looked up and added.
You can get these data for the present date and then 3 days in advance, ie on Jan 30, you can also get Jan 31, Feb 1, and Feb 2

We are still testing this, but we will soon be able to get the predicted pass times for a specific lat lon from the nav app qtVlm.