Barback relies heavily on pumps. Might even say they’re required. And pumps need motors. You can probably guess where this is going… motors need drivers.

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.

The Barback was a smashing success for fact it was banged out over little more than a weekend hackathon. It’s been to dozens of parties, served countless cocktails and has been on several bike rides. It’s never been recharged, the straps are falling off, in addition to always having been a bit janky, and the code has barely been updated. So it’s time for Barback V2.

I’ve been working the design for V2 for quite a while but never felt ready enough to move onto CAM. The whole thing is designed in FreeCAD, using a combination of Part Design workbench and Assembly 4. This combo works really well for my design and fabrication style. All my parts are ‘flat pack’ designed, where everything is oriented the same way, as if it will be cut from plywood…. because it is going to be cut from plywood.

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!

The groundwork for getting started on this project was laid out in this 2018 EEVBlog forum post. In it , Luiz Renault suggests the data rate is 512kbit/s based on the smallest pulse width. My results before vary slightly but should be in the same range.

The minimal bit length looks to be ~1.740us, not far off Luiz’s 1.960us that can be seen in the scope shot in the second post. So 512kbit/s seems like a reasonable rounding point. Luiz also indicated they were able to decode the data, but not what the content looked like. There was also no indication of byte size, start/stop bits. So more digging….

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.