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.

Atmel Smart RF

First step: figure out what I'm going to use for wireless.

I need to keep in mind the goals: use as many Atmel components as possible, keep cost low, and minimize power consumption.

Atmel Arrow Smart Design Challenge

I submitted a design proposal to Atmel's AVR design contest back in October. The grand prize is a Smart Car. I figured winning a new car would be fun.

On Friday, they notified me that I had made it into the semi-finals, along with up to 100 other entries.

Ebay To Go

Ebay has an interesting new feature - the ability to insert gadgets into web pages (and blogs) that contain an ebay listing, or a search of ebay listings. Like so:



Hello web 2.0...

The effects of RAW converters on DSLR quality

Warning, links below lead to web pages with large graphic files.

The perceived quality of a digital camera, particularly DSLRs and their lenses, is heavily dependent on the tools you use to process the image. Not just the "recipe" or settings you use, but also the mathematical algorithms in the particular software package that you use.

Take the demosaicing algorithm. This is taking the red/green/blue camera sensor data and overlaying the colors into pixel data. Somewhat surprisingly, there are various ways this can be done, each with trade-offs for resolution, color, and artifacts. See this comparison.

Sharpening is another algorithm that varies from tool to tool. See this comparison.

Don't take those comparisons as a way to judge the absolute quality of any of the software, because the results are highly dependent on the content of the test image used. And there lies the rub. When you think about it too much, you realize there is an infinite solution space.

The variables are the camera, lens, subject, lighting, exposure, software, settings. A particular image might look best post-processed (PP) in Adobe Camera RAW with sharpening (and at least 6 other controls) set a particular way. Another image might look best processed in Silkypix.

So what to do? You can't run every picture you take through every software tool with every setting. I barely have time to run my best pictures through one tool!

You have to pick a RAW processing tool and learn how to use it well, learn what all the adjustments do and their combined effects, which adjustment to apply in which order. You have to develop different recipes for different types of images. And by recipe I don't mean a set of absolute settings, I mean the methodical steps you go through to adjust the image.

Portraits might be one recipe, landscapes another, low light interior another, and so on.

Do it wrong, and you are likely to blame the camera, or the lens, or the software you are using. Do it right, and you will have a very pleasing result. Maybe not the ultimate best result that could be accomplished some other way on some other software, but then you can't know every software package and you can't try every recipe.