Posts Tagged ‘PCB’


Cheap eBay reflow oven


I recently got a T-962 reflow oven from one of the many front-ends for the same fulfillment shop in California that sells various Chinese imports.  The unit cost $240 with free shipping, and arrived in roughly a week.  It’s the smaller of the two available units, the B model having a 1000W element rather than 800W, and a somewhat larger overall work space.  The unit came shipped in the usual Chinese style: wrap the unit in enough bubblewrap to fill the box on its own, stuff into cardboard box, then add about as much tape by weight (waterpoofing?).  The build quality is reasonable enough at first glance.

I started out with a few small boards (my Xmega DIP adapters) and went with “wave 2” designed for 63Sn/37Pb, peak temp of 225C.  Right off we have our first problem: the UI is horrible.  The screen itself is fine, but the font used is nasty.  The buttons are OK physically, but they’re only scanned once per second(!), which means you have to hold them down until it decides to notice.  Unfortunately, it doesn’t do any state latching, so if you hold it down a little too long, it’ll treat it like another button press.  Apparently debounce and interrupts are too complicated.  Even worse, when exiting some menus, it immediately processes that button press again.  A prime example is anything that uses F4 to return to the main menu: main F4 means “switch languages”….

The next problem is that while there’s a “cool-down” fan in the back, some genius decided that it should blow in to the chassis.  This results in all the solder fumes being pushed out the open bottom of the oven, and into your local atmosphere.  My absolute first modification to the oven will be turning that fan around.  I then need to find a flange with screw mounts for a 4″ flex-duct, at which point I can route the exhaust into my theoretical wall vent and continue breathing actual oxygen.

As you might expect, I took the unit apart to figure out what all is inside.  The answer: an insane amount of very tenacious hot-glue.  They hot-glued everything.  I spent a chunk of time removing all the hot-glue, because it was unnecessary (now that it’s shipped to me…) and because I wanted to actually be able to disassemble it.  I didn’t take any pictures the first time I took it apart, I’ll have to do so again and get all the detail I need.  Unfortunately the fan that needs to be reversed is buried inside several more layers of insulation and silver (duct) tape.  I didn’t dig that far into it yet because I actually need to make certain it’s usable for a while still…

The main board is designed to be split, with the various power stages on one side and the logic on the other.  The MCU is an LPC2134 (ish), with a funky programming header (1×6?) nearby, which bodes well for fixing the firmware stupidities.  A full reverse-engineering of the board will be necessary to figure out all the I/Os, but it doesn’t look like it’ll be a huge challenge.  The good news is that everything looks to be easily controllable, so enhancing the functionality with new firmware should be easy enough.

Just now I did a “large” panel of PCBs, taking up most of the available working space.  Here we find another issue with the oven: it’s not very even.  The panel had a 4×4 grid of boards, and the front row didn’t really come close to soldering in the preprogrammed “wave2”.  I had to not only switch to manual and keep the peak temperature in place for quite a while, but I had to open the tray and very carefully rotate the entire panel 180deg in order to put the unsoldered boards in a hotspot.

New firmware could fix this by running the “cooldown” fan at a very low speed during heating cycles.  The bottom of the unit might need to be taped up in order to force incoming air to enter from the front of the chassis and pull across the boards, though I haven’t looked at the bottom much.  The other advantage of doing this is that the “preheat” stage where the flux fumes start to off-gas would be exhausted to the outside.

At some point when free time actually exists, I’m hoping to hack up new firmware (after swapping out the chip if it’s code-locked, so I don’t kill it completely) and make it a bit more viable.


Crazy-accurate PCB stencils via Silhouette Cameo


Wow, I haven’t posted anything here in way too long.  This might help.

Right now I’m working on getting accurate PCB stencils out of my Silhouette Cameo desktop cutter.  People have been doing this for a while now, but they’ve been plagued by various complications with the data workflow and physical cutter settings.  The process involved transforming your artwork through several formats, importing into a proprietary application (you can buy SVG support for $50…), and hoping you have everything set right.

