Archive for the ‘PCB’ Category


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!


OctoPDI5 board underway


The product I’m working on consists of a number of devices strung out on a bus, all of which need to be reprogrammed and debugged at the same time.  The problem is, they’re potentially meters apart, and more critically their ground potentials are all different (they derive power from said bus, which will sag inward from 0-V+ over distance).  I’ve made several attempts to solve this problem (isolated USB, wireless debugger) and so far they’ve all fallen short for various reasons (none of which can’t be overcome, given enough time, which I don’t have).  This latest attempt is far more likely to work, because it’s based on existing tech and more straightfoward (and breadboarded!).

This board consist of an Xmega 128A1 coupled with an FT245R, along with 8 isolated PDI5 ports.  The ports consist of an Analog “isoPower” ADuM5403 and a 74AHC1G125 tristate buffer plus USB micro-B connector.

The FT245R is hooked up to the memory interface of the Xmega, which means in theory I can read and write the USB serial port just by reading and writing a memory location.  I haven’t had much success getting that to actually work in the past, but I’m giving it one more shot.  I know the bitbang interfacing works, so I can always fall back on that.

Each PDI5 interface is half of an “interface” port on the Xmega, and is set up for the USART.  The TXD, XCK, and TXEN lines go through the ADuM5403 one direction, and the RXD goes the other way.  TXEN drives the 1G125 buffer to engage TXD, because the target side of the PDI5 interface ties the RXD and TXD lines together via resistors to provide the PDI_DATA line.  The Xmega can easily tristate the TXD line when it’s time for the target microcontroller to talk back, but the ADuM5403 doesn’t know any better.  The buffer enables this to work on the isolated side of the circuit.

The software I’m porting over to this beast is existing code that multiplexes communication to all the configured logical modules over the USB uplink.  Each PDI5 port consists of two logical modules: the STK600-compatible programming stack, and a straight serial port.  Using the STK600 port disables the serial port for the duration, but otherwise the serial port provides debug communication with the target.

The micro-B connector has a different pinout than I originally planned.  Rather, this one is actually planned…  I’ve found that even though mini- and micro-B connectors have 5 pins and a shield, nobody makes pre-made cables that have the 5th wire.  As a result I’ve shuffled things so that the +3v3 pin is the one that ends up not being connected between the programmer and target.  This is fine for two reasons: we have a ground and known voltage level, and the ADuM5403 also provides power on the isolated side to run the buffer.

Once this board is up and running, I can use the collection of micro-B to micro-B cables I purchased from Digikey in order to spider out to all the units I’m developing.


Mental excercise: tiny acceleration logger


When watching shows like Mythbusters, Prototype This, and Smash Lab, you regularly see them using accelerometers in order to test the shock characteristics of a given event.  The problem is that these loggers are invariably big (roughly 6″ cube by volume) and fraught with problems such as “triggered, hurry up before we run out of log space!”.  Given the current crop of really tiny accelerometer chips (such as the Freescale MMA4755 mentioned on dorkbotpdx, for $2 quantity 1), microcontrollers, flash memory and batteries, it seems almost criminal that they aren’t using something radically smaller and smarter.

So just for fun, I decided to toss some parts together and see if they would actually fit on an incredibly tiny package.  The design is not complete, as it is missing any charging capability and more importantly a Bluetooth uplink module, but it’s a good start:

I call it “rev -1″ because of the missing features, but it’s a good start.  However, it’s a whopping 1.125″ x 0.5”, sized to match a tiny LiPoly cell from Sparkfun.  It’s got an ATmega48 core, MMA4755 accelerometer capable of up to +-8G, and an 8Mbit dataflash capable of roughly 15 minutes of continuous recording at the maximum 250Hz sampling rate.  A tact switch is used to turn it on etc, and an LED just under that for status.

