Serial/UART communication between two PICs (18F and 16F)

It's taken a long time and a lot of different approaches to get even simple serial communication between two PICs working. Perhaps hampered a little by using two different PICs (a 16F and an 18F series chip) but that really shouldn't make any difference. Serial/UART communication shouldn't be platform dependent!

We've tried serial/UART, SPI, I2C and even bit-banging and each time got different (non-working) results. It's too much to go into in this blog post, so we're just going to describe how we actually got a working prototype:

The first thing to note is that although we're using one of our favoured 18F4550 PICs, we couldn't use the USB  and UART together. So for this experiment, we're reading the data back off our 18F (master) chip via serial, using the excellent PICKit2 programmer and software.

In our first (failed) attempt at creating pic-to-pic communication, we had our 16F (slave) device monitoring it's input pins and simply broadcasting the results as an 8-byte message over UART. The idea was for the 18F (master) chip to read this serial stream at intervals, find the start of the message and decode the rest of it, so that it knows the state of the slave chip.

In theory this sounds fine. In practice, sending more than about 4 bytes to the 18F (master) chip caused it to lock up on the Hserin command. We even tried connecting the PICKit2 to the RX pin on the 18F and removed our slave chip altogether. Our tests confirmed the same thing happening - if we sent one or two bytes at a time to the 18F from the PICKit2 terminal, it successfully received them and sent a response message back. If we sent more than about five bytes at a time, the 18F simply stopped responding - apparently locking up at the point where it reads in the serial data
(we proved this by switching an LED on just before the Hserin command, and turning it off again immediately after).

So it appears that we have a set-up whereby we can receive data from our slave, one byte at a time, but the master can't simply "dip in" to a serial stream being "broadcast" by the slave. After reading through the datasheet, it seems that the 18F has only a two (or was it four) byte buffer so blasting more bytes into the buffer than it can handle is causing some sort of buffer overrun error.

We need some way of getting the master chip to ask for data, one byte at a time.
This is what we came up with:

The master chip sends a pin high then requests a byte from the serial buffer.
The slave chip monitors the state of the "handshaking" line. When the line goes high, and the previous line state is low, this represents a request from the master, so send one byte.
Because we're using hardware UART on the master chip, after the line goes high, the code waits until a byte has arrived in the serial buffer. Because the slave only sends a byte on a low-to-high transition on the handshaking pin, we don't have to worry about buffer under-runs or errors in the master chip.



Slave code

'4Mhz external clock
Define CONF_WORD = 0x3f31
Define CLOCK_FREQUENCY = 4

AllDigital
Config PORTB = Input
Config PORTD = Input
Config PORTC = Input
Config PORTA = Input

declarations:
       Dim linestate As Bit
       Dim lastlinestate As Bit
     
       Dim a1 As Byte
       Dim a2 As Byte
       Dim a3 As Byte
       Dim a4 As Byte
       Dim a5 As Byte
       Dim xorval As Byte
       Dim bytecounter As Byte
            
init:
       WaitMs 50
       Hseropen 9600
       WaitMs 50
            
       linestate = 0
       lastlinestate = 0
       bytecounter = 1
     
loop:
       'all the slave does is read a whole load of input pins
       'and write the response back to the master. The master chip
       'will decide which "row" is live, this chip just takes all
       'the "column" data and sends it back to the master.
     
       'RA0-5
       'RB1-7
       'RC0-5 (6&7 are TX/RX)
       'RD0-7
       'RE0-2
            
       'this should give us 6+7+6+8+3 = 30 inputs
       a1 = PORTA And 63 '(mask off bits 7+6)
       a2 = PORTB And 254 '(make off bit 0, handshake line)
       a3 = PORTC And 63
       a4 = PORTD
       a5 = PORTE And 7
                   
       'now stream the values as a response back to the slave
       'all messages begin 255,255 (since this sequence is not
       'possible in the input stream because we bitmask bytes 1,3,5)
     
       linestate = PORTB.0
       If linestate = 1 And lastlinestate = 0 Then
              'the host chip has asked for another byte of data
            
              'create the checksum value
              xorval = 0
              xorval = xorval Xor a1
              xorval = xorval Xor a2
              xorval = xorval Xor a3
              xorval = xorval Xor a4
              xorval = xorval Xor a5
              xorval = xorval And 127

              'decide which byte of the message to send
              '(the host has to ask for each message eight times for all 8 bytes)
              Select Case bytecounter
                     Case 1
                     Hserout 255
                     Case 2
                     Hserout 255
                     Case 3
                     Hserout a1
                     Case 4
                     Hserout a2
                     Case 5
                     Hserout a3
                     Case 6
                     Hserout a4
                     Case 7
                     Hserout a5
                     Case 8
                     Hserout xorval
                     bytecounter = 0
              EndSelect
            
              bytecounter = bytecounter + 1
       Endif
       lastlinestate = linestate
     
Goto loop
End

Master code

AllDigital

declarations:
       Dim a1 As Byte
       Dim a2 As Byte
       Symbol lineshake = PORTA.0
       Config PORTA.0 = Output
     
init:
       Low PORTA.0
       WaitMs 200
       Hseropen 9600
       WaitMs 200
     
loop:

       Gosub getnextbyte
       'two 255 = start of message
       Hserout 255
       Hserout 255
       Hserout a1
            
