Jns2183

So I'm almost done with 1993 and about 30%-40% finished overall with my NORTHEAST SNOWSTORMS VOL I & II PROJECT There are whispers volume 3 might be out this winter. When finished every snowstorm highlighted in Vol I & II book will have its on Special Portal. I pull in the narrative and analysis from Paul Kocin, Louis Uccellini, various other Scientist who have analyzed each of the storms I provide interactive reanalysis viewer, and laboratory. I try to hone in especially on what feature or part was meterologly interesting as well as local in depth narrative if at all possible, from those inside and around the storm. Mix in GIS NESIS sciring and snowfall maps, detailed co-op, cochras, spotter reports. If recent am trying to do a full 3D imaging and analysis of CCB band and hopefully a proper montage of its highlights. Hopefully by the end you'll be able to close your eyes and taste the storm. Sent from my SM-S731U using Tapatalk

http://CPAWEATHERLAB.COM/SWITCHBOARD.COM UPDATED UPDATED UPDATED **Climate divisions tab** This tab uses NCEI climate-division data: averages built from station observations for 344 regions of the lower 48, from 1895 to August 2026. No reanalysis is involved. - **Map a season across all 344 divisions.** Maps temperature, max/min temperature, precipitation, degree days or any Palmer index. You can map one month or season for one year, a list of up to 30 years averaged together, or a run of years. Show it as an anomaly, standardized anomaly, mean, rank or percentile, against a base period you choose. For precipitation and degree days, a season's value is the total, not the monthly average. For a season that crosses the new year, you enter the year of its last month; the page converts it to NOAA's first-month labelling for you. - **Time series for one division or state.** Gives one division's or one state's history from 1895, as monthly values or one value per year for a season. You get a plot or a plain-text table you can save. Anomalies are switched off for single divisions because NOAA's are wrong there; they work for state averages. - **Which divisions follow a climate index?** Maps how closely every division's seasonal values track one of 30 indices, such as ENSO, NAO, PNA, PDO, AMO or a plain trend. The index can lead or lag by up to 12 months or seasons. The slip tells you roughly how large a correlation has to be to stand out from zero with your number of years. **Daily & special tools tab** - **Follow a pattern through time (Hovmöller).** Plots time against longitude or latitude, averaged across a band you choose. It shows wave trains, blocking and the MJO moving. Data runs from 20CRv3 in 1836 through R1 to NCEP's operational analysis, which is current to within a few days. - **Regional event maps at 32 km (NARR).** Makes daily or 3-hourly maps from the North American Regional Reanalysis, 1979 to August 2026. You can frame the map on one state, like Pennsylvania, or a custom box. This is PSL's best source for recent events now that R1 has ended. The page asks for a 0.3° plot so the 32-km detail isn't smoothed away. - **Values at one point; find record days.** Pulls daily or 6-hourly values from ERA5, R1 or 20CR at a latitude and longitude, or from a daily climate index. It can plot the series or its distribution, or list the N most extreme days in a season (up to 300), or every day past a threshold. The page catches NOAA's bug where a western longitude silently becomes a point in Spain. - **Map where a field correlates with an index.** Makes a correlation or regression map of a seasonal field against an index, using any of 33 WRIT datasets. You can detrend both series and have the index lead or lag. It shows where a climate mode's influence reaches. - **Trace an air parcel.** Runs forward or back trajectories up to 15 days through reanalysis winds at one pressure level. You can add a box of neighbouring starting points to see how much the path depends on where it starts. Use it to see where a moisture plume or air mass came from. - **How unusual is a day? Distributions.** Gathers every day of a season at one point (from R1, 20CR V2c or PRISM precipitation) or at one GHCN station, and shows the distribution with its deciles and a fitted curve. It can also give the probability of a value you enter. - **Stratosphere–troposphere wave flux (EP flux).** Draws Eliassen–Palm flux arrows, with divergence or the implied acceleration, from R1 or ERA5, averaged over 1 to 30 days. It's the standard picture of waves driving the stratosphere, useful around sudden warmings. Sent from my SM-S731U using Tapatalk

