An open source prop: Part 1

After going to Alone: Discord LARP I ended up chatting with the organisers on social media. They had some 'hackable locks' in the game that worked OK but were really just touching a couple of pads with a wire to make a beep and change an LED.

There were several game organisers playing and chat turned to making a generic 'hackable lock' for modern/sci-fi LARPs. It's something lots of LARPs will have needed or reinvented over the years. We might use them ourselves in March.

So I'm now smashing away at code for a generic lock prop based around the old favourite of an RC522 RFID reader, WeMOS D1 mini, LEDs and a piezo sounder.

The plan is to totally open source everything, with a build guide, 3D printed case, software that is pretty flexible and can be tweaked to behave in different ways.

This has already spawned two Arduino libraries. A tap code library for taking input codes on a single button (for hacking/admin) and an RFID authorisation library. The big plan is for a Web Portal interface, probably using ESPUI again.

Churning out some libraries means the main chunk of code for the prop is much less spaghetti-like and the libraries should be eminently re-usable. I really need to do this with lots of other things I've made or started to make.

Oh and obviously the Cyberdeck prop is on hold again, with no game to use it at for a while.

Quick cyberdeck build: Part 4

Yet more messing about with the design but I think I've finally roughed out how the front panel layout will work. I think it'll look decent so I've quickly (ha!) printed one off to get a feel for what it's like in the hand.

Printing time is quite long, so iterating the design is slow even when broken down into separate modules.

I've added a button on the left, which will do 'select', allowing you to use the trackball with one thumb and click with the other as push to click trackballs are always a bit awkward.

Generally it looks like things will fit easily. In fact I think I'll do a version with two buttons on the left and a third on the right. You almost want four buttons for Android though as you've got 'select', 'back', 'home' and 'task list' so this might force me back to using the trackball to select things.

The battery shown might not be the one I finally use, it's quite old and was recovered from a dead tablet but finding something about the right size shouldn't be hard.

The space in the rear of the phone where the original battery went is going to be used for the Arduino Leonardo that turns the keyboard, mouse and buttons into USB HID devices and assuming I continue with the original plan a TP4056 charging board.

I'll then use a little micro USB breakout to conveniently mount a charging socket on one of bottom corners, although with another couple of button breakouts this will be quite cramped. Were I going totally OTT there's actually space for one of the tiny USB hub boards I have, but I think then situating the external ports for plugging stuff into the device could be hard.

There is space for a Raspberry Pi Zero W, which might be an interesting addition but the phone is actually a more capable computer for any task that doesn't explicitly require a Linux system.

I'm also going to have to face up to the fact this 'quick' build won't be ready for the LARP this weekend. I could rush it and have a version made up but it's actually a bit too physically large to act as the 'covert portable terminal' that fits what the character needs. So I'm probably going to stick some spray paint on an old Sony Ericsson Xperia X10 mini pro, which is an ancient Android handset with slide out keyboard that will work just fine as that prop.

Quick cyberdeck build: Part 3

Did I say quick build? I was obviously mistaken.

I have spent far, far too long messing about trying to get the 3D printed mounts for the trackball and keyboard, well mostly the keyboard, working to my satisfaction.

The keyboard has a kind of rounded kidney shape to it and I don't have the modelling skills to model it exactly so I've done a lot of tweak, print, repeat today.

Also, I did a little more messing with the Arduino library I wrote yesterday and submitted it for inclusion in the Library Manager.

Also, I seemed to kill the cheap clone Leonardo board I was testing with so had to dig out and solder up the headers on another. Obviously not before I wasted time wondering what was wrong. They're tough and 5V tolerant so no idea how I killed it.

Also I faffed with the idea of using a different Android phone than originally planned as it's much smaller but it only runs Android 6, which is frankly way too old and won't handle Termux.

Note to self: Do not get involved in trying to install LineageOS on the Moto G4+, it needs to stay working.

Quick cyberdeck build: Part 2

First, shave your yak.

In the cyberdeck I would like to use this little RGB illuminated trackball sold by Pimoroni. There's python support, but no Arduino library support available.

So I wrote an Arduino library for it.

That's essentially a day wasted. The code isn't consequential but instead of smacking it straight into the spaghetti code I'm going to stick on the Arduino inside the cyberdeck case it's now a library with methods for things I don't need like the onboard LEDs.

Quick cyberdeck build: Part 1

I have, for some time been nibbling at the idea of building a 'cyberdeck' prop for sci-fi LARP which is also a practical, usable device. There's been a ton of these built out of Raspberry Pi machines, but they're generally quite chunky to carry around and often seem to be display pieces more than anything.

