More noise than signal

A scary LED project for MSP430 Launchpad

2010-10-30T00:51:00.000-07:00

I read the Evil Mad Scientist Labs project "A pumpkin that sleeps like a Mac". This inspired me to build up an LED project to light my jack-o-lantern. Their project uses an ATtiny2313 and I didn't have time to order parts. But I did have some TI MSP430 LaunchPad boards that I hadn't even opened yet.

So I installed an IDE and ported the code from AVR to MSP430.

The MSP430 has a timer counter with a PWM function, but rather than learn how to program TI's timer, I just converted the code to a simple, brute force PWM function in software.

Another change I made to the code was to change their algorithm's constants into variables. This allowed me to easily try different values to get the blinking effect I wanted without a lot of re-compiles. I could just pause the debugger, change a value, hit continue to see the effect. Once I had an blink that I liked, I put the numbers into the initialization of the variables and programmed the MSP430 processor.

The basic blinking algorithm is still as Evil Mad Scientist Labs originally designed it. I just tweaked some code details.

One thing I learned is that the IAR IDE is configured by default to disable downloading the code to the target system when you press the "Download and Debug" button. Note that the button right next to it is "Debug without Downloading". Why there is such an option, I don't know. They should grey out that icon, or change the tool tip. It sure wasted a bit of my time figuring that problem out. Anyway, the fix is under Project > Options > Debugger. Change the Driver pulldown from "simulator" to "FET Debugger".

Here is the code:

Some notes on the circuit.

The MSP430 is rated for VCC of 2.2 to 3.6 volts. I used two AA which gives a nominal 3V VCC.

The MSP430 outputs can drive about 25mA. I used some 2.2V red LEDs rated for 20mA, so I could probably have driven the LED directly. That would be running both the MSP430 and the LED at their limits, which isn't good for reliability nor battery life. Instead, I used 180 ohm resistors which gives about 4.5mA of current to the LED. I hooked up two LEDs, each on its own pin. The code as written drives pins P1.7 and P1.6. This seems to be bright enough to light the inside of a pumpkin sitting on a porch.

Actel Smartfusion

2010-07-09T11:43:00.000-07:00

Yesterday, I went to Seattle for a presentation (they call it a "design workshop") on Atmel's Smartfusion devices. They have combined their Flash-based FPGA with an ARM Cortex-M3, the usual micro-controller peripherals, and some configurable analog blocks to make a very flexible, mixed-signal, embedded device. I brought home an eval board and some thoughts on their technology.

First, some background info.

I like Actel's FPGAs. Their on-die Flash and anti-fuse FPGAs tend to be faster than Xilinx or Altera. Actel seems to always put plenty of routing resources on the chip, unlike Xilinx which seems to always starve the routing. Sure, Xilinx can route through logic cells, but then you end up with the occasional 100nS signal delay. Altera seems to fall in between Xilinx and Actel in routability (and thus real world speed - ignore the raw gate delays).

What's in a SmartFusion device? Basically, its a nice ARM Cortex-M3 based 100MHz, 32-bit MCU with all the peripherals and memory you would expect, some configurable analog functions, plus an Actel Flash FPGA fabric. Here is the datasheet. A quick rundown:

SPI, I2C, UART, 32-bit timers, watchdog, RTC, on-ship oscillators (classic MCU stuff)
8-channel DMA, Priority interrupt controller, external memory controller, Ethernet MAC (nice Cortex-M3 support)
Embedded SRAM (dual port!), FLASH, and a bit of EEPROM
12-bit A/D and D/A, comparators
Flash programmed FPGA with 4Kbit SRAM blocks
All tied together by an AHB and APB busses
JTAG programming and debugging

The CPU and perhipherals are implemented in gates aka "hard macros", not FPGA soft macros. This avoids issues with typical FPGA implementations of embedded controllers. Soft macro CPUs take up too many FPGA resources and under-perform in speed. So you can end up with a $50 FPGA-based part that performs like a $5 Atmel or PIC device.

My take aways from the class (more or less from the bad to the good):

No USB interface. IMO, that's as important as Ethernet for a 32-bit MCU embedded design. They need to add that in the next generation.

FPGA tools have slowly improved over the years. Early on, FPGA tools were a collection of totally separate programs with completely different UI's for each stage: design capture, simulation, timing analysis, synthesis, routing. Over time, the different FPGA vendors have added nice front ends that tie those bits together and run most of them in the background. Unfortunately, with the CPU, hard peripherals, and analog functions being added to the FPGA, we're back to a very modal design model where you are obviously launching different tools from different vendors to get things done. By the end of the class, by brain was spinning. You need a very large poster to diagram the roadmap you must navigate to produce a design. At this point, it is not for the feint of heart. Certainly not for the hobbiest.

Too costly. The mid-sized part with 200K FPGA gates is about $50. I don't know the cost of the 600K device, but it must be well above $200. I can get a 32-bit ARM MCU and a nice sized FPGA for under $50. The 60K device, to be released latter this year, may be at a more interesting price point.

The programmable analog looked interesting. Compared to a typical MCU with an A/D and maybe some comparators, the analog modules are more flexible and varied. They include an "analog compute engine", which is really just a configurable state machine. But it gives the designer more than the usual flexibility in configuring how the analog works, and offloads the CPU a bit for simple sequencing of the analog functions. There is also a "post processing engine" that can do low-pass filtering and other transformations that really are better done in hardware than the general purpose CPU.

While I already complained about the tools, I really liked the MSS (microcontroller subsystem) configurator. Atmel and Microchip need to study this and emulate this capability it for their MCU's, immediately. If Arduino added this functionality to their tools, it would really make the platform easier to use for people without a background in embedded design.

The tool presents you with a "block diagram" GUI view of the ARM CPU and hard macro peripherals. Click on any function block to configure or disable it. For example, set the SPI interface to master, disable an unused UART, set up a timer on an interrupt, etc.

Then the magical happens. The tool will generate a software shell with all of the drivers for the peripherals, initial setup functions, and all the .c and .h files set up and ready for you to add your code into the main() function. No more hunting around the web and downloading what you hope is the right SPI code that will work with your part. A lot less adding include files to fulfill dependencies in the drivers. Its like Arduino on mega-doses of steroids. That UART block you disabled - it will be set up for zero power. The SPI interface - just look at the function prototypes and you know how to read() and write() to your SPI peripherals.

If you are uncertain about how to use any of the MSS devices, you can have the tool generate a little example code that will run on the evaluation board, You can then see and experiment with working code.

The MSS tool also supports very easily adding any of the common embedded peripherals to the FPGA and it will hook them up to the ARM through the ABH bus, set up the memory map, and supply the drivers and the setup code. All with drag-n-drop. You can add 5 UARTS with no Verilog (or VHDL, your choice) coding required. But the Verilog is there and editable. If you need a 64-byte FIFO on your UART, you can get into the code and add it.

I know Freescale has something similar in their Processor Expert tool, and probably others as well. Maybe there is a costly 3rd party tool out there that does this. But I haven't had an opportunity to use those yet. Atmel really needs something like this, with the variability in how their different devices implement the same peripheral functions. Microchip is a bit more consistent with their peripherals, but this would still be a nice feature for their flow.

Arduino, thanks to being on a small subset of parts, would have the easiest time implementing this, and their user base needs it the most. I think it could help expand Arduino from 100,000 users to 10 million.

The eval board

The SmrtFusion eval board sold out immediately when Actel announced it. They've had more batches built and they are now available.

For $99 (or $50 for the board plus a day of training, which is what I did), you get their $50 A2F200KM3F SmartFusion part on a board with a (tiny) I2C OLED display, some buttons and LEDs, a 10/100 Ethernet port, external SPI Flash memory, an expansion header, and a USB interface.

The USB interface is implemented in a separate part, not the A2F200K. It is used for programming and debug. It can also be used to send data from an application running on the FPGA through a UART port to the PC using serial over USB.

Basically, you have a way to play with all of the different I/O features on the chip. This comes in handy with the MSS tool's ability to generate example code.

There are several jumper switches on the board. The silk screen is so small, it almost takes a magnifying glass to make out which is which. One jumper has to be constantly changed as you go between programing the part and debugging. That's a pain. At the least, they should have a slide switch, and preferably figure out a way to eliminate that jumper.

Your utility thinks you are lazy and stupid

2010-07-03T00:36:00.000-07:00

Someone was wrong on the internet. That’s certainly not news nor something I want to try to battle every day. But in this case, the problem I discovered appears to be spreading and it is affecting important decisions in the real world.

The energy industry is selecting which technologies to implement based on the belief that consumers are “stupid and lazy”. I’ve tracked down the source of this problem.

A little over a year ago, I went to a community meeting to discuss what Oregon could do to attract federal economic stimulus dollars. The theme was to find ways to leverage Oregon’s “green” reputation. We hoped to identify projects that could use stimulus money to show the rest of the country the viability of new ideas and technologies in areas such as health, renewable energy and energy conservation.

I went to a breakout session on energy. We were supposed to brainstorm some ideas on energy generation and conservation. The group included educators, technologists, inventors, and some people from the energy industry.

Any idea (including all of mine) that involved consumers was immediately shot down by the industry insiders. They told us none of our ideas would work because consumers are “stupid and lazy” and “they can’t even figure out how to program a setback thermometer”. They insisted that the only things that would work were those that could be done without depending on the consumer to do anything. I passed it off as the usual crap spewed by people that are trying to get money for themselves, and don’t want anyone to actually brainstorm new solutions that might take dollars away from their pet projects.

