Jon asked me to post a bit more regularly about what I'm doing. Here's the thing I'm having fun with these days: a USB-controlled lab switch.
This is a fairly old idea that I've never fully implemented. The background is that you often need to switch power, buttons, or similar when testing a circuit. Sometimes, you need a lot of test cycles to make a hardware bug come out of hiding. These days, I'm lending a hand to the debugging of the Milkymist One rc3 boards. One of the problems we don't fully understand yet is an occasional NOR corruption that has been observed on some boards. One hypothesis is that this is a power management issue, but we're not quite sure about it yet. This problem doesn't happen very often, but still often enough that we've noticed it a few times during testing. Now, power-cycling a board hundreds of times and running checks on it is a grueling task at best. But of course, that's what we have machines for. Hence the return of the lab switch project. There are commercially available USB-controlled relay boards, but they lack a few features I'd like to have, and finding a nice case for such boards would be messy at best. Besides, it's more fun to do your own :-) What it will do: its main function is to switch a number of signals or power lines. The power lines may have a high current. The current design will be limited to "safe" voltages, but should ultimately also accommodate mains. This picture shows a first mechanical check of the PCB: http://downloads.qi-hardware.com/people/werner/labsw/tmp/labsw-0-pcb-mech.jpg The two big orange things are relays that can switch up to ~16 A (not sure if the rest of the circuit can handle it, though. I'm using a number of components I've sourced locally and that I don't have documentation for.) On the left side of the image are four opto-coupler inputs, the mini-USB connector, and four opto-coupler outputs (good for up to 200 mA.) There will be a front panel that connects to the relays, have two more opto-coupled outputs linked to the relays, three buttons and three LEDs. The C8051F320 microcontroller will take commands over USB, but it can also be given a "script" (a state machine) to execute locally. This will allow the buttons to perform application-specific functions. Some examples: - press to turn on, press again to turn off (that would be the default behaviour) - turn on for exactly 1 second when button is pressed - turn on while button is pressed, then stay off for at least 10 seconds I expect the design to evolve over a few iterations. For example, the first version won't be safe for mains voltage, I should use keyed sockets where possible, and I need to substitute parts of unknown origin with things that are fully characterized and can be ordered globally. The project is in http://projects.qi-hardware.com/index.php/p/wernermisc/source/tree/master/labsw/ What's next: the making of the front panel. Like the PCB, the front and rear panel will be CNC-milled. I'll (ab)use fped to do the CAD design. Sneak preview: http://downloads.qi-hardware.com/people/werner/labsw/tmp/front.pdf >From left to right: - channel 1/2 off-state relay output - CH1/2 common - CH1/2 on-state relay output - CH1/2 opto-coupler output - CH1/2 LED - CH1/2 button - system status LED, system on/off button This project creates a number of prerequisites on our EDA/CAM/etc. tools and libraries infrastructure: - the scripts I've used so far for making PCBs were for 0.8 mm boards. This 1.6 mm board requires a number of adaptations, mainly to cae-tools/cameo/templates/mkmk-simple - fped needs to learn to output things in a more CAD-ish way. This is the next thing I'll tackle. I'll make it output simply in gnuplot format, which is easy to parse and to convert to other formats. - various new components and footprints for the KiCad libraries, including headers, spacers, and DIP parts. - my USB stack for SiLabs C8051F3xx chips will also need merging into the better structured stack I have for the ATmega U2 series. The latter is derived from the former, so that shouldn't get overly nasty. I've also noticed that I'm exceeding the capabilities of the data sheet viewer (dsv), because I now share data sheets with other projects but don't have a way to reference their BOOKSHELF files. This will need a bit more thought. - Werner _______________________________________________ Qi Hardware Discussion List Mail to list (members only): [email protected] Subscribe or Unsubscribe: http://lists.en.qi-hardware.com/mailman/listinfo/discussion
