Eagle CAD versions

CadSoft recently released version 5.8 of their EagleCAD schematic and layout software.  They have a free version that is limited, but popular with hardware hobbiests.  Now they also have a "Freemium" version that is less limited, yet, too limited.

Throwing in the towel

Tonight, I had to admit that it is impossible to complete my design by the deadline this Friday.

Hand soldering QFN

I tried last night to hand solder another 28-pin QFN part.  A QFN part has no leads, but rather copper pads are built right into the package.  And the leads are tiny and closely spaced.  On top of that, many QFN parts have a big ground "paddle" under the part.  This should be soldered down.  Atmel FAQ explains why.

So I'll give you the summary right up front: use reflow soldering for QFN.

Hand soldering SMT components

Below is based on an email that describes how I do hand soldering of SMT.  I'll try to add a few photos soon.

I use a temperature controlled iron with a good tip, set to 315C.  A temperature controlled soldering iron with a good tip is KEY!

How to waste 2 weeks

Inspired by a class I took from the author of Extreme SMT Instructable, I decided to set up a SMT reflow soldering system.  Although his hotplate technique works well, it isn't as repeatable as I would like.  Recently, he added a follow-up instructable that adds a PID controller to the hotplate system, which should make the process repeatable.  But I didn't see that until I was already committed to the toaster oven system (parts had been ordered). 

And the hotplate technique still bothers me.  The heat is applied to the insulating FR4 fiberglass, so only convection heat is getting to the solder joints.  The bottom of the PCB tends to discolor slightly, so who knows what this means for long term reliability.

Reading several DIY guides, I became convinced that the way to go was to buy a PID temperature controller and a powerful toaster oven.  Why duplicate something you've seen work when you can try to do it "better"?  (hint: This is especially not a good idea when you are under a tight deadline, like I am right now.)

In the Final 10

I got the word on Feb 12th that I made it into the final round of the Atmel SMART design contest.  I was too excited to post about it right away.

I sent out my three PCB designs in a local group order.  Got a great price and quick turn around. The boards literally arrived the same day I heard I was in the final round.

Lantern modification

I have a GE camping lantern that stopped working, so instead of just fixing it, I decided to make it "better".

Phase 2 is complete

I worked until 5am Friday morning completing the information I need to send in for Phase 2.  I got up after a nap and was preparing to email what I had done the night before.  In my email was a note saying that since they wouldn't start judging until Monday, we could submit our material through Sunday.

While I was pleased that I had another 2 days, I was disappointed they waited until the last moment to let us know.  I could have done with more sleep.

Code complete

I finished the code for the sensor board.  I plan to use an ATtiny44 with 4K Flash program memory.  The code compiles to 3720 bytes, so it seems there is room. 

Actually, it doesn't compile.  The Chibi uses an SPI interface.  The ATtiny series doesn't support SPI in the way that ATmega and above do.  An ATmega SPI works like a USART: you write a byte into a register and it gets sent.  In the ATtiny, you write a byte into a register, and then have to manually toggle the SCL line to shift the data out.  A silly "defeature" Atmel did so they could offer devices in different price tiers. 

But, I have just two days left to complete my contest entry.  So I am putting the code aside and working on costing the BOM, a quick power analysis, and writeup.  The writeup will have my known todo items in it.  I think full disclosure will be better than sending in code that won't compile and letting them discover it.

I'm off to Digikey to get prices now.

Never give up, never surrender

I had intended to post more often, but as the deadline nears, it is hard to take the time to craft a cogent post.

I discovered on Friday that the deadline for the round 2 submission to Atmel's Smart Design contest was delayed until Friday, the 22nd.  Four extra days that I really need.  I would not have made the deadline tomorrow. 

Good progress

I finished up the last bit of coding this morning, and made stubs for the RF routines.  Rather than face the problem of deciding on an RF solution, I decided to go ahead and try to get the code to compile.

It wasn't pretty.  Coding late at night results in repeating mistakes like "uint_8" instead of "uint8_t", and lOts of subtle capItalIzation errors.  I should typedef something easier than uint8_t, but it makes the code a little more obscure to someone looking at it later, such as judges.

Light at the end of the tunnel

I finished coding most of the main controller today.  Reducing the user interface to something more manageable really helped.

Time just keeps ticking away

Since the holidays are over, I've had to spend more time (that is, more time than zero!) on other for-pay projects.  That has not helped my progress on the contest.

It is quite clear now that I will have to use RF modules.  There just simply won't be time to design the hardware let alone code low level drivers for the chips. 

Not an Arduino

This is my "main controller" board for the Atmel design contest.  The ground pour pretty completely fills in the white spaces, so I am showing the board here without them so you can see all the lovely traces.

The SMT part in the center is an ATmega328.  The 6-pin connector on the left is the same pinout as an Arduino serial programming port.

So why didn't I just design an Arduino shield?

Well, I tried that.  Between the Arduino shield connectors and the interface connectors I need, the board was a mess of pins.  The ratsnest was also a mess.  The routing looked like it would take at least as long as this board, and for contest judging purposes, the elegance of the solution and BOM cost were not what I wanted.


On the upside, I can fall back to using Arduino boot loader and Arduino libraries if I need to save time. 

Universal PCB design rules

I just went through the design rules of just about every prototype PCB house I know of to determine what my design rules should be so I have complete freedom of choice.

It does get easier, honest

After designing 3 boards (well, actually one of those was a complete redesign after a failed attempt) with Eagle CAD, I have re-learned it's crazy interface.  The fourth board I did today in about 3 hours, from beginning the schematic capture to completing the board layout including passing DRC, and even the silk screen layer done.

Doing it wrong is progress

I spent a day working on the partitioning of the system, mapping functions to pins, and sketching the mechanical arrangement of the boards, display, touch panel, and radio.  System level design work.

Re-learning Eagle CAD

Eagle CAD's free version of schematic capture and board layout is a great tool for hobbyists. Full featured, lots of parts libraries available, and it does a decent enough job for designs that will fit on a 2-layer board up to 4 x 3 inches.

But the user interface is arcane. It takes me a day to remember how to use the darn thing when I haven't used it for a couple months. Yesterday, I spent 2 hours on a 1 page schematic. That was easily twice what it should have taken, but I was re-learning the UI.

Things that eat up time

Atmel's AT42QT2160 uses a 28-lead QFN/MLF package. The datasheet for this part doesn't have package dimensions! So I searched around and found that their ATmega168PA/328P also comes in the same package. But that datasheet has dimensions for for a 20-pin QFN (which the 168P does not even come in). Thanks Atmel, you are a ton of help today.

So after wasting time searching, I'm stuck calculating what I hope are the 28-pin package dimensions, and if I'm wrong, eventually I'll be wasting a LOT of time redesigning my board.

RF design tradeoffs

Well, more like architectural tradeoffs.

I've looked at the Atmel AT86RF212 datasheet and some example code, and compared that to the RFM12B datasheet and the code in the RF12 library used in the JeeNode. I believe I could fairly quickly port the RF12 library to use Atmel's part. Some features, like a fast SPI interface and 128-byte TX/RX FIFO will make the Atmel device easier to use than the RFM12B. Not easier to port, but easier to use in my application code.

But, and this is a big but, I am worried about the time needed to debug the code. Debugging wireless is hard. Of course, I don't have to debug it before the paper design is due in 30 27 days. It just has to simulate.

Yes, that's right, 10% of my design time gone, and I haven't even made a decision on the wireless solution.

I'm going to move on to other parts of the system. Design and code those, then see how much time is left before the deadline. I have a feeling that I'll have to go with Raven modules due to time constraints.