Solar charging ESP-Now BATMAN prototype 5

 After generating some good data on power use of the ESP8285, I've finally got around to sticking an ESP32S2 into the same board using a hand-soldered adaptor based around a programming board. The board has LEDs on but I can probably account for this extra load. Mostly I want to know a rough equivalent power usage.

With a little tweaking of the code it runs fine, so I'll conduct a charge test over 24 hours and see what the graphs look like. If it's promising I may be migrating the project to an ESP32S2 because of the extra pin count and resources. Squeezing an SD card slot in along with the connections to the charge controller uses almost every usable pin the ESP8285 has.

Also, while I don't want to include a USB FTDI chip on the board, a spot for an OTG USB connector is another matter as by itself it uses no power. It would allow my board to also run CircuitPython, which is quite popular and were I to stick some on Tindie broaden interest I think. It's also a nice 'desk charging connector' and the 5V could go straight to the charge controller. The added component count would only be the socket itself and a resistor I think.

In winter, this is what you resort to.

I've been doing more work with the MCP73871 charge controller today, initially playing with my bench PSU and taking readings from the INA219s I've built into the board to simulate varying amounts of available supply from solar panels.

This didn't quite work as VPCC reduces the load on the supply but as the voltage from my bench PSU isn't actually sagging it keeps reducing the current until it hits zero because the voltage never recovers.

With very little daylight on an overcast winter day I resorted to an old school halogen spotlight playing directly on some solar panels to test how it really behaves.

Starting out with a fixed resistor network for VPCC I could see that it was doing some form of load regulation but not what difference it makes as it varies, so this got changed for an old guitar potentiometer I had kicking around.

It's very tricky to set by tweaking the pot. As you change the VPCC threshold for the voltage from the panel it does change the load on the cell slightly but beyond a very narrow range, it stops charging.

Grabbing the data once a second I put this into a spreadsheet and did a scatter of the power provided vs the voltage from the panels, which is moderated by the VPCC threshold.

I'm no scientist but this seems to make it reasonably clear the best power was extracted from the panels when at about 4.5-4.7v under load. This is completely at odds with my initial thinking to set the VPCC threshold at or slightly under the nominal voltage of the panels I'm using, which is 5.5v.

Below about 4.4v we start running into the problem of there being not enough headroom above the battery voltage to allow for charging and it stops dead. More headroom could be had from a higher voltage panel, but then you start approaching the 7v limit on supply for the MCP73871, the highest I'd like to go is 6v.

I also visualised how the power is used over a day of real usage. Even when there is not enough sun to power the board, the panels support the battery, reducing the amount of power taken from it. This is exactly the behaviour I wanted from the charge controller. Anything 'negative' is where panels are powering the ESP8285 and charging the battery. Which now I look at it, feels pretty good for a winter day. The big spikes are when the sun came out briefly and made for a bright afternoon. It's the great stretch of darkness in the evening that really sucks the life out of the battery.

The main outcome of all of this testing is it's shown me that VPCC has little beneficial effect with the panels I have and had I set it by instinct it would have severely compromised charging. Bypassing VPCC and allowing the MCP73871 to draw as much power as it wants lands them in the 4.5-4.7v range which is where they appear to be most efficient anyway.

The other outcome is I have ordered some larger (165x165) 6v panels as all this was making me come around to the idea I just need larger ones. This may help offset things further so the dark evening doesn't leave such a charge deficit overall.

Interestingly during this testing when charging from USB I'm seeing one bit of behaviour that doesn't match the data sheet.

In the datasheet it says..

The MCP73871 device USB-Port current regulation set input (PROG2) is a digital input selection. A logic Low selects a one unit load input current from the USB port (100 mA) while a logic high selects a five unit load input current from the USB port (500 mA).

In practice with PROG2 high I see it max out at 400mA. No matter, I won't often see this as an issue with the little solar panels I expect to use in normal conditions.

Solar charging ESP-Now BATMAN prototype 4

After the last test run, I decided I wanted to investigate the supply load tracking feature of the MCP73871 charge controller to see if it improves charging. With a small solar cell in winter, it will be very easy for the charging circuit load to drag down the voltage from the cell such that it ceases to be of use.

In order to see how well this works you also really need a good measure of the voltage and current at both the battery and the charging input. Which means adding the INA219 modules back again after I took them out.