My initial work on the process was to change the data flow, allowing me to work from Gerbers rather than exporting a different format from Eagle.  It was a cumbersome process that involved using gerbv to write SVG files, then loading those into Inkscape in order to save them out as “R14” DXF, then switching over to my Windows VM to import the file into Silhouette Studio, dragging it to the right spot, and then cutting.  This at least allowed me the possibility of cutting an entire panel as generated by gerbmerge, but took waaay too long.

Now, I’m well on my way to having a radically superior process in place.  First off, I found that there are several projects capable of talking to the Graphtec engine that the Cameo is based on.  These gave me the foundation to write my own simple code to control the cutter, although there are still a lot of “magic commands” that need to be figured out the hard way (I’ll have to set up USB sniffing and exercise Studio a fair bit to figure them out, if I care).  That got me a Python script that could cut whatever I wanted programmatically.

The next step was to try to clean up the physical results.  Ever since I started cutting stencils, I’ve been plagued with strange shapes instead of nice rectilinear openings.  Well, this turns out to be a function of the design of the Cameo blade.  Inside the cutter is a vertical shaft with a very small triangular knife blade that spins freely.  The shaft is centered on the nominal X,Y of the cutter head, but the tip of the blade is not.  It drags roughly 0.5mm behind the center of the shaft.

This means that when you make a hard corner with the cutter head, the blade will not make the same corner.  As the center of the head (black) makes the sharp corner, the knife (red) lags behind and eventually ends up where the head wants it.  The result is a shape that roughly approximates the original, but only mostly.  Even worse, because the blade never actually reaches the start point, it leaves a little un-cut corner.

Cameo drag cutter     Not square!

My initial thought was to basically over-shoot the corner, then come back to the target line.  A simple method uses a single angled return path, but really it should be an arc of the same radius as the blade lag.

Initial compensation attempt

That mostly worked, but then I ran into another problem with blade-dragging: the blade drops with whatever rotation it had for its previous cut.

Drop misalign

In this case you can see that the blade was aligned from a previous upward cut when it dropped, then slowly made its way towards the right cut it was supposed to make.  The solution I came up with was to do a “pre-cut” off to the side before any lines of a given angle.  This leaves the blade pre-set at the right angle to make sure the beginning of the cut is straight.

The final trick was to cut each line in half, and actually force the blade to make two cuts starting from the center towards each end.  This avoids any question of exactly where the blade drops at the corners, and leaves and overshoot at every corner.  At least for rectilinear openings (all I care about just for now), this results in a perfect opening:

The Fifth Millimeter

That’s a millimeter ruler up against an 0.2mm square hole.  Not only is it nearly perfect (to the limit of my ability to actually see the thing!), but it lifted clear of the adhesive cutting mat exactly as you see: the fragment was 100% detached from the sheet.

At this point I’ve got a minimal codebase that reads actual stencil data, albeit the long way around: gerber -> gerbv -> Postscript -> pstoedit -> .pic(troff) -> myscript.  I’m hoping to fix that in the long run by reading Gerbers directly.

I have all sorts of transform functions in place to allow me to implement these techniques then send the resulting cut paths to the hardware.  I’m still tweaking a few things (I don’t have the cut-from-center trick written yet, but I do have a “repeat last line” to make 5 cuts around a rectangle) and getting period odd results (my last test left every single fragment still attached well enough to peel off with the main sheet…), but it won’t be long before I can take a Gerber file straight from Eagle CAM and generate a nearly perfect stencil on my $300 cutter!


Fully-assembled boards


I got a call yesterday that triggered a mad dash to try to get to Canby by 5pm to grab the freshly assembled PCBs.  Not sure they wouldn’t have answered after 5pm, but didn’t want to take the chance, eh? ;-)

The only error was actually caused by Digikey, where somehow they managed to stick a cut tape of some random SOT23-5 part inside a bag marked for SC70-6 parts…  I’ll have to figure that one out with them and mount those parts myself.  Luckily those are on the controller boards, of which there are only 3.

