Observations definitely fell off a cliff as commercial air travel slowed to a crawl. In terms of impact, though… it turned out not to be a big deal.
> Aircraft reports suffered a 75% decline in numbers from mid-March to mid-April 2020; in May the number started increasing again. Despite the loss of data there is no clear signal in the forecast skill—partly because the skill shows considerable variability on daily, seasonal, and interannual timescales (Figures 3 and 4). …
> …
> Overall, we can find no evidence that the decrease in aircraft observations has handicapped numerical forecasts of extreme weather to an extent large enough to incur significant economic impact.
Glad to hear something's being done with the data from the weather radar most commercial jets have. The thought occurred to me about halfway through reading the blogpost.
I hope that data's available publicly, though likely not as publicly as ADSB broadcasts.
My last EV used 22 MWh over 6.5 years. That works out to 390W.
My solar array is located at high latitudes (northern Minnesota), the mounting angle isn't great, it's occasionally covered in snow, etc. In these conditions, I need 6.3 solar panels to produce 22 MWh over 6.5 years.
The area used by 6.3 solar panels -- enough PV to cover _all_ my EV's energy needs -- works out to be a parking spot large enough to fit the vehicle but not large enough to fully open any of the doors.
I've had great results with N100 mini PCs including Power over Ethernet. Here's an N100, PoE, 2.5GBASE-T, case, 8 GB RAM, 128 GB SSD for $129 refurbished:
Great suggestion, I'll keep an eye on this. Not sure if this is 802.3af, or 802.3at, or even 802.3bt. I wouldn't want to upgrade the switch for this alone.
The S100 product page gives me this brilliant description :).
> The processor Intel N100 is the perfect home for the architects of Gracemont and the perfect combination of processes and processes, 7 d'Intel, 4 cores and 4 threads, maximum RPM at 3,4 GHz, 24EU and graphite centroids and TDP. seulement 6 W. La consommation and production of chaleur It’s the perfect place to be. It’s a great deal, it’s a process, it’s N5105, it’s N100, it’s a sign, it’s augmentation, it’s maximum CPU, it’s 500 MHz, it’s L3 cache, it’s 2 MB.
> A station authorization shall be automatically terminated in whole or in part without further notice to the licensee upon:
> …
> (d) The failure to maintain 50 percent of the maximum number of NGSO space stations authorized for service following the 9-year milestone period as functional space stations in authorized orbits, which failure will result in the termination of authority for the space stations not in orbit as of the date of noncompliance, but allow for technically identical replacements.
_Congress_ can change this, but as written, Federal law compels the FCC to automatically terminate the authorization for failing to deploy half the satellites under 47 CFR § 25.161(d), just as they must automatically terminate the authorization when the license expires under 47 CFR § 25.161(b).
Bureaucrats write what falls under the CFR. Congress writes the US Code. Unless there is something in the US Code which specifies the period in which the licensee must have 50% of the satellites in place, the bureaucrats can change the rules in the CFR. Somehow I doubt Congress was that detailed. They likely just passed the buck to let the bureaucrats specify the details.
ESPHome fills much of this niche for me. It's a framework for turning YAML device definitions into custom microcontroller firmware, with myriad supporting tools. The official device database at https://devices.esphome.io lists 554 devices but that's nowhere near the end of it.
Most manufacturers bolt on IOT functions by dropping an off-the-shelf module onto their device-specific board. It's sometimes possible to replace the factory firmware with ESPHome, sometimes even using over-the-air updates. For example, AirGradient air quality sensors: https://github.com/MallocArray/airgradient_esphome
Even when it isn't possible to commandeer the factory IOT module, the fact that it _is_ a module is still useful, because it's almost always possible to inhibit or remove the factory module and connect your own instead. The factory IOT module controls and senses the device, so your replacement module can too, using the same pins. For example, an IOT air filter: https://github.com/mill1000/esphome-winix-c545#final-assembl...
Some devices are designed around multidrop communication busses. These are usually even easier, since the ability to join the bus is an intended design feature, even if the device you're using is not intended. For example, many Samsung residential HVAC systems: https://github.com/omerfaruk-aran/esphome_samsung_hvac_bus/d...
GFS and IFS are both medium-range global models in the class Google is targeting. These models are spectral models, meaning they pivot the input spatial grid into the frequency domain, carry out weather computations in the frequency domain, and pivot back to provide output grids.
The intuition here is that, at global scale over many days, the primary dynamics are waves doing what waves do. Representing state in terms of waves reduces the accumulation of numerical errors. On the other hand, this only works on spheroids and it comes at the expense of greatly complicating local interactions, so the use of spectral methods for NWP is far from universal.
You're right, and in fact S3 does this with the `ETag:` header… in the simple case.
S3 also supports more complicated cases where the entire object may not be visible to any single component while it is being written, and in those cases, `ETag:` works differently.
> * Objects created by the PUT Object, POST Object, or Copy operation, or through the AWS Management Console, and are encrypted by SSE-S3 or plaintext, have ETags that are an MD5 digest of their object data.
> * Objects created by the PUT Object, POST Object, or Copy operation, or through the AWS Management Console, and are encrypted by SSE-C or SSE-KMS, have ETags that are not an MD5 digest of their object data.
> * If an object is created by either the Multipart Upload or Part Copy operation, the ETag is not an MD5 digest, regardless of the method of encryption. If an object is larger than 16 MB, the AWS Management Console will upload or copy that object as a Multipart Upload, and therefore the ETag will not be an MD5 digest.
https://datatracker.ietf.org/doc/html/rfc7725