The flickering is solely a result of cost cutting in the power supplies of these LED lights. The problem is totally solvable with a constant current switching power supply. But the filtering circuitry adds cost.
The problem is that consumers usually cannot know this about a particular light (or a lot more) at the point of purchase, so even if you are willing to pay a premium for this you cannot.
I would pay a premium for longer life, and at least in some cases (e.g. lights I read by) for better quality. How do I do so? I would love to be pointed at sources of better ones (in the UK).
In the EU, lights have to be sold with a mandatory energy efficiency label. A lesser-known component of this is that this label includes a link to a standardised datasheet, which includes things like flicker metrics, CRI, chromaticity, and a measurement of the spectrum.
It doesn't fully quantify the light, but it's good enough to distinguish trash or even passable lights from actually good ones.
tl;dr: Just buy Philips UltraEfficient (I think these are roughly equivalent to the infamous "Dubai Bulbs"[1]) or Ultra Definition bulbs. They cost a little bit more but will probably pay for themselves over the years.
Buy name brands with a history of putting out decent bulbs instead of the Amazon alphabetsoup brands that won't be around in 5 years (although TBF some of my cheap BogAo bulbs are still going strong after 8 years). You can get a good feel for the light's "quality" by looking at the CRI and color temperature.
For CRI, anything 90+ is good.
For temperature, IMO around 3000k is the sweet spot. go higher if you want sterile operating room vibes or lower if you want super yellow/orange cozy hobbit hole vibes.
Heh, funny how personal preference differs. I find 3000K to be just slightly too harsh on my eyes, and prefer 2700K for everywhere except perhaps the bathroom mirror lights.
2700-3000 are honestly both fine by me. I just feel bad for people who go to Amazon, search "light bulb" and buy some random sponsored result that's 5000K
Hi thanks!
Sure, certainly!
I also want to eventually add some physics-based levels for fun, with like a box2D sim interacting with the circuits (with N circuit ticks = 1 box2D "tick"), or even little games on top of the circuit, but I need these tutorial campaigns first otherwise the step curve is way too high.
Unfortunately not really, but we've found (and used in production for a year) that Claude 3.5 is perfectly capable of identifying anomalies or other points of interests in very large sets of time series data.
Think of 100-200K worth of tokens formatted like this:
<Entity1>-<Entity2> <Dimension2> <ISO 8601 time +1> <value>
The only pre-filtering we do is eliminate "obviously non relevant" data, such as series where the value is completely flat the whole time, but this was done to add more data to the context, not because Claude struggled with it (it doesn't).
There could be a few benefits to what is proposed in the article, here are my semi-educated guesses.
1. Less dependent on local geology. Geothermal wells are well suited for hot, non-pourous (?) geology.
2. Might be cheaper. It can take years to drill the wells for a closed loop system (e.g. Eavor), less for a fracked geothermal well (e.g. Fervo). I imagine drilling a single borehole for this is way simpler.
3. Less water loss. Fracked geothermal well wells can be pretty lossy (20%?). If water supply is an issue your options may be limited.
200W at 300g is realistic for a modern BLDC motor. The article states that Maxon was the motor supplier so they likely used the EC-4pole series, I'm guessing it's one of these.
It's 30mm diameter to fit in a down-tube, 200W, and 300g. But just because it's 200W doesn't mean you have to run it at maximum capacity, there's no reason you couldn't run it at 5-50W.
'var' is JavaScript's older variable declaration construct. Variables created this way are live from the beginning of the function that contains them (or globally if there isn't one). So a block with braces (such as you'd use for a for or while loop body) doesn't actually restrict the scope of var `v` below:
console.log(v); // <-- v is a variable here, we can access its value even though it is only declared below
// prints 'undefined'
{
var v = 1;
console.log(v); // prints 1
}
console.log(v); // prints 1
You used to (and might still) see a workaround to recover more restrictive scoping, known as the "IIFE" (Immediately Evaluated Function Expression): (function () { var v; ... code using v here ... })() creates a function (and thus a more restrictive scope for v to live in) and evaluates it once; this is a sort of poor man's block scoping.
`let` and `const` were created to fill this gap. They have block scope and are special-cased in for loops (well, `let` is; you can't reassign to a `const` variable so nontrivial for loops won't work):
console.log(l); // <-- throws ReferenceError: l is not defined
{
// pretend the console.log line above is commented out, so we can reach this line
let l = 1;
console.log(l); // prints 1, as expected
}
console.log(l); // throws ReferenceError: l is not defined
// ^^ l was only in scope for the block above
Fun(?) fact: it's not technically true that const can't be used in for loops:
for (const i = 0; i > 0; ) {
console.log('this is stupid');
}
let ran = false;
for (const i = 0; !ran; ran = true) {
console.log('this is also stupid');
}
reply