Projects


As I mentioned in my last post that just before I lost my mojo I ended up completing my build of 10 Rallylogs and testing at a live event.

As these were handheld devices I decided to add a wrist strap to stop things from getting dropped and damaged at the checkpoints, especially as it can get busy as the bikes pass through a checkpoint.

Here some of the pics with a hand strap added. I simply purchased a heap of Wii Mote straps from one of my favourite places and attached with a split pin through a hole I drilled into the top cover of the spark fun enclosures, I used the top Cover as there was more room to drill the hole.

(Click on the images to view)

SCE_20110210-6919.jpgSCE_20110210-6921.jpgSCE_20110210-6922.jpg

The Wii Mote strap is looped through the split pin at the base of the handheld, to stop any abrasion to the plastic caused by movement of the split pin I used a washer on each side of the case. I just placed a length of insulation tape over the inside covering the split pin (not shown) to protect any possible shorts with the PCB.

SCE_20110210-6917.jpg SCE_20110210-6914.jpg

To keep them all warm, cozy and dry when not being used these utility bags were purchased from the local surplus store, although I did see DX sells them as well (just can’t find the link atm), they’re a perfect fit for the spark fun case and also have belt loops on the back.

SCE_20110210-6912.jpg

All 10 completed and ready to go for the big event…..

In my previous post I described the design process I went through in selecting the right components from my Rallylog that would fit into the Sparkfun Project Case, all while mounted on a PCB. What follows is the process of getting the actual case machined with my Zenbot CNC machine.

How am I going to machine this thing?

I didn’t tackle any machining until after my PCB design stabilised (three revisions) but the day did come when I had to work out how I was going to automate the machining of the project case. As I previously mentioned in my last post that I was going to use my ZenBot Mini CNC to do the work, I just need to figure out how it was going to do it.

To tell the truth I have hardly used my CNC other than for prototype PCB isolation routing. I had never used if for cut-outs or any 3D machining. One thing I needed was a way to produce my tool paths or G-Code that Mach3 uses, Mach3 is the controlling software I use with my Zenbot. It takes the G-Code and handles all the X,Y,Z movements. I could hand code G-Code but, hey, I’m not that good!!! So I needed some CAM software Alibre does have a CAM option, but I had a heart attack when I received the price, so after much googling I found Cambam,

The Fixture

As I mentioned I needed a way of holding the Sparkfun project case in a repeatable way as I need to machine 10 of these, also I was going to be doing the machining from the inside of the case, this way I could pocket around the LCD at the same time as I did my cut-outs and light pipe holes, all in one hit. So some sort of fixture was called for…..

I decided to mill out the profile of the top spark fun case to create a fixture where I can just drop in any case top lock it in and then press the ‘go’ on Mach3. To do this I imported the Sparkfun 3D STL Model that I used in Alibre, again I had some issues of the “standards” and used a open source program called Meshlab to first import in the STL model with the clean-up enabled then to save it as a new STL. This work and I now had the Sparkfun project case in the CAM software

image

Some of the traps I found is that the model needs to be aligned with the Z-Axis 0, this is how the Cambam sees the top of the work piece.

Cambam has a handy function for exactly what I want to do, this “Mold” function, allows a mold to be created from the 3D object, and by varying the Clip Areas I can control how deep I want my mold, in this case just 3MM so I can get the Case top to sit nicely in the fixture.

My Zenbot can only take a max shank size of 1/8 as I had initially replaced the Dremal for a Wolfgang Engineering Spindle for my PCB routing, for those interested these spindles Rock!!! the spinout is incredibly tight.

Creating Tool paths

I first created 2 tool-paths in Cambam, one to rough out and remove most of the material quickly with a 3.175mm end mill (1/8) and a second tool-path to finish with a ball mill to do the edge profiles. Cambam generates the crossovers and the plunge rates based on the tool size.

image

image

image

Setting Machine Origin

Another feature of Cambam is I can set the machine origin, this is the origin of all the Axis (X,Y,Z) in relation to the work piece, now I have the way to repeatedly setup my work pieces by referencing everything back to this origin mark (red X below). If I marked this on my fixture all I have to do is zero my Zenbot to this origin before I run the job and everything will be referenced correctly.   In this case it’s 5mm below the work piece corner.

image

Machining the Fixture

I had some scrap plastic board that came with some flat packed furniture that was to become my fixture. Below you can see the rough tooling has finished and it running the finishing tool-path. you can see where I marked my origin in the bottom right of the work piece. I use this to Zero Mach3.Sparkfun fixture


Zenbot Maching Sparkfun Project Case Fixture

Perfect fit, no slop or play, I did re-jig my tool paths to go down another 1mm in depth so the inside of the case is aligned with my Z-Axis Zero (or the top of the fixture) that makes things easier when I go to do my cut-outs and pocketing.

Test fit

Machining the Project Case

Now that I had my fixture for the actual case I needed to work out my cut-outs, drills and pocketing, using the same project file in Cambam that I used for the above fixture machining, I created addition layers for my cut-outs. This was good as I could see where everything was located in relation to the 3D model, I used measurements from my Alibre model to place the Circles and rectangles that were to become my machining profiles.

