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.

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.

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.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
        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
        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.

Creality Ender spool holder upgrade

I've been using my 3D printers a lot recently and as is the case with pretty much any tool, heavy use shows up flaws.

The spool holder that ships with the Ender models is a simple large diameter plastic tube. Which kind of works but I've realised this has a couple of problems.

The standard spool holder simply doesn't hold the 0.5Kg reels I have, the diameter is too large. More importantly there's a lot of friction that means it pulls the filament tight and I think on a couple of occasions has caused it to snap. I tried adding some shiny tape but it didn't really help.

A long time back I made a freestanding spool holder for my old Ormerod and I was using that for the 0.5Kg reels but the filament snapping is very annoying on a long print as the Enders have no filament sensor.

To fix this I spent a little time today knocking up a similar arrangement to the standalone holder for the Enders that goes in place of the tube. It's some 3D printed parts, 608-RS bearings, M8 studding and nuts. Now the spool moves completely freely and filament falls off the spool nicely rather than being pulled tight.

Job done.

OctoPrint PSU control

I've been using my Creality printers with OctoPrint running on Raspberry Pis for a little while now and it's made them really seamless to drive. One last thing has been bugging me, I want the printers to switch off at the end of a long print. A very quick look online shows there's a plug-in for this so I ordered a couple of cheap SSRs and today spent a little while setting this up.

The plug-in can be configured with a GPIO pin it then uses to turn power on/off and I selected pin 8. This meant I could solder up a very simple straight three pin header with 5V, GND and pin 8 next to each other.

There is a tiny gotcha with this choice in that pin 8 is GPIO14 which is used for the serial console on the Pi by default. So you have to use raspi-config and disable both the console and serial hardware in the 'Interfacing options' menu.

With that done, it was simple to configure the pin in PSU control and check it would turn the SSR on/off. This worked immediately but I found that the action was 'inverted' and the plug-in has a convenient tick-box that fixes that.

To manage the printer power I took the existing IEC mains lead and carefully stripped the outer sheath, exposing the individual wires. That made it easy to break the live connection and have it switched by the SSR without having joins in the earth and neutral.

So this was safe to have floating around on my bench, I designed a 3D printable enclosure and have published it on Thingiverse. This enclosure will obviously work for any use of these little SSRs and I'm tempted to buy a few more to have in stock for future projects. The cable channel is the right diameter for typical IEC leads and grips it when you tighten the cover down.

Creality Ender 3 camera mount

I've been using my Ender 3 a lot and am very impressed with it. Teamed up with Octoprint it's just great. Better 3D printers are legion but this will do me for the foreseeable future.

Octoprint supports a USB webcam for remote print monitoring and I've been using one of my stash of old Xbox LiveCams for this.

However I got tired of having it gaffa taped to a jar nearby as I kept knocking it out of alignment. To stop this I made a little mount which works quite nicely, so I stuck it on Thingiverse.

All it needs is some double sided tape to hold it on the printer and a sticky pad for the camera. Should work with any old webcam with a flat base.

I started out designing something to fix with the bolts that secure the Y stepper motor but realised they're too short to use and have any meat to the print. This version fits reasonably snugly so the tape doesn't really take much load.


This is the LilyGo TTGO T-Wristband that turned up today, catchy name.

LilyGo are known for producing a lot of 'maker friendly' development boards where they cram a lot of useful stuff together on a board in various combinations, lots of it based around the ESP8266 or ESP32.

Chances are there's a combination that might not be exactly what you want, but close enough you don't need to build something up from scratch or a tangle of different modules. Want an E-paper display, OLED display, LORA radio, Cellular connectivity, LiPo charging circuit and ESP or some random combo of 2-3 of these on one board they probably make it. It's all cheap and cheerful AliExpress/Banggood fare and I've bought a few things from them over the years.

This here is closer to an actual product, it's a 'fitness band' looking much like one of the sea of cheap BLE ones available for attaching to your phone but it's maker friendly with a programming cable and apparently usable code for all the components on GitHub.

Based around the ESP32 it's probably not the best platform for something like this as it's too power hungry, but it should be something I can program myself.