CPA Weather Lab https://cpaweatherlab.com TAKE A TOUR!!!! https://claude.ai/artifact/3hPJ2tTBfYqULiavQzXZ7U#cf7995a2-237f Most people check the weather, see “60% chance of rain,” and continue living productive lives. I apparently took that as a personal challenge and built an entire weather laboratory to determine exactly where the other 40% went. CPA Weather Lab has live radar, satellite, river gauges, severe weather, surface observations, ensembles, climate records, storm archives, and enough historical data to turn a perfectly healthy interest in weather into something your family quietly refers to as “the website.” The forecast section is particularly useful if you enjoy watching certainty die in real time. Thirty-one GEFS ensemble members begin with roughly the same atmosphere and gradually wander off in different directions like relatives trying to agree on where to eat. You can watch the spread grow, compare consecutive model runs, examine precipitation and snow probabilities, yell at models that have personally offended you, and cackle at yesterday's model run once observational data arrives and exposes its lies. This is meteorology, where screaming “THAT IS NOT WHERE THE LOW IS GOING” at a computer screen remains technically unpaid peer review. And because merely yelling at numerical weather prediction models seemed far too emotionally healthy, there is forecast verification. The HRRR makes a prediction, MRMS observes what actually happened, and CPA Weather Lab keeps the receipts. Hits, misses, false alarms, bias, CSI, probability reliability, lead-time degradation. The model can confidently paint two inches of rain across half of Pennsylvania, reality can put it somewhere else entirely, and the next day we can gather around the statistics and quietly cackle over the evidence like deeply maladjusted meteorological raccoon goblins. Today's beautiful model solution is tomorrow's row in a verification table. Then there is the historical side, because sometimes today's weather is disappointing and you need to investigate whether people in 1914 were also disappointed. Harrisburg records stretch back into the 1800s, alongside snowfall histories, drought analysis, storm catalogs, climate rankings, station records, radar tools, and enough obscure meteorological rabbit holes to make “I'll just check one thing” a statement with absolutely no credibility. Nothing restores perspective quite like spending an evening researching a 117-year-old precipitation event because something about Tuesday's rainfall seemed suspicious. At some point I realized I had essentially become a weather raccoon: awake at unreasonable hours, digging through NOAA's enormous data dumpster with both paws, dragging home anything shiny labeled radar, reanalysis, snowfall, or precipitation, and then becoming strangely territorial when somebody suggests I probably don't need another dataset. The difference is that a normal raccoon eventually gets tired and leaves the trash can. I built search tools for mine. There are tools for examining radar coverage because apparently knowing that it is snowing is insufficient when you can instead calculate how many thousands of feet above your head the lowest radar beam is passing. There are river gauges because rain eventually becomes somebody else's problem downstream. There are weather-station tools because spending hundreds of dollars measuring rainfall naturally leads to wondering whether the rain gauge is lying to you. And there are climate tools for those special evenings when you would rather rank 130 winters than interact with another human being. CPA Weather Lab is also a web app, so if merely visiting this thing occasionally isn't enough commitment, you can install it directly from your browser on your phone, tablet, or computer and give it its own icon like a normal app. On Android you can install it through Chrome, on iPhone through Safari's Add to Home Screen, and desktop browsers such as Chrome and Edge can install it too. Then it opens full-screen, because apparently what your phone was missing was immediate access to river hydrographs, ensemble spaghetti, radar beam heights, and more than a century of evidence that Pennsylvania weather has been doing this nonsense far longer than any of us have been alive. This whole thing exists because weather refuses to behave like the tidy numbers in a forecast table. Models disagree. Gauges disagree. Radar misses things. Snowfall measurements become arguments. Rivers ignore county boundaries. Ensembles abruptly discover seventeen different futures. A model that looked brilliant at 00Z can become an object of ridicule by breakfast. And somewhere in central Pennsylvania, I will be staring at the screen yelling at it, then returning twelve hours later to cackle when the observations confirm that, yes, the lying bastard really did move the storm 150 miles. Instead of accepting any of this like a well-adjusted person, I kept adding datasets. So CPA Weather Lab is basically what happens when “I wonder what the weather is doing” goes untreated for long enough and the local weather raccoon gains server access. Now you can install the condition on your phone. https://cpaweatherlab.com Sent from my SM-S731U using Tapatalk