Goto loop
End

getnextbyte:
       'to get the next byte, we send the lineshaking
       'line high - this tells the slave to "release"
       'another byte. Once we have this byte, we drive
       'the lineshaking pin low to say we're done
       High lineshake
       Hserin a1
       Low lineshake
     
Return

After connecting up the slave to the master (the TX pin of the slave into the RX pin of the master, and RA.0 on the master to RB.0 on the slave) we did actually start receiving intelligible data from the master. So it looks like we've (finally) cracked pic-to-pic communication over serial.

It's probably a bit slower than it needs to be (since the master has to "poll" each byte from the slave) but it's fast enough for what we want - and once we crank the baud rate up from 9600 to about 57600, or even 115200, it should be more than quick enough to scan an entire game board (of not more than 16 x 28 = 448 squares) at a reasonable rate.

Communication between two PIC microcontrollers

We're having a bit of a nightmare getting two PICs to talk to each other.

The master is an 18F4550 which will do most of the grunt work and talks to the PC host via USB (we use Oshonsoft's excellent USB/HID library for our USB work).

The slave is a 16F877A (no reason for this particular model other than we had quite a few of these lying around). This basic idea is that the 16F reads 28 input pins and writes a four-byte value out to the serial port.

The master periodically polls the slave, reading the serial data. It looks for two specific bytes which signify the start of the message, then reads in the next four bytes that make up the message (the fifth byte is the XOR sum of the previous four bytes so we have some sort of checksum).

The problem is that while we can check the 16F using the PICKit2 UART tool - and it successfully reads the message being "broadcast" by the slave - when we try to read data using the hardware UART port on the 18F master chip, the USB comms lock up and our PC app stops working.

It seems that we aren't the first people to run into this sort of problem and there are lots of queries across the 'net asking for help with USB and serial comms together. Here's just one example:

http://www.3dreplicators.com/cgi-bin/cblog/index.php?/archives/461-Fixing-a-software-problem-with-hardware.html

So it looks like USB and UART together isn't going to work.

Which is a bit of a bummer.

Also, like the author of the article above, we were also hoping to use the timer1 interrupt to keep a simple clock running, which makes software-based bit-banging and no-go either. Getting a PIC to work as an I2C slave looks quite complicated too, so we're running out of ideas.

The only thing left for us to try is getting two PICs talking to either other using SPI hardware on both the master and slave chips.

Hopefully this will work with both USB and timer1 interrupts running on the master chip. But until we try, we're not going to know......

PIC16F877A resetting

This is just a general post to remind anyone like me who often forgets the basics and spends far too long trying to find faults with hardware/firmware that just aren't there. Although in my case, it's specific to my 18F877A, the same rules apply to 16F628A chips and pretty much any of the 16F range.

Here's why I'm so stupid......

I've been working a lot lately with 18F series chips.

These are great because they have loads of different "fuses" which let you set up the chip in a particular way. One of the fuses on the 18F range allows you to reclaim pin one - the MCLR/PGV (programming voltage) pin and set it to an input. I do this with pretty much all my 18F chips.

So when I came back to the old 16F series chips (the 16F877A is an old favourite that first got me interested in PIC programming) I completely forgot that you need to apply 5v to the MCLR pin to stop the chip from resetting (pulling this pin low causes the PIC to reset completely).

So during testing, while trying to read the serial message(s) being "broadcast" from my 16F chip, I kept getting blackouts - periods when the serial stream would stop. Wiggle a few wires around on the breadboard and it would come back to life. For a little while.

Everything was pointing at a hardware problem - either a dodgy wire or a loose crystal or something. I re-wrote the firmware on both the slave and master chips, stripping each down to just the bare essentials, and used a really handy tool in the PICKit2 software to monitor the serial stream

You can connect anything that uses serial comms, and set the baud rate to any of the common bps values - 1200, 2400, 4800, 9600, 19200, 38400 etc as well as your own custom baud rate (ideal for debugging MIDI devices at 31250)

Anyway, after connecting everything up, setting it running and not touching a thing, the 16F would periodically shut down. I stripped out all the wires, rewired the board with a brand new set of jumper wires, put LEDs on all kinds of output pins and so on. I checked and double-checked the fuses, made sure the watchdog timer was disabled (and even tried enabling it and littering the firmware with watchdog reset commands) and checked the brown-out option wasn't selected. I even put a few different capacitors on the power rail of the 16F, just in case the input voltage was getting a bit wobbly.

The whole thing was suddenly a lot more complicated than any other PIC project I'd ever worked on and still it kept resetting.....

.... that's when I remembered that pin one (MCLR) has to be pulled high to stop the, erm, PIC from resetting all the time. Bugger.

It was as simple as that!
A single wire from pin one to 5V and everything worked beautifully.
If I had remembered about the MCLR pin earlier, instead of assuming it was always set to behave as an in input pin I think I'd have saved myself about two hours this evening.

Hopefully this post will help others in future to avoid wasting a similar amount of time on something so trivial!

Electronic board game - Blood Bowl clone

Some interesting developments over the last few evenings as we've put together all kinds of ideas for an intelligent board for a board game (like, our old favourite Blood Bowl).
Our original proposal - based on freeing up as many pins as possible from two 40-pin PIC microcontrollers - was to allow for up to 600 squares, or a grid of 20x30

To allow for as much flexibility as possible, while at the same time making it relatively easy to understand, we've decided on a modular approach. Our board game will actually be made up of a grid of 4x2 "blocks" which can then be wired together in any arrangement. It means we've lost the flexibility of really wacky board layouts (although using the same technology it should be possible to create one-off boards with pretty much any layout as required) but does mean that we can simplify making boards of different dimensions.
(it also means that anyone who buys their copper boards in eurocard 100mmx160mm size can still make a board game, using a "patchwork" of smaller boards)

4x2 Board Piece

Each playing square in this board is marked out by a "cross" shape on the board. Small through-hole studs are soldered to this underside, so that on the playing side of the board, a small contact point is visible on the playing surface. Each playing piece has a conductive base (a copper coin glued to the bottom would suffice!) and when placed over the four points of a cross, makes a connection between the top and right contacts and the bottom/left contacts.

Using the above layout, we can place these pieces side-by-side and join the edges, while connecting each group of top/right contacts together using short pieces of (insulated) wire

Using this approach, we've designed our Blood Bowl board.
It's not quite 30 x 20, but we found that vertically connecting 7 "rows" of 4 contacts means for each row we can read back up to 28 lines of "column" data. By placing four of these smaller boards side-by-side, our board size is 28 x 16 playing squares. Not a bad compromise and certainly a sizeable playing area for a lot of different board games.

So what does it look like? In short, a nightmare!

As you can see, each smaller board is connected to the board horizontally next to it (the traces were deliberately lined up to make this bit quite easy). Every 7 vertical rows of contacts are connected via wire traces (shown in this diagram by different coloured bars) and each group of these 7x4 = 28 contacts is then connected to the slave microcontroller via a short wire (the connection points for these wires are circled in a matching colour).

There are 16 wire connect points - these go to the master PIC. The 28 traces from the bottom/left sets of contact points are connected to the slave. By flashing one of the 16 wires at a time, and reading the input values on the 28 inputs, we should be able to work out which set(s) of contacts are being bridged by a playing piece on the board.

That's the theory anyway.......

Students at Harvard creat flexible crawling robot

Robots usually walk, have wheels, or even fly, but this robot crawls using its own body. Gumby is what they call it and it uses it's body to crawl through tight spaces. They based their robot off of a squid and to me they did a pretty good job. In the video above they show the robot's skills and he capability that it has. Thanks for reading and we hope you enjoy the video!

PICKit2 clone programmer alternatives

Something has happened to our faithful old PIC programmer - it was (was being the key word) a PICKit2 clone, iCP01 from piccircuit.com and had worked tirelessly for about three years.
But for some reason, it has suddenly stopped working.
No puff of smoke or funny smell - it just stopped working.

At first it had problems recognising a 16F877A DIP, so - as we always do before wiggling wires - it was removed from the USB port (removing any power from the breadboard) and then when it was plugged in there was no "bing-bong" or any indication that the PC had recognised the USB device.

That's it. Despite stripping off the yellow shrink wrap and inspecting the components on the board (nothing seems to have blown and there's continuity across the connections where you'd expect there to be) the device simply refuses to work.

The PICKit2 software doesn't even recognise that the device is plugged in, and Device Manager fails to identify it too. So it's officially dead. The question is, do we get another one (they're great little programmers and really fast too) or try something else?

An Ipad App We All Wish We Could Have

  As most of you already know if you have been following my blog I am into a lot of different projects.  One of these I have been playing around with again today is Blender 3D.  Blender is a powerful 3D modeling and animation software which I have used to created concept 3D computer models of ideas that I have in my head for future projects or just for the fun of creating an interesting 3D computer generated image or CGI for short.  Today I got a wild idea after shooting a sample video of my Makerbot Semi that I have been creating using a Makerbot 3D printer.  What most people do not realize is that Blender 3D has a built in video sequence editor that is very powerful for creating CGI for movies.  Blender can take a normal video and change it to do something more than just adding titles or background music.  
  I am still learning this portion of Blender as I am always learning new things with the projects that I play with and so today I put together this little video.  I thought I would post it here just to possibly give you a laugh and maybe make you smile.  That and the fact that my video can show you what can be done using just a little imagination and some help from Blender 3D.  Also there is no one that wants this Ipad app more than me.  

Multi-plexing LEDs for word clock

Having failed miserably at debugging our charlie-plexed LED array we've decided to stick to the simpler approach of using multi-plexing.

There's a subtle difference, but since we're already getting down and dirty with multi-plexing for inputs on a board game it made sense to use this same approach for outputs/LEDs. The main difference is that we'll be using a pin for each row and a pin for each column (10 rows x 9 columns = 10+9 = 19 pins).
If we move away from the 16F628A (with 18 pins) and go far a larger chip, with more i/o pins, then multi-plexing gives us a simpler, easier-to-debug solution.

With this in mind, we set about creating a new PCB to use multi-plexing.
So far we've just put a load of LEDs into a grid formation - the actual controller board will be a separate PCB mounted onto the back:

Uln2803a Driven LED array

Here's a photo of the completed board, populated with LEDs, ready for testing.

Unlike last time, testing LEDs is quite straight-forward; and already we've found some potential problems; a lot of the LEDs are re-used from the old board and by connecting a 3v coin-cell battery straight across the anode and cathode of each LED, we've found about half-a-dozen that refuse to light up.

Whether these were damaged during removal, or never actually worked on the original board, we'll never know. But at least we've an explanation as to why the charlie-plexed board didn't work. Sort of.

Anyway, we're going to pop out those duds and test each individual LED on this board before even considering wiring it up to the rest of the project!

RoboFollower, the new letsmakerobots

Hello robot fans! Yesterday I started a project website or blog where google account users can submit their robots to appear on my robot fan site. It is based off of LetsMakeRobots. I hope you enjoy, and heres the link, http://robofollower.blogspot.com/.

The nerds are off to Berlin!

Ok, it's only for a week or so, but we've confirmed our tickets for early next month (December). And a quick look on hackerspaces.org tells us that there are no less than 12 hackerspaces, in Berlin alone!
We won't have time to visit all of them (unless we go to three different ones on each day we have free) so we'll have to concentrate on English-speaking spaces for now (a few of us can speak French to an ok level, but German is a whole new language!)

Woo-hoo, Europe here we come!

EasyBotics Biped Robot Sumo Competition

Usually robot sumo competitions are held with wheeled robots, however EasyBotics held one using their biped robots. The biped's objective were to push the opponent out of the ring, and just like a real sumo fight, the bipeds fought for three rounds. The robot who won the most rounds out
of three won the competition. Thanks for reading and check out the video above to see them fight!

Using 2 PIC micros for a huge input array

After spending some time thinking about a large board game input device - which simply tracks the position of each piece by comparing the current board state to a previously known state - we've decided that a multi-plexed approach will probably be the easiest to implement.

The problem with a multi-plexed approach is that whatever size grid is used determines the number of pins needed (so a 10 x 10 grid needs 10+10=20 i/o pins).

Rather than try the idea out with something simple, then discover it doesn't expand well for bigger/more complex games, we've decided to have a go at quite a complex game, and - if it works - scale it back for simpler board games. For now, we're concentrating on tracking the positions of "dumb" game pieces on the board throughout a game.

One of our favourite geek-games of the 80s was Blood Bowl (which thanks to a console remake being released in 2011 is seeing a bit of revival in recent months). Now, the original Blood Bowl board was a massive 15 x 26 = 390 squares in size.

Obviously, using a PIC with only about 30 spare pins is never going to cut it. So we're back to either using analogue inputs or increasing the i/o pins using shift registers. After much discussion, however, one idea really started to appeal: use two PIC microcontrollers!

This is not only cheaper than implementing a whole array of shift registers, but also gives us a bit more oomph to play with, as we could split game play up over a master and a slave controller.

We're planning on using the master to activate an entire "row" of inputs (the output Port1 in this previous port) but then to start listening on a serial RX pin for a response from the slave. The slave micro simply looks at the input state of all the pins (uC Port2 input in this previous post) and sends this back to the master via serial TX.

Because the master knows which row it activated, it can decode the value received over serial and work out which combination of buttons/inputs were activated. Now, by using 2 x 18F4550 chips, we've up to 30 pins available on each chip and a grid of 30 x 30 inputs (900 squares) is suddenly achievable.

For our Blood Bowl game, we could easily implement a 15 x 26 grid of squares and still have about 15 i/o pins freed up on our master controller (this controlling 15 rows, with the 26 inputs on each column being read by the slave controller). With this in mind, and after much more discussion (and a few more cups of tea and a whole packet of hob-nobs) we reckon we could come up with a generic board game controller which would have:

a) support for up to 600 squares (e.g. 20x30 but not necessarily in a square formation)
b) an LCD display for each player/side which can display current game status
c) built-in dice roll and other random-number generators
d) ability to calculate results/outcomes which would otherwise require dice rolls and table look-ups in the rule book

