I haven't benchmarked Bluetooth on these devices but have you looked at your uncompressed audio rates over WiFi? OP was asking about Bluetooth at high quality and low latency, which I don't think is a possible combo, hence suggesting another ESP32 if wireless is necessary. If it isn't, a wire difficult to beat.
ESP-NOW is another option to look at, which of course won't work to transmit to a phone directly but can do a point-to-point or multicast transmission between ESP32 devices. I've used it in some projects but not for audio, I couldn't tell you how much of a buffer would be needed to make that work smoothly.
Another option for OP, if the audio is being synthesized then the parameters could be transmitted rather than the audio samples themselves and do synthesizing on the receiving device.
Low latency in Bluetooth audio comes down to codecs and the best are proprietary.
If you want to really cut down latency and need wireless with hardware like this, you could use a second ESP32 and send your own bitstream between them.
The specs look great, will see how long it takes to get these as WROOM modules or on little dev boards; my two form factors of choice for Espressif devices. I'm also curious about the pricing, so far they've impressed me with how much more you get in successive generations at a similar price.
Nordic Semi, or maybe ST Micro. I've got an STM32WB on my bench at the moment with sensitive coulomb counting and it looks very promising but without all those radios. Of course with all those radios (ie, if you need LoRa on a watch... which is a design decision I'm also skeptical of) then Nordic has a good track record.
I like a good smart watch and I appreciate open source, but an ESP32 isn't a great pick when low power consumption is important and the device is going to be communicating regularly. I'm surprised LILYGO went that direction in a watch form factor.
My recollection is that a rocket design was scaled up from one that worked, by people who didn't consider how an o-ring should be loaded in order to function properly. They inadvertently changed the design rather than simply scale it. I don't think Feynman got this wrong either. His demo was because the justifications for flight were based on the fact that failure had a temperature correlation, and they had a model representing how damaged the o-rings would be.
The o-ring failure was a measurable consequence of the joint design failure. The data behind the model didn't go down to temperatures as low as that at Challenger's launch date.
For more inappropriate extrapolation to justify a decision: the data for the heat shield tile loss model was based on much less damage than sustained by Columbia (3 orders of magnitude IIRC).
Now they are looking at the same style of fallacy and don't even have a model based on damage sustained in flights.
Another parallel I haven't seen discussed here yet, though I haven't read all comments: I recall Feynman feeling like he was on the investigation panel as a prop, that the intention of the investigation was to clear NASA of any wrongdoing. They used a model, considered risks, etc. Feynman recognized the need for a clear and powerful visual to cut through an information dump and pull it to front page news. The invitation of Camarda to a presentation with a pre-determined conclusion has the same feeling. I don't know what Camarda can do to put it on a (non-HN) front page today.
I haven't kept up with Artemis development but I've read extensively about Challenger and Columbia. These two parts of the article stood out to me:
> Moon-to-Mars Deputy Administrator Amit Kshatriya said: “it was very small localized areas. Interestingly, it would be much easier for us to analyze if we had larger chunks and it was more defined”. A Lockheed Martin representative on the same call added that "there was a healthy margin remaining of that virgin Avcoat. So it wasn’t like there were large, large chunks.”
Followed by:
> The Avcoat material is not designed to come out in chunks. It is supposed to char and flake off smoothly, maintaining the overall contours of the heat shield.
This is echoes both Shuttle incidents. Challenger: no gasses were supposed to make it past the o-rings no matter what, but when it became clear that gasses were escaping and the o-rings were being damaged, there was a push to suggest that it's an acceptable level.
There was a similar situation with heat shield damage and Columbia.
In both cases some models were used to justify the decision, with wild extrapolations and fundamentally, a design that wasn't expected to fail in that mode /at all/.
I know the points that astronauts make about the importance of manned space exploration, but I agree with this author that it seems to make sense to run this as an unmanned mission, and probably test the new heat shield which will replace the Artemis II design in an unmanned re-entry as well.
You might dig into an operations research textbook, there are a number of problems solved with linear programming techniques which might make sense for your interface... In fact might be more intuitive for people that way and with commercial potential.
Ah sorry, I quickly edited that out of my comment! I had the video playing while posting, they were talking about a precursor project for embedded Flutter which this in some ways builds on, /that/ is running on the new RAV4.
One of the example uses given in the talk is 3D tutorials, which I could imagine being handy. Not sure I'd want to click on the car parts for it but with the correct affordances I could imagine a potentially useful interface.
It doesn't say Toyota anywhere on the page and they don't have a link to a repo or anything like that, so I was a little confused. But it is from /that/ Toyota (well, a subsidiary that is making 3d software for their displays) and there was a talk at FOSDEM about it: https://fosdem.org/2026/schedule/event/7ZJJWW-fluorite-game-...
Thanks for pointing it out. I actually use a plugin which rewrites search queries for custom "bangs" which I switched to after waiting for others to be fixed. I didn't realize that the same exists built in.
A surprising fact I /do/ know about DDG: they don't update bang searches anymore, which was one of my favorite differentiators. This feature adds a lot of utility to DDG as a browser default search engine.
You can search "!w Gabriel Weinberg" and it will open the Wikipedia article because of the leading exclamation mark and w. If a site changes their search url, you can submit the precise new pattern they should use for a redirect. If a new service pops up, you can use the same form to request a new search prefix. These form submissions could give someone at DDG an easy interface to verify quickly and approve or reject them.
These form submissions get ignored and have been for years at this point.
There are also Tuya zigbee devices and people have hacked local control of Tuya wifi bulbs to varying degrees. My best stuff is IKEA: their battery powered devices use AAA so I can throw in rechargeable cells and there isn't a ton of waste in CR2032s, and they make the only inexpensive Zigbee buttons I've seen that don't include a double-click (Rodret, not the very similar Somrig). The benefit there is commands are nearly instantaneous, rather than waiting for the maximum double click time before deciding it's a single click. The RGB bulbs don't have a lot of brightness to them in color modes, I wonder if that will change with the new products.
I've got a few locally-controlled wifi bulbs that I bought before seriously getting into home automation. They are Tuya white-label, I'm using the tuya-local integration. Since I can't do something like a zigbee `bind` they are fully network dependent, when they go I'll replace them with IKEA bulbs.
I agree Home Assistant still needs a nerd for setup and tinkering but the default dashboard is impressive and all of the functionality is outstanding.
Most of my current-gen IKEA switches will pop out from their steel cradles with normal button presses, because of the curved back of the switch and the curved cradle it connects to magnetically. They've thrown in die-cut double sided adhesive tissue in what I assume was an afterthought, which doesn't peel from one backer sheet in any of the packages I've opened... Maybe it's humidity or temperature sensitive? After a couple of drops on the ground, some internal plastic cracks and tactile response is lost. I ended up using my own double sided tape but it's not a good user experience. I would bet the new switches don't have a curved back, certainly they've had a number of returns because of this aesthetic choice.
I don't care at all about Thread vs Zigbee (this press release doesn't actually say Thread), beyond the very basics in smart home things you want a computer involved and at that point the way it communicates stops being a big concern. I strongly recommend Home Assistant on a low spec mini pc, beats a Raspberry Pi in ~every metric for this use case.
I've been burned by trusting Matter to mean broad compatability; my Aqara lock doesn't indicate how the door was unlocked over Matter despite showing up in their app, and this is after having to buy their Zigbee bridge because it won't connect to Zigbee devices from other brands. Even with Matter, home automation still needs a geek.
You've gotta count the cost of your time as negative for that to be true. The author built multiple ovens from scratch here, and every cooked meal could be done sooner if the temperature were higher.
ESP-NOW is another option to look at, which of course won't work to transmit to a phone directly but can do a point-to-point or multicast transmission between ESP32 devices. I've used it in some projects but not for audio, I couldn't tell you how much of a buffer would be needed to make that work smoothly.
Another option for OP, if the audio is being synthesized then the parameters could be transmitted rather than the audio samples themselves and do synthesizing on the receiving device.