The only gotcha is that you have to think in reverse as I’m machining from the inside. Below are the cut-outs and drill points for the light pipes

image

This is with the pocketing areas added. I decided to add the pocketing around the buttons as well just in case.

image

With the machining tool-paths added, Cambam also has the ability to add tabs in the cut-outs so the work wont foul you bit. I decided to try this.

image

The Results

I’m very happy with the way everything has worked out. By putting in the extra work in the design stage it seems to have paid off, the Sparkfun Project Case fitted my assembled PCB like a glove, everything aligned up perfectly.

Here is the final result with cut-outs finished, light-pipes installed and the pocketing for the LCD and switches, the actual pocketing for the switches was not needed so the 3D model was fairly accurate. I didn’t photograph any of the cutting in actions so will post a few more when I finish the rest off.

Result cutout and pocketing

I used the same procedure to machine out the end piece from my USB and SD card, that is: mill a mould fixture with a known offset and then generate tool paths within cambam for the cut-outs.

Case and Assembled PCB

Project case end

This is showing my REV B PCB in the case, this had the range issue and the separation of the ground plane below the ID-20 reader corrected the issue.

Snug home

Front with LCD installed

Side profil

Side profile

Light pipes and LCD working, showing a card read under my test program.

Led working

For the open Hardware Rallylog device I’ve been working on, I’d based my design around fitting into the handy Sparkfun Project Case and since most of my projects never get to the “enclosure” stage, they are either used bare PCB or thrown into anything that may provide some protection against the elements, such as the widget sensor housing.
(http://blog.strobotics.com.au/2009/06/15/widget-sensor-housings/).

This project was different for me since I’m required to build 10 of them for the local motorbike club, something a bit more “finished” than your standard geek project. Throughout this project I’ve learnt how to use 3D modelling to check mechanical layout and tolerances, also to use mechanical data supplied in technical data sheets in selecting my components. This along with taking into account PCB heights, button heights. Overcoming challenges like how do I get my LEDs to the outside without using panel mount LEDS, or how do I protect or mount my LCD display again with out using a panel mount. I then used all this to make things easier for me when it came to production to produce CNC tool path G-Code to cut my enclosures.

I thought I’d document the process that I’ve gone through to get my Rallylog nice and snug in the Sparkfun Project Case. BTW this may not be the right way, but it’s the journey I took, I would love to hear from people who do this professionally for a living to get a feel of the full product design process.

It has to be easy to make and assemble

Right from the outset of the project I wanted this to be easy to assemble. Seeing I have to make 10 of them (to start with) I wanted everything to be mounted on the PCB so all I have to do is get my enclosure and put in the finished PCB, screw it all up and its working, i.e. I didn’t want to have a panel mounted LCD or LEDS that I had 1) manually fix to the Enclosure, and then 2) “wire” back to the PCB. I wanted something that I can reproduce easily and with the least amount of human work, I love my projects, but quickly hate having to manually do a lot of repetitive work like solder up individual LEDS etc. (I guess I ‘m lazy). I also have a small CNC machine at home, A Zenbot Mini that I purchased off eBay some time ago, so I wanted to automate the panel cut outs as much as possible. I wanted this to be repeatable, using a handheld Dremal is not my idea of fun, especially if I have 10 to do now I will quickly loose interest after the first one, and it’s definitely not repeatable. Also if I get an order for another 1, 10, 100 down the track I definitely don’t want to do it manually, and I don’t want to think too hard about getting things set up.

I could have also gone with an Arduino board and made up a custom shield or use the RFID shield, again it would have meant more painful hand assembly, so I decided to stick with a custom board fitted into a readymade enclosure.

It all starts with the User Interface

Whilst I already had my initial schematic laid out (in Kicad), before I started my PCB layout process I needed to work out what it was going to live in. I was very eager to start laying down track as I love designing PCBs, but I had to hold myself back and ask a couple of questions first:

  1. What am I going to put it in? It needs to be functional, fairly robust, and fit everything in, including the battery, the RFID module, the LCD, SD Card socket and so on. It needs to be off the shelf that I can easily modify, no custom injection moulded case for this project ( I wish)
  2. What is the user interface going to look like? I needed to keep to the KISS principle. The majority of users at this motorcycle club are semi-retirement to retirement age, so not the most savvy when it comes to geek gadgets,
  3. Will it be easy to assemble?

When you stop and think about it, it makes sense to start with the user interface and how this will fit into an enclosure, then move onto the physical PCB layout and component selections, else my PCB might not fit into the case, it may be too big, too small, same goes for components selected. The user interface may not be functional and then we’d have to start again.

The User Interface design

My initial schematics included a Nokia LCD display and a joystick for user input. Also a couple of LEDS for visual feedback.  

When I asked myself the three questions above I quickly went back to the drawing board, as the Nokia display failed Question 3), same went for the Joystick, also I felt that it was would have been a bit too had for the target audience to use, so it failed Question 2) as well.

In the end I decided to go back to a tried and proven UI design that consisted of a simple and easy to read backlight 2×16 LCD character display with three push buttons for user input and two LED indicators, something a bit easier for the end user to use.