Although we've not actually built anything yet, this is quite an exciting development.
We remember Blood Bowl as being a great game, but bogged down with dice rolling, looking up results in tables, applying modifiers based on the playing piece type and so on. The Third Edition of Blood Bowl tried to do away with a lot of this by using a simpler dice system, but eventually the same thing happened: the immediate action could be resolved quickly (did a particular action succeed or fail) but when this affected another players ability, yet more dice rolls and table look-ups were necessary.

 If we could remove all this dice rolling and referring back to the rule book and introduce a simple interface - so a player could pick up a piece to identify which is being moved, then press a button to say which action they were performing - the microcontroller could do all the random number generating and issue resolving; simply displaying a message on an LCD screen to the user, to inform them of the outcome and what to do next.

Here's how our Blood Bowl game could look with the clever electronics in place:

Using a multiplexed keypad for other input ideas

After a less-than-successful show-and-tell session at the weekend (yes, the one we've been devoting so much time and effort to over the last few weeks, and putting all our own personal projects on the backburner for!) the few people who did turn up spent some time discussing the various projects we were working on.

A few old ideas were explored once again - sometimes a fresh pair of ideas on an old problem can turn up some really interesting ideas in themselves - and a few new ideas were chewed over.

One of the ideas that came up was using a keypad style matrix, not for output (lighting LEDs like we were doing with our charlie-plexed array for the word clock) but for input. It came following the announcement that some of the members of BuildBrighton were looking to set up a monthly board-game-geek meeting (ok, we left Brighton some time ago, but it's important to keep in touch and see what those crazy guys are up to every now and again!). A few of us here at Nerd Towers remember fondly playing uber-geek board games like Blood Bowl, HeroQuest and Space Crusade, as pimply-faced youths, when they were first released during the 80s.

The idea being investigated is using a microcontroller to load data about each piece (a lot of playing pieces in these role-play type games had a range of different values associated with them) and then to place them on the board in a specific sequence. Each piece will be a "dumb" token - i.e. does not contain or broadcast data about itself - but the board-game controller would keep track of each piece on the board, based on when it was placed on the board, and comparing the current board state with a previously known state, to work out which piece has been lifted off the board.

A quick search on Google turned up some interesting results, but most solutions broadly follow one of two methods - a multi-plex approach (using a pin to activate a full row of inputs, then querying each pin on the row to see if it has been activated) and an analogue approach, to reduce the number of pins required.

Because we're potentially dealing with hundreds of squares on a typical board game (even the simplest of board games, chess, uses 64 squares in an 8x8 grid) we're keen to keep the number of pins required down to an absolute minimum:

With the correct value resistors, we should be able to read which key has been pressed using a single input pin. This idea looks perfect for what we need. However, in practice this is quite a difficult method to implement. Why?

The solution above is better suited to single-key entry, such as a telephone keypad or security pad, where each key is pressed, one at a time.

To be able to detect multiple key presses using a single analogue input pin, we'd need to use resistor values in roughly base-2 increments. i.e. 200 ohms, 400 ohms, 800 ohms, 1600 ohms, 3200 ohms etc.

Now we know that 

a) resistors don't always come in exactly the value we want so we have to go for a best match

b) resistors have up to 10% error in them already