The cheapest way to stick a fully featured computer with a screen in a prop is to re-use an old mobile phone and I happen to have a Motorola Moto G4+ which I replaced a few years back. It's still a very usable Android device and mostly I retired it due to charging/battery issues.

After soldering up a connector to the old battery tails it works fine with any old LiPo, within reason.

For it to not just be a phone in a case, it needs a keypad and other connections so I started messing around with an M5 Stack card keyboard I have.

The action is pretty nasty but I persevered and ended up with a 3D printable holder and levers to which I tried to add keycaps.

This does just about work but was still very disappointing and even with a lot of finishing work was always going to be nasty to use and probably not very robust.

The staggered triangular keycaps were a deliberate Blake's 7-esque choice that don't really work without a surround of some kind.

With a game that could benefit from me having a 'cyberdeck' happening in a week I dusted off the idea again and suddenly remembered I have some old Xbox360 chatpads in a box.

These were bought with similar ideas in mind several years ago and I've done nothing with them. These are significantly better than the M5 stack keyboard and are also illuminated in use.

Information on hacking these into other devices is generally very old and often a sea of dead/obsolete links, but I quickly found this video that gives you just enough information to make it work. The example Arduino sketch worked immediately which I call a win.

It's now been tried with the phone and in the dark the illumination works very nicely. That's the keyboard sorted, but I would also like to add the tiny I2C trackball I've got kicking around. Then it needs a case designing and printing. When I started down this road a couple of months ago I made a surround that holds the phone tightly so I just need to do the same for the keyboard and other gubbins.

After fitting the trackball there should still be some pins over on the Arduino. So I might wire them up to some LEDs for blinkenlights, or perhaps to have some extra buttons.

Mixing my ESP-Now mesh, ESPUI and physical objects in a LARP experience

As I've mentioned before, all the stuff I work on tends to be to make props for Live Action Role Playing (LARP) events. LARP comes in many flavours but the variant I'm involved in has people solving problems and fighting skirmishes with Lasertag weapons as part of a collaborative story, usually with a science fiction element.

With the arrival of the pandemic, almost all LARP except that which was conducted via video chat went on hiatus, including a game we'd been planning for a couple of years.

However things kicked off again for us on the weekend of 3-5 September 2021 with an 'anthology event' that consisted of several short games. After a chat with one of the game organisers I agreed to set up some stuff to round their Cyberpunk themed game out.

We play on exclusively outdoor sites, almost always with no access to mains power or permanent Internet service so everything needs to be self-sufficient for the duration of the game. Also with only a couple of hours of setup time available it needed to go out quick and dirty right beforehand.

I put together several elements that got included in the game, spread across three different locations on the site.

When to use send callbacks in ESP-Now

Long time no post, I've been kind of away from microcontroller project work recently. Having picked up coding again I've come across an interesting issue with ESP-Now on ESP8266.

It's not really an issue as such, but might catch you out.

Most of the time, when you send ESP-Now packets with...

esp_now_send(uint8 *da, uint8 *data, uint8 len);

...there's a temptation to assume they will always be sent.

However packets are not sent until the core gets around to it.

If your code does some slow blocking work after asking for the packet to be sent, the core will abandon sending the packet silently. You should instead register a callback function with... 

esp_now_register_send_cb(esp_now_send_cb_t cb);

...and only continue with other activity, especially slow blocking activity, once that occurs.

My code was registering callbacks but as all it seemed they did was confirm a send I didn't really need confirming, the functions were stub ones where I'd commented out everything of note.

Most of the time this won't catch you out, but the timeout before the core abandons sending is rather short. A very dirty workaround might be to delay/yield for a short while after sending, but flagging the send as successful or not in the callback is the better option.

I had been struggling with unexplained packet drops in certain parts of my big ESP application and waiting for the send callbacks has eliminated these. A less I/O heavy application would probably never experience them.

ESP-Now BATMAN Real-time clock

I'm still slowly adding features to my retro computer terminal props and one of the things they lacked was a real-time clock.

So far I've been using 'mesh time' a millisecond uptime value that syncs across the mesh network.

I've now added the option for one or more nodes in the mesh network to share real-time clock information. This leverages the built in libraries for time that are included in the ESP8266/ESP32 SDK. It's just an offset from the mesh uptime with some simple logic to pick a preferred real-time source. Much like the mesh uptime it's not millisecond accurate, but good enough for human scale time, eg. the timestamps on chat messages. It also shares timezone information to correctly handle daylight saving.

