Solar charging ESP-Now BATMAN prototype 3

After the component selection failure with my last solar prototype, I resolved to have another go.

This time, I decided to build as close an equivalent as possible on stripboard despite the presence of several SMD-only components. For this I needed a QFN20 breakout and with the buck convertor, I used one of the first boards I had made, cutting off the large empty sections. The QFN20 was not fun to solder but it works.

I'm glad I went through this step as it showed up a poor selection of GPIO pins for the connection to the MCP73871 charge controller. My very first prototype used an evaluation board and not all the connections are broken out on it. Moving the status connections to the ESP8285 did what I wanted but dragged one of the pins low and stopped it from booting in some states. This is one of those things that again I should have picked up from reading the datasheets, but didn't.

With a little shuffle of pins, the prototype is ugly but seemingly nicely functional so I've dropped it into the shed to test. Late November is a bad time for solar power in the UK, so it's a bit of a 'torture test' of charging viability. It's quite likely to fail as I've not put much in the way of smarts yet about when it sleeps or switches off the radio.

In the meantime I've bought an ESP32S2 module and breakout adapter from a Tindie seller. I may build a second prototype based around this as the S2 is like an ESP8266++ with Bluetooth support and lots more resources without seemingly much more power draw. The extra GPIO pins won't be unwelcome too, the ESP8285 has few and I've ended up re-using the UART pins. Not a big deal but it means you can't have Serial debug info with the charge controller working and you need to rely on OTA updates after an initial upload of the code.

Update

This prototype ran for roughly 66 hours before the battery got low and it started sleeping in an attempt to allow the sun to charge them. That's plenty enough for my requirement of a full weekend's service.

However, from the logs it looks like it only spent 4 hours actively charging the battery, which is shockingly low even given its shady position in the low winter sun. As the MCP73871 only has three binary status indicators I don't feel I have enough data to be clear what contribution the solar panel was making to the runtime so I am going to modify this prototype and add an INA219 current monitor inline with the battery.

Recycling an old laptop into a Command Centre: Part 3

Having decided that Raspberry Pi Zeroes running the PiGFX bare metal kernel was the way forward with the small displays, I created some 3D printed 'backpacks' for the unit.

With the addition of some BNC to Phono adapters it works very nicely.

In order to talk to PiGFX you need to use the UART on the Pi Zeroes and I was going to homebrew something from cheap FTDI boards but then ordered some USB CDC boards from 8086.net. They're cheap and do the job perfectly and tidier than I'd have managed.

The 'backpack' mounts directly on the BNC socket and I think has come out quite tidily. In the very unlikely event somebody wants to do something similar, I've stuck the design on Thingiverse.

Development board LDO upgrade

During my work on the helmet camera project, I found that I was having a few brownout issues and occasional flakiness. At some point I found out that the 'low dropout' 3.3V regulator used on the ESP32-CAM development boards has a minimum dropout of 1V.

That's not a hugely uncommon minimum dropout but simple maths shows that a LiPo putting out a realistic 3.8-4.0V in use is not going to result in 3.3V supply to the board.

I put a multimeter on the Vout of the AMS1117 on an ESP32-CAM board and when in use for video streaming it was down around 2.9V.

In principle the datasheet says the ESP32 will operate at 2.3V but there are onboard 1.8V LDOs used to power PSRAM to take into account too. The datasheet recommends a 3.3V 500mA supply to the module unless you also provide separate 1.8V supply.

As it stands, the module is just not getting that from a 4.0V LiPo.

I had a look for a good solution but my component browsing failed until I was recommended the ST LDL1117S33R. It's pin-compatible with a minimum dropout of 350mV. They're not expensive parts so I took a gamble and ordered 100 as the AMS1117 seems to be the default LDO on many cheap development boards.

After a little bit of hot air rework on an ESP32-CAM to replace the LDO, I measured Vout in the same conditions and found a solid 3.25V.

While I don't know if this will help, it feels like it should improve stability under LiPo power and I know it will make a big difference to usable battery life. It has definitely cured the issue where the 'flash LED' on the ESP32-CAM would flicker while streaming and powered by a LiPo.

I may yet make a 'shield' for the ESP32-CAM that includes other components for the project and a buck convertor would be more efficient still but this is a good incremental improvement.