I have to assemble the 3rd board of each stack myself, because I ran them on the DorkbotPDX group order.  That’s because they’re simple by design, so I can run variations more frequently (and cheaper) as I work on fine-tuning that part of the product.  That and the debug board (which I have to solder a cable to) bracket the above boards, making the whole thing quite colorful ;-)

Part of my design is careful re-usability of parts.  The interface boards I’ve designed for upgradability are also snapped onto the controller, so if I come up with a better version I can replace the controller’s interface just as easily as all the others.

The next step of course is to bootstrap them, which is always a very nerve-wracking procedure…  It begs the question though: if the boards are red and purple, what color of smoke should come out if something goes wrong???


Panelizing PCB & Assembly: prepping the boards


In my quest to get a group of PCBs fab’d and assembled as inexpensively as possible, the first step of course is getting the artwork for the individual PCBs ready.  Once the schematic is finalized and the basic layout is done, additional steps need to be taken in order to make then panel-friendly, and actually get the artwork together into one chunk.

Read the rest of this entry ?


The joys of PCB & Assembly panelization


I’m working on the latest round of prototyping for the product I’m working on.  This time there are a number of factors that are forcing me to change from my previous development methodology.  First and foremost, there’s a lot more pressure to get it done fast rather than cheap, so a major factor is the reduction of unknowns like low assembly yield that were making the process rather slow.  Second, I’ve shuffled things around in the design in ways that both call for tighter design rules than the DorkbotPDX group order provides, and make assembly even trickier to do by hand.

The project itself consists of a whole series of different PCBs.  The main group of 3 boards stack on top of each other, while the controller has a site to stack on the top board from the first stack, then itself live on a larger board that I haven’t finalized yet.  Because of the small quantities of boards and the diversity of the design, panelizing them turns out to save quite a bit of money.  I’m currently running 2 of the main stack plus the first board of the controller.  If I ordered PCBs separately, it’d run about $1500.  Panelized, they came in under $600.  Assembly for each of the jobs separately would run around $3300 based on mostly-accurate numbers, but the panel drops that to around $2200.  Overall I’m saving around $2000 by panelizing.

The downside is that it’s a rather complicated process.  I’ve worked for the last week trying to get everything in order so EpecTec and Screaming Circuits don’t end up with major problems because of what I send them…  However, once it’s figured out the first time, I can do subsequent panelized runs with a lot less effort.  And thanks to the wonders of Open Source, I’m hoping others out there will be able to do the same because of the scripts I’m writing.

I’m going to see if I can make enough time in the next few days to note down most of the issues I’ve run into, and hopefully save others some trouble in doing so.  First up will be setting up the PCBs and panelizing them.


Abirtrary clock generation (with benefits)


The product I’m working on right now has a load of very arcane requirements, forcing me to delve into areas totally new to me.  One of those is precision clocking, since the product requires synchronized capture of data across multiple units.  As such I went hunting for PLLs that would do the job I need.  The key is the ability to adjust the speed very slightly in order to synchronize multiple clocks on multiple units to the exact same speed over the long term.

TI’s CDCE9xx series of chips turned out to have all the right features.  Each chip in the series has an onboard VCXO, which allows me to tweak the exact speed of the crystal with a voltage input, up to +-150ppm.  The various chips in the line have differing numbers of PLLs, each with 2 outputs on separate dividers.  The 12+9 bit N/M divider and 7-bit predivider allow for almost any sane clock speed you can dream up.  Coupled with the right crystal, it does exactly what I need.

But, there’s the problem.  TI specifies a whole mess of arcane crystal parameters needed in order to make the pullable VCXO actually work.  The catch is that nobody selling crystals actually publishes most of those numbers.  That means that you can neither determine the pullability range of a given crystal, nor find a crystal that actually works.  They list a number of specific crystals that “should work”, but not only are those datasheets no more help, but nobody (Digikey, Newark, Mouser, or anybody else I can buy from) sells them.  Hard stop.