I have plans to tie it into my mesh network and directly deliver messages over ESP-Now with no need for a phone.

This is a kind of speculative purchase, I may not find the time to get the code in order for when I need it, but it was cheap as chips and if it does work it will be great.

If it does work I may buy 2-3 more.

ESP32-CAM case, selfie lens and mount - part 1

Poundland (the major UK 'dollar store') had selfie lenses for 50p so I picked up a few to play with on my stash of ESP32-CAM modules.

I've 3D printed a mount that protects the board and lines up the lens perfectly with the existing camera. The lens is an interference fit, at least on my printer, and screws in firmly.

Initial testing seems positive as it really expands the field of view. It's never going to rival a GoPro but makes the module much more versatile. You can buy a wide angle cameras for the ESP32-CAM but typically you have to buy that separately, almost doubling the cost so this was a cheaper way to get similar effect.

It also gives it a 'big lens' look rather than the pinhole camera of the usual module. Which is the aesthetic I want.

I still need to design a back to the case but this should give me a robust housing for these things. Different backs could have different options including a battery holder and switch.

The flash LED is exposed close to the lens but this would work better with a bit of acrylic rod acting as a light pipe and make it possible to make the whole thing passably waterproof with some thought.

The nasty thing with the LED is it shares a pin with the SD card interface so if you access the card it flashes. This is a problem. I have no idea who would have thought that was a good idea, it's not like there aren't any free pins. Fine if you use the camera over the network but makes the flash useless in situations you want to write to SD and if it's battery powered will chew power. Just why?

Mesh networked computer terminals with RFID logon - part 5

After a chunk of work I've got file syncing working fully. The code does a simple manifest of everything on the SD card except for the irritating "System Volume Information" directory Windows puts on there if you view the card on a Windows system.

As my mesh network isn't designed to be high bandwidth and I'm not expecting the files on there to change often, this is a slow, lightweight process. After all it's only running on an ESP8266, don't expect BitTorrent.

The steps the mesh takes to sync are broadly...
  • Recursively iterate the whole file system on the SD card
  • Open each file and do a CRC16 of it
  • Store the full path and filename, size and CRC16 in a data structure
  • Write this to a simple flat file to save this across restarts. Each file is given a sequence number starting at one that increments with each change
  • Once all the files have been read, XOR all their CRC16s together and store it
  • The total number of files and this XOR of the CRC16s are advertised periodically by each node flooding the whole mesh
  • If a node receives a XOR that doesn't match its own it asks for the CRC16, size and sequence number of each file on the other node, one at a time
  • Some simple if/then/else logic decides if it needs the other node's version of the file
  • Files are transferred 64 bytes at a time in a TFTP-esque manner
  • Once the XOR and number of files match the two nodes are considered synced and stop
  • To detect change from an initially synced state, if a file is changed the new CRC16, size and sequence number are flooded to the whole mesh immediately
  • Notification of deleted files use a similar mechanism and stay in the data structure
  • There are timeouts and retries on the various steps in the process so it will fail fairly gracefully and restart
This is probably full of edge case horrors and has no way to handle file conflict resolution. I don't care, this is not an enterprise class distributed file system, it's a bunch of microcontrollers in a field that I need to have the same files on, mostly, and stay in sync, mostly.

Watch the awesome log output!

Mesh networked computer terminals with RFID logon - part 4

This is another little update, I have basic file transfers working, woohoo!

There is no authentication but some basic sanity checking of the data, ie. is the packet from the station it expects, for a file it expects and the chunk it expects next. It's pretty much like TFTP but done over my proprietary mesh network stuff.

I'm currently only shipping 64 bytes at a time, inefficiently packed too, so it's going to suck for large files but the process works and will chunk through a queue of files happily grabbing them.

Now the code needs cleaning up and to allow for things like failed transfers.

I also need to go back to the file manifest handling as it handles change, but not initial seeding. However this is a really positive step forwards.

Mesh networked computer terminals with RFID logon - part 3

The last couple of days I've been messing around with code for building a 'manifest' of the file system on the SD card then notifying changes to other stations.

