3D printed Data Slate props

For a long while I've been using old Nexus 9 tablets to act as 'cyberdecks' in our Cyberpunk LARP, but I was recently asked to dress them for a 40K themed one this summer.

The old 3D printed cases were getting long in the tooth and were clearly just unpainted poor quality 3D prints. So I started completely from scratch for this, only re-using my CAD model of what I needed to hold the tablet securely and operate the power and volume buttons on the side.

One of the major things I wanted to get away from was the obviously rectangular shape of the tablet screen. It's a common sci-fi trope for screens to be weird shapes and to emulate this I modelled a surround with truncated corners and cutouts for the cameras and speakers.

This looks great so long as the tablet is asleep, but once it wakes up the real shape of the screen is obvious. There's only so much I can do here and while I could have covered some of the usable area Android apps tend to quite rightly assume the whole screen is accessible.

On the old tablet holders I had added some old bag carrying straps, which are very practical but untidy looking so I added a very chonky carrying handle as part of the case.

This makes the whole thing physically large, which has the added advantage of making these hard to hide or just stuff in a bag. It's a not uncommon problem in LARP that acquisitive players will squirrel something away in their bag and it's never seen again unless they want to leverage it somehow. These were to have PDFs on them that were plot-relevant and we wanted that information very clearly available.

Annoyingly there's no open source 'kiosk mode' application for Android that I could find but to make sure the PDFs were visible whenever somebody woke the tablet I used the "Librera FD" viewer and the basic screen pinning functionality in Android to keep it maximised.

When asked to make these I wasn't sure how long the documents would be so I decided to add physical controls for paging through and searching documents. There's a scroll wheel, two buttons to page up and down plus a keyboard for text entry. This re-uses an X-Box 360 chatpad as making your own small keyboard keycaps that don't look terrible is very awkward and fiddly. There's also a piezo sounder to do keyboard/button bleeps.

This section is the part I'm least pleased with: the chatpad is too small and the buttons I ordered were too long to allow me to inset it like I did with the tablet section.

The design is ugly because I was rushing and I will most likely re-do this part before they are used again. I may even go as far as making a custom keyboard using tactile switches that fills more of the area.

These physical controls are driven by ESP32-S2 dev boards acting as USB OTG HID devices. I ran into a bit of a struggle with the code for this. Every time the tablet went to sleep, it would disconnect the USB devices and refuse to reconnect. I think this is related to this reported bug but was in a hurry to get this done so just made the ESP32-S2 restart whenever the tablet went to sleep. There is a little latency on waking it up but not a great deal. I would like to add more functionality to this setup, including my LoRa mesh network messaging stuff, so I need to overcome this problem. The 'cheat' would be to connect the ESP32 over BLE but given I have a direct physical connection to the tablet this sort of offends me and I'd need to swap to an ESP32-S3.

In the end though, this all worked out well, I got four of these made in different colours so they could be told apart and the paint weathering on the main body looks good. I didn't have time to weather the control sections so they just got some scratches but if I'm going to re-do them that's fine. I may also try to make some left handed variants and some without the big handle.

These will definitely be getting a load of use. Put Termux on them and they are almost 'real computers' and while the performance is poor in modern web applications we always curate what we let our players access. I've got a drawer full of Nexus 9s so printing and painting a few more of these over the next few months will get me a nice stash of usable props.

GalactiNet GT420 terminal

Back in May I was part of a team running a short LARP in our High Frontier universe.

The game plot called for the existence of a prototype communication device through which 'second contact' with an advanced extra-terrestrial species was being attempted.

In practical terms the intention was there would be a short exchange of messages between the players and these extra-terrestrials while very human chaos raged around them.

We like to do things with 'practical effects' at High Frontier and avoid whispered messages from GMs and the led me to somewhat overcomplicate the prop involved. A lot of this was because we intended to have an multi-user in-game messaging system at our previous event and I flamed out trying to deliver it in time, resulting in a big disappointment.

So this game I very much wanted to make that happen even if the actual amount of messaging would be trivial.

Every player was provided with a personal printed RFID card and inserting the card into a reader in the external unit logged them in.

The physical prop was made in two large chunks: a 'terminal' and the actual 'communicator' itself. Making these physically imposing yet still portable props was deliberate as the players would be faced with carrying them while under fire or abandoning them.

The 'terminal' is an old laptop motherboard and screen carefully fitted into a medium sized flight case with 3D printed and painted fascia. The flight case was interestingly laid out with a padded compartment on one side and I retained that for storage of a compact keyboard, mouse, cables and the power supply enabling it all to be packed down for moving.

Building this took a fair amount of iteration and improvisation. The original laptop battery pack was beyond use so I built one out of new 18650 cells with double the original capacity to ensure it would last the entire game.

Making an aged laptop bearably usable is an increasing struggle and the Raspberry Pi desktop for x86 is my go-to for this. By removing the Office software before updating you can still squeeze it onto 8GB SSDs and so long as you don't want to use Chrome with super-bloated sites performance is as zippy as it can be.

