m2mDirect v0.1.1 release

A long time ago I created m2mMesh, which was an Arduino library for a self-organising mesh network onESP8266/32 that allowed you to do machine-to-machine messaging.

This has been quite useful but sometimes it's overly heavyweight so I've written a simpler thing for direct links between two devices. Also with just two devices you can use the built in encryption features of ESP-NOW. Lack of encryption was always a concern with m2mMesh.

This new library is m2mDirect, which I intend to use for control/telemetry of the various rovers I've been working on.

It's not in the Arduino Library Manager yet as it needs more work, in particular ESP8266 support and channel negotiation, but it is now available on GitHub.

Obscure Arduino tips #5

Just today I spotted an excellent 'ease of use' thing in the Arduino IDE that Sparkfun had used in one of their examples. Maybe consider adding it to any code you are going to share.

There is a pseudo-URL you can add as a comment in code that will link to the Arduino Library Manager and search for a library.

For example

#include "SparkFun_TMF882X_Library.h" //http://librarymanager/All#SparkFun_Qwiic_TMF882X

This way if somebody has your code they can click on the link and be taken straight to an install option within the Arduino IDE.

This is a really nice little usability feature I had no idea existed.

I'll gloss over the fact Sparkfun originally typo-ed the link in the sketch in question. :-)

Trackable Lasertag sensor

As a partner piece to the PDT Tracker I needed to make some 'wearables' to go with it.

My original plan had been to take some of the PCBs made for the PDT Tracker and jury rig them into that wearable.

I did this in May but in the end the software wasn't ready for the event I needed them at and even had it been the game overran and we didn't get to the point where they were necessary.

So I've had a couple of months to come up with a wearable beacon and I decided to go for an MVP of my Lasertag 'holy grail' idea: a  Lasertag sensor that is remotely trackable and sends status updates.

I consider it a 'minimum viable product' because not only is the software a first attempt it relies on external modules for some of its features.

All the PCB has on it is an ESP32-C3 WROOM module, RFM95W LoRa module, LDO voltage regulator, a few passive components and solder headers for various things.

The GPS will always be a bought in module but relying on an external USB breakout, LiPo charger and sounder makes it bulkier than it otherwise might have been. I also put the components all on one side for easy soldering which gives it a fairly large 'footprint'.

Initial desk based testing with the board you can see above showed everything to work so I designed a quite utilitarian 3D printed enclosure and assembled four headband style sensors to test.

Convention in UKLTA is that sensors are worn on the head and this prototype ended up slightly bulkier than the commonly used sensors but with a LiPo inside rather than 3x AAA batteries it was no heavier.

Getting everything inside the case was fairly easy but construction of the headband which includes four IR sensors and four 3mm LEDs was quite tiresome. I'd opted to make little 3D printed enclosures for these and this really exacerbated struggles with getting the wiring done tidily.

In the end this all worked so I'm going to improve on the software between now and our next event in May 2024. I might do a second revision of the PCB with more functionality on-board but without a clear requirement for the system yet the four prototypes I have work and can be used to further test the concept.

One of the things that didn't get tested is haptic feedback, mostly because I was rushing and I didn't have a nice compact vibration motor to use. It's planned though as one of our members is hard-of-hearing and also I really like the haptic feedback in the Laserwar equipment I use at another LARP.

So far this post has been all about the process and the componentry but here's the concept I'm trying to realise.

  • Every participant in a LARP is location tracked, players, crew and 'monsters'
  • The 'health' of every participant in the LARP is tracked
Obviously this only makes sense in an outdoor LARP with an element of tactical combat but that's what I play.

The purpose of this is essentially to allow us to replicate the sort of thing you see in action sci-fi media where there are one or both or some combo of the following two things.
  • A 'tracker' that shows the relative location of friends/foes to players eg. the Alien/Aliens motion tracker
  • A 'squad status' system for squad leaders eg. the 'command desk' in the APC in Aliens that shows the 'health' of the squad.

This is all very mil-sim industrial sci-fi stuff but that's what I want from my games. In principle it should also be able to link the sensor to my prototype Lasertag weapon board using Bluetooth and show when a participant is firing, out of ammo etc.

I would also love to partner it with my HelmetCam prototype for the full Colonial Marines experience but the challenges of WiFi outdoors may make that impractical.

These ideas are taking a long time to come to fruition but I am slowly edging towards them. I bought the GPS modules used in this back in 2020.

eBike battery mount

Way back at EMFCamp I bought an eBike battery to use in a Rover. It came bare without a connector or mount. It took me a long time to get around to searching for a connector and ordered something from AliExpress.

When it arrived it was a disappointment. The connector was just about OK but the mount was rubbish and unusable.

Yesterday I finally got around to designing a 3D printed block to go on the supplied rail and hold the connector firmly in place, unlike the awful flimsy plastic pieces supplied.

I also had to drill the rail to make the locking mechanism work, but that came out OK.

Now I need to get on with the rest of the Rover.

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.

Adding MilesTag to my Arduino Lasertag library

I have for quite some time been attending LARP where Lasertag is used for the combat system. I now participate in games which have two incompatible systems, the UKLTA which uses a proprietary development (Data-over-Tag) of the early Worlds of Wonder system and Humanity Ascendant which uses commercial equipment from the Russian company LaserWar. LaserWar is compatible with the MilesTag system with a few additions for game admin.

For quite some time I've wanted to have a play with time LaserWar kit to see if I can throw some code together that works with it and I finally got round to borrowing some.

MilesTag is simpler than DoT and it didn't take long to update my Arduino library for doing Lasertag so it can both send and receive Laserwar/MilesTag hits. Sending LaserWar game admin codes would also be possible, they're just differently formatted, sometimes longer IR packets.

Sadly I can't make this open source as the packet format for UKLTA DoT is proprietary, but I might strip out the MilesTag parts separately.

LARPCon 2023 interview

 I was at LARPCon 2023 with some of my old props that make good table pieces and got interviewed by LARPBook. There's a small amount of cringe in my off the cuff talk but broadly it's OK.


Unusually, I've made a piece of costume for an upcoming game. This is the Star Wars Endor Trooper 'donut' helmet. It's not a 100% perfect piece of cosplay apparel but it works pretty well. I took a 3D printable model from Thingiverse, a surplus Austrian Army cold winter cap (which has suitable ear flaps), added a couple of big rubber washers for the earpieces with some 3D printed surrounds/caps and threw it together.

I don't often do 3D printed costume pieces (mostly because I hate sanding and painting 3D prints) but I'm really happy with how this came out.