Tis the season where this will come in handy. A gift to the board, with plenty more to follow. Reanalysis Switchboard I put together the Reanalysis Switchboard as a friendlier front door to NOAA Physical Sciences Laboratory’s historical weather and climate tools. NOAA has an enormous amount of reanalysis data and some genuinely powerful plotting tools, but there has always been a slight assumption that the person using them already has a PhD in atmospheric science, knows what every dataset acronym means, and remembers which web form was designed sometime around the Clinton administration. I wanted something where a weather enthusiast could start with the actual question instead. The Switchboard lets you map a month or season, compare two datasets, examine individual historical storms at daily or 6-hourly resolution, analyze changes through time, make distributions and month-by-year heatmaps, run wavelet and autocorrelation analyses, and explore relationships with climate indices such as the NAO, PNA, ENSO, PDO and others. Instead of making you figure out which NOAA tool to use, the Switchboard asks what you are trying to do, determines which NOAA plotting system can handle it, checks whether the dates and variables are actually available, explains important limitations, and builds the request for you. The plots and underlying data still come from NOAA PSL. The Switchboard is basically the traffic controller. I also added a simple Dataset Guide because the alphabet soup gets ridiculous very quickly. It gives basic information about ERA5, JRA-3Q, JRA-55, MERRA-2, NCEP/NCAR R1, 20th Century Reanalysis V3, CORe and the other datasets, including their approximate spatial resolution, period of record, time resolution available through the site, what each dataset actually is, and why you might choose one over another. One example is comparing two famous East Coast snowstorms. I used the Switchboard to compare the Blizzard of 1996 (January 6–8, 1996) with the January 2016 blizzard (January 22–24, 2016). Both storms were analyzed using the same NCEP/NCAR Reanalysis 1 dataset, the same Mid-Atlantic/Northeast geographic area, the same three-day averaging method and the same anomaly climatology. That makes it possible to directly compare things such as the 500-mb upper-air pattern and precipitable water between the two storms without first downloading a reanalysis archive and writing a bunch of code. That is really the point of the project: give people access to some very powerful historical-weather tools without requiring them to earn another degree just to figure out which button NOAA wanted them to press. Reanalysis Switchboard: https://cpaweatherlab.com/switchboard/ Sent from my SM-S731U using Tapatalk

from the flight 93 memorial PEMN weather station cameras appointed right after that tornado warned storm that is coming towards. first picture is 7:10 717-20 thirds 7:30 this last one 7:40 station itself has one minute resolution so if you want to enjoy watching the live webcam I'll see one minute resolution weather station data have at it https://climate.met.psu.edu/data/pemn/?site=SMRS02&numObs=1440 Sent from my SM-S731U using Tapatalk

best ring of fire action I've seen in years and it's quite delayed from normal Sent from my SM-S731U using Tapatalk

Sometimes the hardest part of reading about past disasters is having enough imagination to truly grasp the power of nature. if you ever were curious about the Johnstown flood than go watch the video coming out today about Glacial damn flood in Nepal and China. Especially the one at the border with giant building that gets engulfed. Sent from my SM-S731U using Tapatalk

I love Hawaii for being at the same time a hydrologist nightmare and heaven. the duality of existence in 3 infographs Sent from my SM-S731U using Tapatalk