As yet I had not selected the parts i.e. the LCD or switches, I just had the layout in my mind (or on paper) the UI layout that was a three button input under a standard 2×16 backlit character LCD, and x2 LEDS to the left of the LCD display, these LEDS would be Red and Green, which could be used to indicate different statuses easily, really simple!

UI sketch

The Enclosure

Once I had the basis of the interface this is where the engineering juggling started, I had to find an enclosure that would meet my requirement, and find components at the right price that would work with the selected enclosure in the way I wanted.

I had a look around on a number of sites and found there is a wide variety of enclosures out there, however without physically having one, its a bit hard to start working out measurements and getting a general feel for it in your hand. As luck would have it I already had a couple of Sparkfun Project cases at home that I had purchased for a “future” project, well this was that “future” project, I used this initially as my enclosure of choice, it seemed to fit well in the hand and be spacious enough to seemingly fit everything in, i did this initial check by putting in the ID-20 RFID reader module and a 9V battery to see how things would fit. At this point I still did not have an LCD or buttons selected.

Once I had my enclosure selected it is now a matter of finding the right size components to fit, as mentioned above I wanted everything mounted on my PCB, and now I had the dimensions of the enclosure I could start my PCB design and component selection, this process I found to be the most time consuming. However I initially needed to start working out my clearances with my PCB in the enclosure, I’m also a visual person, I need to see things to make it easier for me to understand, so I decided it would be much easier to utilise 3D modelling and model the enclosure and mock up my UI, I’ve used Alibre in the past and this is what I modelled the Rallylog enclosure in.

The 3D Model

Not wanting to re-invent the wheel I contacted Sparkfun customer support with a request for a 3D model of the Project enclosure and received an email from Casey Haskill, the designer of the enclosure, he was more than accommodating (Many Thanks Casey!!!) and sent me the files in IGES format, one that Alibre supported……supposedly.

The great things with standards is that everyone has their own take on them, obviously Alibre was no exception, the problem was that each time I went to import it failed, after a bit of research I found a small utility program that I used in a two step process that allowed me to clean up the IGES and export it as an STP file, one that worked with Alibre.

image

Once imported I can now can get accurate measurements and start modelling individual components. My modelling is very simple, make a basic 3D model using the supplied mechanical data, no fancy surface or trying to emulate the real thing.

One of the immediate things I could see is that either I had to use a panel mounted PCB or I needed a two tiered PCB design as the headroom above the PCB was quite large. The panel mounted LCD was ruled out due to easy of assembly rule, so I knew that I would be dealing with a two layered PCB design.

Alibre is great for quickly creating 3D objects and by changing dimensions it regenerates the 3Dmodel, so I quickly created a two tiered mock up of a PCB with the correct thicknesses of the PCB substrate being used, this was added to the enclosure assemble so I could visualise the internal dimensions. The two PCB layers are separated by the dimensions of a standard 0.100 header and socket of 8.5mm.

image

image

From this I now had the dimensions required from the top of my PCB to the inside and outside of my case.

Now I needed to know what LCDs, buttons and LEDs out there that when mounted on the PCB how they would interact mechanically as far as clearances with the enclosure, however I had to work into the constrains of my circuit design and of course price.

Due to I/O restraints I couldn’t use the standard character LCD in 8 bit or even 4 bit mode, so that ruled out most of the cheapest LCD displays around. So it had to be I2C, SPI or Serial, my initial design was done with the Nokia LCD in mind and so used SPI, as I wanted it to mount onto my PCB, almost all LCD I’ve found have their own PCB with a connector that either plugs into a cable or you plug it into a socket onto the PCB, so another layer on top of the existing PCB was not feasible. I located the I2C range of New Haven Displays and found one that would fit given the dimensions, however I couldn’t get them locally and ordering in from New Haven was approx. $USD50 per display, not economical! Unfortunately there were not many alternatives.

After talking with my local local supplier he put me onto the EA-DOGM Series of LCD Character displays, these can be run in SPI Mode or traditional 4 or 8 bit mode, there are also directly mounted on the PCB, and have an optional LCD backlight module that mounts under the LCD module. The price was even better, $AUD15 for 2×16 and $AUD4 for backlight, perfect pricing just need to check how they would fit. From the Technical data sheet I whipped up a simple model and added it to the PCB

image

image

image

image

From this I could see that the LCD would fit if PCB mounted, but had an interference with the top of the Sparkfun case, this was acceptable as I would need to machine the cut-outs at some point.

I then did the same for switches and their buttons, I wanted the button to just clear the case and not be too pronounced or the reverse I didn’t want it to be recessed. In the example below using 6mm Omron switches and their associated square buttons. I found they were too pronounced out of the case.

image

I ended up finding the 12mm Sparkfun Push Button which met the right criteria and the button just cleared the case, after modelling it looked perfect, however the switch body itself has some interference with the top of the case, this meant that if I wanted to have a switch with the right height I would have to machine out the inside of the case.  

image

Engineering decision time….After weighing up the aesthetics and the work involved in machining out the case I decided to stick with machining out the inside as I would already have the top case mounted for cut outs, what if I just flip it around and machine from the inside, that way I could kill two birds with one stone. I could pocket out around the switches ( and the LCD if required) and then perform the panel cut out. I didn’t know how I was going to perform this but seemed doable.