A week later, at a different meeting with a different set of people, I heard similar words from some people involved with the smart grid. “Consumers are too stupid and lazy to even program a setback thermometer.” I was beginning to see a trend. I asked them where they came up with that assertion. “Oh, there’s a study out that proves it.” I gave them my card and asked them to please send me a copy or link. I never heard back from them.

Over the course of the next few weeks, I ran into this attitude every time I was in a meeting with anyone in the energy industry. Apparently, it is a meme that has developed within the energy industry. I can tell you that it is actively stifling any innovation that involves consumers. The utilities are using it to justify decisions like not providing consumers with real-time data on energy use from the smart meters that are being installed. Their attitude is that smart meters are only for instrumenting of the smart grid for the utilities use, not for the stupid lazy consumers. Believe me, “stupid lazy consumers” is almost a chant with these guys. I wouldn’t be surprised to hear they use a three letter acronym for this in the office.

Eventually, I found what I believe to be the source of this attitude. I found a Forbes.com article titled “The Smart Grid Vs. Grandma”.

The meme apparently originated from statements being made by Richard Thaler, a behavioral psychology economist at the University of Chicago's Booth School of Business and co-author of Nudge, a how-to book on influencing decision-making.

Quotes from the article include: "Thaler points to Americans' adoption and use of programmable thermostats as an example of laziness trumping logic." and "People tend to be passive," Thaler says. "For smart meters to work, they'd have to be pre-programmed."

He bases his assertions in the article on “a 2005 survey by the Energy Information Administration”. I tracked down the actual survey: the Energy Information Administration’s “2005 Residential Energy Consumption Survey, home energy uses and costs”.

Given the actual numbers in that survey, his analysis and conclusions are pretty bizarre.

Thaler states that "only a third of Americans own the devices and less than a fifth use them to change their homes' temperature during the day, even though half of Americans leave their houses empty from morning until evening". This is a very misleading interpretation of the data in the report.

While it is numerically accurate, 18.6/111.1 is the number of homes that use a programmable thermostat to lower temperature during the day, he is misinterpreted this to imply that 80% of consumers are too stupid or lazy to even program a thermostat to save energy.

His statement ignores a few facts mentioned in the report: many homes are not empty during the day; some homes are in climates where heat isn’t typically needed; some homes have heating systems (example wood burning stoves) that are not regulated by a thermostat; some of the homes in that 111.1 million don’t even have a heating system.

Here are a few of the numbers from the report (in millions):

    * Total US housing units: 111.1
    * Use space heating equipment: 109.1
    * Have a thermostat: 95.8
    * someone home all day: 56.4
    * Lower temperature setting when no one is home: 40.5
    * Have a programmable thermostat: 33.1
    * Use programmable thermostat to reduce temp during the day: 18.6
    * Use programmable thermostat to reduce temp at night: 21.5

The study points out that only half (111.1-56.4/95.8) of all homes are empty during the day, and would thus even be interested in reducing heating during the day. Yet 56% (18.6/33.1) of people with programmable thermostats do indeed program them to lower temperatures during the day. The correct conclusion is that homes which are empty during the day have a higher probability of having a programmable thermostat, and it is indeed programmed.

This statement also bothered me: "If it involves people actually doing something, it won't happen," Thaler says. "Just look at everyone who never figured out how to program a VCR."

The VCR is a poor analogy, based off a bad joke from the 70's. In reality, VCR user interfaces in that era (in case you are too young to have seen them) were very poorly designed, and quite frankly often had poorly translated instructions. The failure was with product development and user interface design, not with the consumers. So yeah, if the energy industry does a terrible enough job, people won’t be able to use the technology.

21 million (40.5-18.6) homes are manually lowering the temperature settings and may benefit from installing programmable thermostats. People are obviously motivated enough to lower temperatures manually.

My conclusion: Consumers are smart enough to program their thermostats when it is needed. Consumers are motivated enough to manually control their thermostats. Isn’t this the opposite of Thaler’s position? Consumers are neither stupid, nor lazy.

There are also quotes in the same Forbes article from Marti Doneghy, supposedly a spokesperson for the Association for the Advancement of Retired People.   Simply put, this lady should be fired.

"We vigorously oppose the mandatory imposition of these smart meters in peoples' homes," Doneghy says. "Everybody has to pay for this change, and a lot of the 50-plus population simply isn't that interested."

Even the simplest online interface for controlling those smart meters, Doneghy points out, is beyond the grasp of plenty of Americans. "Internet access is not a fact of life for every person in the country," she says.

I’m not going to even bother to look for statistics to refute her first statement. The 50-plus population is most certainly interested in anything that can save them money.

Doneghy has no idea what "the simplest online interface" might be. No one is proposing consumers "control those smart meters". "Plenty of Americans" can read a thermometer or gas gauge, and they can understand a display of their real-time energy usage.

As the last statement, the reality is that broadband access is at 74% and internet access is at 85% according to U.S. Census Bureau numbers for 2008. Not quite everyone has the internet, but it’s obvious that enough use it to make it useful.

This “spokesperson” obviously believes people over 50 are "stupid and lazy", and people in the energy industry that I talked to agree with her.

This meme that "consumers are stupid and lazy" is helping the energy industry to make poor, self-serving decisions.   Maybe not everyone in the energy industry has bought into this thinking, but certainly those I talked to back in May and June of 2009.

I checked out Thaler’s book, Nudge. It is full of interesting theories on how to manipulate consumer decision making. He backs up his theories with data from various studies and surveys. After looking into his interpretation of data in the residential energy consumption survey, I have to be skeptical about everything said in that book.

Unfortunately, I don’t have time to track down everywhere someone is wrong on the internet. I am too busy with ideas about monitoring and reducing home energy use that I need to work on instead.

Eagle Cad autorouter on fine pitch SMT

2010-06-14T00:30:00.000-07:00

That first design may be an anomaly, so I tried a couple more designs.

This next design is a smaller board, less complex, density about the same, but with a QFN part. Note that my board density is partially due to the off-board connectors defining the minimum size board, and a tradeoff in size to make it easier for me to hand place the smt components. Plus, not cramming parts too close together for these prototype PCBs allows for cuts and jumpers during debugging.

Here is my manually routed board. I think it flows fairly nicely. The 6-pin header is an ISP programming connector, so I cannot reassign pins on the 20-pin MCU to improve routing. There is also a trend showing up in my boards. I like to put a rectangle on the bottom and assign it to GND to give me a ground plane. Not really necessary on these tiny, low frequency board. Above 16MHz is my rule of thumb for where ground planes are a must.

But it is a force of habit for me, and it saves me from routing the GND net.

I tried routing this board with the routing grid set to 10, but the Eagle CAD router refused to connect to any of the QFN pins. The pins are .5mm spacing. So I tried setting the grid down to 2 and even 1 mil. Still it wouldn't route for some reason. And, routing with a tiny grid gives the algorithm too much freedom. Instead of routing in a few seconds, it can take minutes (on a small board).

So I "helped" by doing short routes out from the pins. A secondary benefit is that this prevents the autorouter from doing anything stupid right up next to the package, like putting in a via that blocks adjacent pins.

That puts the end of the signals on-grid, allowing the autorouter to do its work. So I set my DRC rules to 10/10 (width/spacing) and the routing grid to 10.

Anyway, this isn't great. There are a couple unrouted nets. One is easy to fix, but the other is going to take some work. The routing is noticably less optimal my manual routing. Also note the two vias the router still managed to put close to the QFN. Not good for solerability or rework. There are some goofy squiggles on some nets. If I wanted to help the autorouter some more, I would rip everything up, then route the QFN pin 4 up to the SOT23 and give it another try.

I hand routed this board in under an hour. Cleaning up the autoroute is going to take a fair amount of time, but well under an hour. So again the autorouter is a time saver with acceptable (not optimal) results.

Next, I have a board that has a bit more critical routing requirements. This board is a capacitive touch controller. The signals going to the headers on the right of the board need to be layed out to avoid too much capacitive coupling between signals. The board as placed is a little more dense that the first two, and it could be compressed even more. I left it a bit loose so it would be easier to manually route. I have to admit in fairness to the autorouter, I took two evenings to route this by hand, which included starting over from scratch at one point to make the board larger and easier to route by hand.

Without going into too much detail, there are some considerations in the routing to make the power rails clean, and reduce coupling between the touch sensor signals. The autorouter isn't going to know about those.

Another QFN fine pitch part, so I hand routed some stubs for each pin just so the autorouter would have any chance to route the board.

Next is the autoroute results:

One unrouted net. The autorouter managed to put in some vias and routes to really block that signal from routing. I manually routed it, but it took about 12 minutes of shoving stuff around. The spaghetti routing on the right side of the board may or may not be acceptable, electrically, for the touch sensor signals. I'd have to fab the board and try it to see if the capacitive touch is impaired. It is certainly not as good as what I did, but then the autorouter doesn't know the special constraints in that area.

The routing on the left side of the board isn't too bad. The power signal is routed similarly to what I did, with no vias. VCC is pin 3 of the QFN going to the SOT23 regulator without any vias.

What I might do with this board next is to leave some of the autorouted nets as-is, and rip up a lot of the nets on the right half of the board so I could clean them up.

Conclusion
The EagleCAD autorouter can be useful on some boards. The autorouter was able to route these boards with just some very basic tweeking (routing grid set to 10 mils instead of the default 50) and routing help (fine pitch SMT parts seem to be problematic). This router doesn't support tagging nets as differential pairs or critical nets, so there is a clear limit to what it can do. For hobbyist prototype boards, if you lay out critical nets by hand, I'd say it can be a useful tool to save you some time.

