When it arrived it was a disappointment. The connector was just about OK but the mount was rubbish and unusable.
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.
Making the unreal real
When it arrived it was a disappointment. The connector was just about OK but the mount was rubbish and unusable.
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.
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.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.
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.
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.
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.
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.
Now I'm back on this nonsense again but this time it's for a sci-fi game at Dropzone 2023.
The Supernatural props were great at the time but they had a couple of inherent problems.
A lot of UKLTA games happen in our High Frontier game setting, which is broadly Aliens/Predator/Outland/Space Above & Beyond grungy evil corporations and monsters in space sci-fi.
Which makes an Aliens prop work nicely but the PDT locator is also very generic, it's just a dull tube that shows the distance to something on a display and beeps. So it won't stick out in any modern/sci-fi game. It could function to find a person wearing a tracker or equally be a geiger counter or locator for a stash of equipment.
Since I built the Supernatural props, LoRa has emerged as a cheap and viable long range data radio technology. It's also standards based so not likely to disappear any time soon. I've used an RFM95W module in this, which is the default cheap LoRa module used by 'makers'. It's connected over SPI and handles all the basic LoRa Tx/Rx stuff while also feeding back information about received signal strength etc. Sending data from one device to another is really quite simple but you have to be a good citizen and not transmit too frequently. LoRa comes with rules about duty cycle/spreading factor/power that you should stick to. I've tried to minimise my transmissions but haven't yet actually checked if what I've written complies.
We've also had an explosion in more powerful microcontrollers, I've used an ESP32-C3, which means I can configure the device with a little web interface over WiFi. Should I get around to writing the software using the ESP32-C3 would also allow it to detect Bluetooth tracking beacons and I've got a stash of these, so I intend to have a go at that.
I think the ESP32-C3 is becoming my go-to microcontroller even if something doesn't explicitly need WiFi connectivity. It has a great mix of features and just enough GPIO to get stuff done. With WiFi switched off it still uses more power than some microcontrollers but clocked down to 10Mhz is about the same as a traditional AVR Arduino. Then when you need to configure something you can temporarily turn up the clock, connect to WiFi and have a proper user interface from your phone or PC.
Despite the enclosure being oversize in comparison to the movie prop, mostly to accommodate the display and keep the proportions looking OK, the electronics were still going to be a tight fit.This led me to order a custom PCB from JLCPCB that combined most of the modules together in a compact manner.
This shrunk everything down an awful lot, with the heart of it squeezing directly behind the display.
With the bulk of the space inside the tube free I easily managed to fit a decent size recovered LiPo cell from a discarded vape, a TP4056 protect/charge board and USB socket for programming.All our Lasertag LARP weapons are 'homebrew' and mostly rely on a small number of people doing cottage industry builds of PCBs for them but I've previously made things of my own with Arduino Nanos and stripboard.
The barrier to committing to a 'proper' design of my own has been an inability to settle on a good solution for generating the sound. Generating the Lasertag signal is well understood but we've previously relied on bought in boards that play back uploaded samples, which have been of variable quality and sometimes a bit too quiet for my liking.
With the knowledge that the ESP32-C3 can use I2S to play back sound I've had it in my head that it should be possible to make a Lasertag board based around one. This is especially so as the ESP32-C3 also has the 'RMT' peripheral designed for IR remote control which generates signals similar to our Lasertag system in hardware.
After a bit of prototyping at my desk I got the infrared data transmission, screen and sound working so I've committed a design to EasyEDA and ordered some boards from JLCPCB.They're very much MVP boards, with an LDO for voltage regulator (not massively efficient) and the onboard lithium cell charger being a bought in TP4056 module. This will let me test the design at our next event in May, hopefully.
The desktop testing seems to work OK but real life testing will show up how well it works with other sensors and long ranges. I may have underspecified the MOSFETs and passives, but I'll find out.
One thing that is a minor irritation is the number and naming of the hardware Serial ports changes depending on whether you enable 'USB CDC on boot' and this isn't immediately obvious how to deal with.
With USB CDC on boot enabled you have...
#if ARDUINO_USB_CDC_ON_BOOT == 1#define SERIAL_DEBUG_PORT Serial#else#define SERIAL_DEBUG_PORT USBSerial#endif
You can then just use
SERIAL_DEBUG_PORT.println("Hello World");