Ductapemaster

Water is being used to get heat from one place to another. The idea is being able to separate the heat generation and the heat extraction

If you were to remove the heat at a sufficient rate by, say, turning the lid into a heat exchanger, you would have a stable system.

Nope, it doesn't have to be open loop!

Example of such a system being used specifically for datacenters: https://blog.vantage-dc.com/2026/04/22/cooling-without-the-d...

Evaporated water is condensed, and in the process transfers its heat into another place that removes it. Another simple example is a pot of boiling water with a lid on it.

Evaporative cooling does not necessitate an open loop system

I usually smell it too. I've noticed its when they switch from the air handler provided by the jetway (big yellow hose) to the plane's onboard system. Perhaps there's some sequencing procedure that the staff is moving through too quickly trying to get the plane out on time, or it's just an acceptable amount of cross-contamination.

You're right, I was representing a best-case scenario with an intention to be inspiring.

And yes, the Android approach works too and I have done exactly that with Claude previously. The BLE dongle is however a platform-independent approach.

Quite possible transport is encrypted, but that can likely be overcome with some RE on the Android app. Given the price of this piece of hardware, it's likely recoverable with moderate effort. At least worth a try.

From my experience Fable will reject this request - its pretty trigger-happy with it's safety detector for reverse engineering, even if you push it on right-to-repair. However Opus 4.8 is more than capable of doing it, with a bit of guidance.

While I empathize with your feelings about lock-in, I encourage you to see that we live in an amazingly empowering era. I would wager that with $20 in credits for the LLM flavor of the week and and an equally expensive BLE-to-USB dongle (try the nRF52840 dongle), you will have the protocol reverse-engineered overnight. BLE protocols are often very low-hanging fruit for this type of effort.

Yes, it's annoying this stuff isn't open source from the get-go, but it has never been easier to open hardware up for yourself and others.

Nice work! Through efforts with Claude in the last few weeks, I have a working model of the actual wireless protocol between sensor and bridge, and have built a passive listener device to snoop on local traffic. I'm in the process of creating documentation for the protocol and would be happy to share what I've learned.

Shoot me an email at my username-at-gmail if you want to chat.

The 8266 has no flash readout protection, and the UART is exposed on a programming header. It was very easy to dump the firmware.

I looked into it and the channel sounding approach isn't yet ready. Will need the new iOS as well as some firmware work from Nordic's side.

No need — I simply plugged into the exposed programming header on the gateway.

The sensor has an Atmel SAMD part which I assume has the security bit set. I didn't need to dump that firmware directly as it exists within the gateway flash.

I am planning a write up once I get it working. I'd be happy to share.

My setup is a logic analyzer tap on the SPI bus between 8266 and the RFM69 on the bridge device to log raw traffic, and my secondary RX (ESP32 + RFM69) for over-the-air traffic.

Also, I have a gas meter sensor based on your work half-built on my workbench. I plan to set that up once I finish my Flume distraction. Great work, thank you!

Interesting timing, I have spent the last week with Claude reverse engineering the on-air protocol and I'm getting pretty close to building a secondary "listener" receiver that will collect measurements from my bridge + sensor pair locally.

To Flume's credit, it required me to dump the firmware from the bridge device's ESP8266 in order to extract my key. I didn't consider an approach like this article took, given I have direct access to the HW and there's no flash protection on the 8266.

Nordic has newly-released silicon that supports Aliro using Channel Sounding, meaning a UWB chipset becomes optional. Also, NFC is supported directly.

https://www.nordicsemi.com/Products/Technologies/Aliro/Produ...

This is cool! I have recently been building a "life admin" system that is focused around keeping track of bills and insurance reimbursements, and I am currently extending it to support a recipe database. My data model is markdown + CSV, but it has reached a point where a real database would be helpful. I'll check this out as it may be a good migration. Thanks for sharing.

In simple terms, this works by doing an XOR on the outputs and if they disagree, performing a fault recovery.

There's also space systems that use 3 processors and a majority vote for the correct output, but that's different.

It's not about the whole microcontroller having less than 64kB of memory - it's that each WASM module has a minimum memory size of 64kB, regardless of how much it actually requires. Also, if you need 65kB of memory, you now have to reserve 2 pages, meaning your app now needs 128kB of memory!

We're working on WASM for embedded over at atym.io if you're interested.

I use this app on all my Macbooks — it's great!

I've always wanted a Shaper Origin, but the cost and subscription fee required for accessing some features always turned me off. I don't need it for anything other than fun hobby projects and couldn't justify it. Now I get double the fun: building a tool, and getting to use it! Nice work.

Sadly, Useful Sensors seems to have pivoted to other edge AI tech and no longer sells this or their person detector.

I spent a LOT of time on this website as a 90's kid. One of many that inspired me to get an EE degree. Projects like this always felt like some incredible magic, and came with an artistic aesthetic that I find inescapably captivating. We've instead got little bits of black epoxy everywhere these days and it's just not the same!

Thank you (and the GP) for the correction! I'll admit this lesson came to me a decade ago and I am speaking to a rule of thumb I developed as a result. Time to update my knowledge banks.

On your note about capacitor sizes — at my first EE job, my boss taught me about capacitance-voltage derating[0] for ceramic capacitors and it was quite the revelation. There is a significant inverse relationship between the two, which no one tells you about in college!

I'm now very careful to pick ceramic capacitors with enough headroom on their rated voltage as you lose a lot if you're close to the rated value. This curve is dependent on the different ceramic types as well (C0G, X7R, etc). Cheaper ceramics have a steeper rolloff.

For personal projects I am very careful to pick higher quality ceramics (X7R if I can) and use caps rated to 2-3x my operating voltage. Likely overkill, but I'm not optimizing for cost at volume.

[0] https://resources.altium.com/p/voltage-derating-ceramic-capa...

I live in Alameda and this place is such a local gem. The owners are really genuine people too. Great place to spend some time!

They also own a whole warehouse out at Alameda Point filled with machines. I know they have provided some form of access to the public in the past, but I'm not sure what that looks like today.

As a former Fit owner, I wish I had thought of this! The AC was really bad. We did a lot of road trips and it really struggled out on the long desert highway stretches.

Just op-amps and FETs for the active components. The design from my memory was:

- To get position, 2 integrators were applied to an adjustable voltage representing gravity.

- The FETs were used to set initial states of the integrators.

- A comparator used to detect the table (y=0), flip the velocity and apply a scaling factor for restitution

The math was actually quite simple given its just the standard velocity equations — the challenge was in handling state changes in the electronics.

I looked around a little more and this video is a very close replica of what we built: https://www.youtube.com/watch?v=qt6RVrmvh-o

In my upper-division analog electronics class (the hard one), our lab project throughout the quarter was to build an analog computer that simulated the physics of a bouncing ball. Physical variables of the system were adjustable (gravity constant, coefficient of restitution, etc), and the ball was "released" by pressing a button. The output was viewed on an oscilloscope.

One of the hardest 10 weeks of my life, but also one of the most rewarding. Our team was one of the few that actually got it working in the end. I had to custom-make a gigantic breadboard to hold the entire circuit.

Today I still work in hardware, but mostly with digital circuits. While my analog knowledge has decayed over the last decade, that project and it's success gives me great confidence any time I have to deal with the domain.

If you want to take a look, here's a pretty similar project: https://www.analogmuseum.org/english/examples/bouncing_ball_...