3D printed Data Slate props

For a long while I've been using old Nexus 9 tablets to act as 'cyberdecks' in our Cyberpunk LARP, but I was recently asked to dress them for a 40K themed one this summer.

The old 3D printed cases were getting long in the tooth and were clearly just unpainted poor quality 3D prints. So I started completely from scratch for this, only re-using my CAD model of what I needed to hold the tablet securely and operate the power and volume buttons on the side.

One of the major things I wanted to get away from was the obviously rectangular shape of the tablet screen. It's a common sci-fi trope for screens to be weird shapes and to emulate this I modelled a surround with truncated corners and cutouts for the cameras and speakers.

This looks great so long as the tablet is asleep, but once it wakes up the real shape of the screen is obvious. There's only so much I can do here and while I could have covered some of the usable area Android apps tend to quite rightly assume the whole screen is accessible.

On the old tablet holders I had added some old bag carrying straps, which are very practical but untidy looking so I added a very chonky carrying handle as part of the case.

This makes the whole thing physically large, which has the added advantage of making these hard to hide or just stuff in a bag. It's a not uncommon problem in LARP that acquisitive players will squirrel something away in their bag and it's never seen again unless they want to leverage it somehow. These were to have PDFs on them that were plot-relevant and we wanted that information very clearly available.

Annoyingly there's no open source 'kiosk mode' application for Android that I could find but to make sure the PDFs were visible whenever somebody woke the tablet I used the "Librera FD" viewer and the basic screen pinning functionality in Android to keep it maximised.

When asked to make these I wasn't sure how long the documents would be so I decided to add physical controls for paging through and searching documents. There's a scroll wheel, two buttons to page up and down plus a keyboard for text entry. This re-uses an X-Box 360 chatpad as making your own small keyboard keycaps that don't look terrible is very awkward and fiddly. There's also a piezo sounder to do keyboard/button bleeps.

This section is the part I'm least pleased with: the chatpad is too small and the buttons I ordered were too long to allow me to inset it like I did with the tablet section.

The design is ugly because I was rushing and I will most likely re-do this part before they are used again. I may even go as far as making a custom keyboard using tactile switches that fills more of the area.

These physical controls are driven by ESP32-S2 dev boards acting as USB OTG HID devices. I ran into a bit of a struggle with the code for this. Every time the tablet went to sleep, it would disconnect the USB devices and refuse to reconnect. I think this is related to this reported bug but was in a hurry to get this done so just made the ESP32-S2 restart whenever the tablet went to sleep. There is a little latency on waking it up but not a great deal. I would like to add more functionality to this setup, including my LoRa mesh network messaging stuff, so I need to overcome this problem. The 'cheat' would be to connect the ESP32 over BLE but given I have a direct physical connection to the tablet this sort of offends me and I'd need to swap to an ESP32-S3.

In the end though, this all worked out well, I got four of these made in different colours so they could be told apart and the paint weathering on the main body looks good. I didn't have time to weather the control sections so they just got some scratches but if I'm going to re-do them that's fine. I may also try to make some left handed variants and some without the big handle.

These will definitely be getting a load of use. Put Termux on them and they are almost 'real computers' and while the performance is poor in modern web applications we always curate what we let our players access. I've got a drawer full of Nexus 9s so printing and painting a few more of these over the next few months will get me a nice stash of usable props.

3D printing Lasertag lens units

For over a year I've been faffing with my own Lasertag PCB design but keep dropping the project when something else needs doing.

The PCB design seems OK but with a couple of poor decisions I'd fix were I to order more. The 'beta' software works so I fitted them in two of my own Lasertag weapons and one worked great but the other not so much. I think it's got two current limiting resistors because I didn't realise there was one in the existing lens unit already.

What I don't know was what the real potential of the board was with the component choices I'd made.

Having a board design sort of goes hand in hand with needing lens units to match and I want to do what Phil from UKLTA has done: design a re-usable 3D printed lens unit that can be included in larger things, or printed out to attach directly to conversions. This is especially true if I want to maybe make some 3D printed 40K themed weapons for our upcoming 40K LARP. 

