The system which runs coolant over the chips can be closed but the part which uses an evaporative system to cool that is still open loop and vents water into the air, no?
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.
That's the problem, removing heat at a sufficient rate. Of course it can be done, but the most efficient way (in terms of cost) is just open loop evaporation.
I'm not a datacenter engineer, but I used to work in the ski industry. Snowmaking systems use vast quantities of compressed air. It works better if that air is cool. Blowing hot compressed air out of a snow cannon means the air temperature (wet bulb to be specific) needs to be colder to make snow.
Anyways, most air compression stations use water to cool the air, and then evaporative coolers to cool the water. The water is reused, but a ton (not sure of the percentage) is lost into the air. It's more or less a tower with a big fan on top, and water percolates down from the top, being cooled by the air as it goes. The water is then collected and pumped through the system again (but of course has to be always topped up to counteract what was lost to evaporation).
Anyways, long story short is it's most cost effective to just spray water into the air to cool water, as long as water is free/cheap.
Oh like one of those scenic cone towers like on a nuclear power plant?
Iiuc youre saying: its more cost-efficient to waste water using evaporative cooling so thats what we'll get, not that a closed loop with a heat exchanger is technically infeasible?
Exactly. A car is a closed loop system. Coolant (which is water with some chemicals) cools the engine, then the hot coolant flows through a radiator which transfers that heat to the air, and then it just keeps cycling through. If there's no leaks then no coolant is lost.
The above method could be scaled up to data center levels, but is less efficient in terms of energy usage and cost. Cheaper/easier to just spray water into the air and get "free" cooling that way, as long as you have a source of free/cheap water to replenish what is lost to evaporation.
I'm not a nuclear engineer either, but I assume this is what is happening inside of the big iconic nuclear stacks. That's just cooling water being evaporated off to keep it cool.
Closed loop is of course feasible, and closed loop with an evaporation step is also feasible, but open loop evaporative is the most efficient in terms of total energy usage (cost) and most cost effective in general, so that's what we mostly get right now.
You are adding an extra step though. Use a closed loop coolant and remove the heat from that coolant with the heat exchanger. Why would evaporation in between be more efficient?
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.
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.
There should be bounties for open sourcing drivers/apps like these and generally making 'clean'/better interfaces to hardware devices, now that it's so much easier.
Claude Code reverse engineered cheap (Android only) usb and wifi endoscopes here, wrote/flashed/hardware-in-the-loop developed python+arduino libraries, etc.
It's a completely new world.
@wpm, happy to fund the nRF52840 dongle if you want to try this + release code!
Have you released your reverse engineered endoscope camera work? It's something I've been thinking about doing myself, since the vendor apps leave a lot to be desired.
Is it really as easy as you say? I have one of these Casio watches and plenty of spare Claude credits. Wouldn’t mind doing this but no idea where to begin.
If you ask Claude how to do it, it might already give you some strategy that's reasonable (at least, it's good to see what it thinks)
Make sure to use Fable, and preferably have the Max plan (or plenty of credits)
LLMs can do very good work when they're unattended and optimize towards a goal that's unambiguous / for which you have a reference.
Generally speaking, in hardware, this means having a "rig" ie a testbed where the AI can send commands, observe output, and iterate on its own. You want autonomy, not babysitting (as much as possible)
In the case of this Casio watch, I would start by giving Claude Code context on what you're trying to achieve (read&decode messages sent probably over BLE, reverse engineer the protocol, get to a point where it can send valid messages itself). The goal should be a python/command line tool that can sniff packets, decode them, and send them. (step by step, starting with sniffing)
Get the nRF52840 USB dongle mentioned. Have Claude Code talk to the dongle. Ask it to list devices it sees. Ask it to see/detect the Casio watch. Use the proprietary Casio app and ask CC to record the sequence and decode the messages (explaining to it what you did in the app)
Also: have it do research - has this protocol been cracked/documented before? Is there an Android app for this Casio app which could be decompiled (usually more easily than the equivalent iOS app)?
Reach out if I can help - my offer for a dongle stands for anyone who wants to do this! It looks like a cool watch, it shouldn't be held hostage. :-)
Hi Greg, I am Claude Code junior specialist from Czech Republic and also huge Casio fan.
I've been ignoring all bluetooth enabled models in the past, since I had a lot of negative experience with proprietary apps (Sony Music Center, Ultrahuman etc).
This is not me first time thinking about reverse engineering products app, I love open hardware and I wanted to contribute to the community, but while doing my research (which Claude agrees with), I've figured out that it might not be as easy as I thought.
For example, Googles Fitbit Air is according to some encrypting its traffic in a way, that it reaches Googles Cloud first, unencrypts and then reaches the app itself.
How would you approach this issue? By the way, the dongle offer still stands? ;)
Offer still stands! email me (my email is in my profile)
When there’s a will, there’s a way :) I’m not immediately sure re Fitbit Air (that’s nasty if it’s e2e encrypted!), but… maybe it doesn’t pin the server certificate and you can intercept communications?
Seems like you would have fun reversing this! :) reach out!
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.
ble is just transport layer, if the actual data is encrypted, you can get nothing.
One of our device FW at first transmit raw data through gatt service, then folk at gadget bridge reverse engineer it, which does not sound good to stakeholder, so we have to encrypt the data between phone-device.
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.
yeah, my point is "1 night and $20 of Claude token" maybe not enough.
Also you dont really need the nrf52840 dongle if you want sniffing(Also unlikely to work after the pairing process is done), you can use btsnoop on Android phone to record data, then analyze it with wireshark.
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.
This isn't untrue. I had the same thought when I unboxed my Casio 3565 a week ago and learned that I had been bamboozled.
Except all I wanted was a watch that could 1. keep itself set correctly, and 2. ping my phone when I lose it. I didn't want a project. I have enough projects. I am drowning in half finished projects. They are stacked up to the ceiling. They threaten to crush me as I sleep. No more!
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.
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.
If you document this somewhere I'd love to read about it! I took the approach of sniffing the packets between the radio and mcu on the bridge board, got most of the way into reverse engineering that, then helped build this instead:
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!
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.
Are you saying Apple Wallet based unlock on approach can work with these chipsets without UWB? Current status of relevant uwb dev kits that does this is hundreds of USD and unavailable to purchase/out of stock since months. This repo works with common chips and I'm working on porting it out to ESP too (fingers crossed)
There's a massive update on what I've been working on in case it’s useful to anyone here working with UWB firmware with iOS/watchOS.
openaliro used the iPhone with a key in Apple Wallet to pair and range/unlock over UWB+BLE with the nrf5340DK + DWM3000EVB approach; it was kind of expensive and could be optimized.
I got the whole protocol to work with a DWM3001CDK ($20 chip).
The part worth posting here is the DWM3001CDK target. It runs entirely on a single chip, it has an nRF52833 with the DW3110 beside it, no separate MCU board, no messy wiring with a DWM3000EVB.
The single chip contains: the BLE peripheral, the Aliro reader, a Matter node and an OpenThread MTD and the full UWB ranging stack with a stock iOS/watchOS.
It also has mcuboot with DFU FOTA via BLE; all of this in 409KB flash and 125KB RAM.
The Matter node is hand-rolled, because chip fw does not fit the nrf52833. Tested it out on hardware: Apple Home provisional pairing with a live lock tile, walk-up unlock with the phone in the pocker (the Wallet animation plays) also the Apple watch, and DFU FOTA via Bluetooth. There are ports esp32 variants and nrf5340dk and also support for multiple NFC chipsets.
The code also has multiple nfc chipsets, nrf5340dk (how it all began), multiple uwb transceivers, some community support for AI Thinker BU04 chipset, as well as ports for ESP32-S3/C5/C6.
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.
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.