Eagle Cad autorouter

2010-06-12T14:34:00.000-07:00

In EEVblog #93, Dave Jones rant's that "PCB Autorouters Suck". Especially for beginners, and most definitely in cheap tools.

I happen to agree. So I tried a little experiment. My results surprised me.

I have a small microcontroller board that I created in the free version of Eagle CAD. I manually routed it a few months back. Including placement, I think this took me about 2 to 3 hours (one evening).

The MCU runs at 4MHz off of its internal oscillator. The crystal you see is a 32KHz for a time of day function. None of the signals on this board are above 400KHz, and currents are low. I like to make power traces big mainly so I can quickly tell them apart from signals. I don't like vias under my QFP. I got lazy and put in a top layer ground plane to help with routing ground through my power supplies on the left of the board. So basically, one can say none of the traces are critical. Good design practice has bypass caps near the power pins of the MCU, and the XTAL should have a solid ground plane.

So I ripped up all the traces and took out the top side ground plane. Loaded my 10/10 width/spaces design rules. I set the autorouter to a 10 mil grid. If you leave it at the default of 50 mil, it can't route to SMT pads that are "off grid".

I clicked OK and about 5 seconds later, the autorouter gave me this:

Note it says 100% routed! That right there shocked me. And the other thing I noticed is that the autoroute looks pretty decent. Not too many oddball excursions - it was smart enough to clean those up.

But, it did put 5 vias under my QFP. I don't like that. I like my traces where I can get to them for debugging. So I ripped up the routing, placed a couple power traces under the QFP, then blocked out the rest with some rectangles. I'll take the rectangles out when routing is finished.

I fired up autoroute, and this time it took slightly longer, maybe 10 seconds. I could see it trying various routes. But when it got done, I again had 100% routing, and it looked like this.

Not bad at all! Not counting copy/pasting images for posting here, I've got only a couple minutes invested in this routing so far, and it looks presentable. Sure, there are some longish routes, but at these speeds, its not a problem.

A bit of cleanup, widening some power signals, a little bit of moving signals and vias for manufacturability, and now with a total of 15 minutes invested I have this:

That looks pretty good to me. I'd say that's quite acceptable for a small prototype design.

I have to say I'm surprised at the results. For a quick, small, prototype PCB, typical of what I'm seeing other hobbiests do on Eagle, the autorouter helped me finish the job in 1/5th of the time of manual routing (excluding placement, which will be the same either way). And I got similar quality to my manual work without much fiddling with the autorouter settings.

Sorry Dave, I've failed to prove your (and my) position on autorouters.

What I learned at Code Camp

2010-05-23T11:57:00.000-07:00

I attended Portland Code Camp with about 1400 other geeks yesterday at the University of Portland.

Because paper notes get lost and don't hyperlink so well, I'm going to post them here.

Eventually, the slides will be online and I will link them.

Developing a Rich Interactive Application Experience
Brian Henderson, UX guy from Seattle
@brian_henderson

Start with understanding the user -

What is their environment? Are there post-its or other info they have collected to help do their work?
What is their behavior? What tasks do they do most often?
Collect their stories.

Create mockups on cardboard, walk through with user, rework, try scenarios.
Ask open ended questions. Ask about their problems. Avoid just hearing their proposed solution.
What activity wastes your time? What shortcuts do you use?

Personas -
A made-up, believable person.

Role: e.g. beginner, expert, admin.
Personality
Name

Use the personas to get agreement with team on who they are developing for, get everyone (including management) on the same page.

Sequence what they will do and how. Test on paper, not code. Paper is cheap. Code is expensive, and developers become invested in it - hard to modify.

Focus on solutions, not features.

Features of a Rich Interactive user experience -

Guide users through the app
Help them progress from beginner to becoming expert
Keep it simple - minimum info and context
Focus
Task oriented
Provide meaningful incentives: badge, status, member vs visitor

stackoverflow.com is a good example

Three stages, each with a feedback loop. Make changes at the easiest, cheapest possible level.

Paper design / test
Functional design / test
Production ready design / test

Six Principles:

Make it Direct (obvious)
Keep it Lightweight (minimalist)
Stay on the page (avoid context switches, navigating back and forth)
Provide invitations (lead them)
Use Transitions (providing context on-page)
React Immediately (hints, tool tips, popups. validate input and give feedback)

Matrix of "Interesting moments" - states. A spreadsheet-like list of tasks - see presentation for an example. Helps keep it simple, lightweight.

Need screen considerations: Landscape (PC), Portrait (tablet), Mobile (small)

Couple slides of common screen patterns, UX patterns. Tried and tested, familiar.
Quince - online tool to explore them.

Manage expectations - early versions should have less polish, to let everyone know its not baked yet.

Review

Focus of stories, not features
test earlier - cheaper and easier to modify
Know your users - don't design for yourself
Be visual - storyboards, mockups
Maximize shared understanding - UX, dev, coder, user - personas, wiki, stories

Last page: Resources list
Google "RIA" "UX" "Interaction Design"
Note that stuff from most recent 2 years is better than older.

A good presentation, the second I've attended by Brian.

Developing for Windows Phone 7 Series
Marcello Guerra, Microsoft

Everything in his presentation is also available from MIX. Go there for hours of videos.

Expression Blend - best for Windows Phone development. Looks like Visual Studio w/ a black UI. Used for designing the UI and creating simple interactions. Demo was a very simple version of Mine Sweeper with no code required.

Visual Studio 2010 Express Phone Edition. Has Silverlight and XNA. This is beta, about 5-step process to install. Full instructions on Microsoft web site. Polished single download due out later this year. Note: do not try to install over other Visual Studio, must un-install first.

Microsoft Phone Notification - push notification. Small amounts of data that show up on the app icon. NOT for app update downloads, not for pushing lots of info for the app to have when it becomes active.

Microsoft has new catch phrase "three screens and the cloud".

PC
TV (Xbox)
Phone
Cloud (web services)

Went over the Microsoft Marketplace app submit process. Sounds like Apple.

Current version of requirements has all phones with the same display resolution, all peripherals required that are in the APIs.
2nd version will add resolutions, ad-hoc distribution, Flash and Silverlight in the browser (not in 1st version).

For Windows Phone 7 resources, go to developer.windowsphone.com

Consuming RESTful web services on the iPhone
Frank Schmitt
@frankus

Talked about "Objective Resource", an obj-C library for the iPhone. iphoneonrails.com

Mentioned that REST purists may object to some of what he says/does.

This library is designed to work seemlessly with a Ruby on Rails web site. Frank very quickly created a web app (scaffolding) for a book database with title and auther from the command line using Rails.

ObjectiveResource supports:

List - GET /books
Create - POST /books
Read - Get /book
Update - PUT /book
Delete - DELETE /book

Quickly created an iPhone app to talk to the web app. Classes: Book, Author.
#import "ObjectiveResource.h"

DEBUG key causes the library to send to the console messages about everything it sends and receives from the Rails app on the server. Very handy.

Contrasting to SOAP - SOAP is higher level, more complex, uses pre-defined data formats, more data traffic.

Security - POST user, PW, get GUID. use GUID for session, don't keep sending user and PW! Or, use SSL and certificates.

Note: if the network is slow, finder may kill your app on launch for being too slow to load. Need to set up loading the db in the background (with a spinner over the app).

Mentioned ASIHTTP Request as another option, but he hasn't used it.

Design Patterns in architecting applications in the cloud - Amazon Web Services
Jinesh Varia, Amazon tech evangelist

AWS provides scalable, spike-proof, pay-as-you-go cloud services.

Google "Cloud best practices" to find his presentation, on http://media.amazonwebservices.com/

I mentioned Portland's Urban Airship using AWS to scale their business while the company stayed at 2 guys and a laptop. He is trying to meet with John at Urban Airship to discuss.

Animoto.com is the example he went through. Cool web app that takes your images and soundtrack and "automagically" creates a cool presentation. They went viral with their Facebook application, spiked to adding 25K users per hour. Quickly went from 500 to 5000 servers.

They have a variety of services. You can choose from them cafeteria style. Using one does not imply you must use another.

EC2 - Amazon compute on virtualized server instances. Linux, Windows, Solaris, etc.
Three pricing options:

On-demand - allows for spikey usage. Most expensive, e.g. 8.5 cents/hour per server
Reserved - non-spikey, steady state usage. Cheaper, e.g. 3 cents/hour
Spot - bid on unused capacity. Executes your workload when price

See AWS.amazon.com/calculator to look at various rates.
See cloudexchange.org for spot prices.

Bandwidth is additional 15 cents/GB/month.

S3 - Amazon storage. $/GB. Only pay for what you use.

Other services include: RDS database service on mySQL, SQS Queues, SNS notifications, SimpleDB domains, Analytics.

OS, Framework, Language agnostic. Use what you want, like you would on your own, in-house servers. But without the up-front costs, and instant scalability.

Scalability Best Practices
This doesn't happen automatically. Your app and architecture needs to understand and allow for scaling.

1. Design for failure - recognizing failure, how to recover, rerouting automatically

elastic IP addresses - remappable static IP
use multiple zones, Amazon has 4 - US-W, US-E, Euro, Asia
Use AutoScale for auto recovery
use EBS for persistent file systems. EC2 looses its file storage when terminating or dieing. Back up volume to EBS on a schedule that is right for your app.

2. Build loosly coupled systems
Independant components, blackboxed, decoupled using queues on load balance clusters.

