I’ve been self hosting email for at least three years now, and since the start I’ve been wanting a particular feature. Many may remember years ago when Google announced how Gmail would start prefetching and locally serving up images. A feature that was announced as privacy protecting, but in Google classic fashion really just meant they wanted to increase the value of you data, by preventing other from also tracking it. Googles awful privacy track record aside, it’s still a pretty good idea. I wanted that feature. I wanted Dovecot to automagically fetch remote images to a local server and rewrite the URLs. This method had one particular downside, running a server and a small risk of someone randomly guessing image URLs. What I did end up settling on was… instead of serving them from my own server, I’d simply inline the images with base64 encoding, attached as a multi-part section.

Over the last couple of years I’ve been trying to build out more embedded UI projects. I’ve typically stayed away from this kind of coding, not only because I haven’t had too many devices with screen worth programming, but the dev cycle of UI development in C on and embedded device is >PAINFULLY< slow. I’ve wanted to start pushing more into MicroPython and LVGL to ease this pain, but it just doesn’t seem that it’s there yet.

This research deep dive was inspired from using my Dust Collector Remote . It works great, but after a year using it I’ve found the delay to connect pretty annoying. On bad days with a router misbehaving the 4 or 5 second delay while I’m waiting to turn a tool on can get frustrating.

This started getting me thinking about how it could be handled faster. I’ve used ESP-Now a handful of times and have appreciated it’s quick boot to ‘do something useful’ time. But in past projects, I’ve mostly used it as a raw socket and formatted my own messages. Wouldn’t it be nice to have MQTT infrastructure without the setup latency of WiFi or the complexity of BLE/GAP/GATT? I also spent some time dabbling with CoAP a bit this year and while it seems common to treat it more like HTTP, but when using features like Observe Resource it looks a lot more like MQTT or BLE Notifications.

Once you get to use a dust collector remote in someone else’s shop, your dust collector will not be the same. For me it was in a well maintained woodworking shop in a co-working space in Oakland, every time I was back in my shop at the museum I was irritated to not have it, frequently just leaving the dust collector whirring away contributing to my tinnitus and wasting power. Now that I have a decent workshop setup in my home it was something that had to be addressed, not just for the table saw and other tools but I wanted it to be able to be controlled by the CNC.

As I’m deploying more LoRa nodes I find myself needing a more capable debugging system. While at home I simply use an SDR connected to my desktop to ensure devices are transmitting as expected. In the field that is a loftier goal. I’ve tried using an SDR connected to an Android phone with limited success, this seems to just kill the battery more than anything.

Going to have a small batch of unpopulated PCBs available in the new OiT Electronics shop.

Selling these will help with a final revision of this PCB that will correct some of the mistakes that made manufacturing and bring-up too difficult to make continuing worth while.

Get one now!

I found myself in a conversation about ESP32 boot times. Specifically the time it takes from boot until user code can do something useful with an IO.

As this was something relevant to Richmote but I didn’t have any actual data I decided to do a simple setup to measure the results. My test setup consisted of two probes one connected to the RST line and the other to a random GPIO. The firmware would immediately setup the GPIO as an output and pull it HIGH. Nothing else.