I ordered some 25mm acrylic lenses a few weeks back and I've had a go at designing an adjustable 3D printed lens unit that uses them but what I really needed was a way to range test away from Lasertag events that didn't involve the Police being called on me. Being based in the UK this is a real concern. So last week I made up a 'gun on a stick' which looks nothing like a weapon apart from the attached sight.

Today I've done some testing at the Hackspace on the field and it's "good enough for The Grange" with no trouble hitting a target across the width field at ~140m.

Unfortunately this isn't really a good test as I arrived later than planned and the photos don't really show how much the light was going. I need to test again on a bright sunny day. Home is just a short walk from Wanstead Flats which is a huge area of common ground so I'll have to make a trip there when the sun is shining.

Good progress though.

Hackspace access control

I'm a trustee at East Essex Hackspace which is currently discussing buying a fibre laser and it's rekindled the desire for 'toolbots' to control access to things. Originally I was looking at this over a year ago but got busy with other things so shelved it and then the need suddenly seemed less urgent.

One of our challenges is that when we opened we used some Wiegand RFID readers for our door entry system and fed the UIDs they gave into our membership database. Later on we found out that these UIDs weren't the same as the UIDs other things reported. I did some fiddling around and realised a simple XOR and byte reshuffle that fixed this so we were back in business until I built something using this and found it wasn't right for some issued cards. 

Then the access control project got shelved.

Having dug out my access control mockup again I armed myself with a pile of cards that I know don't map IDs how I thought and quickly realised if they have a 7-byte UID then the byte order reshuffle is different than for a 4-byte UID. So we're potentially back in business.

For the hardware I've taken a bit of an executive decision on the basis that whoever does the work gets to say how it's done, otherwise endless bikeshedding occurs. The hardware will be based on an Olimex ESP32-EVB which is an ESP32 dev board with Ethernet, onboard relays and a bunch of hardware we probably don't need. They're reliably available and properly certified.

To add the RFID reader I've designed a little 'shield' that plugs into the UEXT connector on the EVB which I'll solder some cheap MRC522 boards to.

It also breaks out some GPIO and has LEDs and somewhere to connect a sounder. I'm not even sure if we'll use a sounder, but I just wanted to get the board ordered.

Work on the software has been ongoing for ages but I've started poking at it again and one of the other Trustees already did a bunch of stuff in our membership database so I'm hoping this project can get done without too much pain.

Each tool will have different ways of limiting its use but my expectation most will already have an interlock or emergency stop that can be connected to one of the onboard relays of the EVB. I'd not expect these devices to control the main power feed to the tool unless it's a very small one.

Hoverboard comms library

I'm back making silly moving things using hoverboard hub motors and re-flashed hoverboard controllers.

For months on end I've been vaguely putting off working on the big 6-wheel platform I started because I needed to write a library for the comms protocol so I wasn't committing the sin of copy & pasting great swathes of code to run the three separate controllers.

Now I've finally sat down and got round to it so the excuses for not progressing the big rover project are evaporating. I only started thinking about this two years ago.

MU|TH|UR setup script

I have now (mostly) documented/automated how to create a text-to-speech bot as recently used at our High Frontier LARP.

Instructions are here.

retroTerm release 0.1.6

At our recent LARP High Frontier: The Drake Objective I used retroTerm my ANSI/VT terminal GUI widgets library to create a prop where the players interacted with an offscreen extra-terrestrial intelligence through a purposefully retro computer interface.

This is the whole reason the library got written in the first place.

Work started on retroTerm in maybe 2019. Then the game it was scheduled to be used in got postponed due to the pandemic and despite the extra time that afforded me I didn't manage to deliver anything usable for the game when it finally happened.

It was a terrible case of overpromise and underdeliver, ie. I delivered nothing usable. The work on the retroTerm library itself was fine but the messaging system it was to provide the user interface for just wasn't stable and we abandoned it at the last minute.

When a short 'midqual' LARP event came up last year I rewrote all the messaging code and produced a version of the thing with a cut-down retroTerm user interface that saw a tiny amount of use. There were still some frustrating problems though: centred on it needing an accurate timestamp for all the messages and me getting caught out by GPS just not working for this. I had not realised the building it would be used in had a metal roof and the dubious signal ended up causing it to end up with spurious date & time values, some in 2080. Which is perhaps a failing of the GPS library I used to process the NMEA sentences but regardless this was not good and caused it to misbehave.