c) reading an analogue input is not accurate - you need to take an average over time, or work with "bands" or thresholds, to decide the true value of the input on the analogue pin.

In fact, to get to 16 inputs, we'd end up using really huge value resistors - the error in which could be more than some of the lowest-value resistors, further down the array. In short, calculating unique key combinations on a single analogue input pin is going to be, at best, difficult and in practice, almost impossible!

Which takes us back to the multi-plex approach:

Here, we need to strobe each of D0, D1, D2, D3 and take multiple readings to calculate which pins are pressed. So, for example, we could force Port1 (output) D0 low (since the outputs are tied to Vcc through a pull-up resistor) and then read the values on input pin D3 on the Port2 (input).

Under normal circumstances, D3 is pulled high through the pull up resistor at the top left of the circuit. If, however, D3 is LOW, we know that button 3 must be being pressed down. Now we read the value of Port2 D2. Like before, we expect it to be high (no button pressed) but if it is low, this tells us that button 2 must be being pressed. Similarly, if Port2 D1 is low, button 1 is pressed, and if Port2 D0 is low, button 0 must be being held down.

Now we sent Port1 (output) D0 high and pull Port1 D1 (output) low.

Checking the input pins again this time tells us whether buttons 7,6,5 or 4 are held down.

Although this approach uses more pins and appears more complex (in execution rather than in hardware) it does allow us to tell exactly which combination of buttons are pressed, even if two, three or more buttons are pressed all at the same time.