Having considered reworking the previous board it's just too untidy and with the SD card reader attached the ESP8285 doesn't have enough pins to go around. Using socketed modules allowed me to just make a new carrier board and swap them over. I also made a big effort at tidier wiring, the last one was offensive.

The supply load tracking feature on the MCP73871 is called Voltage Proportional Charge Control (VPCC) and reduces load to the supply if the voltage drops below a threshold. VPCC needs a simple voltage divider that provides 1.23v (or more) at a pin while the supply is OK. If this voltage drops, it reduces current draw to bring it back up. On the new board I've fitted a small socket header so I can fit different values to the voltage divider.

We're also getting to the time of year where it might go below freezing and the thermal protection circuit needs testing. So I've added another header for the thermistor network, temporarily bypassed with a resistor while I fiddle with the VPCC in isolation. I'm going to move my test location to near an indoor window where there's more sun for more of the day and hang the solar cell out of the window. Once I've investigated the practical worth of VPCC I'll add the thermistor network and do some tests with heating and cooling it.

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.

Creating a UI on a microcontroller: Part 7

It's been a while since my last update on this library, but I have been working on things slowly. I got buried deep in the hole of optimising memory until you could again use my library on an AVR Arduino board, but perhaps more importantly it massively reduces the memory footprint on other things.

I got bogged down in the messy detail of handling the AVR program space functions, especially when trying to make it also compile and run for ESP8266. The Arduino core for ESP8266 provides similar looking functions but they don't behave exactly the same. Also I encountered some messiness when trying to use them inside a C++ class, in ways I should have realised was verboten.

Regardless, now if you pass the library a string type argument stored in program space it marks it as such and accesses it differently, depending on the processor. This includes using different methods to find the length of strings for centring and so on.

Time consuming fiddly stuff but it had to be done and finally you can run the example code on an Arduino Nano again, only consuming 1124 of 2048 bytes dynamic memory. The sketch does use most of the program storage, which is down to the large amount of text stored there. It runs stably, something you can easily compromise when throwing lots of string data around with a small margins on the stack.

I've enjoyed this learning exercise, but I now need to test my library with other architectures supported by the Arduino IDE, such as a Teensy with an ARM Cortex-M4. In these cases it shouldn't be so necessary to store small chunks of text in program storage but it is something I would like to be sure of working. I believe I have a Teensy 3.2 somewhere.

Recycling an old laptop into a Command Centre: Part 1

I have, for some time had a plan to build a portable 'command centre' prop which has a generic PC inside but has that industrial look often seen in action movies. A friend asked me to dispose of an old dead laptop so I stripped it down and made it work.

This laptop was a good candidate for this as it was one of those bulky OEMed machines that use a generic motherboard with various components on little daughterboards. It was dead because the PSU socket had been smashed but as this was a discrete socket clipped into the case, fixing it up was easy.

It's too old to be much use with modern software but a stripped down Linux install works just fine.

Over a lazy afternoon I carefully stripped out all the modules, including taking the webcam and microphone out of the screen surround and it's now ready for when I get the time to build the physical enclosure. I'm particularly pleased with how bright and clear the screen is after a careful clean, initially it looked dismal.

My plan is to use this ridiculous stainless steel waterproof keyboard/trackball combo I bought some years back as part of the prop.

I'd also like to use this set of rackmount monitors, but they take a composite input.

It seems reasonable that a USB to composite out peripheral might exist but if it doesn't I can run them with some microcontrollers and maybe do a Serial to composite display that shows text you send it, a bit like a dumb terminal. throw in support for some basic ANSI control characters and I'm creating the other half of my terminal UI library.

I've seen products on Tindie that turn a VGA monitor into a proper VT100 compatible terminal but nothing for composite and I'd need it to connect over USB anyway. I have a small stash of composite displays I've picked up over the years and creating something to drive them would be good. It could be easily argued that a Raspberry Pi Zero is a better way to do this but then you've got three computers to look after and I'm a fan of using microcontrollers instead.

The laptop can also drive a VGA screen for yet another display but I think that would make the prop physically too big.

Rookie SMD mistake

 

I received the new boards from JLCPCB and they look great, but I've made a real rookie mistake when ordering.

Working in EasyEDA, component selection defaults to 0201 packages for things like the resistors.

These are tiny. Really really tiny.

This is something I already knew and just missed it when laying out the board.

