Ricohote? Ricmote? It's a remote for a Ricoh GR II camera.
Adobe Portable Document Format - 55.96 kB - 08/16/2019 at 02:28
My last post may have seemed a bit doom and gloom but thankfully it hasn't stopped progress. Aside the soft power switch not working everything else on the board looks good. Power, battery charging, the button and the APA102 LED are all working as expected. With that I decided to press on with firmware and some usage testing before moving onto a rev2 hardware. I was able to bypass the power switch by tying the VIN net to PWN_EN and use the ESP32 deep-sleep. I've yet to get around to checking any sort of power consumption, but on 500mAh it seems to at least 3-5 days, it's a bit hard to tell where the dead battery starts and the firmware bugs begin.
This is the first board I went through and convinced myself I had shorted and fried the ESP32. Turns out I'd connected TP_EN, which is the ESP32 EN pin instead of TP_PWR_EN, the AP2112 EN pin. Ah, labels. Works fine. Once I've progressed the firmware a bit more I'll give one of them to a friend with the same camera.
Currently the firmware is pretty basic and mostly based on what I came up with while sick in bed earlier this year. The original purpose of the firmware was photogrammetry, it turned a 360 servo and snapped a picture. I never got around to making the model but did realize this would make a handy shutter. But the HTTP client part was a nice starting point.
I knocked together a small demo showing it's present state.
The button press wakes the ESP32 from deep sleep. First thing it configs the WiFi and starts scanning. For now the AP info is provided by Kconfig but later will be setup via Bluetooth. If the AP isn't found, subsequent presses of the button will initiate a scan again. After a minute it goes back into deep sleep.
Once a connection is made pressing the button will send a shoot command to an HTTP endpoint on the camera. So far I haven't been able to find a complete documentation of the API end points but the web app was fairly easy to pick apart. At some point I'll probably write some script to pick out all the important strings.
I'm mulling over several ideas for the next hardware revision. I'll probably use a single specialty component for the power switch but not sure yet. I still want to see what my deep sleep power consumption really looks like. I'll probably add a P-Chan MOSFET on the LED power pin to ensure it's not consuming any additional current. Otherwise I'm pretty happy with the rest of the board.
In the meantime I plan to keep plugging away at the firmware. First up will likely be multiple button press and long press for different functions. I'm unsure what long press will do yet but my first though it toggling between the pre-defined custom modes. The longer term plan once enough of the API is covered I'll start working on the BLE interface. With that in place the button functions will be able to be changed on the fly. Another alternative functions I have in mind is time-lapse triggering. Something the camera doesn't provide. A long press could bring the remote into time-lapse mode, then a single press would start and stop it triggering.
Welp, that's it for now. Next update will probably be on the rev2 progress.
I did end up populating one of the boards the other night and for the most part things went pretty smoothly. I'm please to say the #SOICbite Programming/Debug Connector Footprint worked brilliantly and will keep moving forward with it on this board, even if (likely) another revision is required. I even managed to have the clip on and all the wires connected on the first try! Flashed the ESP32 on the first try! I used my #ESProgrammer, which is showing all sorts of problems of it's own but is working...
So... onto the problems... First is a problem in selection for the SOICBite. The way I was thinking about this was, it's a programming interface, break out the things the ESP32 needs. The EN/IO0, TX/RX, 3.3V and Ground. This made flashing easy but, also that I could not test major parts of the board. I have a couple major power nets, VIN for example, is the combination of VBAT and VBUS (USB), switched by a P-Chan FET. The problems start with the fact I cannot test that part of the circuit.
What's worse is because I'm supplying 3.3V externally, testing the soft power switch has become increasingly difficult do to by the fact I have no idea what going on when I apply voltage to the AP2112 EN pin while there is already 3.3V on the output pin. In the little testing I've done so far, it does even appear power is flowing backward through the regulator. I've worked around this issue by not connecting the programmers 3.3V and connecting the USB cable for main power.
Boards arrived over the weekend but I haven't had time to solder them up. They look absolutely wonderful in the new @oshpark After Dark solder mask option.
Little video of my test circuit in action. I still need to do a little testing to verify that the button is actually functioning once the circuit is powered on, it appears a little flaky but that could easily be due to the fact I slapped the code together in roughly 5 minutes.
The circuit powers the ESP32 on which immediately pulls the button input pin high, grounding the P-FET via an NPN.
Link to PeerTube video for those (like me, but they're no emmbedable) that prefer to avoid YT.
Now that babies first Def Con is in the bag and I can slow a bit on #The Cacoffiny I want to revisit this project. Last I left it it was in pretty good shape but I've had a couple more considerations over the last month. The first is wanting to give #SOICbite Programming/Debug Connector Footprint a try and as I wanted to forgo the USB interface for this project anyhow it seemed like a good fit. That change was put in a couple weeks ago.
The other change I only thought of on my way home from Vegas, after listening to the latest Hackaday Podcast (#30). The discussion on the soon to be defunct Ama$on Dash got me thinking about soft power switching. I feel like this is a good fit, it could potentially go 3 or 4 weeks between uses, it doesn't need to do anything while not directly in use so why waste power on deep sleep at all?
The entire schematic has been uploaded but here's the relevant part. There's a somewhat janky Falstad simulation so I guess it'll work. Any thoughts? Has anyone else done a soft power switch with an ESP32? And being that I'm going to use this button during normal use, I'm guessing I should still debounce it but am having trouble figuring out how/where (in Falstad at least). I'm thinking a cap between BTN and R4 connected to ground should do but not 100% sure.