All it needed to do was run PuTTY as like my previous work on off-grid multi-user messaging this was a 'microcontroller first' design, implemented on ESP32-S2.

I took my previous, frankly unmanageable, project for messaging and created a new back end for it this time based around the port of sqlite available for ESP32. My goals were far more modest than the original project in UI terms but the back end still has most of the features to now resurrect it in what I hope is an actually manageable fashion.

Inside the communicator itself is a custom PCB I made a small batch for as long term I want to develop and use this messaging system for future games. It uses the ubiquitous MRC522 RFID reader and has a GPS attached for getting an accurate time signal, which is necessary for the system to work. There's also a uSD socket for storage (although it could use LittleFS), a sounder and some indicator LEDs.

By the time I was actually coding things for the game I realised I'd made some omissions on the PCBs but broadly they worked.

While the players interacted using a retroterm UI on the physical terminal, GMs could connect over WiFi and use a hacked together web interface to view previous messages and send new ones.

I did start by writing a fully featured web interface but the framework I used meant the ESP32 began to run out of memory once there was a non-trivial number of things in the database. Moving things into PSRAM helped, but not enough realistically.

The sqlite cache also caused me grief as it would rapidly eat all the heap memory of the ESP32, despite nominally being able to manage that itself. Tweaking compile time constants helped but in the end I found I had to aggressively clear the cache using the sqlite API after every interaction. By this point I was very close to the game, stressed about the deadline again and as messy as this solution was it worked well.

Using GPS for time, even indoors, worked well in testing but was another cause of stress on the day even though we're nominally an outdoor LARP system.

A cold GPS start, metal roof on the building used and need for it to work quickly ended up with us having to leave the communicator outside the building on a long USB lead for it to work at all.

I will not wholly rely on GPS for time again and look to fit a dedicated RTC that is set then updated by the GPS only if necessary. Even outdoors the time signal seemed unreliable but it was impossible for me to troubleshoot at the game. This meant weird slow performance and trouble logging on that I simply hadn't seen in testing.

In the end though, messages were exchanged and this massively overcomplicated setup delivered even though it gave me and the rest of the game team huge amounts of stress.

What I need to do now is work on it in the in-between times so that the back end approaches plug and play for other applications and my 'microcontroller first' plan actually means it can be used across a range of lightweight devices.

There was a whole PC doing almost nothing in this setup that could have done the messaging instead but my plan is this 'backwards' approach would allow cheap ESP32-based props to interact with the system.

You can buy something that could in principle be turned into a pocket touchscreen communicator for <£10 and I plan to pick up a couple. It's just the tip of the iceberg of what you can do with little ESP32 based gadgets. Previously I was thinking to use M5Stack/M5Paper products as well.

The messaging back end I've christened backslang and is on GitHub but I would say it is very much an unfinished mess not fit for anybody else to use. Maybe I'll find time to fix this before our next event. I'd love other people to dive in to the repo and fix my naïve mistakes but it seems unlikely anybody will have the inclination and time.

Making ESPUI a captive portal on ESP8266/ESP32

There's a really nice UI for making basic interactive web applications using the Arduino IDE on ESP microcontrollers, ESPUI. This is a real shortcut to usability for very basic "push a button a on web page and something happens" projects as it works asynchronously and does all the behind the scenes dirty work for you.

It does have one dull limitation though, it doesn't by default work as a captive portal. You can bodge a fix to this with the following steps.

First, find the line in ESPUI.c

server->onNotFound([](AsyncWebServerRequest* request) { request->send(404); });

Then comment it out and add the code

server->onNotFound([](AsyncWebServerRequest* request) { request->redirect("/")});

This means any time a request for an unexpected URL hits the Web Server on the ESP it will redirect to the root of the server. You can change this to some other URL by changing the "/".

Now this still won't get all requests to hit the ESP, you need to add the following bits into the rest of the sketch. This assumes your ESP is acting as an AP on the usual IP address 192.168.4.1, but you can see how it's easily changed.

<near the top of the sketch>
#include <DNSServer.h>
IPAddress apIP(192, 168, 4, 1);
DNSServer dnsServer;

void setup()
{
    <rest of your setup stuff>
    dnsServer.start(53, "*", apIP);
    dnsServer.setErrorReplyCode(DNSReplyCode::NoError);
}

 
void loop()
{

    <rest of your loop stuff>

    dnsServer.processNextRequest();
}

I really should submit a more complete solution as a pull request and new example to the library.

Now when most devices hit the ESP they will take you straight to the page asking you to "sign in" etc. and it doesn't stop you manually going to the page.

In praise of Adafruit IO

After a long delay on the delivery of the solar panels I want for my solar mesh nodes, I finally got around to doing some testing with them.

