No, I'm not. AFAIK there has been years of regulatory wrangling between Starlink, Kuiper, OneWeb, etc. about who gets which orbital shell. Shells aren't yet as scarce as GEO slots but companies are already planning for a future where they might be.
For these large constellations, vehicles are generally raised slowly at the beginning of their lives, and debris spreads out as it decays downwards. A significant increase in debris at 550km would have an impact on all orbits below it, including all vehicles raising through that debris zone.
> A significant increase in debris at 550km would have an impact on all orbits below it, including all vehicles raising through that debris zone
Space is huge. Try this trick: the number of satellites in orbit is about the same as the number of planes in the air at any time. (~12,000 [1][2].)
The volume of space from the ground to 50,000 feet is about 200x smaller than the volume from the Karman line to the top of LEO alone (~2,000 km).
Put another way, we approach the density of planes in the sky in LEO when there are milliions of satellites in that space alone. Picture what happens if every plane in the sky fell to the ground. Now understand that the same thing happening in LEO, while it occurs at higher energy, also occurs in less-occupied space and will eventually (mostly) burn up in the atmosphere.
Put another way, you could poof every Starlink simultaneously and while it would be tremendously annoying, most satellites orbiting lower would be able to get out of the way, those that couldn't wouldn't cause much more damage, the whole mess would be avoidable for most and entirely gone within a few years.
There are serious problems with space pollution. Catastrophic Kessler cascades that block humans from space, or knock out all of our satellites, aren't one of them.
> The volume of space from the ground to 50,000 feet is about 200x smaller than the volume from the Karman line to the top of LEO alone (~2,000 km).
Volume is the natural way to assume space scales, but it's incorrect. Two planes can fly parallel, side by side. Two satellites cannot orbit side by side.
In the limit, if Earth had a solid ring of infinitesimal width, it would take zero volume but all orbits.
Yes, it’s absolutely a trade off against prop (argon) lifetime, energy spent thrusting, and atomic oxygen degradation of plastic components. The benefits of increased drag for these shells of thousands of vehicles must be worth it.
+1, if only for the documentation. If you haven’t, skim through it: https://pip.raspberrypi.com/documents/RP-008373-DS-2-rp2350-... it’s truly unlike any reference manual I’ve ever read. I will happily pay a few extra cents at modest volumes for a chance to get the detailed technical details and opinions from the design team.
Adafruit is pretty clearly the front-runner these days in the educational/hobbyist market, Arduino (and even SparkFun) have fallen by the wayside. My only gripe is the focus on micropython these days, it can introduce a barrier later in the learning process when you eventually need to leave the nicely organized sandbox. They still support the “Arduino” C++ libraries, but uPy is the default.
Adafruit actually focus on CircuitPython which is a fork of Micro Python but takes some of the complexity of Micro Python away. I don't personally like coding in C++ as I started my career with Perl then PHP and Javascript. Writing Python in my own choice of text editor instead of the Arduino IDE is much more my style.
A couple of weeks ago, I bought a 'sensor kit' from Amazon for my son to use with his Raspberry Pi. It includes some input devices (e.g. button, moisture sensor) and output devices (e.g. LED) that can be plugged onto breadboard.
In my experience LLMs can code C++ for the Arduino framework pretty well these days. The mistakes they make, like wrong pin numbers, are pretty language agnostic.
I’m not sure why the age of majority in the region of the server would be relevant. The user is not traveling to that region, the laws protecting them should be the laws in their own region.
I don't know if "should" is intended as a moral statement or a regulatory statement, but it's not at all unusual for server operators to need to comply with laws in the country in which they are operating…
Kudos for making this exist, it was an inevitable place for the conversation to lead, and I’m actually glad it was “hacked” together as a project rather than forced into a consumer product.
The camera specs don’t really matter here, this is about having the conversation. If this catches on, it will be a feature of every smartphone SoC.
On one hand, it’s a cool application of cryptography as a power tool to balance AI, but on the other, it’s a real hit to free and open systems. There’s a risk that concern over AI spirals into a justification for mandatory attestation that undermines digital freedom. See: online banking apps that refuse to operate on free devices.
The fact that this is the most appealing option is an indication that our electrical system, both equipment and code, are failing to address people’s needs. If you get a quote for a hybrid (on and off grid) system, they’re absolutely unaffordable.
High voltage, low RDSON FETs are (slightly) more expensive, and these products are cheap. A better design would use a higher-voltage rated input switch with poor (slow) switching performance, like an IGBT. Don’t design critical infrastructure around EcoFlow hardware.
Fujitsu, which sells MOSFETs for this application, writes: "Firstly devices should be rated at 600V or 650V, as this will generally provide more than adequate protection against the threat of high voltage transients."[1] That's a nice big safety margin. It should hold until the voltage monitoring shuts the whole thing off.
Not seeing UL certification on this thing.
If we're going to have US protectionism against China, a good first step would be to require UL-type testing, carried out in the US, on all imported electrical devices that run on more than 12VDC or contain a battery chemistry capable of thermal runaway. Electrical safety is a solved problem if you can keep people from cheating.
The voltage ratings of the MOSFETs used for 220/230/240 V applications have been increased over the years.
Decades ago, when bipolar transistors were used, they were rated for 350 V, which is barely enough for 220 V + 10%.
When everybody started to design universal converters usable for 220/230/240 V, the ratings were increased to 400 V. The first power MOSFETs were also rated thus.
Then there were too many converters destroyed by random voltage spikes, so the standard ratings were increased to 500 V. That proved to still be not enough in many places over the world, so the ratings were increased to 600 V or 650 V, already many years ago, in order to make extremely unlikely the destruction of the transistors by voltage spikes much greater than the nominal mains voltage.
600 V or 650 V is used for converter topologies where the transistors see only the peak input voltage. For converter topologies that use fewer transistors, but those see peak-to-peak voltages, the rating of the transistors must be 1200 V.
For 650 V, gallium nitride FETs are the best available devices, while for 1200 V or higher voltages silicon carbide transistors are the best. Silicon transistors are the best only for ratings much lower than 100 V, but they may be preferred also at high voltages for being much cheaper.
My understanding is that mosfets themselves are usually not UL certified/listed. I recently did a UL certification of a power supply and the IGBTs we used were themselves also not UL certified. The UL certification was more about the overall system design.
reply