Need a good read?

Sometimes is great to get away from the computer and the soldering iron for a while and do something "old school". A while back a few of us here at Nerd Towers took up painting models again, to see if we could still do it (after 20 years, the eyesight isn't quite so keen, but the results were ok-ish) some have gone back to really old-tech stuff and even trying reading books!

If there's one book everyone should have on their bookshelves at home - and yes, Kindle-loving-cool-kids, one of those things made of paper with pages that you actually turn over and not just flip with one finger on the screen - it's the Machinery's Handbook.

This one was actually printed in 1982 but it was first published in about 1914. It's an awesome read! Lots of it is just tables - logarithmic tables, sine, cosine and tangent look-up tables and the like - but it's full of loads of really useful, and interesting, bits of information.

If you want to know how to lay out 11 holes in a circular formation, the answer's right here. Or want to know the ratio between two tangents to a circle, or a tangent and a line bisecting the radius... loads of really cool tips and short-cuts are not only useful to have under your belt when making stuff, but lots of it is just quite interesting; even if you never use most of it yourself, it's just a really good read!

Anyone interesting in getting hold of one of these classic books can just search Google or Amazon for Machinery's Handbook but get ready to shell out about £30-£40, even for a second-hand copy. But if you can afford it, it'll repay that many times over, just keeping you entertained during those enforced hours of "downtime".

Knowing when it's time to start again

As we learned with our LC oscillator "diversion", sometimes it's ok to try something out and it simply doesn't work. Along the way, you can try ideas out, test your understanding and - sometimes - a negative outcome is just as valid as a successful one. And if something doesn't work as expected, it's fine to just say "ok, let's try something else".

But sometimes, things go wrong because you've been an idiot. The only thing we learned from this latest effort is that ordering components without fully understanding their format/package is a bad idea - here are some SOT559 hall effect sensors:

Even for SMT fans like us, there are limits to how small you can go!

Take a little time to re-route a PCB....

... even if you've already spent hours on it and just want to get your project "out of the door". We did just this, moving a couple of traces, and got a much better board because of it. We were also able to eliminate one of those nasty "jumpers" (we're using 0-ohm resistors instead of bits of wire, but they're all pretty much the same thing at the end of the day).

Using a parallel-to-serial (PISO) shift register properly!

At the heart of our modular digital board game system is a parallel-in-serial-out shift register. But our earlier board design completely missed out the fundamental part that made the whole thing work: daisy-chaining shift registers is achieved by connecting the Q7 pin on one to the DS (serial data) pin on the next.
And we'd completely forgotten to connect the Q7 pin to our ribbon connector!

Here's the new PCB layout with the extra pin connected (there's probably a neater way to do this, without having to cross the traces over each other with 0ohm resistors but without a complete re-write, this is next best thing!)

Our ribbon connector is now a 7-way plug. We've drawn it as a dual-row 10-way IDC connector only because these tend to be quite common in the "real world" and are more easily sourced (and cheaper too) than lower pin-count connectors.

Adding glow to playing pieces

We're still on the fence over Dreadball, but it's looking like the ideal game to convert as part of our digital boardgame project. The Tron-like glowing edges are a big part of the game, so we thought it'd be pretty cool to create actual glowing edges on our playing pieces.

Edge light acrylic is often used for signs and is readily available. Basically, shine a light onto the surface of the plastic and it defracts in such a way that the edges appear to glow.

Now already we're thinking, since we decided to stop worrying about the cost of making our board game, adding a few more pence to the cost in order to add some surface-mount LEDs might be a cool idea. We could drill a hole in the centre of each square, connect the LED to the hall effect sensor (so it triggers when a playing piece is detected over the hole) and have the LED light up the base of the playing piece from underneath, which in turn is made from edge-light acrylic.

We've yet to find out if a hall-effect sensor can provide enough current to light an LED and hold an input pin on a shift register high (it should be able to, but we really need to try this out for sure) but in preparation of receiving our latest batch of goodies from Farnell, we've come up with a PCB layout:

(a 2mm hole drilled through the centre of each pair of SMT LED pads will allow us to mount an LED "upside-down" on the board, so that it shines through the hole when viewed from the top side)

