Thursday, 17 April 2014

No posts for a while can only mean one thing...

...real work is taking over!
That's not strictly true, but one of the joys of working as a computer programmer is that often there's quite a large overlap between hobby and work. The last few days, I've been getting to grips with Linux and PostgreSQL and PHP. Up until the turn of the year, I'd been Microsoft through-and-through. Not because of some fanboi love-in (ok, maybe a bit - I still think Microsoft wrote some of the best applications in the last twenty years) but because it worked perfectly well for what I needed, both in work and at home.

I'm a total noob with Linux and Postgre - I've used PHP and even mySQL but always within a familiar Windows environment (ok, stop shouting at the back, we all know PHP plays nicer with Linux - but it does work on Windows too!)

I had a crash course in setting up a Linux server, thanks to Justin and DigitalOcean.
I was really impressed by DigitalOcean and how easy (and, let's be honest, cheap) it is to set up a server; $5/month gets you a 20Gb Linux Ubuntu server with 512Mb RAM - not the biggest, baddest server you're ever likely to see, but at about £3.50 a month, and a working server within 55 seconds, they're certainly one of the best hosting companies I've come across in a long while! (and they take PayPal).

Their tagline is "simple cloud hosting built for developers".
And they fit that perfectly: creating, reinstalling, flattening and rebuilding a server is done through a web-based control panel, and takes just seconds. Very, very impressive!

So as quickly as Justin was typing his responses through online chat, I had the server up and running. I took me a day or so to fully appreciate the power of "sudo apt-get install" but now I've got all the tools installed on my home machine, I'm almost sold on it!

One of the advantages of working with PHP is the massive library of code that already exists, to do a lot of the grunt-work. And one of the things I was keen to try out was the much simplified social media integration that PHP affords (as writing oAuth routines in classic ASP is a real headache!).

I found HybridAuth which is a great set of routines to quickly get you logging in and out of all your favourite social media platforms - such as Google, Facebook, Twitter, Windows Live and Yahoo!

Unfortunately, the power of community-built software is also it's biggest downfall - and part of the reason why I'm still so distrustful of open-source zealots who insist on using "open" software just for the sake of it. And, sadly, HybridAuth has fallen foul of the "open curse": While I was able to get Google, Facebook, Twitter, and even Windows Live integrated with a simple php-based website in maybe half an hour (it took that long to create accounts and make API keys and secrets on each one) the Yahoo implementation simply doesn't work.

And searching around on the 'net for answers to "hybridauth yahoo error" returns a million and one pages, all from users of the software, asking how to fix it. And zero pages from people who have actually read, understood, and posted a solution to the problem. Such is the way with a lot of open source software.

In theory, it's great - people add to and improve peer-reviewed software, ensuring it's integrity, making sure it works properly. In practice, everyone assumes someone else will be responsible for fixing it. After all, we've just had the Heartbleed "incident"; a vulnerability in some open-source encryption routines - used by some of the biggest online companies in the world - which every else assumed someone else had validated.

I'm finding a similar problem with my PHP routines.
I love the fact that I can copy-n-paste some code and it just works.
What drives me up the wall is that sometimes it doesn't.
And if truth be told, I can't be bothered learning how it all works in order to fix it - because if I did, I probably wouldn't have migrated to PHP in the first place!

Wednesday, 9 April 2014

Electronic board game - time to start shouting about it?

We've been busy working on our electronic board game and maybe it's time we started talking to a few people to see if there's any interest in taking it beyond our current one-off-prototype stage. So far, all the hardware works perfectly, but we've still got some Flash coding to do, to finish off the accompanying app.
The dozen or so board sections we've already made up do look quite impressive when laid out as part of a tabetop game:

Even with just seven of our twelve board sections connected together, we're seeing the start of an interesting board game layout. And because of the way it all works, new board sections can be added at any time, even in the middle of a game. Space Hulk anyone?

Now it's one  thing to suggest an idea to someone, and another to actually show them. So over the next few evenings, we're going to work on a video to demonstrate the electronic board game in use. It may take a bit of smoke-n-mirrors to show it's full potential (since we haven't finished coding the app yet!) but already things are looking really exciting.