3. Implement Elasticity - dynamic reconfiguration
On bootup - who am I and what is my role? Enable dynamic config, not static. Resiliant to reboot and relaunch.

4. Build security at every level
encrypt data at rest in S3. Encrypt data in stransit with SSL. Set up security groups. Consider encrypting data in EC2 for sensitive data (they don't wipe data, so next one to use that server might have access)

5. Don't fear constraints
Can always get more instances, etc.

6. Leverage Storage Options
Showed a spreadsheet for pro/con for each type.

7. Think parallel

Start small, put some small piece on the cloud, get experience, scale and expand over time.

C# IDE Tips and Tricks for VS2010
Kevin Pilch-Bisson, Microsoft developer for Visual Studio for 8 years.
@pilchie

There are a lot of underused features, some from versions prior to VS2010.

As Kevin went through his tips and tricks, he received several rounds of spontaneous applause from the audience when he described how to get to features users have been wanting for a long time. And "oh!"s when he described "undiscovered" features that have been around for a while.

ctrl-e - brings up search window for any text in your project.
ctrl-comma - navigate to. Extensible navigation tool. Understands camel-case. Type TST and get TestStatusText. Understands pascal-case. Type test text status and get TestStatusText.
ctrl-period - display menu for a smart tag. These are the small red or blue tags VS puts on code. Much easier than trying to hit them with mouse.
cltr-alt-space - toggle suggestion mode for auto complete. new mode: tab to accept suggestion. space, period, etc are taken literally.
F12 - go to definition !!!
ctrl-dash - go back to last cursor loc after a search or goto. With a 5 button mouse, the "back button" does the same.

Hover over a variable in debugger, after 1.5 seconds, click on the push pin to get a "permanent" watch pinned at that location in the code. Rather than clutter the watch window with variables all over your code.

Breakpoints - now have export (via XML file) to save or share your break points.

.exe projects now default to 32-bit, even on 64-bit systems.

Edit and Continue - nice, but many limitations. Doesn't work for LINQ, for example.

Intellitrace - only available in high end SKU above Pro. Shows a list of exceptions that led up to a problem.

cltr-shift-F12 - see list of where identifier is used in your project.

F8 can now cycle through results for any list, e.g. compile errors. Shift-F8 to cycle backward.

Other resources he recommended:

CodeRush Xpress - free tool that adds more features to VS.

csharp.net - C# developer center.

VS key bindings posters available at blogs.msdn.com/lisa/

AVR Dragon vs slow clock rates

2010-05-03T12:17:00.000-07:00

I am using the Atmel AVR Dragon board for debugging. For $50, its a great tool. The AVR Dragon supports virtually all AVR devices, and works with AVR Studio to support Atmel assembler and GCC C code and in-circuit debugging. It also works with other tools, such as the command line AVRDUDE utility.

To do in-circuit debugging, AVR Dragon uses something Atmel calls "debugWIRE". This uses the RESET pin to communicate serially with the AVR. To make this work, you must NOT have any capacitor hooked to RESET. You are allowed to have a resistor on RESET, but it should be 20K ohms or higher. Of course, no active circuit can be driving REST.

It can be a little tricky to bring up the AVR Dragon and your target board. The problem is that the AVR Dragon's ISP interface senses the target's AVR voltage, but does not intend to drive power to the MCU. However, some small amounts of power can reach your AVR processor through the signal pins. Just enough voltage to get it to come up in a bad way so that the target AVR processor will "hang". Thus, it is important to power the target board separately, and power it up BEFORE plugging in the AVR Dragon.

What I do is power up the target with the AVR Dragon attached via the 6-pin ISP interface, but the USB cable not plugged into the AVR Dragon. Then I plug in the USB cable. This seems to work reliably.

Another thing to note is that when you debug code, the AVR Dragon will first write the code into the AVR's Flash. This has a "side effect" that later when you try to start up a debugging session, and you plug in power to the target board, it will begin executing its code. This can be a problem.

The real problem is that the AVR Dragon does not like AVR's that are running below 1MHz. This can confuse the debugWire serial interface on the RESET pin in the AVR. If the clock rate in the AVR is below 1MHz, it becomes very difficult to bring up debug mode. The slower the clock rate, the more problematic it can be. At 32KHz, the AVR processor is essentially "bricked". You have to find a way to re-program the Flash.

For my project, I am trying to conserve battery power. So my program lowers the clock rate, then puts the AVR (an ATtiny44A) into the IDLE sleep mode. The AVR wakes up on an input change or in 10 minutes via TIMER1. It changes the clock rate back to 4MHz, processes the input or timer event, then returns to sleep. So 99% of the time, the clock rate is low.

This works fine. And you can even debug it using AVR Dragon as long as the Flash code doesn't come up and immediately put the AVR into low clock rate sleep mode.

I learned all this after "bricking" my board by loading and debugging a version with the lowest clock rate, 8M/256 = 31.250KHz.

So now my sleeping clock rate is not a #define, but rather a variable in RAM. The variable is initialized to "clock_div_8" which is 8MHz/8=1MHz. This results in my code starting up with a default of a 1MHz clock during sleep. I manually change the variable to 256 during debug to see what happens at 31KHz. Now when I try to debug with AVR Dragon, the Flash code will start off with 1MHz, and everything works.

I was able to un-brick my board. I wrote a very tiny, do-nothing program and, after a couple tries, got the AVR Dragon to re-program the Flash. There is another solution I found on LadyAda's wiki that uses AVRDUDE to erase the part, but I didn't have to resort to that.

Eagle CAD versions

2010-04-06T16:40:00.000-07:00

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.

Here are the basic versions of EagleCAD. Most hobbiests go for the Freeware version. You can do a lot in one schematic page, and a 2-layer 100x80mm board.

Version	Schem pages	PCB Layers	PCB Size (mm)	Price
Freeware	1	2	100x80	Free for not-for-profit use
Light	1	2	100x80	$49
Freemium	4	4	100x80	60-day Free trial
Standard	99	6	160x100	$747 ($498 w/o autorouter)
Standard Not-for-Profit	99	6	160x100	$125

The Freemium would be nice to have, with the extra room on four schematic pages. 4 layer boards are more expensive than two, but useful if you are doing high speed or dense board design. With four pages to play on, the 100x80 board space might become an issue.

The trouble is that once your 60 day free trial is over, you have to either drop to the Freeware/Light version, or move up to the Standard version. There is no non-free, unlimited use version of the Freemium version.

But, for complex hobbiest projects, there is an option of getting the Standard version for $125 if you promise to use it only for "not for profit" use.

If there was a not-for-profit Freemium version for $49, I'd buy it.

Throwing in the towel

2010-03-24T01:07:00.000-07:00

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

It was all my own fault. I threw away a month waiting to see if I'd made past the first selection to the top 100 entries.

I wasted a second month on getting reflow soldering working. In a couple evenings, I could have hand soldered enough boards to get debug started, then worked on the reflow in parallel.

So I had only three weeks left for debug, but could have had eleven weeks. Ouch, my bad. Terrible planning.

It turns out, I also don't do my best design and debug work at 1am. Debug was going way slower than it should have.

Here is what I debugged in one of my typical evenings, between 10pm and 2am:

Reset AT42QT2160 incorrectly
Forgot to turn on LCD backlight regulator
Cold solder joint on connector pin for backlight power

The first problem was that I misread the datasheet back when I coded the initialization function, and for over an hour of debug assumed my understanding was right, just coded wrong. I mean, how hard is it to send a reset command? Pretty easy on the QT2160 as it turns out. I just tried to make it hard.

The second and third problems were two bugs with the same symptom - the LCD backlight wouldn't come on. So I went round and round with that for a while before I realized there were two bugs I was dealing with.

The good news is I don't need to survive on 3-5 hours of sleep any more. I won't give up on this project, but I'm not going to kill myself working late at night any more. Its just not productive use of my time because I'm so inefficient that late at night.

Hand soldering QFN

2010-03-13T12:47:00.000-08:00

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.

Since I can't solder the paddle under the package with my soldering iron, I applied solder to the paddle and to the PCB pad, hoping for some mechanical contact would be "good". This caused the part to "high center", and it rocked back and forth as I tried to align the part with the solder pads. So I wicked it down as much as I could.

In the future, I might try putting a via right in the middle of the paddle and use it to conduct heat up to the paddle from below for hand soldering. Watch this Schmartboard video for this technique in action.

Anyway, my next problem was aligning the pads. In reflow soldering, the viscosity of the molten solder will pull the part into nice alignment. It's fun to watch the parts suddenly shift when the solder paste melts, and a great way to tell you've reached reflow temperature. This works really well up to misalignment of 50% of the pad spacing - at that point, the part might move onto the wrong pads.

Hand soldering, getting that first pin soldered with good alignment all around the package is just trial and error. The act of touching the pad with my iron tends to pull the part to the iron. So you need to hold the part down with pressure from your tweezers or something. I saw an idea on Hackaday on using pliers and a small screwdriver with a rubber band to create a tool to hold down ICs. It works pretty good! But rotation of the part vexed me last night. Eventually, I got misalignment down to 1/4 to 1/2 of the pad width. Yes, I was satisfied with 1/2 - it was very frustrating.

Next, I applied flux paste all around the part and "drag soldered" the pins. Look on Youtube for videos on drag soldering. I use .015 diameter solder and apply a fair amount of solder.

I got quite a few shorts. One side had just one short, but the worst side had all pins shorted. I can see shorts using a simple magnifying glass - its pretty obvious when there is the shiny glint of solder from one pin to the next. You can and should use an ohm meter to verify adjacent pins are not shorted. What is very hard to do is verifying the pads are soldered down. So I used plenty of solder.

Removing a short, if there isn't too much solder, can be done just by touching the solder bridge and dragging some solder away with the iron. In cases with too much solder for that to work, I used solderwick to pull off excess solder.

I started around the package, removing visible shorts and verifying with the ohm meter they were clear. It went pretty well for the first two sides.

Unfortunately, on the third side, the ohm meter "lied" to me. I was trying to clear this one short, and no matter how much solder I removed, the pins were shorted. Eventually, I gave up and went to bed (4am).

The next morning, with a clearer head, I realized that the two pins I was working on were VCC and GND. These pins were shorted on the fourth side of the package! So I had to re-apply a bit of solder to those pins to ensure they were soldered. That meant getting the flux back out and dragging that side of the part. Yay, more shorts to clear.

I fairly quickly removed those shorts and the ones on the last side of the package. Double checked every adjacent pin for shorts. Everything is clear. What I don't know is if I damaged the part while I fussed with the VCC GND pins last night. I should find out fairly quickly when I begin software debug. Unless the part is "sort of working" and just flakey. That takes a while to figure out.

Sorry for the lack of photos, but all you'd see is a little tiny IC on a PCB under a 3rd hand magnifier. I need to get a macro lens for my camera.

Hand soldering SMT components

2010-03-02T00:37:00.000-08:00

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!

I bought a Aoyue 937+ digital soldering station for about $50 through Amazon. You can buy a "fire-starter" soldering iron without temperature control for as little as $10. But even an "expensive" soldering iron without temperature control makes SMT soldering more difficult, your tips don't last as long, and you are at greater risk of heat damaging parts and your board. Excessive heat can lift traces and pads. If you need to save money, you can buy the Aoyue 936 analog controlled soldering station for $40.

For SMT, I use a roll of .015" (very thin) Sn63/Pb37 no-clean solder. Not lead-free. Lead-free takes at least twice the skill. That's for pro's or "pro-sumers", not us hackers.

I use a magnifying glass on a third-hand base to see my work. I keep both eyes open so I can use depth of field. I don't use the alligator clips, I just use the third hand to position the magnifier where I need it. The board is held in position with scrap PCB's taped around it. I use a gooseneck lamp or a strong LED flashlight to illuminate my work. A ring light with a center magnifier would probably work better, but I don't have one (yet). Decent microscopes are too expensive and don't allow me enough freedom in choosing my angle of view. If you can afford one, you are a pro-sumer and should be working on your lead-free skills.

No prep on the pad, just drop the part on and position it with your very-fine tipped tweezers. Note that one side of my supposedly "anti-magnetic" tweezers have already become slightly magnetized. But titanium tweezers are over $20, "anti-magnetic" stainless are just $5, so I just deal with it. Solder wire doesn't magnetize, so I use it to hold down 0603 and 0402 parts while I pull away my tweezers.

Make sure your soldering iron tip is clean and well tinned, but no excess solder. A very tiny bit of excess solder on the tip will help heat conduction, but it also too often grabs the part with the surface tension of the solder to cause it to tomb-stone. That's where the part pops up to a vertical position, like a tomb-stone sticking out of your PCB.

Touch one side of pad and end of part with the tip. Count to 2 or 3, touch the pad with solder wire. Exhale (to blow fumes away instead of inhaling them). Solder should flow across pad and up the lead of the part. 0603 parts will tombstone about 25% of the time, 0402 about 75% (less with practice). When it happens, use the end of your solder wire to quickly push the part back down. If part has rotated, maybe 10% of the time, push it straight with solder wire. Pull iron away. Try not to dwell overlong positioning the part with the iron heating the joint, as you can damage the part and/or the pad. Of course, you have to remember to remove the solder wire before the iron.

On other side of the part, touch iron to pad and lead, count to 2 or 3, touch pad with solder, pull solder away and pull iron away almost simultaneously.

Admire handy-work. Soderwick (tm) is your friend at this stage, but very rarely needed, about 5% or less of my joints need rework thanks to using thin, lead-based solder and my temperature controlled iron with good tip. Be generous with oderwick. Once used, cut the end away and always use solder-free Soderwick.

I have found I can hald-solder SOT-3 parts. These have 5 leads in about the size of a 0603 component. I was surprised that I could align the parts and solder them with basically the above technique. Even with my magnifier, it is very hard to see the leads to tell if they are aligned. For hand soldering, using larger than recommended pad lengths helps.

I do not have a very good technique for QFN (leadless) IC's. Basically, I align the part carefully and try to hand solder one corner pin without moving the part. Then I drag solder the sides (starting on opposite corner from first pin) resulting in many shorts. I clean those up with Soderwick. Lay it snug along one side of the part, and drag the soldering iron across the Soderwick. It easily pulls all the excess solder out, leaving just enough to make joints. I ohm out all adjacent pins to verify no shorts.

I have one QFN part that requires a solder pad under the body to be connected. No choice there but to use a SMT reflow hotplate or toaster oven.

Always ohm out power to ground when you are finished, before applying power.

LED's are about the most easily damaged SMT part. My digital meter has a diode check function. I apply that through the load resistor to check for LED operation (and correct orientation).

How to waste 2 weeks

2010-03-02T00:00:00.000-08:00

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.)

