Another entry chronicling my adventures assembling and testing my Firestarter Boards. Part one can be found here. I was busy over the last week, so there was a larger gap between testing than I expected.
KiCAD is an Open Source EDA (Electronic Design Automation) suite, which I use for schematic capture and PCB layout. Like many other EDA tools that are floating around KiCAD can make 3D renderings of your circuit boards. If you use stock PCB symbols this is great; however, when you make your own PCB footprints you need to define your own 3d models.
I personally find it convenient to utilize OpenSCAD to make 3D models of most eletrical components, which are simple and easily defined parametrically in OpenSCAD's language. OpenSCAD allows you to write code that translates directly to a 3D model and export this to an STL. However, KiCAD expects VRML files which can be easily generated in Wings3D (which can import STL files). On the plus side Wings3D will allow us to add color elements and surfaces for nice rendering by KiCAD.
However, there is one pretty terrible problem: Wings3D can't for the life of it read in STL files read by OpenSCAD. Actually, Wings3D will just crash. To fix this you can use meshconv; however, use of meshconv does require use of the command line (in either Windows, OS X or Linux). I can only vouch for its usability under Linux. This will modify our workflow a little bit, but not by much.
The question now is how does this workflow go down?
For BU Rocket Team I needed a quick way to test E-Matches and get two readings off of then, namely current draw and to monitor voltage sag from a 3.7V Lithium Ion battery which will eventually be powering the board that is controlling the motor.
At first I tried to test using an IRF820 I found. The main reason was that I could quickly breadboard a test rig, get my data and call it a day. However, the devil is in the details, because at 3.7V this transistor simply can't draw more than 50mA or so. However, for the actual controller board, called Firestarter, I was going to use SI2308BDS N-Channel FETs, which have a much nicer V_ds vs I_ds curve for our application. The SI2308s only come in a SOT-23 package. There are methods to get around this, but I decided to take the opportunity to try PCB Etching.
The goal of this is to design a simple watch made from a single PCB and a watchband. In this initial version the time will be told using an RGB LED to tell an approximate minute time in color, and 4 LEDs to tell the hour precisely in a binary encoding.
When art and electronics meet some very beautiful things can be born. Here Antonin Fourneau made this wonderful piece, basically a wall of circuit boards with LEDS, when exposed to water the LEDs light up. A friend of mine came to me immediately after he saw it and asked me how it worked, so I took the time to do some experiments of my own and am currently working on making my own Water LED Graffiti display with the BUILDS hackerspace at Boston University.
I gave a basic explanation to Kawandeep Virdee with New American Public Works over The Sprouts mailing list, another space in Boston, to explain some of the engineering behind Antonin Fourneau's amazing art piece. His writeup can be found here:
Basically there are two exposed pieces of metal around each LED (that correspond to each LED). Water is all pretty much conductive, due to the fact that water ionizes things, and as water is splashed onto these metal contacts you will have an decrease in resistance and allow current to flow through the LED. All said and done, taking some measurements you generally wont get much lower than 100k, but it is geometry dependent. However, for many LEDs, especially super efficient super bright ones, this is enough current to get a pretty bright light coming out of them (we attempted with a small pad 1206 pad on a PCB we had around and a super bright 3mm blue LED).
Read on for more.
For Boston University's Artemis Project, a STEM education summer program for female rising high school freshmen, the BU Electronics Design Facility designed a synthesizer kit and ran a two day soldering workshop for the students. The whole kit was put together over about a 1 month period.
The Artemis Synthesizer is a basic 12-bit resolution synthesizer which has an output sample rate of 22kHz. The output audio is filtered at 11kHz to satisfy Nyquist and prevent weird aliasing and reflections in the output audio. Internally the synthesizer generates sound using a predetermined wave table, which can be changed and recalculated if desired. By default, the wave table contains a sine wave with 256 steps, but harmonic sound data can be programmed into the synth kit using our web interface.
The synthesizer contains two interactive modes and one mode for the optical communication link. These modes are: a keyboard mode, which contains 4 scales (C major, C pentatonic, C blues and C minor) and has 8 available keys; and a sequencer mode, which can hold eight 8-step by 8-note sequences. In sequencer mode, new sequences can be entered from the web interface.
The optical link, which is kindly called the "Optoloader" has its own separate mode and detects timed transitions between black and white from a computer monitor. The light levels are taken in on a photo-transistor and transitions detected using an analogue comparator interrupt with the comparison set at V_bat/2. The data is encoded using BiPhase Mark Code which encodes the clock with the data. The link is generally reliable when the monitor is set to a high brightness and a low speed is used. Mostly it allows for us to have a kit which is interactive with minimal programming experience and can still be changed and played with long after they leave. Thus the web interface which was developed by Sam Damask becomes very important for the end goal of our project.
The development team contained:
- Christopher Woodall [Me] who designed the kits and wrote the firmware
- Eric Hazen who reviewed my designs, advised my decisions and wrote the assembly instructions and parts list
- Sam Damask who wrote the web interface code.
Along the way I documented the process, explaining a few design decisions and experiments. I will go over vital information and reference the posts which contain relevant information as I go along:
- Artemis Synthesizer 1: Testing the TDA2822 Audio Amplifier
- Artemis Synthesizer 2: Interfacing with the MCP4921 SPI DAC
- Artemis Synthesizer 3: Basic I/O with Buttons and LEDs
- Artemis Synthesizer 4: Post-Mortem
- The Optoloader: Transmitting Data With a Blinky Box (Coming Soon)
- Fixed-Point Arithmetic: Fast Fractions using Integer Arithmetic (Coming Soon)
Previously, I was prototyping the Artemis Synthesizer and documenting some early design decisions: "Artemis Synthesizer 1 - Testing the TDA2822 Audio Amplifier", "Artemis Synthesizer 2: Interfacing with the MCP4921 DAC" and "Artemis Synthesizer 3: Basic I/O with Buttons and LEDs". All of this prototyping was being done for the production of a kit for the Artemis Project. Now the kits were made and built up by 24 rising high-school freshmen involved in the Artemis Project, a women in technology initiative at Boston University. So how did it go? Well, after the jump you will find out, as I inspect the timeline of the project and the two days we had with the students!
In my previous two posts "Artemis Synthesizer 1 - Testing the TDA2822 Audio Amplifier" and "Artemis Synthesizer 2: Interfacing with the MCP4921 DAC" I talked about the Artemis Project and my involvement in making a synthesizer kit for them. At this point the schematic is done, PCB layout is complete and I am almost done writing the firmware. Before doing a full write up of the final version, I figured I would write up some of the basic design decisions for the Buttons, LEDs and how I chose the volume control resistor and potentiometer values.
There are 6 I/O interfaces on this board:
- Volume Control
- Speaker (Already Covered)
- Light Dependent Resistor for "Optoloader" (In a future post)
- USB-B for USBasp bootloader (In a future post)