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.

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.

It is more complicated than that

It seems that on the RFu328 at least, pins 11 & 12 on the Arduino float high when there is no power to the device. This is with a 1M pull-down resistor to ground. Probably something to do with them being usable for FTDI programming.

Which makes them no use to drive the MOSFET for the soft power switch as it's then 'always on'.

Moving the power connection to pin 2 fixes this. I'm using pin 11 to drive a little vibration motor but if that spins briefly on boot that's no big deal, so I've left that in use.

Live long and prosper

R.I.P. Leonard Nimoy.

I find it kind of odd that on the weekend of his death I have spent a fair chunk of it pottering about with something called LLAP.

One of the things I want to get on top of this year is a set of location aware props. The plan is for Spookytron 2 to be wireless and location aware, plus later on I want to build a 'scanner' that can find things, either by having active 'tags' or waypoints.

To this end I have bought a couple of cheap GPS/magnetometer modules from eBay, the sort intended for fitting to a drone. These have a u-blox Neo-6M GPS and HMC5883L magnetometer combined on one board. They're not really integrated in any way, just two things on the same board. You have to power them separately and it even suffers from the GPS having a regulator so it's 5V tolerant while the magnetometer doesn't from what I can see.

After a little looking around to find the pinouts, which aren't widely mentioned, and a play with the examples for the TinyGPS and HMC5883L libraries it all went together very easily.

LLAP less so.

When I was working with LLAP to trigger sounds on another board it was very simple, send a message and deal with it. However, having to constantly process the NMEA feed from the GPS to get a fix showed things to be more fiddly than I'd like.

The Arduino SoftwareSerial library you have to use because the hardware one is connected to the SRF radio has to do a fair bit of work in the background. So it needs the buffer emptying all the time otherwise it drops characters and sentences of GPS data get corrupted. In fact it seems to struggle a bit even when not much else is going on, I need to investigate why as I don't think this should be the case.

The other difficulty I've had is that the LLAP library issued by Ciseco is not only still quite limited in function, it also seems to play poorly with TinyGPS. They say it's in beta but there's sadly no sign of active development.

The library is implemented using the SerialEvent routine, which is kind of like an interrupt in that it is triggered only if there's serial data to be read. However it happens at the end of the main loop, not when the event occurs.

The standard examples for TinyGPS have you slurping as much NMEA data as you can in one go to avoid missing data in the main loop. Then at the end LLAP slurps however much it feels like and faffs around with it. It should only be 12 characters in each packet but it still seems to faff a bit.

This adds up to LLAP messages getting missed (a lot) and GPS data getting corrupted (a bit) as one thing then the other blocks. I'm going to have to do a bunch of messing around to make it so all this blocks as little as possible.

TinyGPS will play nicely with this, but I can see the LLAP library will need a full makeover. Given none of the functions for two way communication seem to be implemented, you can send messages but won't see acknowledgements or responses, I can see me rewriting the whole thing.

Or ditch LLAP altogether, the 12 byte packet is already shown to be an issue for sending GPS data as you only have 9 characters to play with. Once I start having to code a way for floating point numbers to be fragmented or encoded before being pushed around the yak shaving will be in full swing.

Spookytron 2 first testing

A very long time ago, my first ever Arduino project was Spookytron, which in a fairly dumb way played spooky noises for use in LARPs.

PIRs detected motion and it played sound somewhere else. If you walked towards the sound it stopped.

Very simple stuff but it was my first project and it was surprisingly effective.

The big problem is it was housed in one central box and had speakers on the end of very long cables. For convenience I used CAT5 cable as it's something that's easy to buy pre-terminated and I had a load anyway.

It got used twice but the need to lay massively long cables round a wood got tiresome very quickly. As soon as it got used people said, 'can you do a wireless version'.

When I saw Ciseco's SRF radio technology it was obvious this was a good use for it. I've been busy with other things, but now I'm having a first stab at it.

Here we have a very simple mesh of two nodes. Mesh discovery isn't in place yet and it's got one sound PCM encoded into the sketch but if you trigger one device, the other plays the sound. I've used Ciseco's LLAP protocol for this which is trivially easy to work with, it's just fixed length serial human readable messages with a two character address field.

The plan is to do this with some RFu328s which will be much smaller but right now I'm prototyping it with a couple of Unos and the shields from the Kickstarter.

The LLAP library Ciseco released needs a ton of work, so I'll hunt the Internet to see if anybody has done a better one. I seem to remember spotting one a while back.

RFu Protoyping