Transparent HUD using ST3375S SPI display: Part 4

I spent a little time with my 3D printer and soldering iron to make this into a more practical testbed.

As I've been working on the project, it's become very clear to me that trying to hold the screen in front of an eye while testing it just doesn't work. You just can't hold it steady enough and you end up looking at the screen rather than 'through' it, because it's moving. 

For the helmetcam project I've been making them to fit to a FAST helmet copy as they're a cheap standard piece of milsim-looking kit. So it made sense to do the same with the HUD. The bracket I've made sticks out too far to be safe walking around as you'd catch it on things, but it does a pretty good job of holding the screen in about the right place to work.

I did a little looking around with it fitted and I think I'm making good progress. You can see the image on the screen without it blocking your vision badly. It's blurred, because you're not focused on it but large icons and blocks are very recognisable.

However it doesn't work well enough yet, there are a few things that have obvious scope for improvement.

• I need a more appropriate test pattern than the Adafruit example code and to make it updateable OTA.
• The black frame is intrusive. I need to print it in translucent material, which I don't currently have any of.
• Shortening the PCB would help with clearance from my face and glasses. I have already desoldered the SD reader from the rear and I think I can simply saw a section off without cutting any tracks used by the display.

There are also some things I can't easily fix immediately, without buying another screen.

• The 'white' parts of the screen are a bit dark, so it doesn't work well indoors.
• The screen is a bit small, it really should cover more of the field of view.
• There is an area of permanent black round the edge of the usable display area.

I'm going to continue to slowly chip away at this over time as I still think the idea has merit, especially when tied into the camera and other communications gear I have planned.

Transparent HUD using ST3375S SPI display: Part 3

I spent a little time soldering up a Wemos D1 Mini to the transparent display and put it on the end of a tube with another little 3D printed bracket.

Nothing much new to see but it does make holding it out in front to look 'through' easier.

Tomorrow I'll design and print a bracket that will allow me to attach it to a helmet and play with angles and distance from my face.

The USB cable was just for convenient power supply, my plan is that the battery will be at the base with wires passed up the tube.

Recycling an old laptop into a Command Centre: Part 2

One of the things I want to do with this prop is have multiple screens. A primary one then the three small composite displays that used to be part of a video production setup.

With no way to slot extra display cards into a laptop, my first thought was to use a USB-VGA adaptor then a VGA-Composite convertor so I picked one up from Amazon for only £6. Even before purchase it was clear it would be a bit sucky over USB2, but that doesn't matter for a mostly text display.

It arrived and actually I'm quite impressed with it. Yes it only does 800x600x8 over USB2 but it does work (at least in Windows) even if it's not going to be any use for things like video. I can actually see myself using this with my laptop (which has USB3) for an extra screen. The messy thing is that it's not well supported under Linux, seemingly needing extra kernel drivers that don't work in current kernels etc. at which point I got discouraged. It also looks like you can only use one. Maybe. I plugged it into an Ubuntu 20.04 box and couldn't get any life from it but resolved to fiddle around with the drivers in a few days.

This got overtaken by serendipity when Hackaday reminded me of the existence of the PiGFX project, as used in the RC2014 retro computer. I'd not paid a lot of attention to it when it appeared as it just looked like a way to piggyback a Raspberry Pi Zero onto the board. Which it is, but I hadn't appreciated the software is a 'bare metal' kernel that stops it being a full Linux system and makes it into a 'dumb terminal' listening on the Pi UART and displaying on an HDMI or composite display. A quick play on my desk showed it looks the part, so I soldered up cables to the composite outputs of a couple of Zeroes and tried it with the small rackmount screens.

That's the hard part taken care of and while poking around the Pimoroni site ordering a Zero for the third screen I spotted 8086.net make a USB-UART shim specifically for them and they're cheap. This covers the other half of the job with a readymade board so once the parts show up I'll have three serial terminals connected to the laptop by USB.

There's a big overlap here with my work on creating a library for controlling this kind of terminal from a microcontroller, so coming up with code to drive them won't be new ground. It's a shame they're not full graphical displays but it will make them very easy to spit status info out to. If I need graphics I can go back to investigating the USB-VGA adapters.

Transparent HUD using ST3375S SPI display: Part 2

I had a go at fitting the light spreading film in the frame of the transparent screen. This is a really fiddly thing, it took several attempts to get the LEDs snug up to the film and everything in place.

