@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