Well, as I was looking through the listed vendors hoping to get my hands on some at least some samples, I tried to focus on US-based companies so I could actually communicate with them (all the others are in China etc).  Turns out Pletronics is based in Lynnwood, Washington, just a couple hundred miles north of here.  I sent them an email asking if they could point me to a crystal that’s supposed to work with and be pullable by the CDCE9xx series, and got back an answer that surprised me, and made my week.  They happen to sell a part that’s a CDCE9xx and matching crystal in one package!

The FD77T is the biggest of that line, based on the CDCE949.  The package is all of 5x7mm, which is ever so slightly larger than the CDCE913 alone (5×6.4mm), and noticeable smaller than the CDCE949 (7.8×6.4mm).  Compared to the CDCE949, crystal, and related parts, it’s radically smaller and easier to deal with.  It takes VCCIO, VCCINT, I2C, and VCXO control and spits out 7 PLL outputs, end of story.  The smaller versions (FD7[345]T) have fewer PLLs and outputs, but in the exact same package.  Pletronics seems to stock the FD77T for at least sample quantities with 24MHz, 24.576MHz, and 25MHz crystals.

The kicker is that the 1,000 unit pricing I was quoted was in the $2.50 range.  That’s cheaper than either the CDCE913 or the high-spec crystal separately!

In order to do testing, I made up a tiny adapter board for the FD77T that brings out all the pins, supplies the 1.8V VCCINT, and adds an extra set of top-side headers for the I2C programming interface:

In order to program the actual chip, you have to set up a rather complex sequence of registers.  TI provides a program called ClockPro that does it for you, but it seems to be written in MatLab and is ludicrously slow.  To top it off, it’s Windoze only and doesn’t provide any easy way of getting the register values out in a form that can be programmed in.  I’ve had to resort to literally typing in hex from the binary show in the bit viewer, which is very error-prone and not much fun at all.  So last night I constructed a Python script that does the core PLL calculation, and this morning added code to use the BusPirate to set the clock.  So far it works like a charm!

The code uses an iterative method, but one I’ve already thought through as far as implementation in a microcontroller.  It works back from the target clock, first finding a Pdiv that results in a Fvco closest to the nominal 135MHz.  It then tries all valid Pdiv’s above and below that still fit within the 80-230MHz range.  For each Pdiv/Fvco combination, it tries all the N multipliers from 1 through the max 4095, checking if the multiplied frequency modulo the Fvco results in no remainder, producing a viable M.  From there it calculates the intermediate values required to shove into the PLL registers, and outputs an I2C string to the BusPirate to set the clock.

As useful as the above is, setting the clock speed can sometimes be something you want to do at run-time.  Or more likely, you just don’t want to have to go through all that trouble when prototyping requires you to change the clock.  To solve that problem, I also designed a board that includes a microcontroller:

Populating this board is lower priority, but it’ll happen sometime soon.  The Xmega32A4 on the right is intended to run a microcontroller version of the above algorithm, with some tweaks in place for performance.  Mostly that means trying to fit the calculation into common bit widths, and dealing with the cases where it can’t gracefully and efficiently.  The goal is to have a register set on the MCU accessible via the various available protocols (the upper row of the board is a straight copy of a “serial” port on the Xmega, providing hardware async serial, I2C, and SPI) that lets you simply say “I want xx.yyyMHz on pin X, go!” and get a clock out.  Things get a little bit more complicated when you ask it to deliver two different clocks on pins that share a PLL, but that’s only a matter of finding a common Fvco with which two Pdiv’s generate the requested clocks.

A more interesting feature of the code destined for the MCU is the ability to lock the crystal to an external pulse.  To do so you would designate one of the interface pins as a trigger, and configure it for a particular mode.  To start off, the MCU will switch its clock from the internal oscillator to one of the PLL’s outputs, thus creating a cycle counter based on the crystal.  When these pulses are detected on the pin, the MCU will compute the difference between the actual counter and the desired counter, and run a PID to generate the VCXO control voltage, thereby dragging the crystal back into alignment with the external source.

