Thursday, 21 July 2016

Arduino Pro Mini - it's ok as it is

Sometimes, making custom PCBs can be quite fun. There still remains - even after all these years - that little tingle of a thrill when you boot up your custom circuit board and everything works.

It's like committing to your idea. Once etched in copper, there's no going back and changing it (although given the number of times we've forgotten to add a ground plane, it is easy to tack on a wire or two to correct a couple of mistakes!),

I still love making PCBs (at least, I do, when they work). But that's only for one-offs or small volume prototypes. The idea of having to make 100 identical circuit boards leaves me cold.

Which is probably what Tony was thinking when he asked why, for our latest board-game-controller-idea, we'd stuck a "hulking great big atmega" onto a board and simply extended all of the i/o lines to the edges.


But that's all we actually need - we're multiplexing an array of hall sensors, and sending the data out to a bus-connected serial port. That's all there is to the board! Size is important, so we made the board as small as we could. But not everyone is a whizz with hand-soldering surface mount parts, so we used the large, through hole components.

So he asked "why are you making your own boards? Why aren't you using an Arduino Pro Mini?"


And we couldn't think of a single good reason.
Although not everyone may be comfortable hand-soldering surface mount parts, there are more people comfortable with ebay than a soldering iron - so why not just buy the boards, ready-made?

It seemed like such a dumb question. Which made our current approach look even more stupid! So that's what we're doing - not only going open source, but using off-the-shelf parts. Steve would be so proud!

Tuesday, 19 July 2016

Inkscape to draw PCBs

Of course, drawing PCBs with Inkscape is an utterly ridiculous idea. After all, that's what ExpressPCB is for, right?

Well, 99.9% of the time, we'd agree with that. ExpressPCB is indeed a brilliant bit of PCB design/layout software. It encourages you to lay things out in a nice, neat grid, with perfectly perpendicular lines and 45 degree elbows on all your joins. It's great for making professional-looking boards with 90 and 45 degree angles.

But for this one particular project, that's a bit of  a restriction.
We're looking to put 12 hall sensors around a ring. Which means we want to space them at 30 degree intervals. And ExpressPCB doesn't like rotating anything that isn't 90 (or 180) degrees. So we had to try something else.

Which is where Inkscrape came in.
Using ExpressPCB to get the dimensions of our components the right size, I "printed" the document to a PDF document (using the excellent CutePDF virtual printer) and imported that into Inkscape. From there, I could add and embellish as much as I liked to get the final PCB design!


And suddenly, without the constraints of 45 degrees, the artwork started to get a little bit more... well, arty. I think I've been hanging around artists and designers too long this month!

Monday, 18 July 2016

Through hole as surface mount components

We love surface mount components at Nerd Club. Not just because they're tiny (although miniaturising designs to as small an area as possible is quite fun sometimes too) but because they eliminate the need for all that fussy drilling.

Putting a 1mm hole in the centre of a 2mm pad is straight-forward enough. But if you're soldering up a 40-pin DIP and a number of wire-pads for socket connectors then all that drilling can make your eyes go funny! Surface mount components mean far fewer holes, which means more time making cool stuff and less time hunched over a dremel drill.

We've already come up with a number of designs for our electronic board game, using surface mount components. But, going down the open source route, we're also acutely aware that not everyone is as confident at soldering, or has the same degree of practice we have, with soldering tiny little surface mount parts.


Coupled with the extra difficulty when soldering to homebrew boards (there's no solder resist to ensure it only goes where you want it, so bridging tracks is quite easy to do) we thought about how best to make the controller PCBs as simple as possible to solder.

Now it seems like through-hole is obviously the way forward; everyone with a soldering iron has probably soldered through-hole components in the past. But that then means that our PCBs would have a load of components on the top, and a whole load of little spiky bits on the bottom - neither surface would be completely flat (which would be preferable, so you can stick the flat part of the board to be flush with the bottom of the playing surface).

Through-hole components are larger, and therefore easier to solder. So we came up with (yet another) compromise: use through-hole components (for their larger size) but treat them as if they are surface mount components.


So the components go on the "copper side" of the PCB, but have much larger pads and legs, for the homebrew hobbyist to have a go at soldering.

(our "surface mounted" through-hole atmega DIP chip waiting to be soldered in place)


This approach has meant that pretty much all the designs we've spent the last few evenings working on are now redundant. But that's just a casualty of the rapid-reiterative-design-process we're embarking on - not to make the PCBs the "best" or the smallest, or even the cheapest; but to make them the easiest for most people to work with.

(checking the overall height of the board + mcu against 6mm thick mdf playing surface)

(before soldering, we'd snip the legs off, to make the understand completely flat and flush. By turning the entire thing upside-down we can more easily see that it fits within the profile of piece of 6mm thick mdf)

More updates with more designs as they are worked on (and, probably, discarded!)

Monday, 11 July 2016

Multiplexing A3144 hall sensors with an Arduino/AVR

After deciding to go down the "open source" route for producing an electronic board game, we've spent quite a bit of time focussing on almost the opposite end of the market for hobbyists and gamers - originally we focussed very much on mass production, cheap components, robustness and simplicity for gaining the necessary CE marks and other standards required for selling a manufactured product.

With a self-assembled kit of parts, from an open source list of components, we're focussing much more on ease of use, familiarity and "hackability".

Which inevitably means shoe-horning an Arduino in there somewhere.
Our original electronics for the board game were based around a super-cheap PIC 16F1829 (with plenty of internal pull-up resistors, an internal clock running at up to 32mhz) and an A2892 source driver IC (to provide power to each row of hall sensors).

But that was back when we were making a 12x12 grid of sensors. Or when we were looking at an 8x6 grid. Or even 6x6 shaped PCBs for a dungeon crawler type of game. But now we're looking at a 7x7 square grid per board section, possibly running off an Arduino/AVR...

And so, in the name of simplifying things for the Arduino hobbyists, we checked out the datasheets for the A3144 hall sensors and the AVR atmega328P.

(typical values for an A3144 hall sensor)


The A3144 typically uses 4.4mA as the supply current.
We've got 7 of them in a row. That's 7 x 4.4  = 30.8mA if all the sensors in a single row are powered at the same time (we're multiplexing, so only one row is active at any one time anyway).

Modern PICs can generally sink about 40mA but many still only source up to 20mA. Looking at the datasheets for our 16F1829 it says it's a symmetrical i/o port, sinking and sourcing up to 25mA. Just not quite enough.

However, atmega chips can sink and source up to 40mA per i/o pin.
What if....?

If we could source the power for an entire row of seven hall sensors from a single output pin on an  (atmega328 powered) Arduino then we could simplify the design even further and lose the need for a current driver too - simply hook up the sensors directly to the Arduino i/o pins: something that a lot of electronics hobbyist users would be more used to doing.

All we needed to do was try the idea out and see how it fared....

Here's some simple firmware for the Arduino. It uses digital pins 2-8 for the "outputs" (driving each row of hall sensors at a time) and pins 9-12 for the inputs (we only hooked up four of the seven inputs, for ease of use while testing).



int row=0;
int col=0;
int inputValue=0;
int lastValue[]={0,0,0,0,0,0,0,0};
int k;
int j;
bool led;

void setup() {
     // put your setup code here, to run once:
     for(int i=2; i<=8; i++){
          pinMode(i,OUTPUT);
     }

     pinMode(9,INPUT_PULLUP);
     pinMode(10,INPUT_PULLUP);
     pinMode(11,INPUT_PULLUP);
     pinMode(12,INPUT_PULLUP);

     pinMode(13,OUTPUT);

     delay(500);
     Serial.begin(9600);
     Serial.println(F("Let's go"));
     led=false;
        
}

void clearAllPins(){
     for(int i=2; i<=8; i++){
          digitalWrite(i, LOW);
     }
}

void getInputValue(){
     inputValue=0;
     int bitValue=1;
   
     for(int i=0; i<=3; i++){
          k = digitalRead(i+9);
          if(k==LOW){ inputValue+= bitValue;}
          bitValue = bitValue << 1;
     }

}

void loop() {
     // put your main code here, to run repeatedly:

     clearAllPins();
     digitalWrite((row+2), HIGH);
     delay(5);
     getInputValue();

     j=lastValue[row];
   
     if(inputValue!=j){
          Serial.print("row: ");
          Serial.print(row);
          Serial.print(" old value: ");
          Serial.print(j);
          Serial.print(" new value: ");
          Serial.println(inputValue);
          lastValue[row] = inputValue;   
     }

     row++;
     if(row>=7){ row=0;}
   
}


And the end result was...


Success. Sort of.
As we moved the magnet over the sensors, each one triggered and released as expected. Almost perfect operation! Almost. Because this time, we had to use a much larger magnet than with our PIC-based design.


The magnet at the top of the image is 10mm across and 2mm deep. This triggered the sensors when driven directly from the Arduino i/o ports. The smaller magnets are the ones we used for testing our PIC-based board (with dedicated current driver). They are just 8mm across and only 0.5mm deep.

The smaller magnets still work with the Arduino-based test rig, but they need to be placed exactly over the top of each sensor. The larger magnet allowed for a bit of imprecision when placing it (which is what we need, when using it to trigger the sensors from inside a playing piece on a board game). The larger magnet also worked on the reverse side of the board, through 6mm thick mdf. The smaller magnets could not be detected from the underside of the 6mm mdf.

So there we have it - if we compromise on the size of the magnets used in the playing pieces (i.e. go bigger, whereas we've tried to keep them as small as possible) we'll be able to simplify the electronics to just a PCB with an atmega on it (and the usual supply caps of course!) and a diode on the ground pin (swap the polarity of your power supply on an atmega and it goes pop very quickly).

And of course, for the open source brigade (some people are really quite militant about it) we can also now include an Arduino instead of one of those tricky-to-use, industrial-strength PIC microcontrollers - AVRs and Arduino are already the de-facto for hacking and doing your own thing with.

If we were looking at manufacturing, I'd absolutely insist on PIC, even if it meant adding the source driver. But for simplified open source kits that anyone can make themselves... well, Arduino seems to have that corner of the market well and truly sewn up. We'd be crazy not to take advantage!




Thursday, 7 July 2016

More MMA8452 accelerometer (and Arduino) testing

In "real work" we got a prototype device working for  a client who said they loved the idea and commissioned a set of audio devices. The idea is that each device is a ceramic shell-like shape, with an mp3 audio player, speaker and accelerometer (plus, of course, an Arduino, urgh!) embedded inside.

The shells sit in a vertical position, in their holders, but when they are lifted up and placed against the ear, the mp3 player triggers a short audio sample. Because the shell acts like a natural amplifier, and we want the audio to only be audible when it is placed right up against the ear, a tiny 1cm piezo speaker connected directly to the pwm outputs of the audio module is plenty loud enough.

There is more than one sound file in the mp3 module/player. To play different sounds, you simply rotate the shell as it is pressed against your ear.

So we poll the accelerometer and when the y-axis is zero, we take it that the device is "horizontal". We then read the x and z axis values to work out the amount of rotation applied.



In recent testing (albeit with a different accelerometer module for the actual prototype) we simply plotted the x, y and z axis values over time, while rotating the accelerometer around the y-axis. The results looked something like this.


Which is pretty much what we were expecting.
So we ordered up a bunch more MMA8452 accelerometers and prepared to make a few of these devices for the project.

Except this time, something weird happened with the x,y,z results.
When placed on a flat surface, and we expected all values to read zero, there was a constant "flickering" on each axis - it would occasionally go from near zero to near maximum.



These values were arrived at while the accelerometer was on a flat surface and not moving!
For some reason, the x-axis value hovers around zero. But every now and again, spikes to the full/max value, around 1, then quickly falls back to zero.

We thought that perhaps this  is something we might be able to take out in software. But it's not. If we rotate the accelerometer around the y-axis, as before, and plot the x and z values, we get this;



You can sort-of see the 90-degree offset in the x- and z- axes. But the constant spiking is something of a worry. It's as if the axis values are getting "mixed up" - the x value is being reported as the y value and so on.

Whatever it is, it's a mess.
And has put a bit of a question mark over the whole thing!
Unless we can be guaranteed that our accelerometers can be relied upon, we could end up with audio devices that trigger at random, and play any old mp3 file, in any old order.

In which case we should just ditch the accelerometer and write a random number generator in firmware! More investigations will continue over the coming days....

Arduino, AVR and internal/external oscillators

One of the nice things about working with PICs is that you know straight away if you've done something wrong. Things work. Or - if you've got them wrong - they don't.

And when things go wrong, the first thing that most people do is revert to a simple "blinky"  example - check that the microcontroller is actually running, and at the correct speed. It's a time-honoured thing that we all do.

So things got a bit weird today, using the same idea with Arduino.
We wanted our breadboard AVR chip to run from it's own internal oscillator at 8Mhz. We managed to get a blinky sketch running, after poking about with the fuses, but it was at about 1/8th of the required speed; our chip was running off it's internal oscillator, but at 1Mhz.

Of course, simply changing the firmware would fix this - shortening a 1sec delay to 125ms for examply - but this isn't the answer we wanted to implement. So we tried running the board off an external 8Mhz crystal, to see where the problem lay.

Here's the boards.txt we used, complete with fuse settings

##############################################################

atmega328bb.name=ATmega328 on a breadboard (1 MHz internal clock)

atmega328bb.upload.protocol=arduino
atmega328bb.upload.maximum_size=30720
atmega328bb.upload.speed=57600

atmega328bb.bootloader.low_fuses=0x62
atmega328bb.bootloader.high_fuses=0xD9
atmega328bb.bootloader.extended_fuses=0x07

atmega328bb.bootloader.file=atmega/ATmegaBOOT_168_atmega328_pro_8MHz.hex
atmega328bb.bootloader.unlock_bits=0x3F
atmega328bb.bootloader.lock_bits=0x0F

atmega328bb.build.board=avr_atmega328bb
atmega328bb.build.mcu=atmega328p
atmega328bb.build.f_cpu=1000000L
atmega328bb.build.core=arduino:arduino
atmega328bb.build.variant=arduino:standard


atmega328bb.bootloader.tool=arduino:avrdude
atmega328bb.upload.tool=arduino:avrdude

##############################################################

atmega328bb2.name=ATmega328 on a breadboard (8 MHz internal clock)

atmega328bb2.upload.protocol=arduino
atmega328bb2.upload.maximum_size=30720
atmega328bb2.upload.speed=57600

atmega328bb2.bootloader.low_fuses=0xE2
atmega328bb2.bootloader.high_fuses=0xD9
atmega328bb2.bootloader.extended_fuses=0x07

atmega328bb2.bootloader.file=atmega/ATmegaBOOT_168_atmega328_pro_8MHz.hex
atmega328bb2.bootloader.unlock_bits=0x3F
atmega328bb2.bootloader.lock_bits=0x0F

atmega328bb2.build.board=avr_atmega328bb
atmega328bb2.build.mcu=atmega328p
atmega328bb2.build.f_cpu=8000000L
atmega328bb2.build.core=arduino:arduino
atmega328bb2.build.variant=arduino:standard


atmega328bb2.bootloader.tool=arduino:avrdude
atmega328bb2.upload.tool=arduino:avrdude


##############################################################

atmega328bb3.name=ATmega328 on a breadboard (8 MHz external clock)

atmega328bb3.upload.protocol=arduino
atmega328bb3.upload.maximum_size=30720
atmega328bb3.upload.speed=57600

atmega328bb3.bootloader.low_fuses=0xCF
atmega328bb3.bootloader.high_fuses=0xD9
atmega328bb3.bootloader.extended_fuses=0x07

atmega328bb3.bootloader.file=atmega/ATmegaBOOT_168_atmega328_pro_8MHz.hex
atmega328bb3.bootloader.unlock_bits=0x3F
atmega328bb3.bootloader.lock_bits=0x0F

atmega328bb3.build.board=avr_atmega328bb
atmega328bb3.build.mcu=atmega328p
atmega328bb3.build.f_cpu=8000000L
atmega328bb3.build.core=arduino:arduino
atmega328bb3.build.variant=arduino:standard


atmega328bb3.bootloader.tool=arduino:avrdude
atmega328bb3.upload.tool=arduino:avrdude


And the result...


See that little silver thing on the desk?
That's our 8mhz crystal. We took it off the breadboard and yet the sketch still runs. So the mcu is obviously still running off it's internal oscillator. And still only running at 1Mhz.

So it looks like it's working.
Except it's not.

It's on days like this that I really hate Arduino.




EDIT: a few people have suggested that there's no reason why we can't treat our AVR chips just like PICs - i.e. create a hex file (albeit using the Arduino IDE to code it up) and then burn it to the chip using a separate program, just as we do with PICKit2.

AVRDudess is just such a program.
And when we used that to burn our hex files instead of the Arduino IDE, everything worked as expected!


It's on days like this that I really hate Arduino.

Wednesday, 6 July 2016

Electronic board game - we're going Open Source

Remember a while back - and it's something that has become a bit of a running thread on this blog over the last 18 months or so - we had an electronic board game? Although it took a bit of a back-burner, it's something that we just can't let go; and we've tried all number of different ways of turning it into some kind of product that could be released, for gamers to play their tabletop wargames on.

Originally it was a digital football pitch. Then a hex-based multi-section game board. Then a multi-part board game. After that proved too costly, we tried a dungeon-crawler. Creating shaped PCBs with fewer squares than a full square section, but for the same cost, seemed a bit crazy. So we went back to multi-part boards.

And so on and so on.
Each time we tried finding not just a cost-effective set of components, but also a way of assembling (or having the board sections manufactured) that would produce a viable product.

After much trying - and much to Steve's frustration, going around in lots of circles - we finally decided that it couldn't be done. At least, not in a way that would be financially viable as a product for sale.

But, determined not to give up on the entire project, it was with some curiosity that we followed up a couple of suggestions about making the whole thing "open source".


Going with the idea of making the hardware open source means re-thinking it all over again. This time we're not restricted by the cost of assembly, but more like the complexity of assembly. If we published the design files online, how likely is it that someone could pick them up and actually make one of our electronic board games? While it'd be tempted just to stick the PCB designs online and say "off you go, make one of these" not everyone has access to a bubble-tank that can etch 9" square boards, for example, nor feel comfortable hand-soldering tiny sot-23 sized components.

This has led us to re-designing the entire board game section, to make it possible for someone with moderate "crafting" skills to put one together. Wargamers tend to be a pretty "crafty" lot - making, assembling, painting and building - as they do - miniatures and terrain. But our target audience may not be quite so hot on the electronics side of things. Do we even want to try to teach a complete new-comer how to solder, let alone make them responsible for the success (or otherwise) of assembling a kit of bits?

So we hit a compromise.
We can have some (much smaller) PCBs manufactured (our original designs were massive 180mm x 240mm PCBs) and even populate them, and leave the placement and assembly of the hall sensors to the end user.


After laser-cutting some mdf, we came up with some easy-to-follow templates, for placing strips of copper tape across one of the 245mm x 245mm sections


A dab of glue holds the hall sensors in place, before they are electrically connected to the copper strips. In our original design, we simply soldered them in place.


But, recognising that not everyone might be so competent with a soldering iron, we thought we'd try (Bare Conductive) conductive ink as an adhesive. Amazingly, it worked!


Just a nice big, messy blob of graphite-based goop on each leg, and after a couple of hours drying time, everything worked just as we'd hoped:



More details on how to make your own to follow!