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.

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.

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. Additionally one of the goals I had was a battery backed computer that could be semi-permanently mounted in my truck.

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.

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.