I realised my mistake when ordering the components but thought, let's give it a go. I have made an attempt to solder these but with my ageing eyesight I can barely see and handle them, let alone apply paste and hot air to successfully solder them.

Now with the ongoing pandemic I don't have any immediate application for these boards, so I'll pause a little while before coming back to them and producing a new version. Either I'll choose larger components or have JLCPCB do PCB assembly for me, which is increasingly affordable.

Creating a UI on a microcontroller: Part 6

There was some chat on Brian Lough's Discord channel about Bitbank's animated GIF player library.

It's optimised for use on microcontrollers, not classic AVR but anything with ~32KB or RAM or more, and can do much better frame rates than more generic libraries. On real screens it's excellent.

As I've been fiddling around with displaying stuff on the Serial/Stream terminal I quickly hacked around one of the example sketches and made this.

Running on an ESP8266, the terminal baud rate is 230400, any higher generates garbage, playing the GIF back from a PROGMEM array. Terminal client is PuTTY.

It's obviously not high def video but it's oddly satisfying to make this ridiculous thing happen. The GIF is already optimised to mostly send changes, which helps a lot. A static GIF would display quite easily.

So displaying very basic blocky images in the terminal isn't impossible, I might look at integrating it. You'd have to 'curate' what images you displayed.

I also had a go at the badger meme GIF and because it's not optimised and sends just every line the result is far less satisfying.

Creating a UI on a microcontroller: Part 5

In this update I've added 'list boxes' and the ability to style text inputs as password fields. So the list of widgets is now...

• Buttons
• Checkboxes
• Radio buttons
• Text boxes with scrollable content
• List boxes
• Single line text input fields
• Single line password input fields

Creating a UI on a microcontroller: Part 4

In this update I show the work I've done on styling widgets with colours, different box drawing characters and different positions for labels/shortcuts.

Creating a UI on a microcontroller: Part 3

Another update on my terminal interface UI library and after lots of code cleanup it now handles multiple editable text input fields. I started using OBS to capture the output with so this video is cleaner than the first ones.

To recap I've now got the following working as simple to create 'widgets', any of which you can have multiples of on the screen at the same time and swap between them with keyboard shortcuts or the mouse.

• Buttons
• Checkboxes
• Radio buttons
• Text boxes with scrollable content
• Single line text input fields

At this point it's using more memory than is practical on classic AVR Arduino boards but I know I'll be able to reduce the footprint a lot later.

Part ordering gamble

I have for a very long time wanted to build in the sort of 'scanning' you see in sci-fi movies to our LARP events as an actual working piece of tech. As the majority of our events occur outdoors the obvious answer is GPS. So I've made a gamble and bought forty GPS modules that came up just cheap enough to justify it to myself.

More so than other modules, cheap GPS modules seem to appear, disappear, then a few months later something similar but different appears on the market. I had identified some I wanted for this project a while back but then they disappeared and as I want to make a compact wearable with a 3D printed case, changing modules is non-trivial.

These super-compact modules look just the ticket and ordering them is an attempt to force my hand into making progress on this. The plan is that most things I build which are connected to the mesh network will have a GPS module. I did this a long time ago with the 'magic compass' but doing it at scale opens up the possibility of making something like the 'motion tracker' seen in Aliens etc.

Creating a UI on a microcontroller: Part 2

More work on the terminal UI library, but I've now added radio buttons and a scrolling text window, useful for showing a larger block especially from an SD card or stored in program flash memory.

If loading from an SD card it would need to be loaded into the memory of the microcontroller, I've not yet added support for very large blocks of text.

 

Creating a UI on a microcontroller: Part 1

A chunk of my work has always been about building things with microcontroller boards (either classic Arduino AVR or ESP8266/ESP32) that you interact with directly.

For our (postponed) LARP event in March I had created a fake 'computer terminal' that you interacted with, where all the work is done on an ESP8266. RFID cards log a user on and there was a chat application, file viewing and so on, all using my ESP-Now mesh network to allow the individual terminals to send messages to each other.

In order to make this I used ANSI/VT100 escape sequences to create a very simple 'application' that you accessed using a terminal emulator, PuTTY, running on old laptops.

It's not wrong to argue this is the 'tail wagging the dog' when there's a much more powerful computer just running PuTTY but the guiding factor was the mesh networking, not the application itself. It also meant anything you could run PuTTY on could quickly and easily be pressed into service as a terminal and PuTTY is available for Windows and Linux. Likewise any other terminal emulator that supported a broad range of terminal capabilities could be used, but all my testing has been with PuTTY.