Each of the seven hexagon shapes (we've drawn them as circles just because this was easier in ExpressPCB which we still prefer to use for knocking up quick prototype boards) has an SMT LED in the centre, with a tiny hall effect sensor slightly offset. The hall sensors we're using are these:

They're absolutely tiny - about 2mm by 3mm in total! In fact, these may prove to be a little bit too small for hand soldering, but they were the cheapest non-latching SMT-format sensors we could find and we'd ordered a load before even checking the dimensions, so these are the ones we're going to try out on our first prototype!

Every board has it's own shift register. We're trying these parallel-in-serial-out (PISO) shift registers:

Because we need to be able to hold the PE (parallel enable line) low and send a clock pulse to get the data from the input pins into the shift register, then pull it high to get the shift register to "pass the data along" on each clock pulse, we're having to send a few of these pins to a connector on the board.

So as well as the power and ground pins, every board also needs a serial data in line, a parallel enable line, a clock enable and a clock pulse line too. That's a 6-way connector. The easiest method we could think of, to allow all the boards to be laid out in any number of configurations, is to include a surface mount 0.1" pitch connector on the underside and to simply daisy-chain them together with some custom-made IDC cables.

Dreadball like Blood Bowl but better?

It's been many years (about twenty more than we'd care to admit) since any of us played Blood Bowl. But always seemed like a nice idea for a game - even if the mechanics of playing it got a bit lumpy with all the rules and look-up tables. It's what originally inspired us to look into making a digital board game, just over a year ago; to take a complex set of rules and have a microcontroller do all the clever stuff, and leave us to concentrate on actually playing the game.

It'd also mean having a hobby that meant turning off the computer(s) for a while, and actually making and painting something - getting back to the arts and crafts side of making, rather than being engulfed in coding and electronics all the time!

While looking for ideas to resurrect the Digital Blood Bowl idea, the ever-helpful Mr Google turned up a relatively new game that launched recently thanks to some massive KickStarter support: it's called DreadBall and, while the author is keen to state that it's NOT Blood Bowl set in the future, on first glance it look like a perfect game to try to convert.

It's a two-player, futuristic, football-come-rugby-come-speedball type game, set in the future. The author - and subsequent players of the game - reckon it's easier and faster to play than Blood Bowl. In fact, all the reviews say it like Blood Bowl but better.

Now being set in the future, with Tron-like armour and shiny futuristic materials, this game lends itself really well to being converted into a digital board game - not least of all because the underlying technology won't need to be "hidden" behind a fantasy, olde-worlde facade, but actually enhances the playing environment. Some early fans have already taken the next logical step of creating custom boards - with LED backlights to reinforce the glowing-edges Tron-style look-and-feel:

In fact, players of the game are keen to exploit this futuristic look-and-feel. They're even painting it into the miniatures used for the playing pieces. The game ships with miniatures that have clear acrylic bases, so that they are less obtrusive on the board. But some players are making the hexagonal bases a major part of the model, painting them to look like they also have glowing edges:

(note the Tron-like glowing edges painted onto the model bases)

This has given us an idea for our hex-based modular board game system. More details (with schematics once drawn) to follow....

A new approach to digital boardgames

So far, we've been trying to build a digital boardgame to a budget. The idea being that keeping costs down makes the idea accessible to more people (not everyone can afford to drop a hundred pounds on a hobby project, but lots more people can find twenty or thirty quid for a one-off project).

This is why we were keen to pursue the LC oscillator idea for detecting board game pieces. It's already been suggested that hall-effect sensors would be a much simpler and more robust solution - simply place a magnet in the base of each playing piece and query each hall sensor on the board to see if it's been activated.

So far we'd ruled these out because they are relatively expensive. In truth, they're about 20p each when bought in bulk from somewhere like Farnell. But if you're building a board game with 390 of them on there, that's getting on for £80, which is a big amount to find to try out on an idea that a bunch of nerds posted on a website somewhere and which you still need to solder up and make yourself and still not know if it'll work 'til you've made it.

So we thought about this and came up with a different approach: a modular hexagon-based electronic game board. The idea is to make individual modules which can be plugged together to make a pretty-much any-sized gaming board for pretty much any board game. Provided it doesn't use squares ;-)