The trigger modes would be pulse-before-count, pulse-after-count, and pulse-per-X.   In the first, the controlling circuit is expected to provide a trigger pulse, and then set a register with the cycle count that it was supposed to be located at.  In the second, you would set the register before the trigger pulse.  In the last, you set the number of cycles that are supposed to occur between pulses that come at regular intervals.  This mode is ideal for interfacing with the 1PPS signal coming off a GPS receiver.  Run the MCU off Y1 at the base 24.576MHz frequency, set the register to 24,576,000, connect 1PPS to the right pin, and suddenly you have a locked atomic frequency.

I intend to sell both of these modules on my (still upcoming) webshop.  The bare module should probably run about $10, while the Xmega-based module will likely run around  $20-$25.  As usual, if you need one of these and can’t wait for the webshop, let me know and I’ll see what I can do.  Just remember the code for the MCU doesn’t exist just yet.


Time-of-flight measurement


One of the requirements of the product I’m developing is that I be able to tell the relative distance along a wire of all the nodes in the network.  Because they are sitting on the bus in parallel and are not allowed to cut and internally bridge the wire, I have to use some arcane methods to figure out where they all are.

What I found was a chip from ACAM called the GP2, which is a time-of-flight measurement chip capable of 50 picosecond resolution measurements between start and stop pulses.  Using this, I can tell each node in turn to place a short across the bus (held with power from a cap), and measure how long it takes for a pulse to traverse one half of the wire, the node, and the other half.  By making averaged measurements and sorting the nodes, I can determine their order on the bus.

The first generation board for this included a bunch of jumpers to allow me to reconfigure the various timing-side pins:

It took quite a bit of time to work out how to get the chip to function in the first place, thus the extra resistor and jumper wire around the crystal.  Turns out ACAM put a pretty fragile oscillator on their chips, which requires both a drive-side series resistor (220R) and as well as a parallel resistor (560K) in order to work.  This could be contrasted with a conventional 8-bit microcontroller that generally functions without anything except the crystal at all, but is “cleaner” with load caps.  Sigh.

The jumpers allow me to enable the start and stop inputs, route the fire-pulse generator to start and the line interfaces, gang the two generators together (for 96mA drive current), and configure the “fire-around” mechanism that I don’t entirely understand since I don’t need it…

In an effort to make the design more useful for integration into a protoboard form of the network master, I redesigned it as a 600mil DIP module:

All the same functionality is present, but without all the jumpers.  The 32KHz calibration crystal is missing from this board because Digi-Key had (and still does, my notification to them apparently not having taken effect yet) the ECS-.327-7-38-TR listed as a 4.9×1.8mm crystal, rather than the 7.0×1.5mm it really is…  I have actual 4.9×1.8mm crystals coming on Monday or Tuesday, so I’ll fill that in.  However, since I don’t actually care about absolute accuracy at this point, I really could care less about the calibration clock.  On the bottom is a (unpopulated) site for an MCP1703-3.3 regulator, with pins on the top left for both +5V and +3V3.  All the power and digital I/O is on the top side, while all the measurement-side pins are on the bottom.

Getting the chip actually running was a monumental exercise in frustration, since the datasheet (“registration” required) for the chip is easily the worst-laid-out document of its type I’ve ever run across.  While the designers of the time-of-flight core in the chip were clearly rather talented, whoever did the SPI and registers front-end needs to be shot. Repeatedly.  That being said, I plan on writing up a better organized and more coherent “quick start” along with default registers for the module…  I’ll probably even publish (as-is) the Python GUI I created to tweak all the registers more easily, which operates via BusPirate.

The first board pictured is about to be shipped to a guy in Brazil who managed to find my un-set-up webshop with it listed.  At some point soon I need to try rebuilding the shop with a different backend and actually get it up and running fully, at which point I’ll be offering the DIP module for sale.  Lead time on the module will be somewhat long though, since the one pictured above has the last of the 3 chips I purchased at ~$32 each.  If anybody wants one, I’ll have to order more chips first.  I have 2 unpopulated boards in my possession at the moment, so if you’re interested in one, speak up ;-)