In the weeks before the event, I was in a 'crunch' working on various props and technology for the game 14+ hours a day until suddenly we postponed due to the pandemic.

As irritating as this was it's given me time to turn this work into a re-usable Arduino library. Such things already exist to place the cursor, change colours and so on but the one I've been working on has 'widgets' like mouse-clickable buttons and does the work of drawing/updating them for you.

The idea is if you have an Arduino project that needs a user interface, perhaps one that's infrequently used, you can build this with minimal pain. Then to access it you just connect a USB cable and there's a terminal UI available over the serial connection. Sadly it does not work in the Arduino console monitor as it's not a proper terminal application, but PuTTY isn't onerous to install.

I have an aspiration this would be usable over the network on microcontrollers with Wi-Fi such as the ESP8266 but it probably has more value on those without. If you've got Wi-Fi, basic web server front ends are going to be more flexible.

Tasmota temperature sensors

I've been doing a little home automation with Home Assistant recently and this involved putting temperature sensors in every room. I started out with some ugly stripboard SHT11 based things but they were unreliable and inaccurate.

During a Banggood sale I managed to pick up some Wemos 'shields' with an SHT30 temperature/humidity sensor so I converted all my sensors over to these. Tidier but still a bare circuit board with power LEDs lighting the room at night.

I fiddled around in OpenSCAD and came up with a fairly decent 3D printed enclosure and now have eight sensors dotted around my house, including the shed. This design leaves the SHT30 sticking out in free air with a 'baffle' to separate it from the rest of the device. Even so the temperature readings are massively effected by heat soak from the ESP8266 and quite inefficient LDO on the board. I've now put this on Thingiverse.

To fix the heat soak you need to connect D0 to RST on the D1 mini with a short piece of wire and enable deep sleep so they draw (and waste) much less power. In Tasmota this needs two console commands...

TelePeriod 10

DeepSleepTime 300

...the 'TelePeriod' means it sends data 10s after connecting to WiFi and 'DeepSleepTime' means it sleeps until the next five minute interval on the clock. If you're copying this example don't issue the commands until you're happy with the Tasmota configuration. The short wake time makes it a pain to issue changes later.

Now they send decent sensor readings, reliably.

Solar charging ESP-Now BATMAN prototype 2

After over two weeks continuous running my first prototype of the solar charged prototype proved itself with a 2W panel. So I spent a chunk of time designing the next iteration in EasyEDA and ordered five PCBs from JLCPCB in China.

I've taken a small gamble with this design as I haven't built it on breadboard first and have added a number of new features.

• Thermal protection for the 18650 cells, a feature available but omitted from the MCP73871 evaluation board. They will now only charge in temperatures of 0-50C, which is a default safe option. I don't feel this will kick in often in the UK except perhaps on a very sunny but cold morning however to omit this feature would be slightly negligent.
• Replacement of the INA219 current monitors with a simple resistor ladder to measure supply voltage after the charge controller with the ESP8285.
• Connection of the MCP73871 status pins to the ESP8285 rather than indicator LEDs.
• A microSD socket for optional file storage.

This is quite a simple project compared to the people making their own small board computers or things based on FPGAs but it's only my second ever manufactured PCB. All the pins on the ESP8285 board are in use, although in principle IO0 which has a button attached for putting it into programming mode could be doubled up with for something else so long as it defaulted to a pullup.

Instead of going straight to the final run of boards I'd like to test these five before ordering more. I made absolutely no effort to keep it compact so even if no changes are needed I'll still move things around and tidy it up before the final order.

Once these arrive I'm hoping the extra efficiency of the PAM2301 regulator will make a 1W panel viable in the UK but if not, 2W panels aren't overly huge.

Solar panel doubling

 A bit of data logging showed a single 1W panel useful for supplementing battery power to my mesh network node, but not really enough to charge it meaningfully at the same time. My garden is south facing and the house blocks direct sun lots of the day so it was only the few hours where the panel was in strong direct sun that the result was acceptable. For something that spends a lot of the time asleep this would be reasonable but as I want each node to run for all the waking hours then I need it to do better. I did get 52 hours of runtime, which is technically enough for my needs if I fit two 18650s in the node, but I still don't like the thought of it running down constantly with only a tiny amount of headroom.