I spent a few days choosing the devices to use, ordering parts, and waiting for everything to arrive.

My materials:

a Reflow 3.0 PID controller from The Silicon Horizon, for $65. This is a PIC-based PID controller with some handy Windows utilities to drive it. No time to build my own - I'm on a schedule here, right?
a type-F thermocouple from TSH, $16.
a Black and Decker Infrawave toaster oven (recommended by TSH) for $70 from Amazon. 1500W is reported to be sufficient for lead-free work. Also, I know that some industrial reflow soldering systems run on infrared, so I figured it would be a good choice.
35amp Omron SSR from Digikey for $18. (recommended by TSH). 1500W/110V is less than 15 amps, but you want to be overdesigned here so the SSR doesn't overheat.
Misc 120VAC parts from HomeDepot and Surplus Gizmos (an electronics surplus store just a short drive away).

Note that this is a fairly high multiple in cost over the Instructable's hotplate method.

Not wanting to risk electrocution or a fire, I put the AC stuff all into an electrical box. I chose a metal weatherproof box so the box could act as a heat sink for the SSR. It turns out that the SSR runs pretty cool in this application. I don't think the metal box was actually necessary. The spot where the SSR is bolted to the box with a bit of thermal paste barely warms up under full load.

I added a red indicator lamp so I can see when power is flowing to the outlet through the SSR. And an on/off switch so I can easily kill power whenever I want. I leave the switch off when the oven is not in use, for safety.

The Infrawave oven's controller needs to be bypassed so the SSR has complete control of the heating elements. I didn't follow The Silicon Horizon's instructions. They say you need to defeat the door switch, but the door switch just feeds into the toaster's controller. It is not directly interrupting AC, so after bypassing the controller, it has no effect.

Also, they suggest soldering bridge wires around the SSR's on the toaster's controller. The AC wires coming to the oven and going out to the heating elements are all common 1/4" spade connectors. I used three spade receptacles, a wire nut, and a small amount of wire to completely bypass the controller. The unused controller no longer receives power using my method. Thos connectors are just laying on the green PCB, they are not connected to it.

Right after I took this picture (taken with the toaster upside down), I removed the brown relay board shown at the top of photo completely. There wasn't room for my wires with that board in there. But it no longer does anything at all, so why store it in there?

So here it is, all assembled. Note that I'm not going to give detailed instructions on what I did. AC is dangerous. If you don't know enough to do this without detailed instructions, IMO you shouldn't be mucking around with AC.

Next, I experimented with some scrap boards and no-lead solder paste.

Some notes on the Reflow 3.0 controller. It uses a USB connection to the host PC running Windows. As you change parameters, it seems to reset the controller and its USB connection a lot. I'm thinking that changing a profile or PID parameter shouldn't require a complete reset. Probably some optimization can be done there. The source code for the controller is reportedly available, but I don't have time to look at it right now.

Starting a reflow is hit or miss. Fairly often, the Windows app will report that the reflow operation has started, but nothing happens. Just hit stop reflow in the app's Reflow menu. Check that power is on to the Reflow 3.0 and in the SSR controller box, and then re-start the operation. It seems to always start the second time.

The instructions for the Reflow 3.0 say to start with 1-1-1 for PID parameters. The Infrawave tends to work well at 40-0-120. That's a long way from 1-1-1. Other ovens will work best with different PID parameters, but don't expect to be using anything close to 1-1-1. I wasted an evening finding all that out. The guy that runs The Silicon Horizon responded to my email first thing the next morning and set me straight.

The Infrawave, for all its 1500W of power, struggles to hit temperatures over 220 C. It can take over 60 seconds to get from 180 C to 235 C. The no-lead solder paste I was using was not reflowing at 235 C.

You can see in this microscope photo that the flux has been activated and is mostly gone, but the solder doesn't reflow - it just forms balls. When the solder reflows properly, surface tension should pull it onto the pads and leads (see below). Instead, it has just puddled, flowing out from the pad on the 0603 cap on the left, and shorting all the pins on the QFN (lead-less) package on the right.

I've been told this is a symptom of too low a soldering temperature. I need to get the temperature to 240-250 C for several tens of seconds to properly reflow the no-lead paste. Eventually, I will try that, but it looks like doing so will exceed the recommended time at solder temperatures for most components. From past experience, I know this is especially a problem for my SMT LEDs.