did you see some of the rain totals?? I downloaded a bunch of the networks and saw many 20" to 40" totals. Multiple hours of 2"-5" per hour rates. what's nuts is unless those gauges are weighing gauges, which only a few are, those totals are definite underestimates due to the nature of tipping bucket rain gauges when you have heavy rain and wind Sent from my SM-S731U using Tapatalk

I plan to do a whole series of posts in the next week but if anyone wants a little preview I did a big study of Schuylkill County climate and I plan to do the same one for each of the counties around here here is a link to the PDF. https://drive.google.com/file/d/1MHxIs3rJgobWYai4cVpQR4d_XyRf-hFQ/view?usp=drivesdk Sent from my SM-S731U using Tapatalk

Six Windows, Four Products, One Rainfall Puzzle in the Lower Susquehanna The clearest finding is that the Lower Susquehanna’s apparent wetness depends heavily on the time window being examined. Lancaster and Cumberland looked dry during the most recent seven and fourteen days, but abruptly became wet when the period expanded to twenty-one days. That reversal occurred because the twenty-one-day window captured a substantial rainfall episode around July fourth through July tenth, while the shorter windows missed much of it. By thirty days, both areas were closer to normal, while the sixty- and ninety-day periods still reflected broader background dryness. Schuylkill experienced a weaker early-July wet surge and remained comparatively drier over the longer periods. There was therefore no single honest answer to whether the region was wet or dry without first stating the dates involved. MRMS, PRISM, Stage IV, and IEM Reanalysis generally agreed on the broad placement of wetter and drier areas, particularly over the seven-day period and again by ninety days. Their seven-day accumulation estimates were fairly close, and their ninety-day totals converged to roughly ten and a half to eleven inches across the three forecast-zone domains. The most conspicuous disagreement occurred in Cumberland during the fourteen-day period. MRMS estimated about zero point eight nine inches of precipitation, while IEM Reanalysis estimated about one point two six inches, PRISM about one point two eight inches, and Stage IV about one point three six inches. MRMS was therefore describing a materially drier two-week period, not merely displaying the same rainfall through a different map resolution. The products disagreed more strongly about percent of average than they did about actual rainfall accumulation. PRISM frequently appeared wetter relative to normal even when its estimated rainfall total was similar to the other products. Over seven days, for example, PRISM showed Lancaster near ninety-eight percent of average, Cumberland near one hundred one percent, and Schuylkill near one hundred thirteen percent. IEM Reanalysis showed those same areas near seventy-one, sixty-eight, and eighty-three percent. This demonstrates that some disagreement comes from the climatological normal used by each product rather than from the estimated rainfall itself. Accumulation describes how much precipitation a product believes fell, while percent of average combines that estimate with the product’s own definition of normal. Examining only the anomaly maps would therefore hide whether the argument concerns the rainfall numerator, the climatological denominator, or both. The PACLIMATE station archive provides the observational context needed to determine which product was most accurate, but the station records must also be treated carefully. Stations such as Middletown-Harrisburg, Reading, Harrisburg Airport, Reading Airport, Cashtown, Newport, Mahanoy City, Lebanon, and Harrisburg Eight South-Southwest had little or no estimated precipitation during the recent one-year period and are the strongest starting points for validation. Other series contained many estimated days, including Landisville and the Lower Susquehanna Climate Division, where all three hundred sixty-five recent days were estimated. Those records remain useful for understanding and reproducing PACLIMATE behavior, but they are not equally independent gauge truth. The next analytical step is to mask the grids to the exact forecast-zone boundaries, extract each product at the reliable station locations, and calculate bias, mean absolute error, and root-mean-square error for every time period. Sent from my SM-S731U using Tapatalk

I need some feedback before a website page that's basically a report which is better a, b or c Sent from my SM-S731U using Tapatalk

