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.
LARPCon 2023 interview
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");
Reject modernity, embrace tradition
They've all been variants on an ESP32 microcontroller, some kind of 3.3v power supply then a load of headers for the specific peripherals I want for that specific project.
My SMD soldering is a bit hit and miss, I've had a few irritating failures from creating shorts under big modules like the ESP32-WROOM or the uSD socket. I'm OK at putting solder paste on, but then I tend to very slightly botch the placement and have to nudge the module into place smearing it. I just don't have hands steady enough to get it right first time. I'm fine with the smaller components.
On the whole though it's a positive experience and I've got better at this than when I was first ordering things in 2019.
One of the things that changed since then is the proliferation of microcontrollers that have native USB support. Now there are multiple ESP32 variants with it but it's appearing all over the place, right down to the ultra-cheap RISC-V chips from WCH.
The boards above have ESP32-S2 modules but I'm also making things with the ESP32-C3, which I'm coming to really like due to low cost, native USB for programming and just enough GPIO for most things.
The upshot of this is making boards with USB naturally leads to wanting USB connectors for the boards.
Which I dislike.
Low volume electronics projects with SMD soldered micro-USB sockets have a bad history for me. I've damaged or totally ripped off the socket on more than one board and they're often just a bit cruddy. Professionally made high volume products are better but it's still a weak point.
The obvious solution is to fit USB-C, which addresses many of the issues but have you looked at the soldering footprint for one? Nope. Also I don't need USB-C. These are USB 1.1 devices with no need for Power Delivery or anything smart.
So I've embraced old-school full size USB-B connectors for the larger PCBs. They're trivial to hand solder and robust. Which is good if they're likely to get rough handling, which some of these may do. If it's going in a physically large object the extra size isn't going to matter.
The ESP32-C3 is replacing the ESP8266 in my affections and I ordered twenty of this PCB. It is effectively a small battery efficient development board. So I've reinvented the wheel a bit.
In the kind of projects where I expect to use this I often bury the main PCB inside somewhere but will want the USB socket accessible in the side of the enclosure.
Having the USB socket on a short flying lead is convenient for this and USB is more tolerant of this than you'd expect. In principle you need to match the track impedances/lengths etc. but in practice you get way with it. It adds a lot of flexibility and if the socket gets damaged it can be easily replaced.
Separating the the USB socket also means I can come up with whatever power path I want at time of build. Some things are going to have LiPo batteries and want an onboard charger. Some will have removable batteries. Some will be USB powered. These boards are generic after all.
I may come back to this and design myself a board that includes onboard power path management/charging for a single LiPo cell, which I did on an old design, but for now I'm happy with how these are coming out.
A library full of boilerplate maybe becomes useful?
A while back I wrote an Arduino library to do the tedious bit you add to every bit of code you write for an ESP8266/ESP32 where it tries to connect to the WiFi and waits for it to happen, or not.
This is the most basic stuff and it's in almost every thing I make, frankly almost everything anybody ever makes with an ESP and Arduino. Yet you end up rehashing it and typing it or copy & pasting it. Again and again and again.
So I put it in a library.
It feels like an act of fraud. It's not a fancy connection manager with credential storage. It just tries to connect and feeds back the result. It can optionally stick out a load of diagnostic stuff on the Serial port, which is nice but it still felt like overkill.
Now, inspired by something of Larry Bank's I've made it do geolocation of the device through the https://ipapi.co/ API and it handles the setting of timezone and the system time using NTP.
That is useful as a one-line addition to any network connected project.
A lot of the time people don't bother with their devices 'knowing' the time themselves but I'm a big fan of it and I often use it somehow in my projects.
Useful Sensors Person Sensor testing
When these very cheap sensors from Useful Sensors appeared I grabbed a couple.
Their USP is supposed to be that they offload all the machine learning face detection onto a dedicated module you can just get readings from and will even learn specific faces. In practice I found they seemed to be very prone to false positives so I left them sitting unused for a month or two after an initial burst of enthusiasm.
At LARPCon I had a chat with a droid builder who'd brought one of their in-progress projects along which is part-finished B2EMO replica.
This made me think of the Person Sensor again and have another go with it. For testing I attached it to the cheap pan/tilt setup I have the drone camera in and started trying to filter out the false positives from the Person Sensor.
It became clear pretty quickly that the false positives are very 'bursty', ie. you'll get 2-3 false detections in a row then they disappear. With detection happening at around 5Hz, ignoring any detections with less than four consecutive positives seems to pretty much kill them all without adding much latency.
I then set about making it track the 'best' face and move the pan/tilt setup. After a bit of faffing with preventing constant hunting due to lag I eventually got decent enough tracking so long as the lighting is favourable.
Yes you could do this with a powerful SBC like a Jetson Nano and do it better, but this is doing it with a standalone $10 module and offloading the work. I made a little video of it tracking in my cellar. Beware the static on the audio channel, this video is coming from a USB 5.8GHz receiver and the camera has no microphone.
I think this works passably OK now so I'll be investigating this further and seeing about making a more stable pan/tilt mechanism. I may also wrap the Person Sensor functions up into an Arduino Library for the benefit of others. It's not complicated to use but abstracting stuff into a re-usable library is better.
Subscribe to:
Posts (Atom)