Dastardly Demon Detecting Devices

I've not been blogging recently as I've been working on a complicated multipart prop for a UKLTA Lasertag game which uses the TV show Supernatural as its background.

Some months back I had discussed the game with my friend Mik who said it would involve a demon possessing different people in turn. To which I said, "if I started soon I could probably build something that will track it".

Here's what it ended up as some months later. This is a 'magic compass' made from a cheap eBay purchase which tracks the demon. Who carries around the blue box you can see. Getting this to happen involved a whole load of making and coding.

There are GPS units in the compass, the small box the demon carries and the EMF meter I later decided to build. Then packet radio to share location data. Then relays to relay the data, increasing range.

It all escalated quite quickly and I plan to write each component up properly, but at least I can share the final result.

As alluded to previously I've ended up writing my own simple mesh networking protocol to make it happen. Which is quite a task, but now I've done it it'll get re-used, oh yes.

The Internet of Props

I have a general pattern of escalation in the complexity of the props I'm making. The exception to this was that during April I was making a ton of stuff for the Fallout game but it was mostly set dressing.

So I've ended up with things like a Fallout Vault door, some crates, a Sheriff's  noticeboard, odd looking ID badges and a fake external hard drive. All of which are essentially static, physical props even though a some of this has blinkenlights.

To make up for this, my current project is a multi-part set of props that need to communicate across a LARP site. Which is a large hilly wood where it can take a good walk to get anywhere.

This is challenging. Just think of the difficulties of getting good mobile phone signal in some places and that's a decades old industry with billions of pounds in development spent on it. Or perhaps more relevantly, using walkie talkies on a LARP site and being able to contact each other reliably.

My current approach is to use the ISF band serial radios released by Ciseco and I've posted here about using them before with their 'Internet of Things' protocol LLAP. The first stab at this was a failure. I made a 'GPS tag' to attach to an object so it can be found but it simply didn't have the range in a wood to be of any use.

So I escalated matters.

Now I've got a higher power radio in the tag, which necessitates a separate microcontroller, bigger batteries and a chunky voltage regulator which has made the device grow a bit, but not terribly.

Also I've now made some 'relays' which are similar sets of components in anonymous boxes with better aerials that can relay data packets for other things. When it comes down to it, fitting a radio powerful enough to go from one end to the site to the other in small props is going to be problematic. Hence, relays. I've built two so far for testing, but plan to have four in the end.

There are other bits to the set but I can't post them yet because, well spoilers sweetie.

The introduction of relays made me abandon LLAP for communication, it simply doesn't facilitate this relaying of data and being ASCII based isn't good at passing floating point numbers around without losing precision, which is essential for what I'm building.

So I've written my own vaguely self-organising mesh communication protocol that pushes data around in binary and implemented it as an Arduino library.

It appears to work.

We're testing this on Wednesday in a wood. No pressure then.

Sworn to secrecy

One of the problems with making props for LARP is that very often I can't talk about them outside of the circle of game organisers in case of plot spoilers and generally ruining the surprise.

We recently did a Fallout themed game and this little bunch here were part of it but I couldn't really say anything for just this reason.

Look, this one has a laser!

Not for long though. I've done an exact copy of the first gun body I did this week and tagged it up. So I now have a matched pair of unlensed MP5K-esque machine pistols to use for the upcoming long weekend of Lasertag games. It may involve shouting "Die motherfucka" a lot.

They're very much a cheap and cheerful conversion, but well that was the whole point.

Soon I'm going to have to bite the bullet and make a 'proper' Lasertag gun in the form of a rifle that's got a decent range. Which means bigger lens units mounted very seriously to the body and getting the sights dialled in.

Before this happens I have a Mossberg-esque pump action shotgun to build. Which will be a 'proper' build, but an unlensed one again.

Before they get used I need to do that 'instant start' code I was thinking about. It really shouldn't take long, so I'll tackle it over the weekend while I'm waiting for some paint to dry on something else.

I have the self control of a toddler

I've recently been gifted a pair of identical cheap plastic gun bodies which others bought and decided weren't worth converting to Lasertag. Being super cheap I decided I would anyway. With a ton of projects already behind this was definitely going to be something to tackle once I'd caught up.

Except I couldn't control myself and did one of them this evening.

Once opened up there's a basic spring metal trigger switch and nasty looking but quite decent sounding loud sound/light board with fair sized speaker. It's so cheap and nasty it uses a little incandescent bulb instead of an LED for the muzzle flash.

A little look at the wiring confirmed the sound board has a power supply and separate connection that you take high to trigger it. Perfect for driving from a microcontroller.  When you pull the trigger it also drives a motor with offset weight on the spindle to cause vibration but I decided to junk this.

The battery holder is easily accessible and takes three AA batteries. With alkaline batteries in this gets you 4.5V or more and connected up to the 5V side of an Arduino Nano, rather than the Vin this drives one just fine. Adding a recharge socket and rechargeable batteries is faff I can't be bothered with in a cheap fun gun.

There's also a button on the side, which in one of the guns activates a crummy laser pointer so you can do the red dot thing beloved of 80s action movies. The switch is still there in this gun despite it not having the laser and it makes a perfect reload button.

I couldn't be bothered to make up a lens assembly for these so I stuck an IR emitter in a metal holder and hot-glued it where the laser was supposed to emerge. I've put a plug/socket arrangement in case I decide to go back and fit a proper emitter. Unlensed the range is going to be poor, but I want them for a bit of fun in the Judge Dredd and Fallout based games that are being run at Dropzone next month.