For now, I've run out of time, so I have resorted to hand-soldering my boards. I've also got some leaded paste on order from Macetech. It should reflow nicely at around 220 C. That should easily work with my system as-is for doing additional boards. I have over 10 boards I need to solder after debugging the first board of each type - way too much for me to hand solder.

Below is what the joints should look like, under the same magnification as the picture above. You can see how surface tension has caused the solder to wick onto the metal pads and leads.

Here is the Fail Whale, visiting my attempt to do lead-free soldering in a toaster oven.

In the Final 10

2010-02-17T00:12:00.000-08:00

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.

As you can see, the quality is good.

One surprise was that the vendor printed all of the silkscreen text, even the very tiny component values I had left in the data but assumed the vendor would filter and not print. It doesn't hurt anything, as the silkscreen isn't over sold pads, but having text smaller than the size of a 0603 part doesn't help me, either. Moral: put what you want in the gerber outputs, nothing more or less.

My parts order arrived a couple days later. I tried to time the parts to arrive with the boards, but the boards came faster than I thought.

At this point, I am hung up waiting for a part for my toaster oven based SMT soldering system. The part I need is in the mail and should arrive this week. But when it arrives, I need to calibrate my system. I grabbed some scrap SMT PCB's from Surplus Gizmos to run tests.

SMT soldering is easier than many people think, but getting consistent quality of results is dependent on having control of your technique. I'm using a infrared oven from Black and Decker. It's 1500W will easily melt lead-free solder paste. The oven will be controlled by PID code running on a micro-controller with a solid-state-relay controlling the heating elements and feedback from a K-type thermal probe. Standard, well-proven techniques. This gives me accurate temperature profiles and avoids thermal shock to the components.

Still, I plan to do the soldering out in the garage. No use poisoning the house with flux vapors or stinking things up should a board somehow get over-heated. Downside is that it is still winter here. Typical high temperatures during the day are in the low 50s. I am hoping the high power of the oven coupled with PID control will be able to handle whatever the ambient temperature happens to be.

While I was waiting for the boards and parts, I did more simulations on VMLAB. I believe I've got the UI 100% tested. I can't be too sure about the I2C interface, but it seems to be doing what I think it should. The provided I2C simulation component helped me out.

There is no SPI simulation component available. I looked into building my own, but the documentation and examples are lacking for someone with limited time budget. If the I2C component source was available, I think I could tweak it, but it isn't. I can see the SPI signals wiggling, but I can't easily control what data gets read, so I had to do some manual poking of values into memory. That area of the code is not well tested.

An SPI write followed by a read.

PB3=MOSI, PB4=MISO, PB5=SCK, PB0=Enable

An odd thing happened with the clocking. The MCU is set up to use its internal oscillator, and a 32KHz crystal on the external oscillator pins. The MCU model doesn't seem to handle this quite right. But in a couple (out of dozens) simulation runs, the timer interrupt routine started getting executed regularly. So the timer code got checked out, but I'm not really sure what is going on there. I hope it is the model, and not some crazy bug in my code.

I've written some stripped down test code to debug each module individually. I plan to start with the timer code. Either an LED will be blinking with a 1 second interval, or I'm afraid I'll be spending a lot of time debugging oscillator and timer initialization code. The good news is that the LCD routines are debugged and look solid. printf will be my friend once again.

Lantern modification

2010-02-02T21:58:00.000-08:00

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

This lantern uses 4 D cell batteries and a CFL bulb. 4D cells last a long time, and the CFL put out reasonable light for camping.

But for no reason, it wasn't dropped or left in the rain, it stopped working. I checked around, and there are no replacement parts for this lantern. A lot of people online are complaining that their GE lanterns have also stopped working.

This is probably a symptom of the "capacitor plague". As long as I needed to fix the lantern, instead of mucking around changing capacitors, I figured I'd make the lantern "better". I decided to replace the 4 watt CFL with a 3 watt LED and get even more energy efficiency out of the lantern.

I ordered a Cree LED on a star heatsink and a regulator from DealExtreme.

The important thing to know is Power = Volts * Amps. A 3 watt LED with a rated forward voltage of 3.7 volts needs 3W / 3.7V = .81A, or 800mA of current. The LED regulators are designed to put out a specific current, not a voltage. So I bought a regulator rated at 800mA. Matched with this LED, the regulator will adjust the voltage to be around 3.7 volts to get the delivered current to be 800mA.

A 3 watt LED can get mighty hot, and I didn't want my lantern to fail early due to overheating the LED. So I found a little 1-inch square heatsink I had laying around and a package of thermal paste.

Then I had to figure a way to secure the LED to the heatsink (thermal paste is NOT glue) in a way that would survive car trips and the banging around at camp. I came up with a bent paperclip design that is sort of based on the bails you get on CPU heatsinks. I bent it into a "W" shape as you see in the picture, then twisted the arms to the sides so I could get the flat part up into the fingers of the heatsink.

Then I soldered the power supply to the Cree. Red is positive, Black is negative. Solder to any of the appropriately labeled pads on the top of the star. The bottom of the star is electrically isolated. It just conducts heat, so don't try soldering to it. Also, it is a heatsink, so you probably won't be successful soldering to the bottom anyway. In retrospect, I probably shouldn't have soldered the power supply to the star at this point.

I also applied way too much paste to the bottom of the star. A very tiny bit goes a long way. You just need a very thin film of thermal paste to ensure good thermal conduction between the star and the heatsink. Then I put the star on the heatsink and twisted my paperclip bail back into position, making sure I wasn't shorting out power.

As you can see, the bail is pressing down pretty hard on the star, squeezing all that excess paste out. You should use just a tiny drop.

The bottom of the lantern unscrews, for replacing the batteries. To get to the CFL bulb, unscrew two screws in deeply recessed slots revealed by removing the bottom. To separate the glass from the base, you need to unscrew four nuts that are sealed with Locktite.

I cut the battery lead right at the CFL bulb assembly and removed it. Then I replaced the CFL assembly with a little bit of plastic to support the heatsink and LED at the bottom of the lantern's glass.

I didn't come up with a clever method of mounting the heatsink. I just used my hot glue gun. It turns out, hot glue doesn't stick all that well to flat plastic nor heatsinks, so it took a couple applications to get it mounted. This is a weak point in my design. There must be a better way. The 1 inch heat sink was slightly longer on the diagonal than the hole in the lantern, so I had to file out a couple notches. Hopefully, this adds some stability to the heatsink.

To assemble this, I needed to solder the power supply to the battery wires with the case off, yet position the heatsink on the platform after putting the battery holder back into the case. This isn't what I did, but what I would do if I had to do it again:

Solder the battery leads to the power supply.
Use a spot of hot glue to stick the power supply down to the top of the battery holder.
Position the power supply output leads so they are sticking above the platform where the hole in the base will be.
Lower the case over the battery holder, threading the power leads through the hole.
Solder the power leads to the star. Red to +, black to -.
Attach the star to the heat sink with the paper-clip bail.
Hot glue the power supply to the platform. Use plenty of glue.

In the end, it should look like this:

A 3 watt LED is piercingly bright. You do not want to look into the LED when it is on. Mounted like this, most of that light gets lost in the top of the lantern, yet you can see the LED directly, which is hard on your eyes. So I added two features to the lantern: a plastic ball as a diffuser around the LED to protect my eyes, and a reflector at the top of the lantern to reflect more of the light out in a useful direction.

It turns out, a ping-pong-sized ball works nicely for the diffuser. It diffuses the light coming directly from the LED to your eye and it fits the lamp's reflector on the base just right. I cut holes on opposite sides of the ball to get more light up to the reflector. Then I used hot glue to attach it to the reflecting ring from the lantern.

Forgot to take a picture of the ball with the holes cut. I made them about an inch in diameter.

For the reflector, to reflect the light 90 degrees, I need a 45 degree surface. I know the diameter of the top of the lamp is 3.5 inches. Therefore, the length of the side of the cone then needs to be 3.5 * cos 45 = 2.47 inches.

I drew a circle of radius 2.5 inches on a bit of cereal box cardboard. Then I made a cut from the edge to the center. I covered one side with aluminum foil and taped it into place. Forming it into a tight cone that would fit through the opening in the bottom of the glass housing, I pushed it to the top and let go. The cardboard tried to flatten out, which resulted in a friction fit with a cone about the dimensions I wanted. Fortunately, the glass diameter is largest at the top, so it all hangs in place pretty securely.

Then I reassembled the lamp:

Turning it on, I get about the same light intensity that the fluorescent light produced, but thanks to the efficiency of LED technology, even better battery life.

Phase 2 is complete

2010-01-23T23:51:00.000-08:00

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.

I used the extra time to complete the Chibi RF driver support in my sensor design, and got the code to compile error free. I grabbed a few more screen shots of the simulation, and added in PDF's of the schematics and board designs. Then I had to go back and edit the text of my submission to reflect these changes.

Instead of the partially baked submission I was preparing on Friday, I've now got what I feel is a completely baked entry, and its only Saturday evening.

When I started to work on the BOM, I expected to find some part shortages, based on what I'd been hearing on the web. I only found one out of stock part, out of the 60+ unique parts in my design.

But I did notice some "sub optimal" decisions. I had used through hole mount LEDs when I could be using SMT. Another example is that I noticed the temperature sensor I had chosen has a minimum operating voltage of 2.3volts. Not good when you are running a device on two AAA batteries. I found a slightly more expensive National part that is good down to half that.