We're looking at the 18F4550 which is a 40-pin PIC microcontroller (and includes USB so we can easily download game data onto the chip) but when you take out all the used pins (2 x power, 2 x ground, usb etc) we're lucky if we have up to 28 pins to play with.

In a grid arrangement, this gives us not much more than a 14 x 14 matrix which is pretty small for anything but the simplest of board games......

Fanell Blogger Outreach Program

Here at Nerd Towers, we're big fans of Farnell.
The level of service, fast delivery but most of all, their amazing website leaves the others in the shade!
Although you can sometimes save a few pence (or even a few quid) by going to competitors such as RS, Rapid, Mouser, eBay etc, you often find buying a few bits from one, and a few bits from another - just to get the best deal - means waiting ages for all your different suppliers to send stuff out.

Wherever possible we try to source all our components in one hit, from one place. And more often than not, it's from Farnell.

The reason is because their website is so easy to use!
I've never really browsed by category, or spent any time just clicking from item-to-item. I go straight for the search bar, type in what I want and then apply different filters to the results until I get what I want. Unlike some sites (*cough* RS) where even if you provide the exact part number you don't always get a match, the Farnell site has some really clever search intellegence behind it. You can even type in a vague description of the sort of thing you're after and it'll have a stab at what it thinks you mean. And then alongside each set of results, are alternatives or related components. Not Amazon-style-other-people-bought-this, but actually complimentary alternatives to what you've found.

Now we must add in a caveat to this Farnell-love-in.
But it's just another reason we put them above the others - brand loyalty.
Like most other "tech" suppliers, Farnell recently entered into the "community" arena; RS have their DesignSpark community (and their, frankly, dismal PCB design software), Instructables was recently bought up by AutoDesk - suppliers of the eye-wateringly expensive AutoCAD - just to get a community base and even gave away free versions of their CAD software, and Farnell launched element14.

In fact, element14 was one of the first to recognise that what drives geek-communities is a challenge. So they set up the Global HackerSpace Challenge. They even gave each hackspace a budget to buy stuff with. Not drop their own branded "freebies" onto them as a cheap alternative to beta-testing, but gave away real, genuine cash, and said "go buy stuff, make something with it, tell us what you made".

