s_tec

Probably the pole, footing, and wages for the installation crew.

It seems to be a general principle: If AI is better than you at something, you use it. If AI is worse than you, you don't.

Each time the frontier models get better, I see another wave of AI doubters suddenly become believers. People say things like, "AI couldn't code last year, but now I use it for everything!" Interesting. Now we know how that the person who said this has the coding skills of a Claude Opus 4.5 or whenever the frontier was when they flipped.

Meanwhile, the rest of us keep using AI as simple tools, like the person in the article. I wonder how long it will take before computers can program better than me, and I flip too.

Location: San Diego, CA, USA

Remote: Hybrid preferred

Willing to relocate: No

Technologies: Electronic design (KiCad, Verilog, SPICE), Embedded Linux (U-Boot, Yocto, Kernel drivers), Full-stack web (TypeScript, React, CouchDB, PostgreSQL, Redis, RabbitMQ, Prometheus, Grafana, Docker), Mobile development (React Native, Android, iOS), Graphics (DirectX, OpenGL), Blockchain (wallets & related cryptography)

Résumé/CV: https://swansontec.com/resume.pdf

Email: hire-me@swansontec.com

I co-founded the Edge crypto-currency wallet in 2013, but my background is in electrical engineering. With 25 years of technical experience, I can lead high-performance teams to ship products across any level of the technology stack.

Nifty! I recently bought a RISC-V VisionFive 2 Lite SBC, which required a lot of mucking with firmware and talking to the U-Boot serial console before it would boot Linux for the first time. A tool like this would have been super-handy during that time.

On the other hand, I'm a low-budget hobby user. I like things that are cheap, easy, and hackable. It sounds like your product might be for more-advanced users? Or do all these fancy features stay tucked away until you need them? If you make your product cheaply, that might hurt profit margins, but it might also open up the low-end market. I have so many questions about the business side of this.

But really, I am most curious about the user experience. It's not super-helpful if learning the tool becomes its own project, so I'm hoping it's simple.

Edit: Oh, it's a software project. I thought it was a hardware project. My bad.

This is more of a compressed-air battery than a sand battery, except that the "air" is CO2 and it's "compressed" enough to cause a phase change.

Heat-based energy storage is always going to be inefficient, since it's limited by the Carnot efficiency of turning heat back into electricity. It's always better to store energy mechanically (pumping water, lifting weights, compressing gas), since these are already low-entropy forms of energy, and aren't limited by Carnot's theorem.

I don't know much about this CO2 battery, but I'm guessing the liquid-gas transition occurs under favorable conditions (reasonable temperatures and pressures). The goal is to minimize the amount of heat involved in the process, since all heat is loss (even if they can re-capture it to some extent).

Thermoelectric cooling is pretty inefficient, because the materials need to balance competing requirements:

- Good thermal insulator - Good electrical conductor - Good semiconductor

This is because the hot & cold sides are sandwiched closely together as a PN junction, so once you move heat from one side to the other, it just leaks right back. Mechanical cooling doesn't have this problem, because the hot & cold sides are separated by thin bits of tubing. This makes the thermal leakage a "minor annoyance" in a mechanical system as opposed to "literally the whole problem we're trying to solve" as it is with thermoelectrics.

One work-around is to stack lots & lots of thermoelectric coolers on top of each other. That reduces the temperature difference at each individual PN junction, which in turn lowers the leakage. That's what this team is doing, but using layers that are only a few nanometers thick, so they can fit dozens or hundreds of junctions in a single package.

I'm not an expert, but my understanding is that silicon really loves to be with lithium, which makes it a really energy-dense anode material for batteries. It's also cheap and abundant. The problem is that absorbing lithium causes silicon to mechanically expand, which quickly destroys cell life. The anode physically crumbles away with repeated charging and discharging.

These researchers have found a way to make a silicon electrode like a sponge, which helps with the mechanical problems. Their test cell has pretty "normal" degradation of 80% capacity retention over 1700 cycles, which is incredibly good for silicon. Normally it would be in the 10's or 100's, iirc.

This isn't the charging circuit - that goes in the charger. This circuit is responsible monitoring the state-of-charge (for that little LED bar graph on the front), disconnecting the cells if something goes wrong, and negotiating available current with the tool. It should also be responsible for cell balancing, but it looks like Milwaukee forgot to implement that feature (oops).

The videos at the bottom of the article have most of the details, since those dive into the communications protocols as opposed to the raw schematics.

This is an excellent idea! It would probably make the most sense to perform these adjustments on April 1.

I assumed the post title meant nanometers. Why? Floating-point rounding bugs. A nanometer is about 9e-15 degrees of latitude, which is right about where a double-precision floating point number runs out of digits. So, if a piece of software uses exact `==` equality, it could easily have a bug where two positions 3600 nanometers apart are seen as being different, even though they should be treated as the same.

React Native added auto-linking years ago, which solved the native dependency problems. Just `yarn add` whatever you need, and if it has native code, the the Android side will incorporate it on the next build. On the iOS side, you do have to run `pod install` to lock in the changes, but everything after that is automatic.