In fact, we're considering taking a trip to the Salute 2014 exhibition in London this weekend, to talk to game and miniature manufacturers and suppliers, to see if there's any interest in making a commercial product. It might be a bit of a punt, but there may be someone out there, just dying to take their own boardgame idea "to the next level" (as presenters on X Factor might say, along with "you really nailed it" and "you made it your own" etc.)

To be able to demonstrate that we've not just built a spaceship-based shooty game, and that the technology can be used for other genres (after all, this whole project started a couple of years ago, when we were asked to create a digital version of Blood Bowl) we're hoping to knock together a few generic board sections.

Because we're using hall sensors and a non-contact method of detecting the playing pieces, the same board sections could be used for a variety of different games: simply place the appropriate graphic over the top, load the corresponding app, and you can easily change your football pitch into a wild west village, for example.

With this in mind, we've already got a working prototype of a generic piece:

It's simply a 6x8 grid, split into two sections of 24 squares (since our room-with-four-exits uses a total of 24 squares, we could re-use the firware and a similar pcb layout for each half of the grid.

In the photo above there are a  couple of extra zero-ohm resistors and a few jump wires. These are not present in the final design: when testing this board, it refused to power up at first so we isolated different regions of it by cutting through the connecting copper tracks! With the problem found and solved, it was just easier to bridge these gaps than etch a new board piece.

And - for completeness - here's the testing showing each of the sensors being successfully activated (and released) as a magnetic piece is passed over them

All that remains - preferably before the weekend if possible - is to make up another two or three of these generic-style board sections, and to get the video camera out so we can show the world what we've been up to!

Saturday, 5 April 2014

BuildBrighton door entry system update

Our new door entry system at BuildBrighton went live on Thursday night. It not only looked great, but worked a treat too.

We were happily giving out new keyfobs to all our members, and recording the RFID numbers as they displayed on the screen. Entering the RFID values against the member's profiles on our members website at saw the 'fobs becoming "live" almost instantly. Success!

Originally we'd planned on designing and building a pcb for the entry system but, this being a hackspace, we thought it might be nice to keep the circuitry on it's original breadboard - complete with loops of wires and ad-hoc amendments that were added into the system as it was designed and tested.

The reasoning being that other members could add to the system some time in the future (maybe adding a wav player or something, instead of the current monotone beeps we have to indicate success or failure).

Everything was working well - members could have keyfobs to "swipe in" to the hackspace, allowing their presence to be recorded on the members website. Even if the fob hasn't been activated to open the main space door (new members are given discretionary 24/7 access after an initial welcome period of a few weeks) new members can have fobs to record their presence at the 'space. This is really useful for our growing community as it allows everyone to put a name to a face (rather than ask amongst themselves "who was that guy who was hear the week before last, with the moustache and the stepper motors" for example).
BuildBrighton members can log into the members website and see examples of this at

Then disaster struck.
Leon proudly took his new 'fob to the reader and presented it. The familiar bleep went off, it connected to the internet and retrieved his (newly updated) keyfob data. "Accepted" said the display and the door mechanism triggered. "Welcome Holly" it said.

A duplicate RFID tag??
It's not beyond the realms of possibility, but highly unlikely.
We already have about 40 or so "older" RFID tags that long-standing members have.

The newer tags are more oblong, and were sourced from a generic chinese supplier off eBay - so it's possible that there's duplication. Or maybe even something wrong with the tags. But the most likely reason is something wrong with the reader of course!

It was noticeable that the duplication was all with the new fobs: none of the "older" style (round) tags generated duplicate values. But with the new tags, the same six or seven names kept appearing on the screen - even for tags that were "fresh out of the box". Something was definitely awry.

