A Wi-Fi-enabled power supply in AA-battery form factor. Originally designed for sex toys but has the potential for so much more!
February 2020 feels like a decade ago, doesn't it? Well, on Valentine's Day I gave a talk at my local hackspace, xHain, and it was filmed for all to enjoy! It's a weird feeling, presenting a project that's attributed to my fursona, but presenting it as my human self. That's part of the project, as I briefly explain in the video—exploring the intersection of intimacy (a face-to-face talk where everyone recognizes me) and distance (publishing the core of the project under a pseudonym). Well, here it is!
Unfortunately, there's no text transcript. If you want one, ask me and I'd be happy to transcribe the talk for you, but I don't have the right permissions to embed it in the YouTube video.
Progress on the double-oh stalled in March, as did everything else in my life. But now I'm sort of getting back to a stable place and I have a good progress report!
First, I'm pleased to announce that hardware version 2.4 basically works! A few days ago, I ran a demonstration on Twitter (slightly NSFW) and invited people to sign a guestbook served from my butt (no pictures, but still NSFW simply by association). And I should have done a better job sanitizing the guestbook comments, because...well, they were susceptible to HTML injection. In a historic moment for the field of teledildonics, I was rickrolled by HaD user [arturo182].
It doesn't fully work, mind you; it turns out that the factory-reset jumper and the battery voltage detector are both connected to inputs that can't be used when WiFi is on. This required mercifully minimal changes to the routing, but it does mean waiting for another batch of PCBs. I also want to make the variable voltage output go lower than 1.3 V (its current minimum), so the double-oh can trigger low-battery warnings if necessary. This requires tweaking some resistor values that aren't behaving as I expected.
On the firmware side, I was encountering a frustrating bug with the UDP libraries in PlatformIO. Switching to the Arduino IDE immediately fixed all the bugs, but GOLLY it's not very fun to code in the Arduino IDE.
The theme of this log is duality. The double-oh project on Hackaday has doubled in population! [Spatz] is a full collaborator now and brings with him a grand redesign of the double-oh: a 4-layer PCB, populated on both sides, with all kinds of protections and sweet new features. HOWEVER, I'm still working on my own design, a 2-layer PCB with components on one side only, because it's fun and I still think it has some merit. I've incorporated lots of [Spatz]'s work into the 2-layer design, but I'll let him discuss the major changes in a forthcoming project log.
Two developers. Two different designs. Lots of progress for double-oh in the year two-oh-two-oh!
The second OO works-like has been assembled and shipped! In 1-2 weeks I will receive it and, hopefully, get firmware-uploading working at last. So, what can I do in the meantime? Answer: redesign the entire right-hand side of my PCB!
Yup, I'm going to try and ditch the ESP8285 (and all the external components it requires).
The ESP32-PICO-D4 system-in-package IC is 7mm square. My board is 9mm tall. With all the routing, it just barely fits. But it fits! Admittedly, I had to do some sketchy routing where the thermal pad used to be, and I'm not sure it will work. See, here's what the datasheet specifies for the ESP32-PICO-D4 footprint...
...and here's what I did to it.
I have no idea if this is an acceptable design approach. If it isn't, then I think I have to continue using the ESP8285. However, if it works, it opens up a whole world of possibilities that the current OO design wouldn't achieve! That said, I probably won't pursue this further until I've got a functional ESP8285 prototype.
Please get in touch with me if you have experience with the ESP32-PICO-D4, or experience doing hacky routing underneath thermal pads!
As I said in the previous log, I got some extremely valuable assistance from HaD member [Spatz] who pointed out numerous flaws in my design. Most glaring: I was using an LDO to supply constant 3.3VDC, and an op-amp and a digital potentiometer to supply variable voltage to the battery output. This op-amp setup is only rated to source 60 mA, not even enough for the inexpensive vibrators (um, "eccentric rotating masses") I want to control! [Spatz] rightly said it was much more sensible to use buck converters.
[Spatz]'s suggestion was to do away with the digital potentiometer entirely: let the buck converter supply fixed 3.3V and 1.5V outputs, and use MOSFETs and PWM to simulate the range of voltages. This is an elegant, simple solution, but I want a bit more control. By keeping the digital potentiometer, I can set the PWM upper limit to any value between 1.2V and 3.3V. This way, when I PWM the double-oh output, I can control both the duty cycle AND the pulse voltage. There are drawbacks to this approach (having to use I2C, more power draw, more ways the circuit can fail), so I may still change this method. We shall see!
Other big changes: a small flyback diode (this proved extremely useful on the SMOL, I'm surprised I forgot it on this design), correcting the crystal oscillator footprint, and updating .gitignore so the repo actually includes my parts libraries. Let's call this hardware version 1.3 or something like that.
I've ordered a new WL prototype, to be assembled in Shenzhen instead of in my poorly-lit office. In the meantime I'll find a spot where I can rework the existing WL and at least try to get USB communication working.
I think the next update will be decidedly ESP32ier...
First of all, a huge thanks to Hackaday user [Spatz] for helping me out with the schematic! Soon I will post another project log entry describing all those changes from the original! But for now, some physical prototypes.
If you're unfamiliar with the term, a "works-like" (WL) prototype is a prototype that doesn't look like your intended design, but it has all the features you think are going to go in your intended design. It's usually large, easy to assemble, and easy to re-work where necessary.
I designed and ordered a WL board about two weeks ago. A LOT has changed in the design since then (more on that later). Still, it would be a good opportunity to sanity-check parts of the design and, hopefully, run some firmware!
...Well, the works-like doesn't work.
Big issue 1: can't upload new programs to the ESP-WROOM-02. This is discouraging because it's such a dumb mistake on my part. In my excitement to order this WL PCB, I completely failed to finish the design. Around the WROOM-02 module, I'm missing pullup resistors on EN and GPIO2, I didn't tie nRST to Vin, and I didn't tie GPIO15 to GND. And, since I laid out this board so badly, it isn't as easy to rework as it should be. While I was soldering on those connections, I knocked Q1 off the board. That's a teeny-tiny SC-70 package that will be hard for me to reattach. Sigh.
Big issue 2: LiPo charging doesn't work as promised. What is the deal with these MCP73831 modules? The datasheet describes what the STAT pin should do: turn an LED on when charging, turn the LED off when charging isn't happening. So how come my LED turns on when there's no battery plugged in? How come it stays on after the battery is fully charged? I built my circuit precisely like the datasheet specifies, with the correct resistance to match my LiPo's 1C charge rate. I even used their suggested value for the LED current-limiting resistor, even though it was WAY TOO BRIGHT. I don't know. Should I be using a different charge IC? I don't know where to begin diagnosing this one.
So, that's what I'm grappling with right now. There are enough design changes in the circuit that I'm not sure it's worth my time to keep re-working this poorly-laid-out PCB. I'd much rather pick up the pieces and build a friendlier WL prototype that incorporates the latest version of the circuit. Speaking of which, I'll post another design log soon describing all those changes.
Lots of hardware tweaks today! This is my first IoT project and I have a lot to learn. For example: I implemented code that lets you specify a fixed IP address, and connect your ESP module to your Wi-Fi network. I tried setting it to 192.168.1.35 and typed in my Wi-Fi SSID and PSK. The module connected to the network! Woo! Serial output confirmed it was serving my settings page at that IP address. So I tried browsing to it. And...I couldn't reach it.
I can't change the fixed IP without reaching the settings page, and I can't reach the settings page until I change the fixed IP! Short of clearing the EEPROM, there's no way to rescue that module.
So now I know how important a "factory reset" button is.
See those gold pads under Q2? If you short those while booting up the board, the system will load its default values instead of whatever you had configured previously. That's what I mean by "factory reset." It's a useful feature and I'll be sure to include it on future designs!
The question I've gotten the most is "Where does the LiPo go?" I hope this crude animation clears up how the parts fit together. Once the end-caps are in place, the entire assembly is 49.2 mm long and 14 mm in diameter. So tiny!!