At the moment I'm testing with SNTP (which is supported directly in the SDK) but my plan is it can take any RTC source. My code just checks "is the time set?" before sharing time so this should be trivial. this could include manually setting the clock from a watch, but I suspect it would drift fairly quickly. I'll attach some GPS modules onto a couple of my nodes for a time source in the field.

Chindōgu - part 3

I've been tempted for some time to do my planned updates to the Chindōgu, adding sound and more importantly, trying to throw together some code that avoids using Ekiga in the graphical desktop. The Pi Zero really struggles running the desktop and graphical applications but is fine when throwing stuff straight at the framebuffer.

Some research suggests it's possible to spin up OMX player wrapped in such a way it'll play a network stream straight from a camera and I'm going to try and use that for the video at least.

Coincidentally, there's currently a Hackaday retro competition and I think this could make an acceptable entry, if I get the software together and have several all talking to each other. I've accumulated multiple Sony Watchmen and Pi Zero Ws to do the build with.

To get started I've pinned out the main components on a board as it's otherwise hard to work on. One thing I want to do is get the image as decent as it can be and these horizontal gun CRTs were always dodgy.

Lacking a service manual I've worked out the function of the trimmers by trial and error.

• RV501 - Vertical size
• RV502 - Horizontal hold
• RV503 - Keystone adjustment
• RV504 - Horizontal size

Tweaking the framebuffer settings on the Pi Zero and tweaking these has made the display almost usable. With is set to 320x240 you can actually read the command line.

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.

Creating a UI on a microcontroller: Part 12

 

After much yak-shaving to make my UI library usable for other people I've finally made it public on GitHub.

It's very much a 'perfect is the enemy of good' initial release. It seems stable in use, I've written quite a chunk of documentation in Markdown and added an example for every widget type.

Now it's also been submitted to Arduino to see if I can get it listed in the Library Manager. If it is this will be a big milestone for me, giving back to the community.

I'm gonna need a bigger bench

Ever since I got my cheap Ender-2 I've been a fan of Creality 3D printers. That got partnered with an Ender-3 when a cheap Black Friday deal appeared and I can almost treat this one like an appliance. So long as the removable bed plate is cleaned and degreased occasionally it just prints.

I know some people struggle with their Creality printers, build quality can be variable, but both mine have been excellent and an Ender-3 of some flavour is my default recommendation to somebody new to 3D printing.

This is not because they're the best, they're far from it, it's because they're adequate and cheap. If you find you're using an Ender-3 lots, great now start modding it or buy something better. If it gathers dust after the novelty wears off you've only wasted £150-200 or thereabouts.

My Ender-3 gets used lots and short of an Octoprint setup, webcam and lighting isn't actually functionally modified at all. I'm into practical structural prints that will probably get some refinishing, not beauty prints. The Ender-2 is mostly idle but I sometimes run both at the same time if I'm working hard on a project.

Now I've scored a used CR-10 Max, which is at the other end of the spectrum of Creality printers. It's their biggest at a build volume of 450x450x470 and on account of that, by far their most expensive model. The huge heated bed has its own PSU.

For a long time I've wanted the facility to print larger items and I've got some costume parts I had literally been wondering about how to create in the days running up to seeing this for sale. Now I need to up my 3D modelling skills to being able to produce armour pieces.

Breaking out of the Espressif/Arduino rut

I have been noodling around with ESP8266/8285/32 microcontrollers almost exclusively now for a couple of years. 

The absolutely excellent price/feature/performance combo of these Espressif MCUs means I simply don't see any reason to change. There  have been a couple of things I built using AVR based Arduinos for very specific reasons to do with high I/O pin count or generating IR Lasertag signals with hardware timers, but that's it.

I've also mostly given up on Raspberry Pi based things because once an MCU has Wi-Fi and >64KB of RAM you can do most single-purpose things apart from a complicated GUI and I've been working on a workaround for the latter.

Likewise, much as people sneer at the Arduino IDE it is terribly easy to set up and use, broadly supported and just C++ (with an odd/incomplete selection of standard libraries) under the hood.

I have however been tempted by the new Raspberry Pi Pico. It's cheap (for now), dual core, has native USB, plenty of I/O and a massive push behind it comparable to the Adafruit Feather ecosystem. So I tacked a Pico and interesting carrier board onto an order from Pimoroni to have a play with one.

This could be my gateway to MicroPython, although I can see myself also having a go with C++ as this board is actually a good candidate for porting my serial terminal UI library, given it has no wireless connectivity.

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.

Creating a UI on a microcontroller: Part 10