With these post-Apocalyptic themes I want to have one in each hand firing wildly, shouting obscenities in a kind of cinematic manner. Bothering about being seriously effective in Lasertag games is for other people, I mostly want to have fun. Sometimes that means being effective, sometimes that means dying in a silly way and I want some silly at Dropzone.

The only real mod I had to make to the case was to Dremel out a hole for an on/off switch in the side. Then it was wire it up to the Nano, hack some code around and it worked straight away. With no sound board to send serial commands to or different fire modes it's massively simpler than my Skorpion pistol, which being my first Tag gun took me days on end to build.

OK, right now this is single shot with no ammo count but that'll take no time to sort out. Once I've completed the code I'll convert the second body. This has a snapped off foregrip so it'll need some kind of bodgy repair. This may just be a case of filing down the sharp edges and smothering it in gaffa tape.

Something I may try in this code is to make it an 'instant on' gun. Most guns have a start up delay to stop you just turning them off/on to reload or reset the number of magazines available, which would be a bit cheaty as both have an enforced delay. This startup delay seems to take forever and can be very annoying if you've forgotten to switch it on or just want to test a sensor.

As the Arduino has EEPROM built in, it should be trivial to make it record the current shot and magazine count every time it changes. So you can turn it off/on and then it'll just carry on where you left off. It'll then need some kind of button combo to tell it to reset, this could be as simple as holding down reload while switching it on, at which point you get the long startup sequence. Or something like that. Really, the long startup sounds trivial but it is a pain in the arse and it's one of the things tagger moan about, so experimenting with alternatives seems like something to do. If it works well I'll add it to the Skorpion.

I'm sure they're smaller in the movies

Having sussed my software stability problems with the LLAP serial library I polished off the GPS tracking tag I've been making and took it out for a range/accuracy test in the sort of environment it'll get used in, ie. a large hilly wood.

This weekend was our first Lasertag event of the year and the site is a good example of the sort of thing you see in LARP. I wasn't expecting a massive range but in the end was a bit disappointed with only about 50m.

For this I did a slightly unscientific test using a USB stick radio and wandering off with a laptop until I stopped seeing packets from the tag. The USB stick only has an integral chip antenna so I'd expect a bit more with a wire fitted, but this is nothing like the 150m I'd hoped for.

Still, my plan was for this stuff to work in a mesh as even 150m isn't very far in a large wood, so making some high power transmitters with decent aerials to act as relays was kind of always on the cards.

This particular box is just a proof of concept so I can test range/meshing but it'll serve as an anonymous tag that could be taped to a prop that can be 'tracked' or left in a location for people to find their way to.

The good thing is that under the trees the GPS module gets accuracy 100% of spec or occasionally better, so that's down to a 2m area. Which is great, 5m or so would be good enough.

I already have a couple of high power radios and sticking them in boxes to act as relays should be fairly easy. The sticky bit will be the software, so I mustn't underestimate how long that will take. It always takes me 2-3 times longer than I leave time for and I end up pulling some late nights before I need it.

Is this a stand up fight...

I may have found my first bug in a major open source project for years. This has made me unexpectedly excited.

My current project revolves around using Ciseco's RFu328 microcontroller/radio combo and a GPS. This is to do some communication between devices using mesh radio so that they all know where they are relative to each other.

I've built one piece of this system into a small project box and had nothing but trouble with it. Over Easter I was in Brussels and had a few spare days so I took what I needed to work on it with me.

The failure condition was that the microcontroller, which is Arduino compatible, would hang after a while of running. Sometimes there were problems even programming it. As my sketch had got bigger and more complicated the issue became more pronounced.

Thinking I might have a hardware problem I put the code on a genuine Uno R3 and got much the same behaviour, although slightly less flaky.

I put in a watchdog timer to reboot the device if it hung and even this didn't work. It would restart then almost immediately hang.

Messing around wading through my code, chopping piece by piece from it, I narrowed it down to the LLAP serial library I'd been using. So I swapped to a different one. Which behaved the same way despite being a massive refactor and almost complete rewrite of the original.

Hours of head scratching later, I had the culprit. It is almost certainly the Arduino flush() function. Comment it out from the library and the problem evaporates. The library is using this in a justifiable, sensible fashion to ensure that radio output gets done ASAP in a single packet.

Looking online suggests there was a race condition seen in older versions of the Arduino IDE that caused this. Now I've got to get this boiled down to its bare bones and submit a decent bug report with reproducible examples.

You spin me right round

One of the projects I have in the pipeline needs a pointer that spins a full 360 degrees. The idea of using modified servos for this offends me and the position needs to be pretty accurate, so I picked up one of these cheap geared stepper motors and drivers you see on eBay.

OK, so this is all very standard stuff but it's the first time I've played with a stepper so it's exciting for me, honest.

Something I'll have to deal with is getting the initial position of the pointer calibrated then keeping track of it. I'm currently thinking that I will make it return to zero before the device switches off. Alternatively I could write the last position to NVRAM occasionally but this isn't rated for a vast number of writes on Arduinos.

Next thing after this is to start on the physical build of the prop as the various electronic modules are coming together. I think my last worry is a power supply and batteries. I want to use two Li-ion batteries salvaged from a laptop pack to give it loads of poke, but they won't be easy to remove because the prop will be all sealed up and this will make charging them troublesome.