The next steps would be to add the Bluetooth module (e.g. this one also from Sparkfun), some kind of charging circuit, and possibly a USB-A connector to make it into a “USB key” for both data extraction and recharging.  I’d drop the huge battery connector in favor of soldering it on, and put the Bluetooth (and maybe some other parts) on the opposite side of the board, but I still think it’d fit.  I’d want to find a solid power-management chip designed to handle USB input and LiPoly charging that’s also insanely tiny, but these days the manufacturers are so keyed in on making multifunction chips in stupidly-small packages that it’s probably going to be harder to find one big enough to do on the group-order design rules.

Total retail price on this module would likely be in the $75-100 apiece, but the combination of size and potential feature set should be hard to beat.


Xmega board up and running!


This morning I soldered up the first of the A4 boards, and it works great so far!  I’m working on thorough “boundary scan” testing in the form of hooking up LEDs to each of the pins and making sure the chip soldered properly, and if that passes I have a perfectly functional board.

For those who got boards and parts kits last night at DorkbotPDX, here are ZIP files of the final Eagle and Gerber files the boards were made from:

One thing I forgot to mention to everybody is that the crystal has to be connected via a pair of solder jumpers right up against it.  The soldermask is supposed to be missing from between them, and the gerbers show that it’s supposed to be, but the boards look like they have some in there anyway.  What it boils down to is that you need to make sure you glob plenty of solder in there, either paste or after the fact.

After some research into the costs associated with making these in quantity, I came to the conclusion that a redesign was in order, to use the PQFP parts instead of QFN.  The resulting boards are a hair wider, and use surface-mount headers on the bottom, but are schematically identical to this first batch of boards.  The A3 version might actually end up being a 900mil board though, since the PQFP-64 isn’t liable to fit on even the wider 600mil board…  The resulting boards will end up my upcoming webshop, hopefully within a few weeks.


DMX-512 module in development


In response to a question on answers.hackaday (this one) about an open-source DMX-512 platform, I figured I’d post something about what I’ve got under development as part of a larger project.  The long-term goal is to develop a wall-mounted control panel (e.g. in the standard light-switch box) for lighting scenes.  A number of these would be installed at key places in our church sanctuary, allowing the DMX-controlled lights to be operated without having to trudge upstairs and find the light board.

The module in question would be the brains of such a beast, having a microcontroller and the necessary DMX interfacing.  An ATXmega would form the core, given that it’s the most versatile MCU I’ve used so far.  DMX interfacing uses a pair of MAX13430’s, which are dual-voltage transceivers allowing me to run the DMX ports at the proper 5V yet interface cleanly to the ATXmega running at 3.3V.  A soft-USB port is present for configuration, though that depends on either porting or rewriting the AVR-USB stack to run at 32MHz, or just running the whole module at say 20MHz (the max current speed for AVR-USB).

The module takes the physical form of a 40-pin 600mil DIP, for which sockets are easily available anywhere and everywhere.  All the pins not used by the DMX interfaces are brought out on pins for use by whatever you want to drop this thing into.  DMX and power connections are made via screw terminals, which could be routed to standard 5-pin DMX connectors on whatever chassis you have.

This module is still under development, as in I was modifying and cleaning up the PCB just a few minutes ago.  The DIP power pins are yet to be routed, and there’s more cleanup to be done.  However, I’m waiting to turn the actual boards until I get my baseline Xmega adapters populated and can start developing some of the software so I know I’m not smoking something.  I expect to turn these boards in 2-3mo, and shortly make them available for purchase.


Logic Helper under development


I’ve struggled with juggling all sorts of tools for development for years, ranging from serial adapters to chip programmers to logic analyzers.  So, I decided to do something about it, but I haven’t gotten far enough yet to use it.

FT4232 Logic HelperThis board is built around the FT4232 from FTDI, which has a total of 32 I/Os in 4 groups of 8.  Each group has a serial port, and the first two have MPSSE (Multi-Protocol Synchronous Serial Engine) blocks capable of doing SPI, I2C, JTAG, and others.  All 32 I/Os are routed through 4-bit voltage-level translators, and then grouped to a set of 8 RJ-45 jacks.  Of each of the 4 chip ports, the A jack has pins 1-4 and 7,8, while the B jack has pins 5-8 and 3,4.  The other two pins are GND and VCCIO for that bank.