Just to make sure where my interferences I used a great feature of Alibre called “Assembly Boolean” where I can select the top of the project box as my blank, and then select all the buttons and the LCD as my tools, the Result is the top of the Project box with all interferences subtracted so I can I know where to machine.

image

Just to cover my bets I added both switches to my design, that way I could use either if the other didn’t work, much easier to add the extra footprint at design time that to find out after that I really should have used the other switch, so I had an escape clause Winking smile

image

The LEDS

What about The next thing I needed to worry about was what to do with the LEDS. Where possible I now use SMD components rather that PTH, but using the PTH over SMD was going to be my only choice, however they would be standing quite tall off the board, and as the end user would have to remove the back of the case to eventually change batteries, I didn’t want them to be able to damage the LEDs if incorrectly re-assembled for any reason.

I started looking around for solutions, not being in the industry I wondered how they did it, looking at every day consumer electronics I saw that pretty well every LED indicator is displayed through a plastic window, that’s what I needed, but what are they, after much Googling I found the correct term of “Light Pipe”, this made things easy. I could stick with my 0603 SMD LEDS and have a standard 3mm vertical light pipe (they come in many different flavours) bought directly to the top of the SMD LED.

image

The Final PCB

Happy with the components selected I then proceeded to finished my PCB design, again to make things easy to assemble I designed the two layers as a single board separated by tabbed routes and tooling strips so the individual boards can be separated after assembly. I also moved my LEDS over to the right hand side to accommodate for the PCB connectors finished result.

To see the full assembly steps see my previous blog entry http://blog.strobotics.com.au/2010/07/21/rallylog-assembly-progress/

rallylog pcb

Next…How I machined my enclosure cut-outs

While testing the serial functions I had issues as mentioned in the previous post where the AVR <-> FTDI seemed not to be working.

Initially I thought it was a hardware problem due to a hidden solder bridge or such, further testing on the ASCII example sketch revealed that something was being sent, albeit garbage, to me it looked like incorrect baud rate. After unsuccessfully checking bitrates, I filed it as a fail and moved on, however last night when I set about writing the RFID read function using NewSoftSerial on the RFID I was getting nothing reported back back on the AVR, not a thing coming back from the RFID Rx Pin, yet my logic analyser showed that the correct data was being presented on the correct pin of the CPU, it then got me thinking that it must be a fuse setting on the AVR.

I re-programmed it to the same settings as my wireless widget using the internal oscillator and now everything is now working.

I had assumed, incorrectly, that the AVR defaults to 8Mhz internal clock, which is the case, however it also has the divide by 8 fuse enabled by default, so reprogramming my fuses to the settings below fixed everything

L:0xE2 H:0xDA E:0x3F

Over the last couple of nights I’ve been verifying the respective individual circuits of Rallylog before I get down to developing the application.

Test Results so far:

3.3 V PASS
5V Enable PASS
RFID FAIL (Fixed)
LCD PASS
LCD Back Light PASS
RTC TODO
SD Card FAIL (Fixed)
SD Card Detect PASS
Buttons PASS
LEDS PASS
Buzzer PASS
Battery Voltage Monitor PASS
Programmer I/F PASS
Reset Button PASS
USB Reset PASS
USB – FTDI PASS
USB – AVR (Serial) FAIL

 

RFID Module

I’ve had a couple of problems so far, first the RFID module has very short pins that only just go through the PCB to allow for soldering, I had what looked to be a dry joint on one of the pins, after re-soldering with a bit more heat and solder all joints now are solid and is working no problems.  The Range of the card read seems to be far less than specified, so I’m wondering if the GND fills on both sides of the PCB near the RFID module could be causing this, I will remove them in the next PCB iteration. However it is working and the range is sufficient to work as required.

SD Card

I now have writing to the SD card working, had an initial problem where the pull-up resistors were causing the problem, removed and now ok.  I’m using the filelogger library (http://code.google.com/p/arduino-filelogger/) and have it writing the test message to the card.  A gotcha was an existing 1-Byte sized file needs to already exist on the SD card for the library to work.  I’m also having some problems when the card is removed and re-inserted no writing takes place.  This appears to be a library problem so will investigate further later.

USB

Another problem is the USB side of things.  I’m using an FTDI FT232RL USB-Serial conversion chip, fairly common, however the output on my Tx is garbled, I’m also assuming that my Rx is the same as I have yet to delve deeper into the problem.  It may be an unidentified solder bridge somewhere that I can’t see, the pitch on this component is pretty fine.  

I’ve checked correct bit rates but still failing.  I initially found I had problems when I went to program the bootloader and could not get any of them to work, so have filed this as a FAIL and moved on to complete the rest of the testing as I’m using the programmer interface to load my test sketches.   I’ll revist in detail later. 

UPDATE: I have downloaded the FTDI chip programmer utility and this sees the FTDI chip and alls it’s registers ok, so the USB-FTDI circuit appears to be working, but the FTDI – AVR is not.

Last Friday I received my second revision of PCBs.  As mentioned in one of my previous posts I majorly stuffed up on my LCD footprint along with some additional board changes including the larger 3V regulator and the 5V regulator PCB.  

I’m very happy with my switch to Kicad also with it’s resulting PCB below.

(Click through to flickr images for more details. Some are commented and have notes)

rallylog pcb

After verifying the PCB again (this time successfully), I set aside some time over the weekend to assemble the first unit for testing.

 

Rally log with all SMD components assembled

rallylog smd assembled

 

Rallylog with all components assembled and removed from the tooling strips

rallylog assembled

 

Test fit in Sparkfun project Case, have yet to fit the top cover, i.e. drill holes for LEDs, Buttons and LCD, will be leaving this until after testing, but happy with the results so far :)