The data also shows the regulator board I took out of a drawer is an LDO, not a buck converter, so it's 60% efficient a lot of the time. I will make a pin compatible replacement with the converter I specified for the final boards and that should be a big help.

I've now set up two 1W panels in parallel to make an effective 2W panel. Only a few hours later it's clear this makes a massive difference as they spend lots of time charging the cell rather than just 'treading water'. I'll leave the test to run until the battery protection kicks in at 3.5V but it looks like 2W panels really are what's needed even if I were to replace the LDO. There are some really quite affordable 2W 5.5V cells on Banggood, so going up in size isn't a big deal.

Solar charger data logging

 After a little fiddling around today I had software on ESP8285 node so I can keep track of the battery use and how well the MCP73871 manages things.

Working at my desk it seems to seamlessly charge then swap over to battery if needed, but more importantly if there's roughly 0.5W charging capacity, which is what I'm expecting from the solar panels I have, available it'll run the ESP8285 and use excess to top up the single 18650 I've fitted for now. This is exactly what I was hoping for from the chip, but what's not clear yet is how well it works around dawn and dusk. Playing around with my bench PSU would give me some idea but with solar cells varying voltage under load I've just gone straight for a practical test.

The code I've put on isn't anything like the final application but it does sit there connected to WiFi pushing data to MQTT every 30s so it's a pretty reasonable test. I'm dropping the output into a .csv file on my server and I'll look at it periodically to see how the battery fares. As I wanted real timestamps on the data I used the quite nice ezTime library to sync with NTP but more importantly maintain a usable time based off the ESP8285's internal clock and only periodically update it. This is a feature I will need when things happen for real, although I'll probably have to use GPS and a local NTP server due to lack of guaranteed internet access.

Also Blogger has changed and all my layouts are broken. Sigh.

Solar charging ESP-Now BATMAN prototype

Putting a 'production' board together rekindled my interest in a solar charging prototype of my mesh network nodes.

A small solar cell in typical UK weather is not going to be able to run the node 100% of the daytime, but it will almost certainly work as a useful 'runtime extender'.

I started looking at this way back last autumn then like a lot of things my enthusiasm waned and it languished in a box for months. Today I finished off putting it together to a point where I could knock some software up and start logging charging/load data.

I'm using the same ESP8285 module I have for the nodes, with an MCP73871 development board for charging and power management. The naive approach would be to stick a conventional LiPo charger in parallel with the batteries but the load messes with the charging.

The MCP73871 manages the power path so that depending on the charging power available it will run the load from that while also charging the batteries, run the load from it, or once it it is too low run the load from the batteries. As the battery isn't directly connected to the load this can be done while maintaining proper charge behaviour for the LiPo. It is not proper MPPT tracking for the solar cell, but it does sensing of how much current it can draw before the voltage drops too low that will have a similar effect. For extra efficiency a DC-DC converter that does MPPT would help, but I'm going to suck it and see if this prototype is 'good enough'.

I've shoehorned several INA219 current/voltage sensors into the power path so I know the battery, charging and load detail. My plan is to stick this inside my shed, with a solar cell outside and simply log the data until it falls off the network because the MCP73871 has decided to protect the battery.

ESP-Now BATMAN boards

Back in February I was faced with a looming deadline for our LARP in March where we would be using my ESP-Now mesh network for messaging between props and also to end devices used by players.

For this to work we'd need some fixed nodes to give minimal coverage. I had previously built ten static nodes using Wemos D1 mini Pro boards and NiMH batteries and used them in testing but battery life was only around eight hours which wouldn't be enough even with overnight charging.

I did a few sums, came up with a power budget and figured something with a more efficient regulator, no indicator LEDs and a couple of 18650 cells in parallel should easily run for a whole weekend, eliminating another point of stress for the game.

Scratch building all this would have been a drag so I designed and ordered twenty boards from JLCPCB in China.

I had previously tried designing boards in KiCAD but found the interface impenetrable even for simple things and got deterred. For these boards I tried out JLCPCB's own web based EDA software, EasyEDA and was pleasantly surprised.

While I did have a bit of a struggle finding matching footprints for the components involved the process really wasn't hard. They also integrate this fairly tightly with the PCB ordering making the generation of gerber files, drill files and so on something you don't need to worry about too much.