A quick hunt around on Google and we may have a solution:
Most RFID tags work with both "serial/UART" style readers, and the Wiegand protocol. We're using a Wiegand RFID reader, so that's the format we're reading the data from the tags. Wiegand is a 26-bit value and most RFID tags produce 26 bit values. We're taking a 26-bit value and presenting it as a 12 character, 4-byte string, in the form AAABBBCCCDDD (where AAA is a byte value between 0 and 255, including leading zeros, BBB is a byte value and so on).

Apparently, it's not unknown for some manufacturers to use 32-bit values in their RFID tags.
If this what is happening in our case, it would make sense of what we're seeing - the last 6 bits of the RFID value could be being truncated. And if the tags in our batch are numbered, even roughly, serially, dropping the least-significant bits of the value would result in the same value being produced when two different tags are presented!

Imagine one tag had a 32-bit value 00000011 11110000 10101010 00000001. This would be 3,240,170,1 and we present this is 003240170001.

Now imagine another tag had the value 00000011 11110000 10101010 00000010. This would be 3,240,170,2 - the next number in a sequence. A 26-bit version of this number would be 11 11110000 10101010 00000010 and give the same results. But, of course, if we're reading a 32-bit value as if it were a 26-bit one, we're losing the last six bits, and both tags would read 00000011 11110000 10101010 00. This would give the vale 3,240,170,0 for both tags. And this would, of course, result in "duplicate" tag ids.

Luckily, we had some different style RFID readers.
As well as the Wiegand reader (which was originally bought for use outdoors, as it came in a fully weather-proof enclosure) we also have two or three serial/UART style readers hanging around. These are not only very easy to interface with (simply provide power and when an RFID tag is presented, they spit out a 14-character string over serial) but they're also much cheaper than a fully weatherproofed reader.

this serial-based RFID reader is very similar to the one in the "owl-based" door entry system currently used to provide access to the BuildBrighton hackspace.

A quick bit of poking-wires-into-holes and we quickly had a replacement for our Wiegand reader, while able to leave the rest of the firmware (and hardware setup) pretty much as it was. In fact, it actually tidied up the breadboard quite a bit. It seems quite fortuitous that we didn't go to the trouble of making up a PCB now - as swapping one reader out for another will be much easier to do (with the rest of the hardware mounted in place on the back of the door) while everything is still on the prototyping breadboard!

So what does all this mean?
Well, everyone who has been given a (working) keyfob for the new door entry system will find that it no longer works. As we're reading the RFID value back as a 14-character string (the first and last bytes are start/end markers, and the next-to-last two bytes are a checksum) all our keyfob IDs are now 10 character strings (using the numbers 0-9 and A-F, whereas before we were completely numerical). To make integration with the earlier system easier, we'll simply prefix the "new style" IDs with the characters BB (for BuildBrighton) to make them 12 characters again.

So with this new reader in place, everyone should expect their RFID tag to be reported as BB-something-something. We'll have to update the members website, and once this is done, we can finally put the project to bed and move on to something else (CNC pick-n-place anyone?)

Wednesday, 26 March 2014

Electronic board game - almost ready for testing

Maybe Steve had a point. He said we should forget about making a CNC pick-n-place and just get some board game sections made up, to prove everything works as it should. Of course, there's no way we're going to give up on a CNC - not least until it's moving in both the x and y axis, and then it starts to get a bit tricky and we'll get bored and move on to something else.

But for a long time, Steve's been saying we should just bite the bullet and solder up a few boards by hand. It's a tedious, laborious task, but - every now and again - we've taken to spending 40 minutes or an hour or so with the soldering iron, and have ended up with a few board sections now.

They are in various stages of completeness, but there's one thing that we have made sure of, and that's they all work! We did have a couple of boards with a few dead squares, but some careful levering with a tweezers-and-soldering-iron combo, and we were able to replace the dead sensors. So every square on each of these boards is working.

We've pretty much got enough pieces now to actually try out a game on the modular sections. A few people have already commented and said that the game looks reminiscent of "Space Hulk". And while it can be used for that, we're more inclined to say it's "Laser Squad on a board game" (not least of all because we don't want GW thumping the door to Nerd Towers down in a fit of pique!)