rallylog assembled

As mentioned in my last post, Rallylog is a new open Hardware project it also uses Kicad as the EDA.  Well late last week my prototype boards arrived from Gold Phoenix and very happy with the results, well sort of…..

Testing

When I receive a new design, one of the first things I do before any components or power is applied to my boards is to check all the physical connections with my trusty multi-meter on continuity settings then with schematics in hand I proceed to check every connection and check it off on my schematic.

From the schematics below you can see how I was progressing.  the green highlights are errors I’ve picked up, only a couple of minor ones that are easy fixed, until I got to my LCD board.  This PCB design is across two boards to account for a LCD, buttons and LEDS for the UI so that I can fit it all in the sparkfun project case.  I had created a new component for the LCD module I’m using, a low cost SPI based backlit LCD module, and I had placed the top row of pins on the module the wrong way around.  Still can’t work out why I hadn’t picked it up, but these are the problems when you’re a 1 man development team and there is no one else around for a design review…sigh, anyway changes have been incorporated into REV B.

20100713164141445_0001-cropped 20100713164141445_0002

Voltage Regulator sizing

Other significant change is to the 3.3V Regulator circuit, when I initially did my power budget I calculated that my 3.3V rail power requirements would be around:

Atmega328  – 5mA
LCD – 250uA
LCD Backlight – 80mA (20% Duty cycle)
SD Card – 80mA (200mA Spec)
RTC – 300uA

In total ~ 165mA .  The 3.3V regulator I had chosen had a max load of 200mA so plenty of headroom right? Wrong!!!

After revisiting my original design I realised I had made a mistake, I had not taken into account the input voltage and the de-rating effect of the volt drop across it.  In my case a 9v battery is being regulated by an LDO regulator down to 3.3V so in the process heat is generated, the larger the difference between Vin and Vout the warmer it will get, and the warmer it gets means my Max current output of the regulator drops, so how do I find if my regulator will still cut the mustard in this design? 

After a bit of research I found that I need to calculate the maximum power that can be  dissipated by the regulator and use this along with the max power of my circuit.  In this case my LDO is a SOT23-5 device.

so for my circuit:

Power(dissipated) = (Vin – Vout) * Imax

VIn = 9V (from battery)

Vout = 3.3V

Imax = 165mA

Power(dissipated) = (9 – 3.3) * 0.165 = 0.94W

This is close enough to 1W of power to dissipate in my SOT23-5 device.  Next thing is to see if the device can dissipate this amount of power.

From my technical datasheet the device has a max operating temperature of 125DegC and the thermal Resistance from Junction to Air is 220 DegC/W.  I also need to allow for Maximum ambient temperature, in this case 40DegC.  The thermal Resistance determines how efficient heat is transferred away from the junction i.e. the lower the number the better, meaning it’s more efficient at transferring away the heat from where it’s generated.  If the temperature reaches it’s operating max then the device will thermal limit, i.e. shutdown the output, which is not good.

Power(dissipatedMAX) = (TempMax – AmbientMax) / 220 DegC/W (for SOT23 Device)

= (125 – 40) / 220 = 0.386W

