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!

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!

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

RFID door entry system

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!

Pushing the case for a CNC pick-n-place

When Steve found out we were spending time on a CNC rather than just go heads-down and hand-solder some boards for our prototype game, he made a wager - a bet that the CNC chews up more than 20 hours (the time we reckon it'd take to hand-solder a dozen or so board game sections). The prize? A bacon butty.

It looks like Steve is likely to win the wager.
But only because he bet we'd spend more than 20 hours on the CNC - had the wager been we'd spend more time on the CNC than on soldering the boards, it might be a different outcome.

Because of the two boards we soldered by hand the other day, neither worked!
Inspecting them shows some really nasty blobby joints:

A lot of this probably comes down to dabbing on too much solder paste at the start (and so a stencil, rather than a pick-n-place machine would probably be the answer). But there were at least two instances when a shaky of a wobbly hand spread the paste around a bit, across the tracks (so perhaps a solder mask might also have been useful!)

Normally we don't worry too much about this - with plenty of flux on the board before soldering, any excess is usually burnt away, leaving a nice, clear joint. But obviously something is not quite right, with both of these boards refusing to work - and a failure rate of 100% means it'll take a lot longer than our rather conservative estimate of 20 hours to solder up enough board sections to try out a half-decent game.

So, having already arranged to meet Alex to collect some RFID keyfobs for the new BuildBrighton door access system, and being at the hackspace already, and having a few hours to hand, it seemed a shame not to spend them productively - with a view to getting a moving head on an x/y axis as quickly as possible.

Here's pretty much how we left our CNC x/y axis on Monday evening. So last night, we fixed the x-axis travelling head in place, and mounted the y-axis rails and secured everything, making sure it was as square as we could get it

We used Arthur's approach to squaring up the rails - screwing down opposite corners and pinching them tight, then backing off the screws a quarter-turn: secure enough to hold the rails, but not so much to stop them from re-aligning if necessary. We then ran the carriage up and down the rails a few times, and tightened up the rail mounts wherever they had settled.

The whole carriage assembly glides up and down the y-axis rails perfectly. We we expecting at least a little binding or resistance somewhere along its travel, to indicate that either a rod was bent, or the linear bearings were not quite aligned, or that the rails weren't quite parallel. But - amazingly - the carriage glides up and down the rails with no stickiness at all.

It's all very encouraging - and with the 2.5mm pitch belt in place, it's easy to see how steppers will pull the carriage along. The belt needs to be pulled tight and fixed solid at either end of the y-axis rail. This means that as the stepper motor rotates, it causes the carriage to move along the length of the belt.

Because this is our first belt-driven system, we decided to use two steppers - one on each end of the carriage. Normally we'd be tempted to go with the least hardware and the simplest design (i.e. a single stepper per axis) but we've no idea how this belt works when under load. If we had just one belt on one end, it means that the single stepper is driving one end of the carriage, while dragging the other end behind it (a single belt down the centre of the y-axis would be ideal, but we need to keep our working surface clear so we can place circuit boards anywhere within the x/y reach and not worry about the belt getting in the way).

If all the rails are perfectly square - the two rails on each axis are perfectly parallel, and the rails on the other axis exactly perpendicular to them - then an single-stepper-down-one-side arrangement should be just fine (it's how most laser cutters work, for example). But given that we were cobbling something together out of scraps of stainless steel rob, laser-cut mdf and some left-over chipboard for a base, there was always the chance that something wouldn't fit quite right.

So we've gone with the dual stepper approach. Both steppers will be driven exactly in sync, and this should ensure there are no dragging or twisting forces on the y-axis as it travels up and down our (rather shonkily-built) rails.

As it's BuildBrighton Open Night tonight, there's a chance that not much more will get done on it until the early hours - though perhaps we might just forgo the tea and pizza and keep cracking on with it - once the new door entry system has been fitted, of course!

Testing RFID door entry system for BuildBrighton

Next Thursday night is BuildBrighton Open Evening, and we'd promised to have the new door entry system working. In principle, it's a fairly straight-forward idea, but - as with most software (and hardware) development - most of the effort seems to be going into the "fail-safe": what happens if, for example, the internet connection goes down?

Firstly, here's the theory of how it works:
We have a members website for BuildBrighton, and our key-issuing members can access an admin screen, which allows them to issue keyfob numbers to members, and to activate certain "flags" on the keys (so the same keyfob could, in future, be used to access lots of different pieces of equipment - for now, we're concentrating on opening the door).

Each member has an RFID keyfob number against them, and a number of flags to say what that keyfob can do. This can be administered by anyone with admin access to the BuildBrighton members website.

For testing, we've removed the ethernet-to-UART module, and have plugged in our PICKit2 Programmer, which has a simple UART interface, so we can emulate sending data backwards and forwards between the RFID reader and the website (it can be difficult, during testing, to force a network error - or diagnose an error reported on the hardware, when everything looks like it should be working, and there's fault on the web server!)

We've also added in loads of logging into the microcontroller handling the data between the RFID reader and the web server, so that we can see how different conditions are being handled.

The first thing to do is present a keyfob/rfid card (the reader works with any 125khz RFID tag) to the reader. The hardware displays the number read from the fob on the character LCD (the reason for this will be explained in a moment) and then tries to contact the web server.

As we're using an ENC28J60 ethernet modules with another microcontroller attached (it'll be an ATMega328 but we're prototyping on a full Arduino) to do all the talking over the internet, we can simply send this ID number over serial/UART. The ethernet module will post this ID number to a URL and await a response from the remote web server. Any data sent back from the web server appears on our hardware here as a serial string of data.

We're emulating this by simply typing data into our PICKit2 UART module.
When a correctly formatted response is received on our hardware, it displays the name of the keyholder for confirmation:

So far, so simple.
The bulk of the work in this project, however, has gone into making sure the device works when there's a network error. So, each time valid data is received from the internet, we store it in some local eeprom (that's what the 24C256 eeprom chip is doing there). That way, if ever we don't get the expected response from our web server, we can compare the keyfob ID against a known "database" of valid fob numbers. If there's a match, we use the credentials stored in eeprom, rather than over the 'net.
The next time the same keyfob is presented to the hardware, it checks against the web server first - so any updated credentials get downloaded to local eeprom, once the internet connection is back up and running.

Here it is in action:

And here's the massive data logging output.

Starting keyfob reader
Flushing buffer 176 96 193 131
Keyfob reading complete
Sending data to ethernet
176096193131:0100:0
Data received: OK:8761:Chris Holden

Reading eeprom address 0
Data from eeprom: 255 255 255 255
Keyfob serial: 176 96 193 131
Writing new record at 0
End writing eeprom

Starting keyfob reader
Flushing buffer 35 70 141 26
Keyfob reading complete
Sending data to ethernet
035070141026:0100:0
Data received: OK:8761:Steve Carpenter

Reading eeprom address 0
Data from eeprom: 176 96 193 131
Keyfob serial: 35 70 141 26
Reading eeprom address 32
Data from eeprom: 255 255 255 255
Keyfob serial: 35 70 141 26
Writing new record at 32
End writing eeprom

Starting keyfob reader
Flushing buffer 35 70 141 26
Keyfob reading complete
Sending data to ethernet
035070141026:0100:0
Data received: ERROR

Reading eeprom from 0
Data from eeprom: 17696193131
Keyfob serial: 35 70 141 26
Reading eeprom from 32
Data from eeprom: 357014126
Keyfob serial: 35 70 141 26
Record foundData received: OK:8761:Steve Carpenter


Starting keyfob reader
Flushing buffer 176 96 193 131
Keyfob reading complete
Sending data to ethernet
176096193131:0100:0
Data received: OK:0000:Chris Holden

Reading eeprom address 0
Data from eeprom: 176 96 193 131
Keyfob serial: 176 96 193 131
Data found at address0
Updating record
End writing eeprom

Starting keyfob reader

So what's happening in the video?
To begin with, we presented a new card to the system. It queried the remote server (sending the key ID 176096193131) and we emulated a valid response. The response "OK:8761:Chris Holden" tells the hardware who the key belongs to, and which flags are set for that person (effectively, which bits of equipment this keyfob is valid for, so they can be compared to the flags in the hardware device).

This activity is reflected in the log above.
After receiving the data, the hardware then looks through the eeprom chip, reading 4 bytes at a time and comparing them to the 4 bytes read from the RFID tag. If it finds a match, it will update the following "record" in eeprom. If it finds a series of four 0xff bytes, this indicates a blank bit of eeprom memory (where we've reached the end of all the records) and so writes a new record at this address.

We can see this happening, in the log above.
At address zero, there are four lots of 0xff (since the eeprom chip at this point is completely empty). So a new record is written, starting at address zero.

Then, in the video, we pick up the blue keyfob and present this to the reader.
The results of this can be seen in the log above - the web server responds with an OK message and identifies the keyfob as belonging to Laser-Robot-Steve. If you read through the log, after this, you can see that the previous record is found in eeprom, at address zero, so it skips forwards 32 bytes, and reads another 4 bytes back. This time, four sets of 0xff are found (blank data) so it knows it's reached the end of the data in the eeprom chip, and adds another new record.

So what if we present a keyfob but the internet connection is down?
We simulated this by having the serial response from the ethernet module read "ERROR"
And you can see in the video, the hardware identifies the error, but then after querying the eeprom chip, validates the keyfob as belonging to Steve - and so activates the door lock and lets him in, even though the internet connection was down.

By reading through the log above, we can see that after receiving an ERROR response, the hardware queries the eeprom chip. At address zero it finds four bytes, but these do not match the ID from the keyfob, so it jumps forward 32 bytes and tries again. This time, it does find a match, and so validates the user as Robot Steve, and opens the door.

Now Steve's been let into the 'space, he can reboot the router and get the internet connection working for anyone else who needs to access the space using their RFID tag. Without this safety net, there's a good chance that we'd end up with a queue of people all on the outside, not able to get in, to sort out the problem causing the internet connection failure that was keeping everyone out!


The last bit of logging (not shown in the video) shows how keyfob credentials are updated by the members-only website. In the last example, the flags for Chris Holden have been reset to zero on the website (as if the keyfob has been revoked). When the revoked keyfob is presented to the RFID reader, the new credentials are downloaded from the web server, the appropriate record is found in eeprom, and is updated/overwritten. So in the event of another internet failure, the key remains revoked once contact has been made with the web site (and doesn't let Nasty Chris in, if he's cut the cables to the phone lines on a future visit, for example!)

Hopefully we don't have to worry about revoking access with BuildBrighton members.
But exactly the same principle can be used to grant additional access to tools, equipment etc. to users in future. So once a user is issued with their own RFID tag, they could use this to, say, activate the laser cutter and log time used on it, or power up the CNC with their RFID tag.
We're a long way from it, but the principle could be extended by other people using this system for things like snack purchases and donating for hardware use, even if the member doesn't have any cash on them at the time.

Hopefully we'll have more ideas on Thursday evening, when the new system "goes live".

Why we need a CNC pick-n-place

It was good to spend a few hours this weekend actually making stuff again, rather than just coding and coding and doing yet more coding! So good, that we thought it was time to make a few more board sections for our electronic board game.

In about two hours we managed to get just two pieces made up. Mostly this was down to dabbing the solder paste onto just three or four sets of pads at a time, then hand-soldering each SOT-23 sized hall effect sensor, and each 1206 sized resistor in place.

Hand-soldering SMT components is slow going. And almost an hour per board section is pretty woeful. So it's time to start seriously thinking about this CNC pick-n-place machine. Steve is going to go beserk.

I went down to BuildBrighton for a few hours this evening, with Grumpy Paul (he doesn't have a G+ link). Over a few hours, we cobbled together a basic x/y axis, using some 12mm linear bearings and stainless steel rods that have been lying around for ages. We've mounted the steppers onto the y-axis carriage - one on each side rather than a single long belt down the middle, as we need to keep the middle clear for placing components. Also, because we're expecting the head to travel to the edge(s) to pick up components from a tape reel, we couldn't really use the moving y-axis bed approach we implemented in our CNC drill from about 18 months ago.

We've gone for "proper" stepper motors this time, and a 2mm pitch timing belt, and proper CNC pulleys (rather than some cheap plastic mouldings and £2 motors from China!)

Here's the x-axis carriage being assembled. The steppers are mounted on each end. A belt will run along the outside edges, over the pulleys on the motors that are mounted on the carriage, to a fixed point at each end of the travel - using this sort of arrangement:

As usual, the entire thing is being designed and built on-the-fly.
There's no real planning gone into the design so far (as Grumpy Paul will testify, having had to take a rasp file to it on more than one occasion). We're using Arthur's method of getting everything square - that is, to fix one end, run the carriage up and down the y-axis a few times, then bolt it all down onto a scrap sheet of wood, wherever it rests!

The travel on the y-axis is surprisingly smooth. Maybe it's because of the added weight of the stepper motors (we expected these to make the travel worse, not better). Maybe it's because we lightly sanded the rods with some wet-n-dry paper, as the linear rails felt a bit sticky in places. But in all honesty, it's probably Paul's idea that made all the difference - a tiny blob of lithium-based grease on the rods makes the carriages glide up and down with hardly any resistance at all.

We didn't actually get much further than laying everything out tonight (despite nearly five hours, and staying 'til almost midnight). But there's every chance that we'll have the CNC moving in at least two axes on Thursday night. That's if Steve doesn't put his foot down and ban us from doing any more work on it 'til the board game is finished!

The thing is, at our current rate of construction, we're going to need about 20 more hours just to make up enough board sections to call it complete. Surely spending a few hours to build the tools to speed up finishing off the board game it time well spent? Isn't it?

Why can't smart advertising be just that little bit smarter?

Many years ago, cross-domain security meant that what happened on one site couldn't be disclosed to another. Then, with the advert of social media, and content being shared, re-shared, regurgitated and re-presented as new information (when it's actually a re-hash of someone else's content) ad-bloody-infinitum such restrictions were relaxed. And if not, exactly relaxed, then workarounds were created, and generally deemed accessible - anything, so long as critically important things like a Twitter feed or Facebook status update could be presented as part of the existing web page.

It's not that long ago that the web development community derided Microsoft's insistence on not only supporting, but promoting, iframes. Now they're used everywhere.

And that nasty 3d-effect border that a lot of browsers insisted on displaying, in order to demonstrate what a stupid idea using inlines frames was, has all but disappeared.

These days, content from one page appears as if it's part of another, with the clever use of iframes and a bit of jQuery. In fact, eBay uses exactly this technique to display content when you click on the "my eBay" link - sometimes it goes a bit screwy and you get multiple scroll bars all over the place, but it the main, it's often impossible to tell if the content you're reading is actually coming from the web site that appears in your web browser's address bar.

Whatever the means or the method, advertisers have always been quick to jump on technology to ram yet more marketing rubbish, if not down our throats, then at least in front of our eyeballs. What's getting a little bit insidious is how major website owners are happy to cross-charge each other (and ultimately, the end customer) for showing adverts which are simply inappropriate.

Here's just one example:
I recently search Farnell for some 24C256 eeprom chips.
I even got so far as to add a few to a basket. Then I checked the cost of sending them, if I didn't hit the minimum £20 order level. It was too pricey, so I thought I'd try another site.

So I searched eBay for the same chips and got a list of results.
But right there at the bottom of the page, was an advert for Farnell

It didn't just say "hey, we sell these chips as well, why not buy some from us?"
The data that tracked me adding them to my basket but then not completing the checkout has been passed to eBay. So now eBay uses this information to display an advert, to encourage me back to Farnell.

Which, as an eBay customer just seems stupid.
If the advert is successful, and lures me back to Farnell, then eBay (and the eBay sellers I would otherwise have shopped with) have lost out. So why are eBay sellers being charged ever more to advertise on a platform which is quite happy to encourage buyers to shop on an entirely different site? Why would eBay think sending customers to a "rival" site is a good idea for anyone (except themselves, taking a rake from the advertising revenue)?

But that's not my major issue.
My issue is that this so-called "smart advertising" just isn't... well... smart enough.
Here's the thing, Farnell.

You know I visited your site.
You know I wanted to buy 24C265 eeprom chips.
You even know that I went to your checkout page.
You know that I didn't buy goods from you.
And you know that I then went to eBay to find someone selling exactly the same products.

Here's where I'd like Farnell to use the tiniest little bit of intelligence:
WHY didn't I buy from you?
WHY did I get all the way to the checkout, then jump onto another site, looking for exactly the same product?

It's not like I went looking for an alternative; I didn't search the Farnell catalogue, fail to find what I wanted, and so tried to find it somewhere else. There's only one reason that could be deduced (even by a stupid computer) for my reason not to purchase - I thought I could buy it cheaper elsewhere. So why would anyone think that putting a picture of a sad puppy would make me abandon that quest, and return back to the website I'd just dismissed as too expensive? For all the intelligence and data gathering that these massive companies undertake, the reasoning behind showing "targetted" adverts just seems pretty dumb.

I hate advertising on the 'net. I hate spam, and Twatter and Facebook, and the constant barrage of adverts that litter many web pages. But I also appreciate that, for some, it's a necessary evil. I'd even concede that, sometimes - if it's targetted well enough - advertising might even be useful for the customer.

But the current level of "intelligence" being used by advertisers is about 2 out of  10 - and falling. And I just wonder what the thinking is behind all this cross-site advertising when, even a cursory analysis would conclude that, in perhaps eight out of ten cases, it's completely inappropriate!

RFID door entry system for BuildBrighton

It's been a few weeks where most of our nerd-work has been coding (the app for our electronic board game is starting to look very impressive btw, we're just not quite ready to unveil it yet!). So it was nice to spend a few hours this weekend working on an actual physical project - an RFID door entry system.

At BuildBrighton we've had an explosion of new members in recent months. Not literally of course - we do play with some dangerous equipment and event a few volatile chemicals at times, but it's a metaphorical explosion. We've had lots of new members, all visiting the space, finding out what an amazing place it is, and wanting to join up as members.

Which is all well a good, but has lead to a bit of a problem regarding giving all our new members access in a timely manner. The current process is that new members must be "accepted" by the community (so are on a "trial basis" for a few months) before being nominated as a member, and approved by a director of BuildBrighton.

This process worked fine, when it was a small group with 30-40 members. But as our number approaches 100 members, we're having to review how we give people access to the space (and, for future consideration, how we give members access to different pieces of equipment, once they've been trained and proved their competency with them).