Now Farnell are continuing in this vein, giving away yet more stuff - but allowing the recipient to decide what to choose, not just promoting their own range of products. It's called a "blogger outreach programme".

And we think it's a great idea.
But then again, we probably would, since we're one of the lucky recipients!
It's hard, being given the Farnell catalogue to choose from, to decide what to go for. Choose something too expensive and you just end up looking greedy and getting expensive stuff for the sake of it. But then again, a handful of resistors worth 50p are hardly worth bothering with! In the end, we took a look at the projects we had on the go, and decided to grab some freebies to help complete them.

So yesterday we received 100 SMT LEDs which originally were going to be for our word clock project (using SMT means not having to drill over 200 holes on the next board!) but we might just incorporate into a full-sized light-up guitar fingerboard.

[photo here]

Since we've spent many months working on our range of miniature instruments, we've neglected what it was that first sparked the initial idea - that is a love of cool/geeky (full-sized) guitars. With a load of LEDs, we started designing an acrylic fingerboard (yup, acrylic. Not rosewood or ebony or maple - the usual choice of wood for a fingerboard, but good old laser-cuttable plastic!) The idea is to create a "learn to play" guitar neck, which can light up and show you where to put your fingers. Such guitars do exist, from places like FretLight, but they're quiet expensive!

We've a load of cheap guitars (off eBay) that play ok so we're going to try to retro-fit a light-up fretboard onto an existing instrument. But once we're done, we want the rest of the guitar to light up too!

So our second freebie from Farnell was a selection of EL (electro-luminescent) wire which we're planning on putting around the guitar body, for the ultimate glow-in-the-dark finish!

[EL wire photo]


We're really looking forward to spending a bit of time doing what we do best - just nerding out with a bunch of components and seeing what we can come up with. And, of course, posting the results on our blog.

Check back for progress updates soon!

Multi-lights controller for toy cars

As one of the younger members of HackLlan Jason was busy making LED traffic lights for his younger brother last Thursday. This week, we've been working on taking that idea to the next level.

Instead of a simple pin-on, pin-off with delay approach, we've changed the code in the microcontroller to use a single Timer0 interrupt (raising an "event" every 1ms) and a number of counters and state machines to control lots of different devices all at the same time.

Instead of the smaller 16F628A chip (used in the original prototype) we've gone to the other end of the scale and put in a massive 40-pin 18F4550. This gives us plenty of i/o options. So far, we've kept PORTB for inputs (using the internal pull-ups to reduce the final component count), put the traffic lights on PORTD and used PORTC for the servo and LED controller for the level crossing.


The what???

That's right. This controller now simultaneously handles:

• two sets of inter-dependent traffic lights
• two sets of alternate flashing level crossing lights
• two servos (level crossing gates)
• a one-shot fire-on-release ultra-bright LED (speed camera)

There are still plenty of spare i/o pins to add more to this project in the future (pelican crossing, belisha beacon etc) but we need to think about finishing off what we've got here, otherwise it'll be Xmas and we'll still have everything on a loose-wired breadboard (which let's be honest, won't be much of a final gift!)

Here's a video showing the breadboard, controlling all the different lights and servos at the same time -
well done Jason!




Note how the traffic lights continue to work independently of the other things on the board - the alternating lights work separately to the traffic lights, and the servo signals are being sent every 20ms to update the servo horn/gate positions. And all the while the speed camera goes off at periodic intervals!

Arduino biped robot

After viewing the easybiped from easybotics, it inspired me to create my own, and in about 20 minutes I created the legs and body. However, that's not the real challenge. Since I am using an arduino board, I will have to program the it to get the legs moving. I have made a video on it, and if any of you would like to help me with the code then I would appreciate that a lot. Thanks for reading and please like us on google plus!

Arduino Servo Code For a Robot

If you're a newbie in Arduino and would like to build and program robots, then this is the code for you. It is written for an Arduino board and it's purpose is to control servo motors. In the code are numbers, and I'll let you change them up and experiment with the code. Hopefully you'll learn something about programming after you use the code. Thanks for reading and click here for even more code relating to Arduino!
The code

/*
Arduino Servo Code
*/

#include <Servo.h>
Servo servoOne; // Define our Servo

void setup()
{
servoOne.attach(10); // servo on digital pin 10
}

void loop()
{
servoOne.write(45); // Turn Servo Left to 45 degrees
delay(1000); // Wait 1 second
servoOne.write(0); // Turn Servo Left to 0 degrees
delay(1000); // Wait 1 second
servoOne.write(90); // Turn Servo back to center position (90 degrees)
delay(1000); // Wait 1 second
servoOne.write(135); // Turn Servo Right to 135 degrees
delay(1000); // Wait 1 second
servoOne.write(180); // Turn Servo Right to 180 degrees
delay(1000); // Wait 1 second
servoOne.write(90); // Turn Servo back to center position (90 degrees)
delay(1000); // Wait 1 second
}

Adding more than one servo!

1. Define a second servo 
Servo servoTwo; // Define our Servo)

2. Attach it
servoTwo.attach(12); // servo on digital pin 12

3. Add it void loop
servoTwo.write(45);
delay(1000);

Removing/Editing Delays

1. Delete the "delay(1000); // Wait 1 second" in the code