I've done a little more work on my retro 'computer terminal' application. When it started out, the key feature was messaging over the mesh network library I've also been working on.

All the code was there but just commented out while I got the user interface library knocked into shape. So I uncommented it and spent some time making some improvements. Again it also showed up some limitations in the UI library. Most of these were around showing/hiding the cursor and moving it back to the line where you're typing reliably.

With these ironed out, the basic chat functionality pretty much just worked despite being written a year ago and not touched since.

I've done a little video of two terminals sending chat messages. At one point I had a 'bot' that produced Lorem Ipsum any time there was activity in a chat. I must dust that off.

Creating a UI on a microcontroller: Part 9

I finally got this library knocked into shape enough that I could start porting my application to it. Doing so showed up even more shortcomings but I've now fixed this and we're back into feature creep.

The application pretends to be a 'computer terminal' and needs to deliver movie style retro computer interactions. Once of these is looking at files stored on the SD card attached to the microcontroller. Which will sync across multiple 'nodes' running the same code.

I've spent a chunk of time this week improving how large chunks of text (or small files) display and have added support for basic Markdown formatting. You've limited capabilities in a dumb terminal but I think it does well enough at stopping it being a wall of uniform text.

Here's a quick video demo of the user interface in action. It can be driven entirely with keyboard but also the mouse works and you can click the buttons, scrollbar on the text window and so on.

Creating a UI on a microcontroller: Part 8

This week I'm back working on my 'rod for my own back' project, ie. making a library to display a useful user interface over the UART of a generic microcontroller.

This week I've started on actually using it for its intended purpose, faking up a retro mainframe computer on ESP8266/ESP32. Trying to refactor my original code for this application to use the library has shown up a few of things.

First I was definitely right to pull out all the code and turn it into a generic library. Secondly it was missing a few features I need but thirdly and most annoyingly it still has lots of bugs.

In particular I had created lots of bugs with redrawing changing items or things that appear, disappear or change frequently. The main application is too complicated to troubleshoot with so I wrote this trivial alarm clock. You set the time and alarm with the +/- under each digit and when they match it turns red, rings the bell and a cancel button appears.

Trivial as this application is, it's really helped with the troubleshooting and I've added a load more functions, one of which changes the title bar of the terminal emulator, if allowed. It's all boilerplate, not fancy algorithms, but I still get a real sense of satisfaction in controlling an AVR Arduino with the mouse and keyboard on the computer it's plugged in to.

Here's a little video of it in action.

Nordic Semiconductor Power Profiler II - dead useful

 I have been playing with the Nordic Power Profiler again today. I'm doing some SD card benchmarks. Not for any real reason but I'm curious.

As well as the speed, I was interested in the power use. Here you can see writes (on the left) using more peak power than the reads (on the right). However, unexpectedly the writes use less overall power. I assume this is because the code I'm using leaves the card in a different state between reads. The writing does a file.flush(); inbetween each test, so I will investigate if this is what's at play.

This is exactly what I bought this thing for.

Also it's a bit like having a tiny bench PSU connected to your computer with USB. I have used it to replace a 3.7v LiPo battery, direct 3.3v supply to a microcontroller and 5v supply to a development board instead of USB.

I continue to be very pleased with it. Only grumble so far is the 'digital channel'  display only shows when looking at 3s or less of samples. If you're using pins on a microcontroller as a low speed 'status' indicator rather than for busier signals this is not helpful.

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.

Nordic Semiconductor Power Profiler II

Given I've been doing a lot of work recently that involves assessing power consumption, I saw a timely video from Adafruit looking at the Nordic Semiconductor Power Profiler II.

I've been sticking cheap INA219 modules into my various stripboard prototypes and exporting data every minute over MQTT. These are great for broad, macro scale measurements over a long-ish period.

What they can't however do is measure down to the resolution needed to assess how efficient deep sleep is and whether changes to code reduce the time spent transmitting or waiting to receive data over WiFi. The former is very power hungry and must be minimised to save battery. The latter might be tuneable to help.

Professional equipment to do this is really quite expensive. The newly released Power Profiler II kit from Nordic is in the hobbyist friendly price range of ~£100. Mildly extravagant and you could perhaps roll your own but this price point is not ridiculous given the time you'd spend building the tool if you want it to work well. Which is why I've treated myself to my first new tool of 2020.

I've got one of my old macro spreadsheets to analyse for the ESP32-S2 WROOM module, but after that I'll be using the Power Profiler to delve deeper into how much power my prototypes are using and if there's anything I can do to improve this.