I tested the “worst forecast summer ever” claim by verifying KMDT MOS guidance against routine MDT observations and comparing the same partial-season dates in every usable year from 2017 through 2026. The broad claim does **not** hold up. Using equal within-model ranks for GFS and NAM temperature, dew point, and wind speed, 2026 ranks **5th-worst out of 10** for both Memorial Day–July 15 and June 1–July 15. In other words, this season lands in the middle of the pack overall, not at the bottom of the archive. That does **not** mean the complaints were imagined. Dew-point guidance was poor, overnight-low forecasts were the real train wreck, and several NBS, NBE, and MEX temperature busts reached **15°F**. NAM wind guidance also had some ugly stretches. Meanwhile, daytime temperature guidance, heat-index guidance, and precipitation probabilities were comparatively solid. So this was an **uneven** forecast season, not a universal collapse. Bottom line: **2026 was not the worst overall, but it absolutely had some loud, memorable failure modes**. I attached the infographic panels below Sent from my SM-S731U using Tapatalk

@Voyager Voyager’s Tamaqua Weather Station: A 91-Day QC Autopsy Voyager was kind enough to point me to his station in Tamaqua, so naturally I reacted in the most restrained and proportionate way possible. I downloaded 26,090 five-minute observations, catalogued 67 nearby station identities, untangled duplicate names and aliases, built several reference networks, pulled Pennsylvania Mesonet and ASOS data, aligned PRISM to its actual observation day, extracted 2,184 hourly Stage IV precipitation grids, separated rainfall into storm events, tested nearby personal stations one at a time, and dropped the whole thing onto a 30-meter terrain model. At some point this stopped being “Does Voyager’s thermometer read a little warm?” and became a minor federal research program, except it produced results and nobody had to attend a webinar. The analysis covers April 22 through July 21, 2026, a total of 91 days. The basic method, or how far down the rabbit hole went The core record was the station’s native five-minute archive. I preserved the raw observations and rebuilt hourly and daily values rather than relying entirely on precomputed summaries. For reference data, I used a professional-tier group consisting mainly of four Pennsylvania Mesonet stations, two airport ASOS sites, and one Pennsylvania DEP station. I also tested six nearby personal or CWOP stations against that professional group to see whether they were trustworthy enough to join the comparison. Then came PRISM. PRISM daily data does not use the normal local-calendar day. Its precipitation day ends at 12 UTC, which is 8 AM during daylight time. My first daily comparison used local midnight and briefly suggested that Voyager’s rainfall had almost no relationship to regional precipitation. This would have been a remarkable meteorological discovery. It was instead a timestamp problem. Once I rebuilt everything using the correct 12 UTC boundary, the relationship became extremely strong. The atmosphere was acquitted. The clocks were guilty. I then added NCEP Stage IV precipitation. That gave me 2,184 complete hourly multisensor precipitation fields covering the study period. Rather than comparing Voyager with one arbitrarily chosen grid cell, I extracted: the nearest Stage IV cell, the median of the surrounding 3×3 cells, and the median of the surrounding 5×5 cells. That matters because a rain gauge measures one point, while Stage IV estimates precipitation over an area. Thunderstorms remain stubbornly unwilling to distribute their rain evenly for the convenience of spreadsheets. Finally, I placed the station and reference network onto a real 30-meter digital elevation model of the Tamaqua area. This allowed me to compare the statistical behavior with the actual terrain rather than merely saying “mountains probably did something,” which is the traditional Pennsylvania forecasting method. Finding number one: the station record itself is structurally good The native archive is nearly continuous and passed the basic physical and internal-consistency checks. I did not find widespread impossible temperatures, broken timestamp ordering, random cumulative-rain resets, or the usual assortment of digital woodland creatures that live inside personal weather station archives. There is, however, one extremely clear processing artifact. The final five-minute observation of each local day contains corrupted daily high/low and precipitation-rate information. Across the 91 days: the mean high-minus-low spread in that final observation was 24.4°F, the median spread was 25.2°F, 80 of the 91 days showed a spread greater than 10°F, and all 36 isolated rain-rate blips in the entire record occurred in that same final local-day bin. Every one of them. Once I removed that final observation from precipitation-rate analysis, no isolated rain flickers remained. The genuine rainfall events had coherent multi-interval structure. This does not look like a thermometer or tipping-bucket failure. It looks like the daily summary fields are being folded into the final observation during the local-midnight rollover. The fix is wonderfully simple after all the detective work: Keep the raw archive, but exclude the final local-day five-minute observation from daily high/low and precipitation-rate analyses. Cumulative rainfall totals appear to remain usable. Temperature: good at night, warm under sunshine and weak wind Voyager’s overnight temperatures behaved quite well against the nearby reference network. The nighttime temperature bias was close to zero. The station and surrounding references generally agreed around the morning minimum. The daytime behavior was different. The station tended to run warmer during sunny conditions, and the warm bias increased when the wind was light. Under strong sun and calm conditions, the difference was roughly three degrees greater than during dark or overcast periods. Daily maximum temperatures also ran several degrees warmer than the PRISM estimate, while daily minima were close to unbiased. The timing helps tell the story. Voyager’s station typically reached its afternoon maximum about an hour earlier than the surrounding reference ensemble. That is what I would expect from a sensor environment responding too directly to solar heating or poor ventilation. A simple calibration error would shift the temperature almost equally at noon and at 5 AM. That is not what happened. Therefore, applying one flat temperature correction would be a bad idea. It would improve some sunny afternoons and make the nighttime values worse. My interpretation is: nighttime temperatures are generally reliable, daytime temperatures should be viewed with more caution during sunny and calm periods, and any future adjustment should depend on solar radiation and wind rather than being a fixed number. Humidity, dew point, and vapor-pressure deficit also showed systematic differences and should be used conditionally. They are mathematically tied to temperature, so a solar-heated temperature sensor can spread its mischief into several derived variables. One biased input variable, many exciting downstream consequences. Software engineers call this efficiency. Rainfall: the gauge did very well This was probably the strongest part of the entire station. Across 2,174 eligible station–Stage IV hourly comparisons: Voyager recorded 10.96 inches, the Stage IV 3×3 neighborhood median recorded 11.12 inches, the difference was only 0.16 inch, and the total ratio was 0.986. The hourly correlation with the 3×3 Stage IV median was 0.930. For wet hours only, the correlation was 0.899. When I grouped precipitation into 36 storm events, the event-total correlation rose to 0.957. The cumulative event ratio was 1.012, and the median absolute difference per event was only 0.05 inch. Timing was also good: the median storm-onset difference was zero hours, the median ending-time difference was zero hours, 81% of storm onsets were within one hour, and 85% of endings were within one hour. The station became more reliable as rainfall intensity increased: during Stage IV hours of 0.01–0.10 inch, Voyager also reported rain about 72% of the time, from 0.10–0.25 inch, detection rose to about 94%, and every Stage IV hour above 0.25 inch was detected. In other words, the disagreements were concentrated mainly in drizzle, traces, and highly localized light showers. Moderate and heavy rainfall was captured very well. That is exactly the pattern I would prefer to see. Trace precipitation is where point gauges, radar estimates, hour boundaries, virga, and the general perversity of Appalachian weather all begin arguing. The spatial comparison was especially revealing: nearest Stage IV cell: 12.75 inches, 3×3 median: 11.12 inches, Voyager: 10.96 inches, 5×5 median: 10.11 inches. The gauge falls between a wetter nearby grid cell and a drier broader neighborhood. That tells me the remaining differences are not simply “the gauge is low” or “the radar is high.” The local precipitation field genuinely varied across only a few grid cells. I found no evidence supporting a universal rain multiplier. My conclusion is that Voyager’s cumulative and storm-scale precipitation record is trustworthy, with normal uncertainty during light and highly localized precipitation. One caution: Stage IV is a multisensor areal estimate, not divine revelation descending from the radar dome. It should not be treated as exact point-gauge truth. Wind: local, messy, and behaving exactly like wind Wind was the least transferable variable, which is not the same as saying it was bad. Correlations with the Pennsylvania Mesonet sites were reasonable for stations separated by several miles, while correlations with the more openly exposed airport sites were weaker. Wind-direction differences were often large. That sounds alarming until one remembers where Tamaqua is located. Voyager’s site sits in a valley environment surrounded by complex ridges. Wind near the surface is blocked, redirected, accelerated through openings, and occasionally sent down the wrong hallway by terrain and nearby structures. An airport anemometer on an open field and a residential anemometer inside Appalachian terrain are not measuring quite the same atmosphere. Demanding identical values from them would be like comparing traffic speed on Interstate 81 with traffic speed on a Tamaqua side street and concluding that one speedometer is defective. Voyager’s wind data is useful for: local wind trends, frontal passages, gust timing, calm-versus-mixed regimes, and what the wind is actually doing at his property. It should not be expected to match an airport or ridge-top exposure exactly. Terrain provided the physical explanation The station’s terrain cell has: a mean elevation of about 274 meters, or 900 feet, roughly 86 meters of local relief, an average slope near 7.7 degrees, a low topographic-position value consistent with a valley setting, and predominantly western terrain exposure. That terrain context matches several findings: 1. Nighttime temperatures were close to the references. Valleys favor cold-air drainage and nighttime pooling. 2. The daytime warm bias increased when it was sunny and calm. A sheltered setting can retain locally heated air when ventilation is weak. 3. Wind direction and speed differed substantially from open reference sites. Valley channeling and terrain blocking are expected. This does not prove the exact sensor-level cause. A digital elevation model cannot see the station’s mounting pole, nearby roof, fence, tree, radiation shield, or neighbor who planted an ornamental shrub in precisely the wrong place. But the terrain provides a physically credible setting for the observed behavior. Pressure, solar, and the remaining odds and ends Relative pressure performed very well and was among the cleanest variables in the comparison. I found no reason to change the current pressure setting based on this study. Solar radiation was useful mainly for identifying the temperature bias regime. The station’s available solar field behaved well enough as a timing and peak-intensity indicator, but it was not a clean integrated-energy measurement. I would use it for relative solar conditions rather than treat it as laboratory-grade daily energy. I made no soil-moisture conclusions about Voyager’s station because it does not have a soil-moisture sensor. I studied nearby network soil sensors as context, but eventually resisted the temptation to grade equipment that does not exist. Scientific discipline occasionally survives. Final verdict Voyager does not have a failed station. He has a largely strong station record with: one sharply defined end-of-day processing artifact, a daytime temperature and humidity bias that depends on sunshine and ventilation, precipitation performance that is excellent at the event and seasonal-total scales, wind measurements that represent his immediate valley exposure rather than a regional open-air standard, and pressure data that performs very well. My practical recommendations are straightforward: preserve the native five-minute archive, filter the final local-day five-minute bin from high/low and precipitation-rate work, retain the cumulative rainfall totals, do not apply a flat temperature correction, interpret daytime temperature, humidity, and VPD in the context of sun and wind, and treat wind as a local microscale measurement. After 26,090 observations, 2,184 Stage IV grids, several reference networks, corrected day boundaries, storm-by-storm scoring, and one digital elevation model, my conclusion is reassuringly ordinary: Voyager’s station is good. It simply lives in Tamaqua...... tis was fun Sent from my SM-S731U using Tapatalk

