Sign inRegisterCheck connection

WD-Live as a Data View of the Latest Packet

WD-Live as an HTML data view of the latest observation packet: named fields on a page, refresh cadence, and why refresh is not the sample rate.

Back to Historical weather observations and forecasts

Weather Display Live is easy to remember as a moving console. This URL was the other product: an HTML data view of the latest observation packet—fields on a page a person or a parser could read without a plugin. The scientific question is what those fields represent, and how often the page is rewritten, versus how often the instrument sampled the air. Refresh is a publishing interval. It is not a sample rate.

The historical TNET Weather page /weather-live.php used the heading WD-LIVE Weather Data and the same hub navigation as the station dashboard (Basic Stats, Forecast, Day Stats, WD Live, Doppler). A recovered capture formatted on 25 April 2005 preserved the chrome and almost none of the field list. That emptiness is a reminder, not a live feed: this address is not a Mesa meter, and it is not the Flash movie.

Historical context

Weather Display wrote compact realtime files (clientraw.txt and companions) and offered two public faces for them. One was WDLive, a Flash SWF that polled those files and drew gauges. That console is documented at /wdlive.php. The other was an ordinary web page that printed the same latest packet as labeled text or a table. This URL was that page.

The split mattered even in 2005. A visitor on a browser without Flash, a screen reader, or a later archivist who saved HTML rather than a .swf still needed the numbers. A data view is the packet made visible. A console is the packet made kinetic. They can disagree in time if one refreshes and the other is cached.

Adobe ended Flash Player support on 31 December 2020. The SWF path died as a runtime. The data-view path did not, in principle: clientraw.txt is still a text file. This article stays on the HTML side of that split.

What a packet data view is

A data view lists the latest decoded fields with names, values, and units. It is closer to a METAR or a get-text bulletin than to a dashboard collage. It should not include a seven-day forecast, a radar thumbnail, or month-to-date climate except as clearly separated extras. Those extras belong on /weather.php. This page’s job is the latest packet.

Minimum field set for a WD-era packet view:

  • Station identity (name or public ID).
  • Observation timestamp inside the file, with zone.
  • Air temperature and unit.
  • Humidity, if present.
  • Wind speed, unit, and direction (calm stated as calm or zero with unit).
  • Rain increment or totals with an explicit period.
  • Pressure and unit (and whether it is reduced to sea level).
  • A missing-data representation for any field the file left empty.

Secondary fields—dew point, heat index, solar, UV, indoor probes—may follow if labeled. Derived indices are not extra sensors. Forecast strings that WD sometimes emits are forecasts. They should not occupy the first screen of a page titled “Weather Data.”

The ClientRaw parser article maps file columns. This page is the human-readable projection of the current row. The current-conditions table is a styled, often broader grid (today’s highs, system stats, sun and moon). Keep the data view thinner: one packet, one time.

Refresh versus sample rate

Three intervals still get collapsed into the word “live.”

Sensor or radio sample rate. How often the hardware emits a new value. That interval is a property of the instrument and link. A Davis-class suite, for example, updates on its own radio cadence regardless of whether a website exists.

Logger archive interval. How often the station writes a climate sample. Daily max/min and NOAA-style monthly files usually come from this archive, not from every radio packet.

Page refresh / publish cadence. How often Weather Display writes the realtime file and how often the HTML data view is regenerated or meta-refreshed. WD documentation treats realtime FTP of clientraw.txt as an operator setting, typically seconds to about a minute, matched to the console refresh when a console is used. That setting is not a sampling theorem.

A data view that auto-reloads every 30 seconds can still show a one-minute-old packet. A data view with no auto-reload can still be scientifically live if the observation time in the file is recent and disclosed. The honest live label is now minus packet time, printed on the page.

If a refresh returns the same payload—same internal timestamp, same values—no new observation arrived. Reloading the HTML is not new weather. Empty fields are missing, not zero. Zero is legal for wind and for a rain increment; it is not a stand-in for “the file did not contain this field.”

How the data view should fail

A console can hide failure behind a frozen needle. A data view has no excuse. Show:

  • File missing or unreadable. Not the last good table.
  • Parse error / unexpected field count. ClientRaw layouts change across WD builds; a silent column shift is a false observation.
  • Stale packet. Age above a stated threshold (for example, several times the expected publish cadence).
  • Clock disagreement. Packet time behind page-render time by more than the cadence; or packet time in the future.

The current-conditions article defines the record contract (ID, time, units, sensor list). The data view is where that contract is easiest to audit because there is little layout to hide behind. If the view omits units, it fails the contract even when the console’s gauge face implied them.

Do not interpolate across a gap to keep a sparkline smooth. A data view is allowed to show a hole. Climate files and weekly tables handle missing days; the live packet should handle missing minutes the same way.

Distinct from the Flash console and the hub

/wdlive.php is the near-real-time console: gauges, poll loop, why Flash died, what a replacement must disclose. This URL is the field list of the same latest packet. Link them; do not clone them.

/weather.php is the dashboard architecture: stats, forecast, radar, live as separate panels. “WD Live” in that nav should point here (data) or to /wdlive.php (console), not paste forecast and Doppler into the packet view.

/get-text.php is a prose bulletin. A WD-Live data view may be almost as linear, but it is organized as named fields from the realtime file rather than as one spoken sentence. Both need units and a timestamp. The bulletin’s audience is low bandwidth. The data view’s audience is “show me the packet.”

Practical checklist

  1. Read the realtime file; do not screenshot a console.
  2. Print packet time and timezone above the fields.
  3. Print latency; fail visibly when stale.
  4. Name each field and its unit; label derived fields.
  5. Document page refresh as an HTML or FTP setting, separate from sensor cadence.
  6. On identical successive payloads, keep the old time; do not bump it to “now.”
  7. Keep forecast and radar off this page.
  8. Do not treat the 25 April 2005 chrome capture as a live Mesa feed.

Modern relevance

Live weather in a browser is still a publishing loop. Connection-intelligence work that consumes public weather fields needs the same disclosures: which packet, which time, which unit, how old. TNET’s how it works page is the modern, non-formula explanation of using atmospheric evidence as one family among others—not as a flashing gauge that proves a sample rate.

Observation hub: /legacy/observations/.

Sources