Even with a relatively few board sections, you can make up some pretty interesting-looking playing surfaces.

This layout reminds us of one of the spaceships in the early 90s Star Trek programmes (the ones with Patrick Stewart in them). A few more board sections to make the "wings" a bit wider and it's a dead ringer:

The long corridor sections could be broken up with the use of doors, much like the early Space Hulk and Space Crusade board games. This could really add some tension to the gameplay - with a player opening a door, only to reveal a hoard of alien monsters, waiting on the other side!

Saturday, 22 March 2014

RFID door entry enclosure

Steve has done a fantastic job of the enclosure for our new door entry system. We're using one of the ABS enclosures kindly donated by Nathan a few months back. The first thing to sort out was where the LCD display should fit. Given the shape of the enclosure, it seemed pretty obvious!

The LCD has rather a large, chunky display on the front, and a massive backlight lumped onto the side, but luckily we don't have to have the entire screen pushed into the opening - the display can be set back slightly, to leave the screen more-or-less flush with the face of the enclosure

Next, Steve scanned in the enclosure, to get a 1:1 layout for the artwork.

Then it was time to get busy with PotatoShop

The printed version was run through the CraftRobo cutter....

....and the final design is ready for fitting:

All that remains is to check everything lines up properly to make sure the scanner wasn't set to "scale to fit" or the scanned image was set to something crazy like 98%

A perfect fit! Another amazing bit of "branding" from Steve - the whole thing not only works well, but looks pretty impressive too. As there are people likely to be using the 'space over the weekend, it's looking likely that we'll have to wait 'til at least Sunday evening (perhaps Monday) before putting the new system live. But at least when we do, we know it'll look  awesome!

Friday, 21 March 2014

Schematics for RFID door entry system

Our door entry system - rather unusually - uses a mix of PIC and AVR microcontrollers; the AVR acts as a serial/UART-to-ethernet gateway and does little else. Most of the work is done on the PIC, but when it needs to send and receive data to/from the 'net, it passes it over to the AVR via serial.

We programmed the AVR by putting an ATMega328 DIP into an early revision of a full-sized Arduino Duemilanove board, uploaded a sketch using the Arduino IDE, then popping the chip out of the socket.

Here's our schematic for the entire entry system - an RFID reader, a 24C256 eeprom, PIC16F886, 16x2 character LCD, LM7805 voltage regulator, 5v coil relay, a few transistors and ENC28J60 UART-to-ethernet module

BuildBrighton RFID door system - ready to go live!

It was touch and go for a while at the last BuildBrighton meet-up. The ethernet module was proving most disagreeable - sometimes it worked, sometimes not. Sometimes it seemed like the server wasn't listening, sometimes the response came back almost instantly.

So to just get a serial-to-ethernet (and back again) interface working, we threw an Arduino Mini Pro onto a board and loaded in the UIPEthernet library. Everything was screaming "nooooo! Learn to do it properly" but we just needed some results - and quickly. So Arduino it was.

Even using a library, the response was intermittent, until Steve discovered a single line of code that seemed to fix things: Ethernet.maintain() is a function call that makes ethernet connections much more robust; and suddenly our project worked first time, every time.

Here's a quick video of it working:

The video shows the members website where keyfob IDs can be assigned to members, and credentials set (who can open the door, who can use the CNC etc.)

When a key is presented to the reader, it seamlessly queries the website and pulls down the latest credentials for the keyfob. The video also shows that keys can be revoked by unticking the "is a valid key" box - when the updated keyfob is presented to the reader, the hardware shows a message "not valid" (and refuses to activate the relay which activates the door). In the same manner, we can easily activate new keyfobs, and add "permissions" to different users, all through the web-interface.

Having proven that the system works end-to-end, we just need to package the circuit up so that it can be put into a suitable enclosure and mounted outside the main BuildBrighton door. We've already had a lot of interest in the new door entry system, with quite a few members being given their own keyfobs, ready for when the system goes live. With a bit of luck, it'll be some time tomorrow evening!