The result is disappointing. In order to make the film spread the light well, it has a 'milled' surface. This means it makes the display less transparent as it blurs everything to more of an extent than I expected when you look through it. Then once lit, the milling creates a moiré pattern with the pixel grid of the display and makes the images look bad.

As you can see in this photo it does make the screen work in low light nicely but makes the display such that looking 'through' it is pretty poor. I'm going to abandon this idea.

Transparent HUD using ST3375S SPI display: Part 1

For some time I have fancied making a HUD (heads up display) of some kind, probably attached to a variant of the helmetcam project. Real HUDs or wearable displays that don't completely cover your face are hard, just look at how Google Glass didn't really take off.

Nonetheless it's a sci-fi trope and I fancy a go at it. My vague plan is a transparent display you look through and don't focus on, a bit like some kinds of gunsight. It's not going to be able to show text, but it may work for blocky colour coded contextual information.

To have a stab at this I picked up a couple of cheap 1.8" ST3375S SPI displays, commonly sold for use in microcontroller projects like weather stations etc. They're very cheap and I bought two, in case I broke one. Having a second intact one to code on will be useful too.

The first step is to peel the whole display from the PCB. It's simply held on with sticky foam pads and luckily on this specific board there are no components to be careful of, just the ribbon cable. A different module might not be the same though. I used a thin plastic scraper pushed slowly but firmly between the PCB and screen to remove it.

Once the screen is free from the PCB you need to separate it from the backlight. Luckily the white plastic surround is very thin and if you gently flex it this will unclip from the the screen.

The backlight is still attached to the ribbon cable so be careful not to rip it while you do this.

The LED backlight is inconvenient so I stripped it further. There are four parts, the white plastic surround, a thin piece of clear plastic film to spread the light, a thin white paper-like diffuser and the LEDs.

The first three parts are very lightly stuck together and you can carefully peel it apart until you're just left with the two backlight LEDs soldered directly on a section of the ribbon cable, which doesn't get in the way too much.

The bare screen is quite dark but when you hold it up to the light you can see the individual pixels which looks quite cool.

Once I'd got it to this point, I did a little measuring and 3D printed a surround to hold the screen safely while I tinkered. After an initial false start, I got the Adafruit ST3375S library example code driving the screen and as I'd hoped, big blocky images are quite legible while looking through the display.

The next step will be gluing a D1 mini to the PCB and point-to-point wiring it to the screen so I can play around with holding it in front of my face on a stick.

Without a backlight it's totally useless in anything but bright light. It may be possible to re-use the light spreading film and have the LEDs provide a little light on the display, for which I'll need to design a different surround for the screen.

Anglepoise repair

I found this lamp dumped in the street a couple of weeks ago and picked it up because it looked good quality. The last couple of days I decided to make a little project of repairing it, as I later spotted it was a genuine Anglepoise 1228.

There were a whole bunch of things wrong with the business end, including damage to the shade, but I 3D printed a new brim for it, fixed the bulb holder and electrics and gave it a general tidy.

The main damage seemed to all stem from the bulb holder plastic being made brittle over time, perhaps with heat from an incandescent bulb. I know they're much less common nowadays but you do still see them in use. I have some stored I swap in when the strobing of LED or fluorescent bulbs causes a problem and I like the light they make.

All the parts of the bulb holder were there but the fixing points had crumbled or snapped. It could be held together but none of the screws had purchase any more. Careful use of epoxy glue allowed me to (quite permanently) get it into one solid piece again. I had to pull the socket terminals out and carefully feed the wires through from the rear then push the terminals back in as it could no longer be unscrewed to get the necessary access.

With this done, I looked at repairing the shade. It's really tough laminated plastic, white inside, coloured outside and I've no idea how somebody snapped a section of the rim. It feels like it would need a full adult weight standing on it to break. I considered trimming the rest of the brim but I know my limitations and it would never have been a neat job. So I designed a pair of rings with a lip that 'sandwich' the original rim and 3D printed them in a contrasting black. The odd coral pink colour of the shade wasn't to my taste so I gave it a little red paint and once dry epoxied the new rim in place.

Now it's all fixed up. I'm not short of lamps, but I hate waste and I'll find a place in my home for it as it's quite attractive.