2. Edit the number "(1000)" to whatever you want. 1000 equals one second.

Changing the degrees

1. Change the "(45)" to whatever angle you want in "servoOne.write(45); // Turn Servo Left to 45 degrees"

Even more code!

If you're interested in programming the servo with more extensive code, then check out the forums and ask for help there. If you need any further assistance on programming, feel free to contact me at the "contact" page!

My Makerbot Semi Project..... 27.87 hours and counting

  With all the projects that I have my fingers into lately I did not want anyone to think that I have given up on my Makerbot Semi build.  Progress is still being made one part at a time and today I was able to put a lot of these parts together to get closer to completing the Semi tractor assembly.  Current time now just printing parts has reached 27.87 hours.  This does not even include the design time, painting or trial parts that just did not work out just right. So I would say to double that amount of hours would be a fair guess as to the time I have put into this project.  But it is all looking really good so it is worth it.  My sister thought I need a time clock to keep track of all the hours I put into a project.  Sounds like another project in itself to put a time clock together.

In this photo the Semi cab complete with seats, steering wheel and windsheild were added to the main frame.  Also the front bumper was glued and mounted at the same time. The sides of the cab were located using 1/4 inch wooden dowels that were inserted into mating holes in the parts.  Photos of this process are included in this post further down the page.

These two photos show the floor/back wall of the sleeper test fit into the assembly.  I was able to print this part all in one piece which worked out very well. 

Here you can see the locating dowel pins that are used in both sides of the sleeper.  This 1/4 inch wooden dowel is sanded slightly to make it easier to be pushed into the mounting holes. Then they are glued into place. 

I slide the sides onto the center sleeper floor/back wall part and it was nice and tight so the sleeper is finally starting to come together.  I even have a clear plastic rear window mounted into the back wall of the sleeper compartment.

In these two photos you will see the red mounting clip that is used to hold the floor of the sleeper to the Semi chassis.  This clip has two oval shaped protrusions that slide into two corresponding oval slot in the sleeper floor. 

In these three shots the Semi cab and sleeper parts are glued together using modelers glue for plastic and then taped together to hold everything together until it all dried.

Once all the glue had dried I was able to mount the sleeper in it's proper location behind the cab by glueing the sleeper to the Semi chassis along with the chassis/sleeper mounting clip into the sleeper floor. This made for a nice easy installation.  Next will come the printing of the roof air dam, and the ten tires, rims, and hubs for the Semi.  I'll use 1/4 inch wooden dowels for the axles to make the asembly easy and strong. I also will mount the exhaust stacks last as these will be the safest way to keep them from getting damaged during the final portion of the assembly.

  Once I have the Semi tractor assembled a low boy trailer for the model will be next on my to do list. (See earlier posts of photos of the tractor and lowboy together.)  As usual I will keep tracking the hours that I will have in this assembly for anyone that is interested. 

  It will take me a while to finish the rest of the model as I have to travel 70 miles to get to the 3D printer in Davenport at the QC Co-Lab maker space. Needless to say I want a 3D printer of my own here at home. A Makerbot or a Ultimaker 3D printer would be great. So if anyone out there is feeling REALLY generous this year and is listening, Christmas is just around the corner!.................. I can dream can't I?

 

?

Debugging charlie-plexed LED array

All of the online tutorials that mention charlie-plexing and LED array over using shift registers list pros and cons. The pro is always few components, simpler layout etc. and the cons always include "difficult to debug".

They're not wrong!
Since getting our 90-LED charlie-plexed array soldered up nearly a week ago, there's still little improvement on getting it to work properly! We did track down a few broken traces (the black toner in the printer was a bit faint in places so a few traces over-etched and had breaks in them). But even after fixing those, and spending hours and hours with the continuity tester/multimeter, there are still six different scenarios that cause the matrix to fail.

Although we feel we're close to solving it (having identified which pins cause it to fail) the last bit - understanding our findings - is still as elusive as ever! Here's the array working as it should:

The sheet in the background is a drawing of our findings - the six scenarios that cause the matrix to fail and the LED pattern created, instead of a single LED lighting up


Every now and again, however, we get something like this result

 The LED we expected to be lit up is in the centre of the "cross" shape - and remains stubbornly unlit

Even more peculiarly, we did some measuring with the voltmeter. When an LED is lit properly (from a 5v source running through 200 ohms) the voltage across the cathode and anode pins is around 2.9V. The voltage across all the other LEDs in the same row/columns is about 0.6V which is the typical voltage drop across a diode, but not enough to cause it to light up.

When we measured the voltage across the pins of an LED that wouldn't light up (the one we expected to light up but is in the middle of the cross - and remains unlit) we got almost a full 5v across the two pins. All the other LEDs that were faintly lit measured about 2.8-2.9V. So in this case, with the dim LED in the centre of the cross, we're measuring 5V across the pins, but it does not light up.

Here's a diagram of the pins combinations which don't work, and the LED "patterns" that are lit up.
If anyone can spot a pattern or - better still - come up with an explanation, please leave a comment below (and anyone else in future having similar problems might have some idea where to begin debugging!)