Use Expo because you like the extra features it ships with, but not because you have problems with native dependencies. The React Native built-in experience is pretty much perfect to start with.

Each OS process has its own virtual address space, which is why one process cannot read another's memory. The CPU implements these address spaces in hardware, since literally every memory read or write needs to have its address translated from virtual to physical.

The CPU's address translation process relies on tables that the OS sets up. For instance, one table entry might say that the 4K memory chunk with virtual address 0x21000-0x21fff maps to physical address 0xf56e3000, and is both executable and read-only. So yes, the OS sets up the tables, but the hardware implements the protection.

Since memory protection is a hardware feature, the hardware needs to decide how fine-grained the pages are. It's possible to build a CPU with byte-level protection, but this would be crazy-inefficient. Bigger pages mean less translation work, but they can also create more wasted space. Sizes in the 4K-64K range seem to offer good tradeoffs for everyday workloads.

Just because some people do bad things does not mean you get to paint the whole group with those crimes. Imagine if you had said, "Black people are criminals, because a black person robbed the liquor store down the street last week." We all (hopefully) recognize the deep racism in this statement!

Unfortunately, there are parts of the country where this type of racism is acceptable and even common. There as similar attitudes towards Catholics, due to America's history as a predominately protestant country. The formula is the same both way - pick a heinous crime from a few members, blame it on the group as a whole, and feel smug about yourself.

Nah. When I am taking a road trip, the last thing I want to do register an account for some random charging network I'm never going to use again (because I'm in a different part of the world). I just want to pay for my power and move on, just like I can pay for food or anything else on the trip.

When I am at home, I plug my car in and it goes on my monthly power bill. This is where the convenience matters.

I recently build my own a level 2 EV charger from an OpenEVSE kit. The heart of the charger is a big mechanical relay, which connects and disconnects the charging cable based on whether a car is connected. To control the relay, there is a small circuit board that communicates with the car, and also provides over-current, over-temperature, and GFCI monitoring. If any of these things go wrong, the relay will not close and the car will not charge.

The DC fast chargers include similar safety features, in addition to a big AC-DC converter. The DC power supply puts out several hundred amps at whatever voltage the car requests (usually 300V, but sometimes much higher). Normally, currents this high would require super thick & heavy cables, but DC fast chargers often avoid this using water cooling and active temperature monitoring in the cable. As the cable heats up from the excessive current, the charging equipment actively throttles the charging session to keep things from melting.

So yeah, there are a few mechanical things that can go wrong.

Please explain. I keep hearing this meme, but the arguments don't make sense. For instance, people will say things like, "New World Order wants us all to use electric vehicles so they can limit our movement!" This is backwards, though, because electric cars can plug in anywhere, but gasoline stations are much more centralized and easy to regulate. If I were the Global Elite, I wouldn't want people producing power on their own rooftops, storing it in batteries, and driving around with it. Green technologies seem to lower costs and increase resilience for the average person. What am I missing?

This seems like a good idea. We have used gas taxes for a long time, but electric cars don't pay this tax. If we want to pay for roads based on how much people use them, we will need to switch to something other than gas taxes. Odometer readings could work, but it's not clear how to get honest readings. Weight isn't perfect, but it seems like a less-bad options than the others.

The National Electrical Code contains the rules for this sort of thing, plus whatever extra rules your local jurisdiction adds. I bought a copy of the code itself plus an "Illustrated Guide to the National Electrical Code" to learn this stuff. There are lots of YouTube videos for electricians, by electricians. DIY channels can also be helpful, but they don't always follow code.

In my case, the local utility requires the electrical meter to be accessible (obviously) and to be a certain distance from the gas meter (obviously). Because of the way my house is shaped, there simply isn't room to move the electrical meter, so a sub-panel was the simplest option. Anything else would involve tearing open the driveway, which would be worse. It really depends on the situation.

I installed the solar first, which cost about $10k for parts, plans, and permits. I got quotes between $18k - $26k for the same-sized system professionally installed, so this was a great savings for 3-4 weekends of physical effort.

I don't know how much I saved on the battery, since I didn't get any quotes. The battery was vastly more time and effort, since I had to move my house onto that backup loads panel.

If you just want to shift usage, the backup panel may not be necessary. The Enphase batteries do support a fully grid-tied mode, where they simply connect to your main panel as a branch circuit. I'm sure other brands do too. This would be an easy DIY weekend project, as opposed to a months-long home re-wiring project. The Enphase mandatory training would be the biggest downside for using them here.

I like the distributed architecture. Each solar panel has its own inverter, as well as each battery. If I want more panels or batteries, I just add them in parallel with the existing panels or batteries. If a panel or battery goes down, the remaining ones keep working. Avoiding high-voltage DC also makes the project more DIY-friendly. The downside is that Enphase requires users to take online classes before they grant access to the installer app (easy but time-consuming).

Right now I have 3.8KW of solar and a single 3.3KWh battery. We are producing more than we use most months, so the solar is good but the battery is undersized. If we have an extended grid-down scenario like what happened in Texas, the system will mainly provide daytime backup plus a few evening hours. This is still better than nothing, and we can easily add more batteries as we have the budget.