As a result when The Drake Objective was announced I made some new hardware that included a hardware real-time-clock and did a ton of work on making damn sure the setup would have a correct time. It couldn't just connect to WiFi and get it from the Internet as it'd be used in a building in a field with no services and also very dubious 4G signal we weren't sure would be usable.

The new hardware worked around the issues well and the whole prop behaved pretty well during a weekend long game albeit in its still quite cut down form.

Part of putting this thing together saw me make some improvements to retroTerm.

I found and squashed a memory leak[1] and have just improved the way it handles 'list box' widgets so I feel it's in a pretty solid spot. Today I fiddled around testing it on an ESP32 over Classic Bluetooth Serial rather than a wired connection and this worked trivially easily.

This is something I can imagine use cases for so I'm glad I finally tried it out. Often ESP32 projects get built with little captive web portals to configure/control them but this gets 'big' quickly. Being able to run a wireless retroTerm interface for this is something I'm going to try in an upcoming project.

Anyway this was all a big ramble to say retroTerm 0.1.6 is out and seems to be working well.

Next on my list is making that multi-user peer-to-peer messaging system I originally promised back in 2019 happen. Even if we never actually use it I want to have done it and to that end have been writing great swathes of code in preparation already which I've been sticking in some new libraries. When they're more finished I'll share them.

[1] Which only showed up if constantly updating something like a clock widget

You now have fifteen minutes to reach minimum safe distance

We have just run a sci-fi LARP where we wanted to have the classic trope of a computer with a sad voice telling the players bad news like MU|TH|UR in Aliens, GERTY from Moon, HAL in 2001 etc. etc. It's a very common part of the aesthetic of a certain kind of sci-fi.

Our game was set in the Aliens universe so we wanted to emulate the female voice from MU|TH|UR. None of the GMs are voice actors (or female) so I made a text to speech device for this.

I got quite far down the rabbit hole of power saving and solar charging on a Raspberry Pi 3A+ then somebody offered to bring a massive lead-acid battery to the game for me so I abandoned worrying about all that because brute force won out. I will come back to it though as I want to make a nice portable outdoor Pi to provide 'infrastructure' at future events. Having infrastructure I can deploy easily in a field with no power has been a constant thing I've been nibbling at the edges of for years mostly with ESP32s and mesh networking.

I put the Raspberry Pi 3A+ into a waterproof box I had and powered it off that big battery all weekend. I even forgot to shut it down on Saturday night and it jut kept going.

The Raspberry Pi communicated with the Internet over 4G using a dongle I had kicking around which conveniently has a tiny NAT router in and presents as a USB ethernet so 'just works' with zero configuration on the Pi, or pretty much anything else. I'll probably try find another dongle the same, it's handy for these reasons.

I then made a 'bot' in the popular messaging app Telegram using their example Python script and used the Microsoft Azure AI voice engine to generate a very convincing voice. This was not a very sophisticated script, really just Telegram's example bot script, their recipe for restricting access to certain Telegram IDs and Microsoft's example text-to-speech script all smushed together with my rudimentary understand of Python as I'm normally an Arduino/ESP32 C++ person.

None of this needs much processing power: an original Pi could probably do it, except the Microsoft library expects a 64-bit OS so the Raspberry Pi 3A+ was a good fit. It's the lowliest, most power efficient 64-bit Pi that also has an analogue audio out and I had one in my stash of dormant SBCs.

The end result was we could type a message on our phone into a Telegram group chat and it would then ring out across the game using walkie-talkies to broadcast it over a large area. There was a little bit of impedence/level matching needed for the line out from the Pi to go into the headset input of the walkie-talkie. I used voice activation in lieu of 'push-to-talk' but that too worked great once I added a preamble 'bong' and little gap before the talking. I may go back and investigate triggering the push-to-talk through the headset connector using one of the Pi GPIOs as it's more predictable and the headset has the feature: I was just bashing the thing together quickly for the game.

"You now have fifteen minutes to reach minimum safe distance"

If players wanted to talk to MU|TH|UR they would just talk on the same walkie-talkie channel and we were listening. We had some quite long player conversations back and forth with MU|TH|UR like this and it worked brilliantly. We'll be using this setup again.

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.