This smoothing over of the complicated process meant I was able to get to grips with EasyEDA, design a board and order it in a morning with my only previous experience being a couple of failed attempts to do something useful in KiCAD.

Sadly with the postponement of our game due to the pandemic these boards have sat on the side since delivery but today I finally built one and it works! I added a reset switch to make repeated programming easier, and were I to design them again I would add a reset and flash button on the board, but for now these suffice. There's almost nothing to the circuit, it's an ESP8285 module, buck regulator, battery holders and some headers. No charging or protection circuit and nothing to leech power that isn't needed.

Until I add more features I have in mind like onboard solar charging then they'll do. In the meantime I'll do some current measurements and rundown tests with this one to check its performance. I'm really hoping these will give us the coverage we need for the game and now I've some more time to work on it I can actually check properly.

ESP32-CAM helmet camera, prototype 3

 

While working with the ESP32-CAM board I've realised that the AMS1117 LDO fitted to it is a bit of a problem due to a 1V dropout value. This means that if you power it from an 18650 cell it starts to brown out far sooner than needed.

Coincidentally somebody from the LARP community asked me to see if I can make a design that takes four AA batteries and I put this new version together. The 6V from the battery pack works much better than the single 18650 and means they can be swapped easily but sadly makes the camera really quite bulky. Nonetheless I've sent them the files so they can have a go at building some units.

Going forward I've seen that the LDL1117 LDO only has a 0.3-0.6v dropout and is pin compatible. I think carefully desoldering the AMS117 and replacing it with one of these would solve my brownout problems.

An alternative would be a small 'daughterboard' that connects to the headers and has a buck convertor. This would be the more elegant option, especially if I managed to include the power switch and lamp button onboard. I've still not found time to see if I can make an I2S microphone work with the board, but that could also go on a 'daughterboard' if it did.

ESP32-CAM helmet camera, prototype 2

 

I did a little more work on the design and added an external antenna, as it's a known fact the board works better with one.

Then I put quite a lot of effort into painting it up in a basic camouflage pattern. I am very pleased with how this worked out.

No other real changes to the project but it shows you can make something decent looking at a low cost.

Creality automatic spotlights

A while back I wired both my Creality 3D printers so that they are powered on and off through Octoprint. This is useful because I work two floors away from the printers and perhaps more importantly because it switches the printer off after a long print.

This has been working perfectly but I often have the light in my cellar switched off making the camera monitor pretty useless unless I go and switch the light on.

I figured it stood to reason that switching some lighting on with the printers was a good idea and I made up a couple of little spotlights attached to the printer frames and connected them to the same SSRs that switch the printer power.

The spotlights are made from some ceramic GU10 bulb holders I had, 20mm electrical conduit and some 3D printed parts I quickly knocked up in OpenSCAD. I knew from my work with making fittings for GU5.3 12v bulbs that heat from the bulb wouldn't be an issue with the printed parts, they barely get warm to the touch even after several hours.

I only did this yesterday but it's already meant I haven't been leaving the cellar light on as much while working on projects.

ESP32-CAM helmet camera, prototype 1

It's been a while since I've blogged. Back in March I was working very hard indeed on making props for our upcoming LARP. With the pandemic we suddenly had to postpone until some indeterminate time in the future.

This killed my enthusiasm for a bit and when I picked up projects again I needed a change.

Over the last couple of weeks I've been fiddling with the ESP32-CAM board again and turned the pile of components in the first photo into a working helmet camera prototype.

With the standard camera example code loaded it works really quite solidly and the battery life with a 18650 cell recovered from an old laptop battery pack seems good.

I started out with the selfie lens for aesthetic reasons but it does a good job of taking in a whole room as you move around, something the default lens these boards ship with doesn't do.

The tactile button on the side switches on the onboard 'flash' LED and there's an acrylic light pipe bringing the light out of the shadow of the lens. It's not a proper long throw torch but it just about manages to light a dark room so you can see and the camera will generate a very grainy picture with the gain up full.

Onboard charging is nice but currently getting the cell in/out in the field is impractically fiddly and the holder is stuck in with tape. The indicator LEDs on the TP4056 board are brought out on the side with another couple of light pipes and these work great. The idea is if these were issued on a multi-day game it would be the player responsibility to keep them charged and a USB charging socket makes that practical. For a short game they probably won't need charging.

Overall this has worked out really nicely and the design I've done in OpenSCAD is modular enough it's easy to swap out the rail mount and add something different. These could easily double as 'CCTV' cameras with a ball socket mount.

