Stale radiosonde data and freshness

Thomas 112

Hi, first off just want to thank you for maintaining that great platform, it's my go to tools and I use it all the time. One bit of feedback though: the radiosonde sounding data is often way behind other sources. Sometimes a sounding that should already be up takes hours or even days to show.
Example: Tanay in the Philippines (WMO 98433). I can see fresh 00Z/12Z soundings on the University of Wyoming archive, but on Windy the latest Tanay sounding is 11 days old!

There are probably a few ways to fix it. Maybe pulling from more than one source so a slow feed doesn't hold everything up? Either way, having the latest soundings as soon as they drop is important to my workflow so I hope this can be addressed.

Suty

@Thomas-112 Hello, do you know about any reliable sources that can be used to offer their data in Windy?

Thomas 112

@Suty Thanks for the fast reply! This one, hosted by University of Wyoming, is the best one in my opinion, and would allow for easy extraction:
https://weather.uwyo.edu/upperair/sounding.shtml

You also have this one:
https://tracker.sondehub.org/

As backups, you can rely on:
https://www.ncei.noaa.gov/products/weather-balloon/integrated-global-radiosonde-archive
https://www.ogimet.com/sond.phtml.en

I hope that'll be useful.

mhaberler

@Thomas-112 @suty

Gentlemen, please hold the horses before reinventing history.

I am the author auf the radiosonde datacollector and backend used by windy.com, and holder of the code copyright. I have granted Windy the right to use this code provided the access to the radiosonde URI's remains open for research and personal use, and a minor compensation for our team which never was delivered by Windy.

What you see in the skew-t diagram was originally written by @rittels as a plugin, and eventually adopted, integrated and improved.

All the meteo knowhow came from @wetterheidi .

You can read up on the code on my public github repo which is by and large what is running at windy.com - more details can be had from @filip_k who took over my code and fixed several issues.

I spent over a year researching, trying and arranging data sources for the data collection process and I think I have them all (or at least had them all back at the time).

Among the candidate feeds was the UofWyoming operator's feed. That gentleman agreed to publish his code, and his feed, and never delivered on that. Therefore: good luck with that.

Btw this pissed me off so much that I decided to build the very best radiosonde feed around, and leave the UofWyoming site behind. If you compare data presentation, detail and coverage you might agree we succeeded at that.

sondehub.org: interesting project, I contributed to funding and am in touch with those folks for years.

Note that sondehub provides raw data as received via radio link, and there is exactly zero curation, plausibility tests etc as handled in the professional radiosonde feeds. So this is certainly not an alternate data source at the same level - you might use sondehub as a backstop if the professional feeds are down. But I would recommend against integrating into a meteo project - it is a best-effort project by radio amateurs.

As for the problem at hand:

It is quite common for radiosonde feeds to have a blackout for various reasons.

One reason for instance is war - feeds from the Ukraine/Russia theater are redacted nowadays since the information is very relevant from a military perspective.

Another common reason is - weather, especially the monsoon season. So better first check if the darn thing is actually working, and data delivered somewhere before scraping for new feeds - which might also be useless as that amounts to solving the wrong problem.

So in your case what you do is: you download an old radiosonde ascent and look at the JSON. I just did this for Tanay and what you see is:

 "properties": {
        "station_id": "98433",
        "station_name": "Tanay",
        "elevation": 651,
        "lat": 14.5814,
        "lon": 121.3692,
        "processed": 1781222718,
        "arrived": 1781222533,
        "firstSeen": 1781178900,
        "syn_timestamp": 1781179200,
        "id_type": "wmo",
        "origin_member": "20260611_1200.gz",
        "repfmt": "fm35",
        "encoding": "netCDF",
        ...
        "channel": "NOAA MADIS",
        "lastSeen": 1781181446,
        "path_source": "simulated"
    },

"channel" gives you how this data was recently acquired - NOAA MADIS in this case.

read up on the github repo how NOAA MADIS is handled - it's an ftp server.

Now go and check if recent ascents from this location can be found, and trace back from there to source of the issue. Having done this before my experience was that is super hard to track down within the average national meteo bureaucracy.

happy hunting

Michael

ps; a bit more of intra-company communication might go a long way to prevent duplication and waste