The backlight for the LCD display I am using draws 60mA typical. The 1/10 watt 0603 SMT resistor I had put on the board layout wouldn't deal with that well. I need to change the board to use a 1206 1/3 watt. There are several other changes I've decided to make. Fortunately, most aren't functional problems, rather they are just better decisions, like SMT instead of THP LEDs.

The net is that every time you look at a design a different way, you find things that need to be changed or improved. I found changes I needed to make while I was doing place and route. I found changes when I sketched out how the boards would be connected with each other and the LCD and radio. I found changes when I was writing the code. And I found changes when I was costing the BOM and checking availability. I'm hoping I don't see too many more changes when I go back to make the updates to the hardware I've already decided to make while working on the software and BOM.

In a normal work environment, I usually don't write the code, and I don't cost the BOM. Other specialists do those things. But then I miss out on those different perspectives and the detailed re-examination of the design those efforts entail.

Since I had the time, I tried again to find an SPI user component for the VMLAB simulator. It appears that none exists. Since there is an I2C simulation component, you would think that SPI would be easy. I will have to make one myself if I hope to do any serious simulation work. Yet another thing I usually get to farm out to a specialist that I will have to do myself.

Code complete

2010-01-20T12:03:00.000-08:00

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

2010-01-18T02:09:00.000-08:00

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.

On Monday and Tuesday, I basically wasted the both days trying to decide which sub-optimal radio I would be forced to use. I had gone so far as to start writing code for a USART-based interface to 2.4GHz Zigbee modules. I was talking myself into believing the logic that they could not ding me for using their favorite technology with 3 Atmel parts in every radio, despite the total overkill and expense.

On Wednesday, I discovered that "Akiba" at freaklabs.org had designed a radio board using the AT86RF212 RF transceiver chip. Even better, he's written a basic driver for it that does exactly what I need done. 3 application level functions: init, send, receive. Under the covers, of course, it is much more complex than that, but that's what my code sees.

Akiba's "simple open source wireless software stack" is dubbed "chibi". He is also working on an open source Zigbee project. AFAIK, he has made the only open source radio boards with open source software drivers in existence. That's quite an accomplishment by one guy.

Friday and Saturday I was out of town. So today I integrated the chibi driver with my software. Then I struggled for literally hours with my makefile. I hate make. We just never have gotten along. I think it knows I'm a hardware guy, so it rebels. I finally called my software buddy and he debugged it over the phone.

So I've now got the entire embedded software package for my main controller compiling without errors! I may not have much time for simulation, but compile-clean is all I've really hoped to achieve before the deadline.

Now I need to write the sensor code. I'm hoping I can have it done by Tuesday night so I have some time to do cost and power analysis, do a writeup, and email the whole lot on Friday. Even with that amazing stroke of luck on the radio and the schedule extension, it's going to be tight.

Good progress

2010-01-11T21:33:00.000-08:00

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.

Another thing that got in my way was the editor that comes with WinAVR, Programmers Notepad, chose Lucida Console for its font. I find it difficult to spot capitalization errors in that font. To compound things, PN uses font styles to do syntax highlighting, so I had to change several styles to make it more usable. It is nice be able to jump right to the syntax error. But I prefer Notepad++.

Programmers Notepad (with font changes)

I got the code to compile without errors a bit quicker than I had planned, so I jumped right into simulation in VMLAB. This is really handy for simulation. There are lots of very handy components to choose from. I hooked up a virtual LCD configured for 4x20 characters, an I2C simulation model, a couple LEDs and some resistors. No programming necessary!

VMLAB simulator

I quickly discovered a mistake deep inside the I2C handshake I'd inherited from that Atmel App note. I fixed that, and suddenly I've got the LCD display working and conversations happening on the I2C. I still need to figure out why my timer isn't issuing interrupts.

So today I'm feeling really upbeat about making the January 18th deadline. I'll even have simulation results! If I can get those interrupts running and the system going to sleep mode, I'll have exceeded my expectations. Maybe I'll have time to put the complex UI back in. jk!

One reason I jumped to compiling is that I was getting worried I'd outgrown the ATmega328. But that should not be a problem. The image is only 7K of flash so far. The RF functions shouldn't be over 2K. I should double check to see if I can move to the *168 part, although it is only a few cents cheaper.

Speaking of parts, I was watching macetech live streaming their SMT assembly process last night. They are building thirty LED controller boards. And we're not talking an Arduino and a couple through hole connectors. This board is about 4x4 inches, covered with buffer ICs and 603 discretes. And when they finish that task, they have to build some large number of LED boards to go with them. Quite a job using tweezers and a toaster oven.

They pointed out the electronics shortage is really affecting the ability to build stuff. They had to redesign their board a couple times due to the lack of available parts. Just what I need, a part shortage.

p.s. If you click on the PN image, you should quickly see why my system isn't going to sleep...

Light at the end of the tunnel

2010-01-10T02:04:00.000-08:00

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

I reused code for a 4-bit LCD display interface from winavr.scienceprog.com/, which required only minor adjustments to retarget it to my system, but ended up taking half of an evening. It was nicely modular code, with all the LCD commands implemented, and a 4-bit handshake, but I found a few bugs.

The handshake was slow. _delay_ms(1) on every handshake edge when _delay_us(1) would work. Painting a 4x20 was going to take 1/3 of a second. Now it should take more like 5ms to paint the whole screen.
The code was not checking the busy flag nor allowing time for commands to complete. I think the 1ms handshake delays were a kludge that happened to fix this.
The code was writing 8 bits to an AVR port, even though the code is written for driving a 4-bit LCD interface. I'm using those other bits for other functions!

Never trust code you download.

For the Atmel Qtouch controller code, I had planned to "reuse" code from an Atmel app note. The .pdf containing the code was copy protected, so I couldn't copy / paste the code, which covered 6 pages. Too much to hand copy. A note to Atmel support got me plain text in less than a day.

Once I really sat down to study the code, I realized it was a useful example of controlling a Qtouch interface, but it made no attempt to be a driver library. I had to create functions to implement all of the driver features I need. I took some shortcuts so it isn't a reusable library, but it is a lot closer than what I started with. The I2C code contained in the app note I was able to use nearly unchanged. That's a big help, although there are other I2C libraries out there. I hope I don't get burned by bugs in that code. I don't relish debugging a I2C handshake.

The one major block I need to work on is the RF interface. Atmel Smart RF devices use SPI, so I can use library code for the interface. If I go with a complete radio, such as Zigbee, it will be UART library code. Either way, coding shouldn't take too long. Debug may be another matter.

Only eight days left. Still lots to do. A "day" is about 4 hours that I can steal from my sleep schedule. My estimate is:

Choose RF solution. 1/2 day
Write interface to RF. 1 day
Write sensor module code. This will be simple code, under 1 page. 1 day
Get code compilable without errors. 2 days
Analyze system power and cost. 1 day
Package it up and send it in. 1/2 day

Which leaves me 1 day of slack in the schedule. I'll take a look at my RF options tomorrow.

Time just keeps ticking away

2010-01-08T02:32:00.000-08:00

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.

With only ten days left now, it looks like I will have to start making some more feature cuts. I just spent 3 hours writing code to implement what I had originally proposed. Its turning into quite a bit of code just for the user interface. I need to allow time to at least get the code to compile, otherwise my project faces rejection at the next step of the contest just because the code won't compile. I certainly won't have done any "simulation". So I'm considering a much stripped down version of the UI. I have an idea that is 1/8th the complexity I had proposed. That should save a lot of time. Time I need in order to finish in TEN DAYS. Yikes.

So, like most engineering projects, time constraints are limiting the features. Nothing new there. Every product on the shelves has had that happen to it.

The basic functionality of the system remains intact, it just won't have usability features I had planned for - and documented in the proposal. The user will have to spend more time fiddling with the interface. Consumers pretty much demand "set and forget". This system will not be consumer ready. But I am determined to make it contest ready...

Not an Arduino

2010-01-04T19:07:00.000-08:00

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.

I've got some protoboard shields that I can use with actual Arduino boards in the early part of system debug, and then shift to my board when it arrives. That way, I can have debuggged (I hope) software running on my un-debugged hardware.

I've been struggling with non-Arduino libraries, trying to find a usable I2C driver. It was looking like a lot of work to get something usable for my project, when a fortuitous Google search found an Atmel app note with code for connecting an AVR processor to the Atmel touch controller. I think I just saved a few days in my software schedule.

Which is good, because I'm running short on days.

Universal PCB design rules

2010-01-03T04:38:00.000-08:00

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.

I think the list is pretty well covered on the Adafruit cost calculator page, along with links there.

Almost all of them will do 4 layer boards. Of course, I can't design 4 layers on the free version of Eagle CAD.

Olimex has more restrictive rules than most. I'm noting where their rules are tighter in the list below.

1 oz copper on 0.062-inch FR4 is universal. No surprise. Only a couple in the list will do heavier copper.

7/7 mil minimum track width and spacing except Olimex at 10. I'm sticking with 10/10 except where SMT parts make it impossible. The boards are more likely to not have opens and shorts at those dimensions.

Minimum drill size is all over the place. 20 mil covers all except Olimex at 24. I happen to have my vias set at 24 mils.

Minimum annular ring around holes is often not specified. A couple require 5 mil, Olimex 8. I'm going with 10 mil (44 mil vias) for reliability and improved yields.

Max drill size is 246 mil or larger for most, but AP Circuits is 125 and Olimex is 195. Several of them won't do non-plated holes, and some will only do them with an extra charge.