The design does need a little more work to make it easy to assemble but broadly it's there. I've also had it suggested that an external antenna would be acceptable, when I thought it would be too ugly. So I'll work on a version with that over the next few weeks, the boards have a uFL connector and it'll really help increase range.

I've got enough camera boards and recovered batteries in good condition to build a set for a whole team of 'marines' and a few static CCTV units. Doing this while keeping the cost down for 10+ units has been a major requirement of this project and I've definitely succeeded at that. The bill of materials using the recovered 18650s comes in at about £7 plus printer filament at the moment.

Mesh networked computer terminals with RFID logon - part 6

Going back a few weeks I was having trouble with stability of the RFID readers. Which I've now fixed with a far less complicated solution.

The library has an option to turn the RFID antenna on and off. Simply shutting it off and turning back on to check the card periodically seems a 100% stable solution.

Obviously you should also check the card hasn't been swapped by checking the ID hasn't changed but here is a a minimal sketch to do this. As checking for a card stops it appearing as new it's easy to get the logic messed up but this is a tested and working example.

Note to self: start putting stuff on GutHub.

#include <SPI.h>

#include <MFRC522.h>

const uint8_t SS_PIN = D8;    //My example code is for a WeMos D1 mini, change these to match your setup

const uint8_t RST_PIN = D0;   //My example code is for a WeMos D1 mini, change these to match your setup

 

MFRC522 rfid(SS_PIN, RST_PIN);

bool cardPresentWhenLastChecked = false;

bool antennaEnabled = true;

uint32_t cardCheckTimer = 0;

void setup()

{ 

  Serial.begin(115200);

  SPI.begin();

  rfid.PCD_Init();

  Serial.println(F("Checking for RFID card removal"));

}

 

void loop()

{

  if(millis() > cardCheckTimer)

  {

    //Start a check of the card

    if(antennaEnabled == false)

    {

        //Turn the antenna back on

        rfid.PCD_AntennaOn();

        antennaEnabled = true;

        //It takes time to wake up the RFID card so the sketch needs to wait before checking for it

        cardCheckTimer = millis() + 20ul;

    }

    else if(antennaEnabled == true)

    {

      if(millis() > cardCheckTimer)

      {

        //Check for a card after a delay for it to power up

        if(rfid.PICC_IsNewCardPresent() == true)

        {

          if(cardPresentWhenLastChecked == false)

          {

            //Card was absent but has been presented

            Serial.println(F("Card presented"));

            cardPresentWhenLastChecked = true;

          }

        }

        else if(rfid.PICC_IsNewCardPresent() == false && cardPresentWhenLastChecked == true)

        {

          //The card was present but has been removed

          Serial.println("Card removed");

          cardPresentWhenLastChecked = false;

        }

        //Switch off the antenna, otherwise the card will not show as 'new' when checked again

        rfid.PCD_AntennaOff();

        antennaEnabled = false;

        //Wait before checking the card again

        cardCheckTimer = millis() + 100ul;

      }

    }

  }

}

Ender 2 magnetic bed upgrade

I'm still down the prop mines so can't post much without spoilers, but as alluded to I've been doing a lot of  3D printing again recently. The Ender 2 is great but the bed material was getting nasty and it's always been a pain to get things off as it's not removable.

My Ender 3 has a basic removable, flexible bed which is so much nicer. You can't get Ender 2 removable beds easily but you can for the Ender 3, very cheaply. This is a magnetic one which avoids any clips and as I have a second I may upgrade the Ender 3.

I assumed the bed would cut down easily to go on the Ender 2. Which has a tiny bed compared to almost any modern printer. I popped the bed off the printer, which is dead easy, marked it out with some tape and it cut easily with a nice sharp craft knife.

You can see how small the Ender 2 bed is compared to the not huge Ender 3. I wandered a tiny bit with the craft knife despite running it against as steel edge, but once on the printer it's not a problem as you'd never deliberately print that close to the edge of the bed.

Just running off my first test print now but after some faff re-levelling the bed, which is tiresome on an Ender 2, things look very promising.

Update: The small surface area makes for quite weak attraction with the base. Tall prints, especially, seem to cause the bed to slip and kill the print. I've fixed this with a couple of clips. So I've still got a removable bed it's just not an instant off one. Which is not exactly a hardship.