We currently have an RFID-based keyfob door entry system.
It's actually made from our Global Hackerspace Challenge entry, a spelling-owl that used RFID cards to show different words.

In true "hacker" style, we chopped bits out, added bits in, and re-purposed it into something else for our needs. But it's a bit clunky, and key numbers have to be hard-coded into the hardware - so every time a new member wishes to have a key for the 'space, someone has to re-code the hardware to make the new key work. This is no longer proving sufficient for us, so we're moving over to a web-based administration system. So, while we're about it, we're building an entirely new door entry system.

Here's how it works:

• We're using the Wiegand26 RFID reader we trailled about 18 months ago.
• We're also using using one of those ENC28J60 ethernet modules to talk to the BuildBrighton members website.
• And, should the internet go down, we don't want members locked out, so we'll store key credentials locally in a 24C256 eeprom chip onboard
• The whole thing displays information on a simple-to-use 16x2 character LCD

The basic idea is this:

• A keyfob is presented to the reader and the serial number read from it.
• The keyfob number is displayed on the character LCD.
• This is sent (via the ethernet module) to a URL to validate the serial number and the web site returns data to say who the key belongs to
• If data is successfully received from the website, it is stored in the local eeprom chip
• If there is a fault and no data can be received from the 'net, the eeprom is searched, looking for a matching keyfob number. If a match is found in eeprom, the data is read out and handled as if it had just come from the website.
• If the keyfob belongs to a valid user, their name is displayed on the character LCD and a relay is activated to open the door.
• If the serial number is not recognised, a "not recognised" message is displayed in the lower part of the LCD display.