Pre-made cables could be designed for common interfaces, such as AVR-ISP or JTAG, or include extra components if needed for protocols such as I2C (the FTDI chips require DI/DO be tied together externally, for instance).

I have a software framework underway that will interface with this board and allow you to stack all sorts of modules together to accomplish what you’re after.  An example would be an AVR ISP module that exposes a custom API.  Underneath it would need to talk to 4 pins (MISO,MOSI,SCK,RST), and would use a standard connection API to be attached to a module underneath that provides those resources.  If you hook it to dumb bitbang pins, the ISP code will hammer out the protocol the hard way.  However, if you hook it up to pins that are aware that they can be controlled by an SPI module of some kind, the ISP code would make use of the SPI interface and give you radically faster programming speeds.  This way you can shuffle your use of the RJ-45 ports to best match your requirements for particular ports and acceleration needs.

I plan on developing a very similar board based on an ATxmega128A1 that will have the same 8 connectors in roughly the same arrangement, but add another 4 connectors for A/D and D/A outputs, and possibly add an LPC memory bus on a different connector.  The memory bus would also have an FT2232 for interface to the host computer.  The remaining port may connect with another microcontroller (maybe via backpack?) that could do all sorts of interesting things with the VCCIO pins, e.g. making them inputs or outputs, suppling particular voltages, etc.  The sum of these enhancements would mean an extremely fast device capable of running things like AVR-ISP, AVR-PDI, JTAG, 1-wire, and other protocols with microcontroller assist.  A serialization format between modules would allow compatible modules to be shoved “down” into the hardware.

I also have a tiny version based on the FT232R, which can provide both RS-232 and 12-bit I/O (only 10 with RS-232 active).  Unlike the FT4232, there is no sync-serial engine, so everything would have to be done via bitbang…

FT232R Logic Helper

I have the two boards shown actually fab’d, but I haven’t put the parts on them yet.  The software is much more theoretical at this point ;-(


Isolated USB cable, hub


The next design I’m showing off is a tiny little board (1.4″ x 0.45″) that houses both an ADuM4160 USB 2.0 low/full-speed isolator, and an ADuM5000 100mW power isolator.  The two together form the core of a fully-isolated USB cable, which means you can safely connect your externally-powered device to your computer without any worries about where the relative ground potentials are.  This is critical for my main contract, because each board takes power from further and further down a main power bus, which means that even after the regulators do their thing, the ground potential on each subsequent node on the wire is different from the previous.

The ADuM4160 requires power on both sides of the transformer isolation barrier to run its encode/decode circuitry, which is why the ADuM5000 is required to provide power.  The upstream port of a USB device does not provide any power to the cable, so there’s no power for the device side of the isolator without the ADuM5000.  However, the 100mW limit means you really can’t run most bus-powered devices off the isolator.  OTOH, why would you be putting a ground isolator on a bus-powered device anyway…?

Isolated USB cableThe other design is a 7-port USB hub based on the same concept.  The upper-left port is the upstream, the remainder are downstream.  All 8 ports are fully isolated for both USB and power.  The 100mW limit of the upstream ADuM5000 should be sufficient to drive the 7 downstream ADuM4160/ADuM5000 pairs as well as the TUSB2077A hub chip, but not provide any power at all to even the lowest-power of devices…

Isolated USB hub

I haven’t had luck yet getting the cable isolator to work, due to a combination of problems not the least of which was the lack of proper silkscreen in the parts library footprint I stole.  It helps if the ADuM5000 isn’t backwards, eh?  I haven’t gotten back to trying to finish that because the memories of spending a week bashing my head bloody against the problem are still too painful.  I’ll get to it soon though, because I will need a quantity of them very shortly.  The hub is still sitting on my desk as a bare PCB, since I don’t really want to start sticking some $70 of parts on the board until I know the smaller version works…

Once they are confirmed working, I plan to offer them for sale somehow.  I know there’s interest, because only a few days after posting to the DorkbotPDX list about them, I got an email from someone entirely unrelated to dorkbotpdx about wanting to buy some. Go Google!