Having messed around with my RFu uploading simple sketches to send serial data I really need to start prototyping with it. The board Ciseco sell for this is pretty much bare. Tonight I've added a breadboard and headers so I can start messing around.

First up I think will work on a wireless PIR detector. Basic stuff but I want to work with LLAP a bit so it is 'smart'. This means learning an LLAP address from the hub and storing it in EEPROM, turning power to the PIR detector off and on, being able to sleep for a set amount of time, warn when the battery is going flat and so on. Stuff that should be the foundation for making a network of these things that is controllable and robust rather than just something that blasts data over serial.

Dangly bits

Today I have been connecting dangly bits to things. First up simple whip aerials to the Ciseco Explorer and Slice of radio. Range indoors isn't as good as I'd hoped, walls really do kill the signal.

Then I added the Pi Noir camera my brother bought me for Christmas to one of my Raspberry Pis. This works beautifully and produces a great image but seems to need a bit of faff to make it work with v4l.

The whole thing, especially the ribbon cable, feels like it won't stand rattling around exposed very well. So I've removed it again and packed it away until I can come up with something to hold it secure and have a bit more time to mess with it.

RFu rescue

If you're thinking of playing with the Ciseco RFu radios I would recommend getting one of these from them at the same time.

Having painted myself into a corner by uploading an stupid sketch that saturates the radio, it was just a case of changing a couple of jumpers, popping the RFu into the socket inside and reprogramming it.

It's only a couple of quid more than their straight USB stick radios but you get yourself a more versatile device. This is doubly so if like me you don't already have a USB FTDI interface.

While the lid's open I may fit an external whip antenna, it seems rude not to.

Pirate radio

A while back I started thinking it would be really good to have a way to make an 'internet of props' for games. Some way that things could communicate so for example a motion sensor could trigger and tell players or GMs it had happened. The radio kit would need to be small, power efficient and affordable.

As mentioned in my looking at the solar lights I think the SRF radios by Ciseco fit the bill and I finally got to have a play with them this weekend.

The first photo is of the RFu-328, which is the tiny board occupying the socket on the top left of the prototyping board. This is an Arduino Uno compatible device with built in radio and you can program it over the radio too (OTAMP), which is frankly wonderful.

Although I can see it being a worry once you've built a load, you're going to have to make sure that you only have the one you want to program powered up when you do. There are clever things can be done with using a different channel for programming but I think that could be a pain to administer as you'd need to keep reconfiguring the radios.

You get these for about the price of a decent Uno clone, although it's designed for embedded use so you need to add a 3.3v PSU and it's in an odd Xbee compatible form factor. I can see me soldering wires straight to them.

The second phot shows their 'Slice of radio', which is a plug and play SRF radio for the Raspberry Pi. It just plugs into the GPIO connector and works, although you need to disable the serial console on the Pi so it can be used effectively for anything else.

I also bought their USB radio, which doubles as an FTDI serial device for programming things with. No photo as it's an anonymous black box.

When I first started I got very frustrated at my inability to program the RFu over the air. By default the USB device is not configured to send the 'remote reset' needed for this to work. Sadly the Ciseco documentation is at the same time both great on detail but unhelpful and a bit disorganised so it took me a while to realise this.

If you download their configuration manager it helps with the AT commands necessary and gives you an easy way to change them. Nothing you couldn't change with AT commands manually but when you start out there's the usual problem of not knowing what you don't know.

With that minor niggle sorted, programming the RFu-328 was a doddle. I put the standard blink sketch on, just printing On/Off to the serial port and it immediately worked. The only thing to bear in mind is that 'pin 8', which doesn't appear on the RFu for normal use, enables and disables the radio so the sketch needs to bring it high during the setup function and the serial port has to run at 115,200 baud.

Now, however I have made the RFu-328 unusable for OTAMP as in a moment of idiocy I uploaded a sketch which blasts characters out of the serial port as fast it can manage. Which ties up the radio and stops over the air programming from working. So I'm going to have to pull it from the development board and use FTDI to program it directly.

I also had a play with the Slice of Pi, running one of my existing Python sketches that does serial output and simply pointing it at the radio instead. It is, as they advertise, just as simple as that.

Once I've rescued the RFu I need to play with Ciseco's protocol for the 'internet of things', LLAP. Reading around the topic it sounds like it's a bit unfinished but then it is at least a start and means whatever I do will have a passing chance at fitting in with other uses of the radios. LLAP has very simple human readable 12 character packets designed for tiny low power, low CPU devices like these. Were I to write something myself that would be what I'd be aiming for anyway.