Unfortunately I was away from home and relying on tethering to a mobile phone for access to the Internet so using my home MQTT server for logging wasn't impossible, but was going to be inconvenient.

It occurred to me to give Adafruit IO a spin as it's designed for making generic IOT logging easy to set up.

Quick and easy to get working it has been logging just fine and I've not swapped back now I'm home. The dashboard is basic but all I need for this test.

In the first graph you can see the VPCC feature of the MCP73871 working well to avoid flatlining the voltage from the solar panel under load. It has a target voltage (arbitrarily set to ~5.3v here) and reduces current draw if the supply voltage drops below this. I've added a small trim pot to my test board to allow me to tweak this and do some runtime comparisons.

VPCC isn't MPPT but it will get better efficiency out of the panel than simply drawing until it can give no more and the voltage sags below a useful level. In the second graph you can see how without VPCC set the load on the same panel causes cycling like this, which also won't be doing the LiPo cells any good.

I have an idea ruminating to use an I2C controlled potentiometer along with a current sensor to make adjustments on the fly to try and optimise the solar output but it may be a minimal return compared to doing the tests once and picking a set value for VPCC. It will certainly increase component count.

There are packaged up MPPT solutions around, but there seems to be a gap in the market with them either super-efficient energy harvesting for tiny panels, or for large domestic/industrial power solutions. My scenario of ~4W panels with a ~100mA load isn't something I've spotted a good packaged solution for.

It wouldn't be impossible to roll my own MPPT boost convertor in front of the MCP73871 but like I said very likely to involve diminishing returns over careful use of VPCC.

Solar charging ESP-Now BATMAN prototype 6

Prototype 5 sucked, trying to bodge in the ESP32-S2 breakout to the old board just didn't work well, so I did another prototype. Also as I now have the Nordic Semiconductor Power Profiler II, testing and measuring power use is so much easier and I could ditch the INA219 current sensors. These added a lot of mess to the previous prototypes.

As it's easy to adjust the voltage from the PPK2 it almost stands in as a dummy solar panel, although you can't current limit the output.

This latest prototype mostly came about because I designed a new schematic in EasyEDA, had a crisis of confidence about pin choice and how well it would work and resolved to just build it. Also it's Chinese New Year and I'm not in a hurry to order the boards.

I'm now absolutely set on using the ESP32-S2 for this project but I'll run this prototype off the panels for a few days and see how it behaves.

Update: I can't continue using the PAM2301 buck regulator I had intended to, testing showed it 'trips out' when panel voltage is ~6v. Which is fair enough given that's what's in the data sheet, but my expectation was charging load would keep voltage on a 5.5v panel below that, even though no-load voltage can be quite high. This is not true.

Creating a UI on a microcontroller: Part 11

I've been doing lots of work on the flow of things in the user interface in the terminal application so it works better. The deeper in I get the more boilerplate I'm writing to make buttons appear and disappear without leaving stuff floating around, so it's quite slow progress.

On the plus side, the syncing of user accounts and so on is working nicely and I've now made it so that it live updates. Make a change to a user and it appears near-instantly on the other terminals. Previously it synced the files on the SD card but they didn't show until a reboot.

Actually coding that to happen took another swathe of boilerplate but each time I do a thing like this I'm edging closer to a believable looking application. Also a bit of bugfixing which might have finally nailed the occasional exceptions when using a mouse.

As it's getting closer to something I can demonstrate I did a quick show and tell on Brian Lough's 'Project Doc' stream this evening. Which I believe is recorded for posterity.

Espressif ESP32-S2-Saola-1R development boards

On account of wanting to assess the power use of the ESP32-S2, not long ago I bought a WROOM module programmer on Tindie, mostly because there's a dearth of the single core ESP32-S2 in the wild. Most Espressif powered boards either use the dual core ESP32 or are still using the ESP8266.

Like most manufacturers, Espressif have their own development boards, but they're not widely sold. The ESP32-S2 variant, the Saola-1, is actually very affordably priced, only ~£5 and on release I considered buying some but the postage from any of the stockists was double the board cost.

Given I was ordering something else already that took me over the free delivery threshold, I tacked a couple of these onto my order. Now I have some boards that are easier to work with than the module programmer, which is nice but not really breadboard friendly.

These official development boards are well made and 'just work'. They're reminiscent of the original NodeMCU, slightly too long for a mini-breadboard and with nice sturdy tactile buttons connected to the reset and GPIO0 for programming. Not that you'll need them, auto-reset/program works like you'd expect.

There's a lack of clutter, beyond a single WS2812 RGB LED, connected to GPIO18.

You can buy them in both WROOM and WROVER variants and with/without a PCB antenna. I picked up the WROVER as I want to experiment with using the 2MB of PSRAM. My plan is to use this for storing bigger data structures than most microcontrollers can deal with, mostly as a big cache of messages sent over my mesh network so that they can be 'retained' for a fixed time if a node is temporarily unreachable.

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.

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.