This allows us to quickly and easily add (and, should the never ever arise, to rescind) keyfobs to the door entry system, without having to actually visit the space to re-program the door opening hardware. If a user presents a keyfob that is not recognised, the serial number from it is displayed on the character LCD. The user simply contacts one of the BuildBrighton administrators and tells them their keyfob number.

The admin user can then log into the BuildBrighton members website and activate the keyfob remotely.

Of course, there's always a chance of a mis-match between the 'net and the local eeprom - but this is a problem with any shared data: there needs to be successful contact with the BuildBrighton website for the data to be transferred locally- and the local data only changes when the BB website is successfully contacted. But, given that the system always tries to contact the web server before querying the local eeprom, we feel this gives the best compromise between data integrity and just being able to get into the 'space in the event of a network meltdown. After all, someone still needs to be able to get into the 'space to fix any problems with the internet connection, which could otherwise bar members from entering!

Electronic board game - SUCCESS!

It's been about ten days since the last meaningful blog update, which can only mean one thing - coding! Actually, it could mean that real life has been getting in the way of nerding about (it has: with the first few nice, sunny, days of 2014 there's been an awful lot more going out and spending time at the allotment than in recent weeks). It could also mean that work (real work, the sort that pays the rent) has been demanding more time (also true, learning two new languages to work on a web-based app is heavy going at times).

