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.
eBike battery mount
GalactiNet GT420 terminal
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.
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.
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.
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.
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.
Donut
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.
Here, put this on.
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.
- They used some proprietary wireless data radios that are no longer made. So while I could have made more things that work similarly with some spare items I bought from the manufacturer, it's a 'dead end'.
- Being themed for Supernatural specifically they're not great for other games that aren't that. The compass could have been used in some other game with magic in the setting but almost all of my LARP is modern/sci-fi so it's just not happened.
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.
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.
The end result has come out pretty much exactly how I'd hoped. Minimum order quantity for the PCBs was five, so I may build a second PDT locator on principle.
The only thing I'm unhappy with is how the colour OLED display is not massively bright. In sunlight the glare on the acrylic used to prevent damage means you need to shade it to read it. So it's better for night games, but that's fine as it's getting a first run out in a night game.
I used a colour OLED instead of a fixed 7-segment LED display from the original prop specifically to make it more flexible long term. I plan to find some larger, 'digital clock' style fonts to make it look more like the original. The currents fonts and UI are just a bit of a placeholder to allow me to test with.
So far I've tested it out to 150m from a beacon and it's fine, which is all the range I need for it. With LoRa, even with the slightly compromised wire antenna inside the case I'm expecting it to hit 200m+.
The user interface only needs to be very basic for end users, as I've written a little web configuration page to set it up more fully for games. The step up from traditional Arduino AVR dev boards in these projects to ESP32 boards really opens up so many capabilities while not increasing the cost.
For now I'm testing using beacons assembled on breadboards, but I will probably assemble the other tracker PCBs I ordered to function as beacons in our game next month. This doesn't preclude later turning them into more trackers by soldering on a display.
Finally getting off the pot
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.
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.
Obscure Arduino tips #4
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...
- Serial - USB CDC
- Serial0 - hardware serial UART0
- Serial1 - hardware serial UART1
Without it enabled you have...
- Serial - hardware serial UART0
- Serial1 - hardware serial UART1
- USBSerial - USB CDC
The 'other' Serial ports don't exist other than when you choose the relevant compile option so you'll get compilation fails when swapping from enabled to disabled for the USB CDC.
Which means writing code that works in both situations needs some mediation. I had a poke around and found the relevant pre-processor directive that helps smooth this over.
Add some code like below and it handles the problem.
#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");
Subscribe to:
Posts (Atom)