I recently installed an Enphase home backup system as a DIY project (crazy, I know). The biggest problem with any home-backup system is moving the loads onto their own sub-panel. When the utility goes down, power needs to flow into the home, but not to the rest of the neighborhood. To do this, a switch needs to physically disconnect the utility meter from the main loads panel. If this isn't possible (such as when the meter is integrated into the panel), all the loads need to move to a sub-panel. This is the hard part.

Once the meter and main panel are separate, the various backup solutions become pretty similar. The disconnect switch installs between the two, with the solar and battery attached. Sometimes the disconnect switch + solar + battery are all in one unit (like the Bluetti EP900), while sometimes the solar inverter, battery, and switch are all separate units (like Tesla or Enphase). The Tesla switch and battery are sleek & glossy, but the inverters are ugly. The Enphase stuff isn't quite as shiny, but at least the boxes look consistent.

Performance-wise, the systems seem pretty similar as well. Most systems are around $10K for 10KWh of capacity, with somewhere around 6-9 KW of peak discharge rate. I imagine these prices will drop a lot over the next decades. If the battery becomes obsolete, just install a different system. Once the home is correctly wired, swapping the storage system should be pretty straightforward.

Well, that just makes it worse! OP strongly implies that there is no good variable-speed solution, but if the industry already has an assortment of products, what exactly are they even selling?!

Normal wiring is terrible, though, since it only supports turning the equipment on & off. If you have a variable-speed fan and variable-speed pumps, it would be nice for the thermostat to throttle those based on the load, but it can't.

If this company has a solution for variable-speed equipment, the best thing they can do is publish an open standard. Suppose the thermostat talks to the equipment over CAN bus, for instance, using a well-documented protocol. If they go out of business, anybody can hack together a compatible aftermarket thermostat.

A lot of solar equipment is already going this way, with batteries talking to inverters over open CAN bus protocols. As one of the biggest energy loads, the HVAC equipment should get in the game too.

I feel like this is an obvious idea, but we simply haven't had the 3D printing technology to make things like this before. Casting this using traditional methods would be extremely difficult. Nobody bothered making stuff like this, not because they never thought of it, but because it was always too expensive.

The main reason to keep hydrocarbon fuels in a green-energy future is for their energy density. Rockets and airplanes will always want the best density and weight available, and that’s hydrocarbon fuel for now, barring some order-of-magnitude battery improvements. Hydrogen rockets are a thing, but their tanks are huge compared to methane or kerosene rockets.

The same thing occurs with Web standards.

If some old IE version did things a certain way, even the most modern browser will want to do things in a similar way to remain compatible. Therefore, the standards bodies will try to reverse-engineer the existing behaviors and then create standards based on those. That way, modern code can simply follow the spec and remain compatible.

The HTML5 parsing algorithm is an example of this. Old browsers tried to "fix" broken HTML by guessing where things like missing closing tags were supposed to go. The HTML 4 specification never described this logic, yet it was there in the wild. The new HTML 5 specification made a point of reverse-engineering the repair algorithms and actually documenting them, so now everyone can be compatible going forward, both with each other and with legacy. Just follow the spec.

That would be a Mebimeter, according to SI. Whether or not this sounds silly is another issue.

I'm not the OP, but I'll bite.

For many species, males have a higher standard deviation across a variety factors. There are biological reasons for this, since males are more disposable than females for reproduction. Think of one rooster for a dozen hens - this is still a viable flock, even if the other roosters get eaten. Nature can experiment more with males simply because the stakes are lower, and sometimes those experiments are worthwhile. [edit: Turns out this is not true for birds, so I learned something!]

Now, if you have two normal distributions with the same average and area but a tiny difference in the standard deviation... well, let's not go there because the math is too politically incorrect. [edit: And besides, many other factors affect outcomes besides genetics, so I do believe we should keep policies gender-unbiased as a matter of principle].

The tangle fails to to the one thing a blockchain needs to do - prevent double-spends. Rather than give up their failed experiment once they realized it didn't work, the IOTA project instead set up centralized "coordinator" nodes to prevent double-spends, since their tangle data structure was useless.

Now, there are ways to build graph-like data structures that do prevent double-spends correctly. I believe both Hedera and Nano (formerly called RaiBlocks) have working solutions, for example.

The key is that not just anybody can create a block (or a graph node), as IOTA does. If anybody can create a node at any time, what prevents them from sending out contradicting messages? Instead, working solutions always involve putting some sort of asset at risk (such as currency or energy), so that if the block producer decides to make a contradicting statement, they pay a steep price. This ensures that there is a financial incentive to always work towards consensus.

If your team has invested a lot of time & energy into mastering the Javascript ecosystem (including things like Typescript), it makes sense to use the same language on the server side as well. Server machines are cheaper than good developers, especially if you can share resources between the backend & frontend.

As for Deno specifically, it's definitely closer to the "browser" way of doing things than Node is, which is super attractive. The main reason to stick with Node is the huge library ecosystem, but Node itself feels kinda weird & old, since the language has moved in a different direction while Node has remained stagnant (poor support for promises & ES modules, for instance).