But, in terms of this blog and writing up the latest nerd-based developments, it generally means, we've been busy coding.

There's not really much you can blog about when you're coding. Here's a screenshot of an error. Here's a couple of screenshots showing how something's not quite working properly, but we can't work out why. Coding isn't much of a spectator sport - and, similarly, there's not really much to blog about while it's going on.

Making physical stuff - hardware, electronics, gadgets, is infinitely more rewarding from a blogging point of view - there's always something to show, some photos to illustrate the latest developments, or a video to show where things are up to. But with code, it's just, well, kind of boring.

But at BuildBrighton tonight, we were delighted to be able to demonstrate a working version of our electronic board game. All the hours of coding look like they're starting to pay off. So here's a video of a demonstration, showing where we're up to:

It's not 100% perfect, and there are a few things to iron out, but on the face of it, things are looking really promising. Firstly, the thing actually works: the software in the video is running on an Apple iPad Mini. We decided to demonstrate on this platform, to show that it would (should?) work on any other platform (since getting multi-platform stuff to work on Apple devices is often the most difficult). Data is being passed from the hardware (that bunch of wires the board game sections are plugged into) to the iPad, without resorting to hacks, dodgy hardware cables or jailbreaking - all the devices simply talk to each other by each connecting to the home hub router.

Also, we worked hard to make adding the board game sections as flexible as possible: rather than simply use a number of pre-defined board layouts, we wanted players to be able to mix-and-match their board game sections - and to add them at any time during the game.