at least it won't be hot these next 10 days because it looks really dry Sent from my SM-S731U using Tapatalk

I don't see how we get any more than some light rain. Sent from my SM-S731U using Tapatalk

you're going to find with you heptic sensors that it has about five different rainfall capacities and the air percentage is sort of different for all of them it also matters how exposed to wind it is and eventually also the temperature aspect. the 17% is pretty much my air percentage over the last 90 days. I've been comparing the three gauges since April. if you really want to get into it the manual one has issues with undercatch and the tipping bucket when it rains hard as issues this rain will miss it when the buckets tipped this technically if you want to get exact there are percentages that they usually add depending upon the rain gauge. to find out those percentages and try to find rain gauges all different types of what the air rates were I could do not they probably spent worldwide millions upon millions of dollars and I have least have seen probably 84 scientific studies just based upon or engage measurements and it's to this day a very active field and a nightmare for everybody Sent from my SM-S731U using Tapatalk

Voyager, I don't know what networks your station is connected to but if you DM me your station info and at least 90 days of preferably sub hourly (most stations are network updated at 5, 15 or 30 minutes intervals) I can do a simple QC check based on actual published methods. For a basic 90-day quality check, I compare each weather station with about 6 to 10 nearby personal weather stations, ideally within roughly 5 miles, plus a reliable airport or professional station if one is close enough. For every hour, I calculate the median of the surrounding stations and compare the station being tested against that local reference. The median is useful because one bad or poorly placed station cannot easily distort the result. I then look at the average bias, which shows whether the station usually reads too high or too low, the mean absolute error, which shows the typical size of the difference, and the correlation, which shows whether it follows weather changes correctly. I also check for missing data, stuck readings, sudden jumps, unusual day-versus-night behavior, and repeated differences during rain, strong sun, or calm nights. The result gives me a practical estimate of whether the station is trustworthy, slightly biased but correctable, or unreliable for a particular measurement. that goes for anyone else as well. I have API setup with xweather, keystone Mesonet, NWS MADIS feed. I ran right to the pipeline knife and messing around with them this is what comes out at the end see attached Sent from my SM-S731U using Tapatalk