Only Olimex specified copper and holes to board edge, and they used 20 mil. I have one board where I put the edges of some traces at 20 mil from the board edge, and it felt like I was putting them right on top of the edge of the board.. I like to leave 50 mil to traces and 100 mil to the centers of holes. If I am making boards at home, I know I will need that.

Minimum board size of 1.25"x1.25" covers them all. Many will go down to 0.5"x0.5". My smallest board is 1.0x0.9, eliminating Gold Phoenix (by 0.1 inch), PCB FAB Express, and Advanced Circuits.

Maximum board size is at least 10"x10" for all but Olimex (12.59x"x7.87" max) and Advanced Circuits "$33 each" deal at 60 sq in. Not an issue for me.

Overall, I could shave a few mils off of my boards with smaller vias, and a few more mils with smaller traces, but I'd pay a price in getting more PCBs with manufacturing defects.

It does get easier, honest

2009-12-31T02:42:00.000-08:00

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.

I had time today to go back to the first board and add a feature, polish up the silk screen layer, and fix some minor DRC errors. I think its important to get the DRC clean. Otherwise, there is a tendency to pass over real problems the DRC is trying to tell you about, hidden in the "errors" that aren't really problems. If the DRC is clean, then you at least know there are no problems that the computer can catch. I hate finding a bug in a fabricated and assembled board only to discover that the problem was flagged in a DRC error that I overlooked back during the design capture stage.

Of course, this was the easiest of the boards so far. Only 1x1 inch. I got a little carried away and did the design without any signal routes on the bottom layer. There are four vias for routing power.

There are still two more boards to do. One is even easier than this board. It will be only one layer, roughly 3x6 inches. I just have to figure out how to capture the design of a board that won't fit in the Eagle CAD free version's restriction of 4x3 inches.

The other board is the radio, which is the hardest board to design in this project. But, my plan is to do the other boards and most of the software, then see if I have time to design a radio. If not, then I won't have to worry about it, I'll just buy Atmel-based Zigbee modules. If I do have time, then at least I should be competent at running Eagle CAD before tackling that job.

I've used up 13 of 30 days doing 3/5ths of the hardware design and I haven't started on the software. While some of those were holidays that I didn't get anything done, some were very long days. It's looking likely that I'll be buying those radios.

Doing it wrong is progress

2009-12-28T18:38:00.000-08:00

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.

There are a fair number of variables to consider. A few of the more important ones:

Power. Where does it come in, what voltages and currents are needed, how does it get distributed.
Connectivity. Do the boards stack, or connected via a cable. What side of the board should the connector be on. What signals are on each connector.
Compatibility. Touch panel and RF both require special care in locating them in the system.
Pin allocation. AVR controllers have a lot of special pin functions. What is the best use of the pins to get the functions I need.

I juggled all that and more, and thought by the end of the day that I'd gotten it right. But the next day, as I started to implement one of the boar designs, I realized I'd made two mistakes. Not merely sub-optimal choices, but flat out broken.

In working on those errors, some other choices came tumbling down, no longer the best fit. My core problem is that I am trying to design too optimally, too close to the edge. For example, I needed to put one more function in an ATmega that was out of pins. If I had chosen an ATxmega device, I'd have plenty of pins to work with.

The good news is that having done the system design once, the second iteration was a lot easier, and it is now a better, "rev 2", design. But I worry that I may have missed something else, and I don't have time to juggle the system around repeatedly.

Re-learning Eagle CAD

2009-12-26T16:00:00.000-08:00

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.

The way to operate on groups always confuses me at first. But it is actually fairly straight forward, if not intuitive.

1. Select (that is click on) the operation you want to do. Move, delete, copy are the common ones I use on groups.

2. Select the group operation - the dotted box icon.

3. Drag select the group of items you want to operate on. An object must be completely contained within the box to be selected as part of the group.

4. Right click any highlighted object in the group. At the bottom of the pop-up menu, there will be a menu item for the group operation you selected before you activated the group command.

Like I said, straight forward but not intuitive.One would expect the menu to be group commands if you have a group selected. But that is not how it works.

I am doing a very small SMT board design based on the Atmel AT42QT2160 touch controller. I chose a board outline that was a little tight. Being "a little tight" on space doubled the amount of time it took me to do the layout. And being out of practice with Eagle CAD probably doubled the time again. So it took me several hours to do a small, fairly simple board.

But now I'm mostly back up to speed on the interface and re-memorizing the hotkeys, and I will try not to make the mistake of constraining the next board to just barely big enough for the next three boards I need to do for the contest.

It's not that my design is so complex it needs four boards, but free Eagle CAD is limited to small boards, and I wanted to modularize the design for re-use. Also, if one of the boards needs a major redesign, it should be easier and cheaper to revise one smaller board than one big monolithic design.

One note on the Atmel touch controller. The pins are arranged fairly nicely, except I have no idea why they thought it would be a good idea to put X6 and X7 on the opposite side of the chip from the other six sense lines. That really isn't helpful, and complicated the layout quite a bit. I'm considering ripping up those routes and using just 6 sense lines, which would give me 6 buttons and a slider. Who needs 16 buttons anyway?

Things that eat up time

2009-12-25T11:31:00.000-08:00

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

2009-12-21T14:02:00.000-08:00

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

2009-12-20T12:56:00.000-08:00

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.

My design centers around wireless sensors, so I figured in my proposal that I'd use Atmel Smart RF parts. The 433MHz ATA5428 transceivers looked attractive. Very cheap, low power, Atmel AVR friendly, really good range, and my sensors won't need much throughput so 10-20Kbps is fine. I thought that perhaps the result might be a really cheap radio design for hackers that don't need all the features of Xbee or Zigbee or WiFi. I was hoping the cost could be under $10 DIY for a radio that could send small bits of information like temperature or on/off commands. Like the JeeNode, but with an Atmel radio.

But last night, I started looking for design information on those parts, maybe some demo boards I could use or at least replicate the RF section, and some example code. After a couple hours on the web, I believe that Atmel has discontinued that particular part, but left the information about it on their web site.

Options

It looks like Atmel has bet heavily on Zigbee. Lots of good info, modules, design data on 2.4GHz and 915MHz radios supporting Zigbee or 6LoWPAN.

Zigbee is way more complex than I need. In addition to the transceiver chip, it takes a fairly robust AVR with at least 50K Flash dedicated to Zigbee protocol. While that would boost my Atmel chip count, I would have problems with cost and to a lesser extent power.

6LoWPAN, IP over wireless, is interesting for building an "Internet of things", but that isn't my goal. Lower processing requirements than Zibgee, and it would be cool to use IP stacks. I'm concerned about power and maturity.

If the brand new, single-chip RF plus AVR ATmega128RFA1 part was available, I might go for that. But then again, I've only got 30 days, not a good time to be playing with brand new technology and a device I can't even order yet.

The Raven boards look interesting. A "scaled back" 802.15.4 MAC and Zigbee. No mesh, no security. I could live with that. $99 gets me two boards plus a USB stick. That would really help accelerate my design if I could go with a pre-packaged setup like that. But on closer examination, it has two processors on it. ATmega3290P and ATmega1284P. One of those is dedicated to talking to the radio and holds the MAC and Zigbee protocols. It talks serially to the other uC which is where the application would reside. All I need to do is read a sensor once in a while and blink an LED. Overkill.

There is some code called "TAT", only 2KB, that gives low-level access to the RF transceiver. That seems more in line with what I need. But it does mean I'd have to create a very simple MAC to send and receive packets on top of it.

I might be able to take the RF12 driver code from JeeNode and adapt it to work with the AT85RF212, but I'll have to spend some time looking at the code and the chip spec to work that out. Having the TAT code in front of me will help.

First day's results

I've decided that I'd like to use the AT86RF212 radio. It uses 915MHz, so the range would be 2X the 2.4GHz Smart RF parts. 1.8-3.6 VCC, so it will run on a pair of AAA or a Lithium battery for a very long time. 1Mbps max throughput is overkill for my sensors, so I'll run it much slower, which should improve range even more. Whole home coverage is important.

More investigation is needed. I still have to research the AVRFreaks boards to see what folks there may have done with Atmel Smart RF. Maybe something will turn up. But I can't spend too much more time on research. The schedule is just too short.

Otherwise, I think I'll dig into the AT86RF212 interface spec, download the TAT code and RF12 code, and see if I can convince myself I can make an merge of those that will work.

Fallback plan will be to use the Raven design and hope that the use of lots of Atmel parts trumps cost, complexity, and power. Not your usual engineering design tradeoff.

Atmel Arrow Smart Design Challenge

2009-12-20T12:36:00.000-08:00

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.

I now have 30 days to produce a "design on paper". Schematics, BOM, software, and "simulations". I got bit carried away in my proposal, so I'm now worried I won't complete this phase of the design in time. I'm pretty busy with some contract work plus trying to start a new business. And lets not forget the holidays.

Maybe I should have started work on the paper design back in October. But I didn't. So here I am, 29 days from the deadline. Time to get to work. Maybe deadline pressure will help me be efficient.

The judging criteria includes:

Uniqueness and creativity of design or application using an 8 bit AVR microcontroller from Atmel
Usefulness of products resulting from design or application (impact)
Low power consumption
Design methodology and technology
Cost of application and incorporation
Number of Atmel components required

I'll need to keep those in mind as I proceed through the design process.

Ebay To Go

2007-05-01T18:28:00.000-07:00

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

2007-04-07T09:09:00.000-07:00

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.