Just sent Dev-Rev2 Gerbers to OshPark for Fabrication (~2PM on 9/15/2014). But before I did I fixed a few things from my last post. I have updated all schematic/layout/gerber files on the GitHub repository for Dev-Rev2 of the Healthy pH Shield. Since I barely (and perhaps that is questionable?) know what I am doing, I crave your thoughts on how I can improve on the design/layout.
The goal of this post is to walk through the errors on the Healthy pH Shield Dev-Rev2 layout.
Thanks to Those That Go Before
Every day I am thankful for the many amazing people that I interact with.
This post would not be possible without the guidance and knowledge shared by Chris Gammell. Just when I think I understand something, I go over it with Chris…and…whoa – I truly was clueless. While he has every right to do so, Chris has not laughed at my learning foibles. Rather he has patiently explained (and re-explained) something I just don’t get.
Results From freeDFM
In the post where I discussed the design and initial layout of the Healthy pH Shield (link), I noted freeDFM – a utility from Advanced Circuits (here is the link) I like to run prior to submitting Gerbers to a fab house – pointed out errors that I couldn’t read. The first problem I had was the coordinate system. What the heck origin was freeDFM using? I mean, I had entered X=2.7” and Y=2.1”….then did freeDFM report an error at X=8.5277987″, Y=-3.2543901”?
DOH! I have ignored actually LOOKING at the Gerber files, relying on the layout view in Kicad’s PCBNew. Um..yah, not good. Considering what actually going on is shown in the Gerbers…. so opening up the Gerber files notice where the origin is:
The origin is way to the upper left. So yes indeed, TP9 (circled) is at X=6.9975″, Y=-4.355″
…and yes, indeed there is a double drill hit:
…and the other based on the coordinates / location in the Gerbers:
The second freeDFM error were 5 violations of Insufficient Trace Width. It turns out an edge of the Arduino GND plane was too close to P1 drill holes:
So I appended the GND plane to include more surface area around P1:
OK, resubmitted to freeDFM…and…and…
Some uglies I cleaned up:
I had the RGB LED – which uses the 5V+ of the Arduino using digital i/o PWM pins, which was how I’d seen RGB LED examples wired. The problem with this is it caused me to draw a rather large and ugly track across the board from the 5V+ pin on the Arduino to the digital i/o pins on the other side. Given this advice (link):
- digitalRead() works on all pins. It will just round the analog value received and present it to you. If analogRead(A0) is greater than or equal to 512, digitalRead(A0) will be 1, else 0.
- digitalWrite() works on all pins, with allowed parameter 0 or 1. digitalWrite(A0,0) is the same as analogWrite(A0,0), and digitalWrite(A0,1) is the same as analogWrite(A0,255)
- analogRead() works only on analog pins. It can take any value between 0 and 1023.
- analogWrite() works on all analog pins and all digital PWM pins. You can supply it any value between 0 and 255.The analog pins let you read/write analog values – basically, instead of giving out a voltage of 0 or 5 (as with digital), they can give a range of voltages between 0 and 5 (both as input and output). Note that the voltage during analog output is only the observed voltage with a multimeter. In reality, the analog pins send pulses of 0V and 5V signals to get an output that “looks” analog (this is PWM).
I ended up moving the RGB LED and associated resistors to analog pins close to the 5V pin:
Then a few smaller uglies. The through hole size of the WallWart and Barrel Jack parts were too small. More like the size of a via than a through hole. Then the GND planes needed fixing up as well as overlapping labels. The point of all this minutia is the importance of sanity checks – and most ideally – reviewing with someone far more senior who will point out errors. So much to learn.
So now I impatiently wait for the PCBs to return from Osh Park. Then soldering and…maybe…power!
Please find many things to smile about.