This has taken a lot of time as I had a few false starts in my reinvention of this particular wheel. I think I trashed my plan and started again at least three times and it's probably still a quite naive scheme. As things stand it's just notification of change, the other station knows if there's an updated file but there's no method to transfer the file as yet.

Oddly I don't think file transfer will be hard. The way I've put my mesh library together makes it quite easy to push arbitrary data around. It will just need to be chopped up into chunks and sent. Maybe also 'lock' the file to prevent local changes while any transfer occurs, just in case.

Mesh networked computer terminals with RFID logon - part 2

Progress on the messaging application is going OK.

I'm having a little aggro with RFID. It works, but not reliably so after 3-4 uses of the card it becomes unresponsive. This may be related to the code I've cribbed from an example to continuously poll the card and check if it's been removed. This might crash the reader but I'm not 100% sure. It's also quite possible I've messed up the state machine that handles the logon process in some way related to idle logoffs.

What is going quite nicely is building a file structure on the SD card with global, per-station and per-user configuration files. This is massively old-school way of doing things but is easily human-readable without writing an admin interface.

An easy example, above, is the 'message of the day' above where the cyan text is 'global' and the 'green' per-station.

I'm now working on an interface for users to display their stored files. Once this is done I would like to make it sync across the workstations with a TFTP-esque setup where the station with the highest sequence numbered file distributes it to the others. This needs to be in place for persistent messaging across different workstations, but will make the configuration more easily maintainable. It's probably going to need metadata stored in each directory, hidden from the user and I can see myself using JSON for that.

Mesh networked computer terminals with RFID logon - part 1

I may have bitten off more than I can chew, but let's see if this works out.

While I've been developing my ESP8266 mesh network library one of the demo applications I've written for it is an IRC-esque chat client with an ncurses terminal interface. It mostly works, but needs some polishing.

This application means you can connect an ESP8266 board into any computer that will run a terminal emulator and chat with other nodes with no infrastructure at all, not even local Wi-Fi. It's completely self-contained, an actual VT100 dumb terminal would work, for that matter, with a little level-shifting of the serial port.

When I went away to Odysseus LARP, they had a forum-esque system that had in-game use, for communication between players, with the GMs and as a source of information. This was an unexpectedly good experience adding to gameplay and was the basis of the in-game hacking mechanic.

For the sci-fi LARP I'm helping run in March while chatting during a writing session we decided to see if we could offer something similar. Odysseus was indoors with a big IT back-end, large player base and huge development team. Our event is mostly outdoors, about 20 players and three GMs plus a few more people helping with props, so tiny by comparison.

Nonetheless I've got a working chat application and want to use the mesh network for other stuff in the game already. Stick some chat nodes connected to laptops in the covered areas where there's power and you're getting there.

Key things I need to add are...

  • Logon credentials/tokens
  • Persistence of messages across logons at different terminals
  • A way to store and show files
  • A 'hacking' mechanic for this that is in keeping with the game

So I've spent a bunch of time this weekend messing around with using RFID cards as logon tokens, storing structured info in JSON files on SD cards, planning and thinking things through a lot.

I think it will work, let's see.

ESP32-CAM programmer from Bitluni

I've got a bunch of ESP32-CAM camera modules and made myself a little breakout a while back as they need a separate FTDI to program. One of the Youtubers I subscribe to came up with a nicer breakout which includes an auto-reset circuit for only $10 on Tindie so I've replaced my scratchbuilt thing with one.

Strongly recommended if you're going to mess about with these boards.

First steps in paint weathering

For an upcoming LARP we are using Bopits for some concentration tests. These are childrens' toys that are a bit like 'Simon' but you hold them in your hand and twist/push/pull various bits in response to voice prompts.

In the game fiction these are supposed to be tools but it has always grated on me that they just look like toys, so I'm stripping them down and having a go at changing the look. This is stock in trade to cosplayers and replica makers but normally I don't bother much with it. I've got a few different ones to work on but so far it's going OK.

I'm going for a well worn look, might have overdone it slightly but it's already much better than gloss white. The weird rubbery lumps sticking out at either end might get replaced with more tool-like 3D printed pieces.