So my device has a max power dissipation @ ambient (40DegC) of 0.386mW , however the power being dissipated by my circuit is ~1W which is > 0.386W, so is not good :(    I need to go to a larger device, or lower the input voltage, in this case it will be a larger device as I’m not changing the battery type.

Calculating again for a SOT89 LDO Regulator with some better thermal parameters.

Max Junction Temperature = 125DegC

Thermal Resistance (Junction To Case) = 35DegC/W

= (125-40)/35 =  2.42W

So compared with my original regulator this one can handle the power dissipation as 1W < 2.42W with plenty of overhead.

Now the 5V Regulator

Doing the same for my 5V rail @ 85mA using the same SOT23-5 regulator (but 5V fixed output) gives  me:

Power(dissipated) = (9 – 5) * 0.085 = 0.34W

This is less than the Max power able to be dissipated by the regulator, i.e. 0.34w<0.386w so will be ok….just….although will run a little warm.

So if I add a PCB heat sink of 25mm square around (and underneath) the regulator using vias to transfer the heat how will that go?

So re-calculating with the PCB heat sink of 25mm square copper trace that has a thermal resistance of ~ 35DegC/W

Thermal resistance from Junction to Case = 81DegC/W

(125-40)/(81 +35) = 0.732W

So by adding a heat sink integrated into the PCB has increased the efficiency of the regulator to get rid of the heat by 89%.    

What I’ve done is to add a couple of vias directly beneath the regulator and opened up the solder mask so that bare copper is directly beneath the regulator.

image

It has certainly been a while between posts, but I thought I write a few things about my conversion to Kicad as my EDA of choice.

Most All of my projects in the past I’ve use Eagle PCB, as it certainly has been the EDA of choice in the open hardware community.  However it was the only non-open piece in my open hardware arsenal, until now…..enter Kicad.

I’ve been keeping an eye on Kicad for the past couple of years and I’ve never really had time to try it out on a project until now. 

A bit of background

My Father is a member of a recreational collectors motor bike club and they have a number of timed competition rallies throughout the year that may go over the weekend and consist of many checkpoints across a course that are located throughout the district. 

In the past they did everything manually i.e. write down their time and details at each checkpoint, so at the end of the rally, times are tallied and winners announced etc. Since it is manual it doesn’t scale very well, at their annual run where a few hundred competitors took part it didn’t scale well at all.  Knowing the geek that I am, my father asked me if I could do anything  to make things simpler.  The club had investigated some commercial rally systems, but was pretty expensive. I volunteered to automate things a bit…..

Enter RallyLog!  An Open Hardware project that will use RFID tags to log competitor times at checkpoints.

So I now had the reason to learn Kicad for a totally Open Project.

Enter Kicad…

Kicad was originally written by Jean-Pierre Charras (more background on Kicad can be found here – http://www.lis.inpg.fr/realise_au_lis/kicad/)

It is actively being developed by a large number of volunteers at http://launchpad.net/kicad and runs on a number of platforms:

  • Windows
  • Linux
  • Mac

Kicad is made up of a number of different applications that run under the Kicad project manager they are:

  • kicad – the project manager.
  • eeschema – the schematic editor.
  • cvpcb – the footprint selector for components used in the circuit design.
  • pcbnew – the PCB layout program.
  • gerbview – the Gerber (photoplotter documents) viewer.
  • 3D PCB Viewer

First Impressions

Coming from Eagle I had to unlearn how I did things within Eagle and move to the  Kicad way, this means a lot of right-clicking to do things, many things were not the same as what I was used to in Eagle, but I quickly picked things up within a day of using Kicad and now find most things fairly intuitive.

If I had a problem I found the developers and the users to be very helpful answering questions on the mailing list.

What About Your Existing Libraries?

Yes this is a big thing, especially those who have build up their own footprint libraries over time, however all is not lost! a ULP Eagle Library conversion script has been written that is run from within the Eagle Library.  This converts the library to the Kicad library format of which the Components and PCB prints are separated out into two files.  One is a library *.lib file for eeschema that contains the schematic representation of the components, the other is in a *.mod format for module footprints used within pcbnew.

In Eagle a library contains the:

  • Symbol – Schematic representation, actual component and
  • Device – the PCB footprint , all of which represent a component.
  • Package – the actual component that links links the Symbol and Device

Kicad component library has been separated into the Schematic and the PCB side of thins, one library for each.  Now That I’ve been using things for a bit over a month I can see that it makes a lot of sense.  When I’m creating a schematic all I want to worry about is capturing the circuit, if I need a new component I create a new component in the library, not having to worry about the footprint at this point in time.  In eagle it is similar, i.e. you can create only the symbol and package without the device, but I found it long winded.

Another added bonus with the components is you can link data sheets to the individual components. Brilliant!

I successfully imported a my libraries across, I did have to manually replace the reference some components as it defaulted to U?

One thing I haven’t played around with yet is the 3D viewer.

The Process

  1. Create a new project within Kicad project manager
  2. Create a schematic (and components if required)
  3. annotate your schematic
  4. Design rules check
  5. Create a netlist
  6. run cvpcb and associate footprints to your components
  7. run pcbnew
  8. import your netlist
  9. layout your PCB
  10. Design rules check
  11. plot your gerber output and create drill files
  12. view with the built in gerber viewer.

Features and Anti-Features (pros and cons)

Pros

  • 100% Open Source!
  • Interface for FreeRoute build into pcbnew, so you can use a push and shove autorouter.
  • In build Gerber viewer
  • 3D Viewer of the PCB.
  • I love the professional looking schematics it generates, even including the border information.
  • Hierarchical schematics – you can place sheets with-in sheets and drill down by clicking on them
  • Hierarchical Pins – have signals displayed in your hierarchical sheets as shown below.image

    Cons

    • Drills – Kicad has no concept of drills or holes in the pcbnew program, so you have to put in a pad that has the drill and the pad size the same, unfortunately this results in plated holes unless you notify your manufacturer of the holes not to be plated.
    • Component layers – I like the ability within Eagle to have a document layer for my footprints, where I can put information that will not included in my final output. (this is actually implemented in Kicad just a bit harder to find and not so intuitive)
    • Lack of inbuilt scripting like eagle, however you can write scrips in any language you want and manipulate your schematics, PCB and components externally du to the open format it is all saved in.

    The other day when playing around with different fuse settings on the Widget Board, I incorrectly wrote the wrong values, oops one bricked board :(   However all is not lost.

    With a second working Widget Board and a simple Arduino sketch , I used the following procedure to recover from my mishap.

    First I installed the following sketch onto a working Widget Board

    void setup() {
      pinMode(3, OUTPUT);  
    }
     
    void loop() {
      while(1) {
        PIND |= _BV(3);
      }
    }

    What this sketch does is generate a 1.2MHz clock signal on the INT1 port of the Widget Board. (Click the picture below to see the the full trace )

    image

    Next I attached this signal to the XTAL1 pin (Pin 7) of the AtMega168v on the bricked board (I just held it against the crystal pin). 

    While holding this connection on the pin, I then fired up AVR-DUDE and rewrote the correct fuse settings, after confirming that the fuse values could be read back I then remove the wire and everything was back to normal.

    So all is not lost :)

    Version 1.0 of the boards is progressing to the point where I’ll be starting work on v1.1, integrating user feedback and any issues on the tracker, I’ve put a few up there so please check them out, comment or add your own.  Issue Tracker.

    I’m extremely happy to say that everything has progressed really well, there are not any show stoppers with the board and as they stand are very usable.  The range of the RF with the units I’ve tested is brilliant, mainly inside, I’m hoping to do some tests over the weekend outside.

    The rest of my components finally arrived yesterday and I now have fully complete boards, the low profile crystals look really slick, alas I’ve decided not to keep them in the next board revision and opted for a more generic and cheaper HC49 type crystal.   There are a few more changes, but check out the Issue Tracker.

    In the Wild

    A few of the extra PCB I sent out are finally arriving at their intended destinations and hopefully everyone will have time and skills to build them.  For those that have already built them I have received some great feedback.  Looking forward to their test results.

    Arduino

    Last night I installed the crystals on all my boards and they are now running after re-programming the fuse bits.  I’ve also re-compiled the lily pad boot loader for 8Mhz and 10Mhz along with updating the Arduino board files, I will have them online in SVN shortly.

    I’m also assuming that you know how to program your fuse bits and they are correctly programmed.  The fuse values I’m using are found below in the boards.txt file. I don’t have to remind you that programming incorrect fuse values can potentially BRICK your board.  If you’re unsure please ask on the discussion group.

    You need to have the correct boot loader up and running on your Strobit first.  I’ve yet to test the boot loader programming from the Arduino environment as I do all mine manually using avrdude, but here are the hex files, the 8Mhz is for if you don’t use a crystal, the 10Mhz is if you have the crystal installed.

    Below is the boards.txt found in the Arduino hardware directory, just copy and paste into this the boards.txt and restart the Arduino environment. 

    Then select the Widget Board of choice from the TOOLS|Board menu.

    ##############################################################
    strobit1.name=Strobit Wireless Widget (10 MHz) Atmega168
     
    strobit1.upload.protocol=stk500
    strobit1.upload.maximum_size=14336
    strobit1.upload.speed=19200
     
    strobit1.boot loader.low_fuses=0xE6
    strobit1.boot loader.high_fuses=0xDF
    strobit1.boot loader.extended_fuses=0x00
    strobit1.boot loader.path=strobit
    strobit1.boot loader.file=strobitBOOT_168_10MHZ.hex
    strobit1.boot loader.unlock_bits=0x3F
    strobit1.boot loader.lock_bits=0x0F
     
    strobit1.build.mcu=atmega168
    strobit1.build.f_cpu=10000000L
    strobit1.build.core=arduino
     
    ##############################################################
     
    strobit.name=Strobit Wireless Widget (8 MHz) Atmega168
     
    strobit.upload.protocol=stk500
    strobit.upload.maximum_size=14336
    strobit.upload.speed=19200
     
    strobit.boot loader.low_fuses=0xE2
    strobit.boot loader.high_fuses=0xDF
    strobit.boot loader.extended_fuses=0x00
    strobit.boot loader.path=strobit
    strobit.boot loader.file=strobitBOOT_168_8MHZ.hex
    strobit.boot loader.unlock_bits=0x3F
    strobit.boot loader.lock_bits=0x0F
     
    strobit.build.mcu=atmega168
    strobit.build.f_cpu=8000000L
    strobit.build.core=arduino
     
    ##############################################################

    Strobit RFM12B PCB Layout

    I’ve started to document the Wireless Widget Board in the wiki, documentation is currently all over the place, but slowly getting there.  Currently I’m working on the build instructions so those of you that I’ve sent PCBS to can at least have a parts list.  

    I’ve also put up an initial bill of materials. But it would be great if someone can do a Octopart BOM and share it.

    Initial building instructions can be found here: http://code.google.com/p/strobit/wiki/Rfm12BuildingInstructions with more to come.

    I had a chance to grab a few photos of the progress so far, also helps that most of my components that I had on order arrived today so the boards has been kitted out with all the headers.  Now I can plug the prototype personality in, still waiting on my crystals, switches, and diodes.

    This gives an idea of size. (I don’t have big hands either)  This board has a 900MHz 2dB GSM SMA antenna, prototype personality board installed and battery holder for CR123A Lithium battery. 

    0515-1105040515-110420

     

    Different battery options, using x2AA with a switched battery pack soldered onto the board.

    0515-110726-01

    The SMA connector is a standard PCB straight SMA connector that has been soldered onto the edge of the board.  The board have been designed for the Sparkfun PCB edge mounted SMA connector (SKU: WRL-00593), however I found that a standard PCB SMA connector will do the same job, the distance between the centre pin and the ground pins is the same thickness as the PCB and all the pins line up with the Sparkfun footprint, the centre pin fits perfectly and so do the two bottom ground pins, only difference is the two top ground pins don’t get soldered.

    0515-110243

     

    One of the LEDs flashing….Its Alive!!!!0515-110702

    Today I constructed another 2 boards, very easy to do all done in around 30 minutes.  This now brings the total to 3.

    Applying the boards with solder paste by hand, manually placing the components, bake them in the toaster oven together.  This time I got the LEDs the right way around and the right amount of solder paste on everything, no bridges on the CPU pins and looks like the right amount of fillet on the RFM12B module, very little cleanup work required, it’s amazing how little solder paste is required.

    Add another 5 minutes to hand solder on the SMA connectors and program the boot loader on each, voila all done in around 30 minutes.

    Now I have a potential “Network” I will start testing the RF side of things.  Currently I’m using the 915MHz modules.

    Today I got a chance to do some testing on the boards. 

    State of play so far:

    1. Checked for shorts on power – OK
    2. Did a board level continuity test – everything as per schematic.
    3. Power at the correct levels and at the right places.
    4. Found that my USBASP programmer needs sw2 set and now all working, I can now read and set fuses etc.
    5. Arduino lillypad bootloader successfully loaded and working – Whoot!
    6. ASCII sketch loaded via Arduino development environment, serial port tested at 9600, all working.
    7. Jean claudes RFM12B Test Sketch loaded and working.  Can configure device and some random data is being read back from RFM12B, need a second board operational to fully test the RF side of things.

    TODO:

    1. Build a second device now that the basic circuit is working and verified.
    2. Fully test RFM12B and wireless comms.
    3. Test I/O i.e. Analogue and Digital ports, LEDS  etc
    4. Customise boot loader to use onboard LEDS.
    5. Document all of the above for others on the project’s website.

    All in all I’m pretty happy :)

    The PCBs arrived last week, unfortunately not in time for the long weekend so I haven’t really had a change to do anything until today and from my initial observations I’m happy with the results.

    RFM12B PCB

    IMG_8691_crop

    2.4GHz MRF24J40MA PCB

    IMG_8693_cropped

    Prototype PCB

    IMG_8699_cropped

    As I mentioned on the Strobit-general Google List and the SPOT-development Google list,  they seem to have multiplied from when I placed my order to when I received them,  I calculated I would get approx 12 back of each board, in the end I received 32 of each board, go figure…..so if anyone wants a couple of free blank PCB then contact me and I can send you some if you cover the postage costs.  Please use the contact form to let me know.

    Hot Out of the Oven

    Today I assembled the first one!  Didn’t take long at all due to the minimal component count.  If anything I need to add more solder paste to the RFM12B footprint, but seems to have taken.

    RFM12B PCB Assembled

    IMG_8706_crop

    I’ve partially assembled the board, enough to give me basic functionality so I can do some tests, while the rest of my components I’ve ordered (SMA connectors etc) arrive.  Unfortunately my stash of 0603 capacitors were actually 0805 ones in disguise, so I’ve had to use these even though the footprints are for 0603.   In the photo you can see some of them installed on their side.   Same goes for my bead, I only had some 0805 in my stash but have 0603 on order, just couldn’t wait :)  

    I’ve enabled all the solder jumpers so I don’t need to install the switch and the BAV diode for the time being.

    Changes for next board revision:

    A couple of things stand out with this board revision, nothing major but niggly enough to warrant changes or at least thinking about them.

    Crystal Footprint – One thing so far, I’m kicking myself for not making the crystal footprint a HC-49 SMD, I thought about it before I send the files off for fabrication, instead I opted for the sleek 0503 ceramic smd crystal, problem is they are more expensive and not as easy to come by, so I’ve added this as a change for the next board revision.  In future I’ll stick with the stock standard low cost crystal HC-49C footprint.

    Switch – Do I really need it?  The onboard switch seemed like a good idea at the time, but in reality do I really need it?  I’m glad I had the fore thought to add a solder jumper to bypass it. Honestly I will probably more than likely use a switch remotely (i.e. on the side of an enclosure) or on the battery pack itself rather than on the PCB.  I may just leave the ability to have a remote switch and remove the onboard footprint all together.

    LDO regulator onboard? – I’m still up in the air about this one.  Initially I wanted to keep things as low cost as possible (and I still do), and then add additional functionality via the personality boards so keeping the core board to bare minimum components, as I have only intended these to run from battery or from USB, not from a wall wart or A/C plug pack.  I have added some reverse protection with the BAV Scotty diode, but this won’t protect the board if someone connects a 9vDC source.  Anyway I think  I will wait and see how I go with testing and community feed back.

    Next Page »

    Switch to our mobile site