The video demonstrates the app detecting when a new board section is added to the existing map. (the delay between the board being added and the app detecting the new piece is deliberate, to allow time for the piece to be lined up, the connector to get jiggled about a bit and so on - although perhaps 3 seconds is a bit long, on reflection).

When a new piece is detected, buttons on the controlling hardware can be pressed to rotate the piece, or - in the event of more than one potential destination on the board being available - locate the piece at the end of a different section of corridor or room entrance. This means that there is no need to poke at the tablet/smart device running the app to make any selections - something we feel might detract from the gameplay, during a boardgame.

The video also shows playing pieces being added to the board, and being correctly placed in the app. At the time of writing, it's not perfect, but it's a workable demonstration. Most of the problem stems from us using tiny 3mm magnets, which are not perfectly lined up in the centre of each playing piece.

Here's our robot playing piece. We're using the tiny 3mm magnets because we don't want one playing piece to affect more than one hall effect sensor at a time, as the pieces are moved around the board. It's important that a playing piece leaves one square before appearing in another - too large a magnet, and it's possible that one piece could influence two or more hall sensors at one time, and could lead to confusion.

But such tiny magnets mean they have to be right over the top of the hall effect sensor, to get it to detect the presence of the playing piece. This isn't really a problem, except we were a little "slap-dash" in gluing our magnets on the underside of the playing pieces.

The 28mm "slotta-bases" are made in such a way that when we glue a magnet to the underside, it's slightly off-centre. This is why, in the video, the robot playing piece is not immediately detected when placed on it's square: the playing piece is in the dead centre of the square, but the magnet is only close enough to activate the sensor as we lift the piece off. Were the magnet in the centre of the playing piece, this error would not have occurred.

When the app detects a new playing piece has been added to the board, the player is asked to choose which character this piece represents. Again, selection is made using the hardware buttons, rather than swiping (and potentially disturbing to position of) a touchscreen.

So we've managed to get the app to detect board sections as they are added to the map: these can be all done at the start of the game, or at any time during play. We've detected not only when new playing pieces are added, but also are able to track playing pieces as they are moved from square to square. All in all, a pretty good start!

We've already coded line of sight (for hidden movement and to keep the opposing player's pieces hidden until they can be seen by any one of your playing pieces) and firing weapons, so we're hoping to implement these very soon into our hardware-based version of the game - and then we won't actually be too far away from demonstrating our first board-game-based-Laser-Squad-a-like-y video!

(and hopefully Steve will finally relent and let us build a CNC machine for making the other board sections - but that's for another post!)