Let there be light.....and some time to go with it...... The Plexi-glass clock project

  Over the past couple of weeks I have been working on projects such as the Makerbot Semi that I have posted before on my blog and some secret projects that I won't post simple because they are Christmas presents that I want to keep secret.  Along with these projects I have come up with another idea that I hope will interest everyone as it has already for me.  My CNC machine has made it possible for me to make some interesting things like the 40 inch blimp that I just completed so I thought I would figure out the correct way to do engravings with this wonderful tool.  It took me several tries to work out the best CNC machine settings to engrave acrylic plastic and to do so I just took a piece of scrap that I had laying around in my workshop and started experimenting.  With this playing I aquired the know-how to engrave whatever I wanted to make so that it was near perfect and then more ideas started popping up in my head. The photos below will tell the rest of the story.

This is the simple little engraving I did with the piece of acrylic plastic and of course I just had to put my name on it. It is only three inches long and an inch high and a half inch thick.  Nice material that I want to find more of.  After doing the engraving I taped off the back side of the part with painters tape and I cut it to size on my bandsaw and then sanded the cut edges smooth.  The tape on the back of the part keeps it from getting scratched on the table of my bandsaw. The bandsaw by the way cut through this stuff like a hot knife through butter.  The next step was to carefully and slowly heat the sanded edges with a propane torch.  Slowly is the word here as if you go to fast the plastic will simply melt out of shape or worse yet burst into flames. The heating with the torch clears the foggy effect you get when you cut and sand clear plastic and gives you a nice smooth clear finished part. It's nice but not that impressive to look as some people may say and I agree, but that changes once you see the next photo.

  

Now this looks a whole lot better!  I took a small piece of cardboard and cut a hole in it and then shined a light through the hole.  Then I placed the little name plate engraving into the cut out which in turn lights up the engraving like a neon sign. Again some people will say "Ok...so what?".  Wait there is more.

Now this is a photo of the famous Pink Panther engraved on acrylic plastic with a red colored light from a lighting base.  Just a bit more impressive than my little name plate engraving. Getting more interesting as I go along don't you think?  Keep reading.

Now comes the idea and another interesting project.  I got to work using Blender 3D graphics on my computer once again and created a 3D model of my idea for you to see.  How about making a plexi-glass lighted clock?  It would be made up of several layers of clear acrylic plastic that would be lit like my little scrap name plate and the Pink Panther. Each column in the clock would have three separate layers of clear engraved plastic.  One number would be engraved on each layer. On the left of the display would be the hours and on the right would be the minutes. This clock would have a black case and background for the display. You could also so the seconds on the clock if you have to be that precise in your time keeping.  Me personally I would be happy that it just displayed the correct time.

?This clock is exactly like the previous image only the display would be clear with no black background. The individual numbered layers in any column would be lit by led lights from the base and a small circuit board with an internal clock would keep the time. It could be made to practically any size that you wanted.  My design here would have a display that is three inches tall by ten inches wide.  The overall size of the clock would be a couple of inches more on both dimensions to include the clocks outer case. 

  This would make a nice desk top clock that would not be overly large.  I will have to print out a display on paper to double check that it would not be to big for a desk. If it is I will adjust the display size accordingly. I also plan on making some test clear plastic pieces for lighting each column in the next couple of days.  If this works out as I suspect it will I'll then proceed further and start building parts for the Plexi-glass clock project.

  Follow along with me and we can both keep our fingers crossed that it will all come together as I have planned.

Review of the hexbug scarab

Today I got the new hexbug scarab and it's sleek and fast! It has six legs, angled teeth, and a fast gear system. The price of this bot is $12.99 at RadioShack and they come in red, blue, orange, grey, and green. The physical features are pretty amazing, it has small 12 gears, 6 legs (obviously), and 2 angled teeth. Its capable of turning around when it hits an object because of its angled teeth, and it can flip itself back over like the nano. Thanks for reading check out the video below of my review.

Hexbug Christmas

Nothing says happy holidays like a good old hexbug christmas video! This video was made by hexbugtv and its filled while all sorts of hexbugs and holiday theme. Thanks for reading and please thumbs up the hexbug video!

US Army Robotics Montage

Most of us think of robots as machines that do our chores and make our lives easier, but robots on the frontline do more than just that. The video above shows clips of robots that save soldier's lives, and prevent people from getting hurt. Some of them have treads, arms, cameras, and even fingers to complete their dangerous task out on the battlefield. Thanks for reading and please follow us to keep up to date with our daily posts.

Testing our 90-led charlie-plexed LED array

There's something not quite right with our LED array.
In the main, it works fine. By simply applying 5V across different terminals we can see individual LEDs light up. Here's an example of lighting a single LED by applying 5v across two of the 10 available terminals:

(yes, that is Jason's traffic light LED project - I just nicked the 9v battery and 5v regulated output for the sake of testing this new board!)

But every now and again - and it is just every now and again, not very often - we get a peculiar result. Instead of single, bright, LED lighting up, an entire row (and sometimes part of the column) lights up too. We're putting this down to either a dodgy LED somewhere, or an LED being soldered in the wrong way around.

At the minute there's no real pattern to which combination of terminals gives the bad response.
There's one way to get to the bottom of this - to build an LED tester:
The idea is to create something that we can control which pin takes 5v and which takes ground, and record the result in a truth table (similar to the table created at design stage). Hopefully by cross-referencing these results to our schematic, we should be able to identify which LED(s) are common to all the problem terminals.