haha, tipping bucket. if you want I can get you the exact error measurements of heptic vs tipping vs manual gauge. heptic has about a 17% error vs tipping bucket 3-4% Sent from my SM-S731U using Tapatalk

it feels like a steam bath and a sun breaks out oh my God Sent from my SM-S731U using Tapatalk

these storms are tapping something. It usually doesn't thunder like this all morning Sent from my SM-S731U using Tapatalk

My air quality monitor finally paid of. I have it upstairs in my daughter's room. The 4.0 has been a bit worse than 2.5 and 1.0. regardless they have peaked in the aqi range of 104-115 inside Sent from my SM-S731U using Tapatalk

I’m offering to perform this same kind of MADIS-inspired quality-control and calibration analysis for other personal weather-station owners. The analysis can examine data completeness, outages, nearby independent reference stations, duplicate feeds, temperature and humidity bias, pressure accuracy, wind multipliers, rainfall performance, and solar or ultraviolet readings where available. I would need at least 90 days of timestamped station. and for now I would analyze a maximum of one year. At minimum, I would also need the station location and elevation, hardware and sensor models, siting details, and any correction settings or known equipment changes. Anyone interested can direct-message me with their station information and available data. TLDR...... I take your station’s historical data and compare it against nearby independent weather stations, airport observations, MADIS/Xweather records, and local climate data. I clean the records, remove duplicate or unreliable stations, identify outages and bad readings, then measure how your temperature, humidity, pressure, wind, rain, solar, and UV differ from the best available references. From that, I produce a plain-language report showing what is accurate, what is biased, and which calibration settings should be kept, changed, or verified. I've slowly build it out.I’d describe the system as about 80% automated at this point. I collect the station and nearby reference data, then the system automatically cleans it, removes duplicate or unreliable feeds, identifies gaps, calculates biases, and generates most of the comparisons. I still manually review unusual results, confirm the best reference stations, and decide what calibration recommendations are scientifically defensible, and not just giving your wind data witch craft spells so it matches KMDT better and doesn't require rooftop thuggery. Sent from my SM-S731U using Tapatalk

Just about 1" in 40 minutes Sent from my SM-S731U using Tapatalk

About to be some major convergence of cells Sent from my SM-S731U using Tapatalk