Each module could be a group of seven hexagons. Each module has a hall effect sensor in the centre of each "square", an 8-bit parallel in/serial out (PISO) shift register, a wired plug and a pin-socket which allows multiple squares to be connected together.

The idea is that the shift registers are "daisy-chained", with the hall effect pattern copied from the parallel interface (we're only actually using 7 of the 8 available bits) onto the serial output. As the microcontroller sends a clock signal to the first module in the "chain", the status of each square in each module is shifted out of the last module in the chain. Send enough clock pulses and the you get a massive binary pattery back, indicating the status of every square on the board. Provided every board is oriented the correct way around, we should be able to work out whether each square on the board has a playing piece immediately above it.

Now each individual module is going to be more expensive to manufacture than an entire board made from cheaper components - but the upside is that the same modules can be used for lots of different board games by simply unplugging them and re-connecting them in a different configuration for a different mcu!

Other than cost, the downside of this approach is that to create a rectangular playing area, there are quite a few unused squares across multiple modules:

Here's an example of a rectangular-ish board made up from hexagons - it's from a BloodBowl-esque game called DreadBall:

It uses up to 40 hex-based pads (including those with unused squares) which - if we go down the hall-effect sensor route - makes the total construction cost quite expensive. But already that's something that's already been queried by a few people...

After all, a brand new copy of Blood Bowl costs about £50 new. And that's made up of a cardboard playing surface and some plastic miniatures which most players replace almost as soon as they can afford to! If each module costs, say, £2 to make, a full DreadBall sized board would cost about £80. That's a lot to shell out in one go - but it's quite affordable (and much more realistic) to make up, say, 10 modules at a time. With only 10 modules, they can still be plugged together and used to confirm that everything works, but without the one-off massive cost of nearly a hundred pounds all in one go.

There's no guarantee that we'll ever make enough modules to complete a full-sized Blood Bowl board, but - like the LC oscillator - there's an idea that needs investigating. So we've got a load of components on order from Farnell to try out over the coming few days....

LC Fail!

It's been an interesting, if not ultimately frustrating exercise, trying out using an LC oscillator as a miniature metal detector. The truth is, we didn't get the expected response from our board, even without any metallic pieces present.

A simple PCB connected each inductor and capacitor in parallel, which in turn were connected to a PIC i/o pin:

Here's the board all made up and connected to the PIC (ok, we only soldered four out of a possible eight squares, but it's just a prototype to prove a concept, so we're not too worried about that!)

We quickly knocked up some code to test the board. We're using XOR to detect which pins have gone high/low. This kind of thing often throws up some queries, so here's a quick explanation:

First we get the PORB input.
Let's assume it's 00011000

Now we XOR it with a previous read.
Let's pretend that previously the input was 00001000

So 00011000 XOR'd with 00001000 give us 00010000
This result tells us that PORB.5 has changed. Just by looking at the "before" and "after" port states, we can see that this is correct. So we've identified which pin has changed - but has it gone high or low?

If we AND the result with the "new" read data, we should get a pattern telling us which pins have just gone HIGH: 00010000 AND 00011000 gives us 00010000

Incidentally, if we AND the result with the "old" read data, we get a pattern telling us which pins have just gone low. We're not interested in this information right now, but it's a handy technique to know!

Now we've a way of telling, very quickly, which pins from an entire port have just gone high, we can use this to track how long it take for the oscillating LC part of the circuit to go from high, to low, and back to high again. Here's the code we used:

Define CONF_WORD = 0x3f32
Define CLOCK_FREQUENCY = 20
AllDigital

Config PORTB = Output

Dim i As Byte 'declare a variable
Dim portb_input As Byte
Dim portb_last As Byte
Dim portb_change As Byte
Dim portb_rising As Byte
Dim portb_response(8) As Word
Dim portb_final As Byte
Dim read_count As Word

High PORTB.0
Hseropen 9600 'open hardware uart port for baud rate 9600
WaitMs 1000 'this delay should be used in a real device
Low PORTB.0


i = 0

Hserout "Starting PIC: ", CrLf 'send formatted output to serial port
WaitMs 1000 'this delay should be used in a real device

loop:

     'switch on timer 1
     T1CON.TMR1CS = 0 '(use fosc/4 as time base)
     T1CON.T1OSCEN = 1 '(enable timer1 oscillator)
     T1CON.TMR1ON = 1 '(turn the timer1 on)

     'make all of PORTB an output
     TRISB = 0x00
     'wait a sec
     WaitMs 100
     
     'make all PORTB inputs
     TRISB = 0xff
     
     'wait for the inputs to trail off to zero
     portb_input = 0xff
     
     While portb_input > 0
          portb_input = PORTB And 15
     Wend
     
     'now reset the timer
     TMR1H = 0
     TMR1L = 0

     'get the input from the port
     portb_input = 0
     portb_last = 0
     portb_final = 0
     read_count = 0
     
     While portb_final < 15 And read_count < 1000
          portb_input = PORTB And 15
          portb_change = portb_input Xor portb_last
          portb_rising = portb_change And portb_input
          portb_final = portb_final Or portb_input
          read_count = read_count + 1
          
          If portb_rising.0 = 1 Then
               If portb_response(0) = 0 Then
                    portb_response(0) = (TMR1H * 256) + TMR1L
               Endif
          Endif
          If portb_rising.1 = 1 Then
               If portb_response(1) = 0 Then
                    portb_response(1) = (TMR1H * 256) + TMR1L
               Endif
          Endif
          If portb_rising.2 = 1 Then
               If portb_response(2) = 0 Then
                    portb_response(2) = (TMR1H * 256) + TMR1L
               Endif
          Endif
          If portb_rising.3 = 1 Then
               If portb_response(3) = 0 Then
                    portb_response(3) = (TMR1H * 256) + TMR1L
               Endif
          Endif
                                        
          portb_last = portb_input
          
     Wend
     
     'now write your results out over serial
     Hserout "Read count ", #read_count, " "
     For i = 0 To 3
          Hserout "R", #i, ":", #portb_response(i), " "
     Next i
     Hserout CrLf
          
     WaitMs 1000
     
Goto loop 'loop forever

The idea here is that we send the output pin high, charging the LC circuit. We then turn the pin to an input, wait for the LC/input to drop to 0v, then time how long it takes before the oscillator takes the input high again. The results were quite unexpected:

 

Using an inductor of 1.5mH and a capacitor of 3.3uF, we calculated that the oscillator should be running at about 71khz. But different input pins were returning different timing values. Something didn't look right! We took the board off the PIC and re-ran the code and the results were pretty much the same; the input pins were reading as if they were just floating!

One way to eliminate false reads from floating input pins is to add a pull-down resistor on each one. We did this and re-ran the code:

As expected (except, for some reason, the input on PORTB.1) once the input has gone to zero, it never comes back up to a positive value - any current in the circuit from the LC oscillator is being pulled straight to ground through the resistor.

Conclusion? Epic Fail :(

In fact it's not quite as bad as all that. 

It's not a roaring success.

But for a while it was nice just to get back to making stuff and trying ideas out!

Array of LC oscillators for grid-based contactless input

With a load of inductors and capacitors on order, it was time to prepare a PCB for etching to see if this thing will actually work. Even now, we're not entirely sure that it will, but here's the theory behind our current approach:

We're going to dynamically add a ground to each "column" of sensors; the idea being that we can attach multiple oscillators to the same input pins, and activate only the column we want to read by giving a ground to the "left-hand-side" of the circuit. Instead of connecting and removing the blue wire, we're going to set an i/o pin to a high output, then turn it to an input. By turning the pin to a (high impedence) input pin, we're effectively removing the power source and setting the oscillator running.

Now we need to create a grid of sensors, attaching multiple oscillators to each i/o pin. Consider the diagram below (we're still not sure this will actually work, but this is the theory so far!)

Note the resistors on the i/o pins. Although the PIC has internal clamp diodes to enable it to cope with reversed voltage (from the inductors during oscillation) we need to have high value input resistors to protect the internal clamp diodes from too much current.

Let's say we want to read the left-most column of sensors. We set the output pins on the shift register such that Q0 is low and Q1-Q7 are high. This means that the capacitors and inductors C1-C4 and L1-L4 have no ground connection and - in theory - are taken out of the "read" part of the circuit.

If we turn PORTB into an output and make the entire PORTB high, capacitors C5-C8 should begin to charge and only coils L5-L8 have a ground connected to them (capacitors C1-C4 and coils L1-L4 have no ground connection and should not be affected). Now let's concentrate on just C5/L5:
If we make all of PORTB an input, C5 should begin to discharge. But there's nothing stopping it discharging through coils L6-L8 as well as (or instead of?) L5. But if we make ONLY PORTB.0 an input, C5 should only be able to discharge through L5 (since L6-L8 has power still connected to the "right-hand" side of the circuit). So we should be able to read the time taken for the current to oscillate through L5 and use this to determine whether or not a metallic object is interrupting the magnetic field of L5.

We then turn PORTB.0 to a high output pin and turn PORTB.1 to an input pin and repeat for L6. After reading L6, we should be able to read L7 and L8 in a similar fashion.

Now presuming all this actually works, we should be able to adjust the output from our shift register, to make Q0 high and send Q1 low (keeping Q2-Q8 high). This in turn provides a ground connection for the right-most "column" of sensors only. By repeating the reading process, we should be able to detect the presence of metal objects above L1-L4.

At this stage, it's all supposition and makes a lot of assumptions. But there's only one way to find out if this will actually work - and that's to make up a PCB and give it a try!

Metal detecting for board game inputs

It's nearly the end of February and there's been very little coming out of Nerd Towers of late. Strictly speaking, that's not true, since we've been coding like the proverbial 1,000 monkeys at 1,000 typewriters (the output has been pretty similar of late too!). But software coding just doesn't feel like "making stuff" so we're determined to put that right.

While browsing the 'net the other day, looking for information about inductors (what they are, what they do, what they're used for) I stumbled upon this interesting animation. They say a picture speaks a thousand words; this one explained inductors and LC oscillators beautifully:

It came from this website: http://www.talkingelectronics.com/projects/Inductor/Inductor-2.html
Now in itself this demonstrates a fascinating property of inductors and capacitors when connected together. But then we came across this - http://www.schoenbuch-electronic.de/index.php?id=145
Which suggests that placing a metal object near an inductor affects the magnetic field and causes the frequency of the oscillator to change. Now that got us thinking:

If instead of the blue wire we connected the LC oscillator to a PIC i/o pin, we could set the pin to output mode and "charge" the circuit. After a delay, we could turn the pin to an input and set a timer running. When the input on the pin changes from low-to-high, we've got a means to calculate the frequency of the oscillator. We've ignored the negative voltage from the circuit because with PIC microcontrollers, every input pin has a clamp diode ensuring only voltages within the range 0-Vcc are accepted. In fact, a PIC is a pretty robust device and can handle really large +ve and -ve voltages (http://www.electro-tech-online.com/microcontrollers/96653-detecting-12v-pic-input-running-5v-off-7805-a.html ). The only thing we need to do is make sure the input diodes are protected by large value resistors.

So the principle is we send a pin high, wait, set it to an input then wait to see how long it is before we get a response back on the input pin. If the delay is larger or smaller than expected, we can confidently say that a metallic object is present. If only we could work out the "natural" oscillation of our LC circuit....

This website had just what we were looking for! http://www.deephaven.co.uk/lc.html

If we type in an inductor and capacitor value, it works out the expected frequency of the circuit. Perfect!

So now we have a very basic metal detector circuit. What now?

About a year ago, we started work on an electronic board game (Blood Bowl). After hitting problems with capacitive sensing, not much more was done with it. But this latest development has got us thinking - the playing pieces in the game are (pewter) metal (but the same approach could be used for many board games, with a small piece of metal inserted into the base of the playing pieces). If we could use inductive sensing to detect when a piece is placed/removed from the board, our idea of a digital board game could well be back on! And coupled with the alarm clock audio player we came up with a few months back, could even include sound effects too!

Given that a chess board has 8x8 = 64 squares, and a board game has 300 or more playing squares, it's going to be important to keep costs down on this idea. So we're looking for 

a) cheap inductors

b) cheap capacitors

c) accurate capacitors (there's no point using -20%/+80% caps to detect a 25% change in inductance!)

d) easy to use components (there's going to be a lot of soldering!)

So we came up with a shopping list.

These surface mount inductors from Farnell are less than 5p each in volumes of 100+

They're 1.5mH and accurate to 10%. They're in an 1812 surface mount package, so just a bit bigger than the SMT resistors we're already familiar with

These surface mount capacitors are 1.5uF, also accurate to 10% and cost less than 3p each.

They're also in the familiar 1206 SMT package so should be quite easy to work with.

If we use a 1.5mH inductor and a 1.5uF capacitor, in theory we should be able to create an LC oscillator which runs at about 100khz - ideally we could use "bigger" value components and get a slower oscillation; but a PIC micro running of a 20Mhz crystal should be plenty fast enough to read any variance in a 100khz signal, so we're trying to keep the cost down and use as cheap components as we can get hold of!

Using the components we've identified, each square on the board will cost 8p in components (not including the MCU or any external i/o expanders or shift registers). Although this isn't a massive cost, for anything more than a simple chess-type board, things could easily get very expensive, very quickly. For example, a Blood Bowl board is 15x26 squares in size: that's 390 squares. For just the inductors and capacitors, that's £31.20. Not a massive cost for a one-off prototype, but quite pricey if we ever decide to make more than one!

Before we go crazy buying up loads of kit and components, it's probably best to try the idea out with a few rows and columns on a board game board. That's exactly what we're going to do - and post the results here in a few days.......

Getting started with iOS iPhone apps and Flash CS6

One of the reasons there's been little activity (hardware development-wise) at Nerd Towers is we've finally joined the cool kids and had a go at making some iPhone/iPad apps. Yes, yes, not before time and all that. But it's been quite a learning curve!

Not the coding - we've been writing stuff in Flash/Actionscript for a while now. But it was time to upgrade from that old work-purchased CS3 so we went crazy and subscribed to Adobe Flash CS6 for 12 months. At just £17/month it's actually really good value - it'd take about three years to pay back the £600 purchase price at this rate, by which time, there'll probably be an update on the way! Using the monthly subscription method, you automatically get any updates as they are released. Well done, Adobe!

Anyway, back to this blog post - making our first iPhone app.
Actually, if you're using a Windows version of CS6, getting it up and running is actually a bit of a faff, but perfectly do-able. All the tutorials on the 'web tell you to use a Mac if you can (I can't bring myself to, and other people I know have battled on down the Windows route successfully so I thought I'd give it a go!)

There's no point repeating here what the Adobe website tells you to do, perfectly well, at http://help.adobe.com/en_US/as3/iphone/WS144092a96ffef7cc-371badff126abc17b1f-7ffe.html but the upshot is that after about an hour of messing about (including going to the shops for milk and coffee) we got a working .p12 certificate. And more importantly, this little screen:

We successfully created our first iPhone app (well, I did anyway!).
Now we're off to bug Steve about how to actually get it onto the device....

Microchip samples

Well, it's February already and we've not really got much to show for 2013 yet. It's been all work, work, work and little chance for play. But hopefully all that's about to change - thanks to some fantastic FREE samples from Microchip that arrived in the post this morning:

We've got quite a range - including some monster 16F877A 40-pin chips, to make a couple more word clocks, some of our new-favourite 16F1825 chips as well as some beefy 18F4550 USB-based chips so we can have a go at getting USB working with Sourceboost. The little tiny teeny chips are some 16F455s which looked intriguing, not least of all because they offer a full USB stack on a 16F chip. They also have an internal oscillator running at 48Mhz, so getting the required 96Mhz for USB should be quite straight-forward!

And while we're on the subject of our word clock, Matt from BuildBrighton kindly donated an RTC with battery backup. It provides a nice easy SPI interface to get the current date/time. We're going to put one of these into our word clock, so that we don't have to keep setting the time every time the main power source is removed.

 (these boards also contain a small eeprom chip to store the current date/time)

(battery backup means they keep time even when power has been removed)

With BuildBrighton regular Thursday nights back in full swing after the New Year, we're hoping to get making some cool stuff again, really soon!