A Wi-Fi-enabled power supply in AA-battery form factor. Originally designed for sex toys but has the potential for so much more!
To make the experience fit your profile, pick a username and tell us what interests you.
Current status of the Double-Oh: I assembled two of the version 3.0 PCB, and they both reboot themselves whenever I try to set the adjustable voltage above 1.8V or so. In addition, the ESP32-PICO-V3 feels like it's getting a lot hotter than the ESP32-PICO-D4 did, but I don't have any measurements to back that up yet. It may be that my firmware needs to be optimized for performance (it does; I should at least be using an async webserver).
So, it's pretty hard to hook up the Double-Oh to an ammeter or an oscilloscope while it's inside a battery compartment somewhere. Something I should have done a long time ago is to build an easy tool to collect key measurements. I'm finally making good on that.
This jig should let me try different loads, measure the IC temperatures, and monitor the current drawn by the load and the device as a whole. And, perhaps most importantly, I can keep a USB cable attached for debugging and serial logging. There are a couple nifty parts of the test jig that I'd like to emphasize. First, the TMP35GRT temperature sensors: there are four in total, pressed up against the underside of the PCB in the test jig. To lie flush with the PCB, they're placed upside-down in slots, like so:
Now how is the Double-Oh held in place? The system I went with works, but I don't like it very much. I could use some alternate suggestions!
Those arms holding the Double-Oh in place? They're Molex connector contacts with the bandolier strip still attached! They are intended for the PicoBlade, not...whatever this is. A removable test point secures it tightly enough to stop the Double-Oh from moving, while also letting me swing the contacts out of the way when necessary.
For measuring the load: the chip shortage compelled me to use the TMCS1100A4 current sensor, which has analog output and a sensitivity of 400 mV/A. Since I only plan to test loads between 0 and 1 Amp, that means the TMCS1100A4 output will in the 2.5-2.9V range—not great for an Arduino and
analogRead(). An op-amp stage should, hopefully, convert that to a 0-3.3V range that I can measure more easily. The sensors are being monitored by an Arduino Nano Every—well, they will be, once I write the Arduino sketch....
It’s been more than a year since I updated this space! The Double-Oh project was mothballed for most of that time, but there have been a few significant developments. Here’s a timeline:
Of course, the v3.0 PCB deserves a more thorough project log. The Pokémon Pinball thing might need its own log, as well. These will come soon! I've run into multiple mysteries on the v3.0 board that I'd love your input on. A new batch of PCBs arrives next week, so expect a writeup not long after that.
Earlier this month I did my second live twitter demo. I ran a poll on Twitter and let the vibrator intensity reflect the poll results. Likes/retweets made the vibrator turn on for 10 or 30 seconds, respectively. Here's the code. Here's the twitter thread.
It was a lot of fun! This experiment struck a chord with people, apparently, because the vibrations just kept on coming. I should have saved the "amount of time vibrated" variable to EEPROM, so I could replace the battery and keep going all night long, but sadly I didn't do that. Still, the project was interesting enough to get written up multiple times:
Two weeks ago I got the web interface working well enough to serve a webpage with guestbook. That was on PCB v2.4. Now, with PCB v2.5, we have voltage control! That's right, not only can you see the current level of the Li-ion battery, but you can control the output level of the double-oh itself! By default, it outputs approximately 1.5 V, like a standard AA cell, but it can go as low as 1.1 V and as high as 2.6 V! I am positively giddy that so much of the project is working as hoped. Up next: OSHWA certification, maybe?
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. UPDATE DECEMBER 28, 2020: the talk has slides and English subtitles now. Let me know if you are interested in translating the talk to other languages!
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.
Become a member to follow this project and never miss any updates