in summary:

we have MUCH better coverage in high-resolution ascents since two days, as well as new stations appeared which had no coverage at all so far

this is thanks to a patch developed by windy's formidable Mr Karpíšek @FILIP_K which is running in the backend now - congratulations, Filip!

the gory detail:

radiosonde ascents are distributed in two formats, a telex-oriented legacy format called FM35, and a more recent high-resolution format called FM94 (or BUFR in meteospeak)

due to redundant data feeds, we receive both formats for many stations - if for a given station a high-res view is available, that is given preference - if we do not have something else, we fall back to the legacy format

I've been running this backend service for close to a year or so, and I always wondered why for some stations we have a strange form of coverage: sometimes we get hi-res data, but in many cases just legacy format. And there was no obvious pattern recognizable why this is so. My initial suspicion was that this was just an artefact of some data feeds which we have no control over, so have to live with it.

This manifested itself most visibly in Russian radiosonde ascents, but - as we later found out - has affected data from many other countries as well.

Following an in-depth exchange with helpful friends in Russia, it became clear we better search for errors in our software. I detected a smell in a central piece of code, and Filip came up with a key improvement in no time flat.

I very happy to have that mystery resolved.

You can probe yourself:

• Hohhot ZBHH (China, WMO id: 53463) - visible in hi-res since two days, no previous data
• same for  Lhasa ZULS (WMO id: 55591),  Ezeiza Aero SAEZ (WMO id: 87576), Neuquen Aero SAZN (WMO id: 87715)
• Bechar DAOR (Algeria, WMO id: 60571) - hi-res now, previously only legacy format
• all Russian stations are hi-res now AFAICT
• ascents distributed via NMC Denmark and Meteo France als improved in quality


I am pretty sure this service is now best-of-class as far as publically accessible sources of radiosonde ascents worldwide go!

https://blog.mah.priv.at/release-announcement-windy-plugin-radiosonde/

Thermal top: The top of the thermal reached, for the selected parcel temperature. This is indicated by the top of the green line, following the dry adiabatic lapse rate.

Should convective clouds form (thus the isohume line from dewpoint and dry adiabat line from surface parcel intersect, the lapse rate will follow the moist adiabat line), the Thermal top then equals the cloudbase. The CLD top will then indicate where the evaporating parcel stops rising

the radiosonde backend is essentially a database which maps a station ID to a series of radiosonde ascents tagged by time
the station ID is assumed to be globally unique, assigned be the WMO, and hence can be used as primary key.

Or so goes the theory.
In practice, all sorts of junk data comes in, like this beauty

search for 'station_id' and well... its just blanks. And there went the primary key.

The code has been fixed to skip such stations, so we have to live without Tunis/Carthage for now until they fix things there.

Another problem creeping up from time to time is: there is no single, well curated source of WMO station information; there are station lists kept by different organisations in varying degree of accuracy and state of rotting. And sometimes those entries are plain wrong - for instance, wrong coordinates.

this manifests itself by a circle on the map at location X, and when you click it, the trajectory shows up elsewhere on the map.

If you find such a station, please file an issue or pull request against this file.

thanks

• MIchael

several station locations have been fixed

A big thankyou for your work putting this plugin together. 👍😁

This plugin just went up another few rungs. And I noticed you have plotted the 1000hpa level wind/temp on the skewt when this is not available on the main window viewer....bonus.

Thankyou (big time)

all the frontend polishing is done by the formidable Mister @rittels !

and no, there arent any known existing bugs since @rittels fixes them so quickly, so it's all Heisenbugs ;)

@stitch Go to extra settings -> select wind display , select Numeric

re sondehub realtime data integration: that was always planned and I'm in contact with the sondehub team since over a year towards that end.

From an integration perspective it looks reasonably straightforward. However, server side things would not be as easy as the current radiosonde backend which is basically serving static files. Also, data quality is an issue - data from sondehub might not be validity checked as the data from meteo aggregators is.

Currently this backend service is running on my hosted server, and its future is undecided as of now.

• Michael

😳 Oops. Thank you for picking that up.

To the development team that put together this plugin "windy-plugin-radiosonde"....top shelf - great effort!!

From a Prof Met's perspective....this is a very useful tool and one I only recently discovered and now use continually....so a BIG thanks!

One issue: could you take a look at the numerical wind speed values within the Skew-T diagram when you mouse over a level. It appears the numerical values are displaying speed in metres/sec when there is a knots value displayed. For comparison, the wind barb notation is correct in units of knots.

Eg

Wind barb is ~60kts....numerical wind speed is 30.3 m/s (and not kts as displayed). Could you correct the numerical value to "knots"?

Otherwise, great work! Highly appreciated.

PS: If you could incorporate real-time sonde data (during the balloon flight) from Sondehub into the Skew-T diagram up until the completion of the sonde (with the data then replaced by completed sonde data - as currently displayed), then that would be a GOLD medal in my books.

Regards,
Stitch

Thanks, I have removed altitude values from AROME, more honest than using calculated values.

Thank you. I fixed the flat skewt a few days ago, but another bug crept into extra settings. Will fix later.

@mhaberler

Hello, I'm not sure if this belongs in the Bug reporting topic or on here but ever since about a week or so ago, both the forecast and observed soundings look very compressed vertically compared to what they used to look like, no matter what web browser I use. Has this been intentionally changed recently?

I've attached a couple of before and after screenshots to illustrate my point: