Matt S, Paul S, and Jon B have joined the No Cube team, be on the lookout for things from them in the near future.
Mike H will no longer be a part of No Cube, congratulations go out to Mike as he will be joining the spark fun team in Colorado. Good luck Mike!
The VidiSynth is a circuit with multiple oscillators that are controlled with light sensors attached to a video screen.
Video + Synthesizer = Vidi Synth
The light sensors create interesting and complex sounds based on the intensity of different areas of the screen. I also learned from experimentation that if the sensors are attached to an LCD screen you get relatively normal square wave tones but if you use a CRT screen (TV or monitor) you get extra noisy and buzzy goodness because of the refresh.
I’ve been tinkering with electronics for just over 2 years and VidiSynth has been a huge part of my learning experience. It all started with early tinkering with 555 oscillators and my first optical theremin inspired by a video from Michael Una. From there I came up with the idea for VidiSynth and prototyped it using individual 555s.
That prototype actually required an audio mixer to combine the different channels because I hadn’t yet learned how to mix the signals. I lived with that prototype for quite a while, even building an interactive project around it for an exhibit at Twin Cities Maker during the annual Minne-Faire. Eventually an Electrical Engineer friend from the hackerspace urged me to evolve it into a PCB for potential sale as a kit. This opened up whole new areas for me to learn. Fortunately I have a couple of very patient EE friends that were a huge help along the way.
The design was done entirely in Kicad which is a nice tool once you climb a bit of a learning curve. I eventually worked my way through all the steps of laying out the schematic which involved creating some custom components, mapping the components to footprints (more custom work) and then finally laying out the PCB. Kicad’s autorouting features worked great for my simple design and along the way I learned details about vias, ground plains and trace parameters for power versus signal. The final step was to learn about all of the various layers that must be sent to the PCB manufacturer and making them all look the way I wanted. Finally I sent my design off to BatchPCB, ordered the components and waited.
When my PCBs arrived I eagerly populated the first one, and IT WORKED!
The PCB version of the VidiSynth was born.
VidiSynth went through various prototypes before its current incarnation pictured above. It uses two 556 chips to implement four oscillators, the output of the four oscillators is mixed through a set of resistors into a 1/8″ mono jack. On each oscillator the resistive element that normally controls frequency is terminated on a terminal block in order to allow different options for controlling the frequency. This can be achieved with photo-resistors as originally conceived, with potentiometers for more direct control or anything else that allows control of resistance. You could also add complexity by switching the channels with transistors.
Here is a list of a few interesting ways to use the VidiSynth that I’ve discovered:
1. As originally conceived you can connect photo-resistors randomly to a video screen and play your favorite movie or any old thing you have lying around to get interesting sounds. Film Noir is particularly dramatic.
2. Pipe the feed from a video camera or do display on a TV or monitor and you have an interactive instrument. I recently had a conversation about using Skype video conferencing in conjunction with this in order to facilitate a remote performance using VidiSynth.
3. Run all the channels through potentiometers and you can play with drones similar to Casper Electronic’s Drone Lab.
5. I have written a midi driven Processing script that displays grayscale blocks on the screen based on the midi commands. This allows sequenced control of all 4 channels. I plan on releasing this in the future once I finalize it.
6. Another method of sequencing I have used is to run a couple channels through Mikey Delp’s Bender Sequencer that was created for sequence circuit bent toys.
The possibilities are endless once you start combining different input methods. You could even mix multiple VidiSynths for more fun.
Below are a couple video demonstrations of the how VidiSynth can be used. It’s a fairly simple circuit, but with that simplicity comes a flexibility that allows for some fun experimentation.
Before I move on to the demonstrations, here is a link to the schematic for the project:
Finally I would like to recognize Paul Sobczak who encouraged me to enter the 555 contest. He’s a smart and humble guy who is infinitely generous when it comes to inspiring people to do cool things and is always there to lend a helping hand. Also thanks to my two tremendously smart and helpful friends Mike Hord and Adam Wolf.
Being a Minnesotan, I have uncomfortably close knowledge of how ugly close elections can be. In 2008, the Franken/Coleman Senate race degenerated into a mass of recounts and recriminations that ended about, what, two hours ago? And that, just in time for ANOTHER set of recounts to begin in the Emmer/Dayton gubernatorial race.
Electronic voting, at first blush, seems to be an answer. Take away the human factor (hanging chads and voter intent ring a bell?) in the vote-casting and vote-tallying process and things are bound to improve, right?
Except, it turns out that you introduce boatloads of bigger problems:
- Machine security has to be tight to ensure no malicious code can be executed and vote tallies can’t be fiddled.
- Stability and uptime are a major problem- a BSOD on a busy election day makes everything worse.
- The lack of a paper trail (I remember one sound bite of a Diebold executive claiming that is was “technologically impossible” to issue voters paper receipts for their votes- I wonder whether he’s ever been through a checkout at a grocery store?) means that voters have no independent assurance that their vote even exists, let alone that it counts.
I believe that the root of the problems comes from trying to do too much. I ask myself, what’s the point of an electronic voting machine? Why would it be better than, say, filling in bubbles or throwing levers or drawing lines?
In short, all the application calls for is an means for the voter to quickly (it took me longer to darken circles than it did to walk to the polling place on Tuesday) and unambiguously (no darkening two circles, no “x” marks instead of lines, no dimpled chads) indicate their intent.
It seems to me that the baggage that comes with the “traditional” method of solving this problem (which seems to be writing an application to run on some variation of a reasonably modern PC) outweighs any conceivable benefit of that solution. If you make the device a one-trick pony, a small, simple embedded system that does nothing but present a clearly readable list of choices, one topic at a time, and locks out invalid choices (too many selections, for instance), followed by validation and finally issuance of a paper receipt, you’ve bypassed the major issues above. The paper receipts can be tallied the same way they are now (in my precinct, and probably most or all of Minnesota, that’s by feeding it into an automated scanner), and the results can be transmitted the same way they are now.
The benefits come AFTER voting (although improved voter throughput is a side benefit). The clear, unambiguous nature of the receipt means every voter can be assured that their vote will count and count as they intended.
I’ve thought about this a lot, and it seems like a good place to start is with a Chumby. Since it’s a Linux based device, the kernel can be pared down to bare minimum, foreign code execution can be limited, and it already has the necessary hardware to support an external touchscreen and printer. It’s cheap, has had the bugs worked out, and is an open source project.
Hopefully, sometime soon, I’ll have some more information up about this. If possible, No Cube is going to pursue this opportunity; we have the unique advantage of being in a progressive city in a state which is desperate for a new way to work elections with less room for error.
I suppose since my partner has blazed the trail with some awesome posts that I should say something about my first design: VidiSynth. Thanks to the help of Mike and my pal Adam Wolf (check him out at wayneandlayne.com) VidiSynth was a total success. Naturally there is always room for improvement and I will be tweaking a couple of things for the first production run, but I couldn’t be happier with how the prototype turned out.
VidiSynth by the way is a fun little noise toy that has 4 square wave oscillators mixed together into a single output. The frequency of each oscillator is controlled by an external resistance loop that can be a simple potentiometer, photo-resistor or something more complex like a sequencer. If light sensors are used you can produce a wide variety of sounds by finding interesting light sources to drive them. One of my favorites is good old CRT television which gives a nice lo-fi buzzy tone and can add a new dimension to your favorite movie.
Look for more information and some demos in the coming weeks as we prepare to put our designs up for sale.
So, the third and final of my designs from the first batch of prototypes is a shield to convert the Arduino to use true RS-232. This design came from a real need in my real-life job; I had an application that needed a timed power cycle sequence, and the fastest and easiest way to do it was to use an RS-232 driven power supply (we buy these by the gross lot, practically) and turn it on and off with an Arduino. I ended up making a shield for it out of a protoboard because none of the RS-232 shields out there in the world fit for that application.
The advantage of our shield is that it’s configurable: you can solder down a female DB9, add a few jumper wires, and have a DCE device (i.e., something that receives commands from a PC), or plunk down a male DB9, do the jumper wires differently, and have a DTE device (like a PC). It also allows for a pair of OOB signals (for example, CTS/RTS or DTR/CTR) and has an on-board buffer which allows you to, by proper connection of yet another jumper wire, set it up such that you can still program over USB even with the shield in place.
Of course, there were some mistakes in this first version:
- I should have added a keepout zone where the USB jack on the Arduino is. The metal backshell of that jack shorts out the leads of several components on the backside of the shield.
- The silkscreening is a little hard to follow. With an instruction page it will be fairly clear, but I think I should put some stuff on the top and some on the bottom.
- I flubbed the placement of the header pins. Three of the four headers are in the right spot but the fourth is off by probably 50th.
- The caps I selected for the charge pump on the MAX232 chip are taller than I’d like- they make it unlikely that you’d be able to stack another shield on top of this one.
Not bad, all around, though. I still haven’t tested it yet, but I’m not too stressed about it actually working. If something turns out wrong with it, beyond these layout problems, I’ll certainly mention it here.
This time, we’ll tackle the thumbino. Thumbino is an Arduino clone in a thumbdrive form factor. It has five LEDs tied to the PWM outputs which can easily be disabled by clearing a solder bridge, and a .1″ header which plugs into a breadboard. We’re planning some shields for it, eventually, but for now, it’s just a nifty trinket.
- Again, width problem on the PCB where it is supposed to mate with the USB. Considering that thumbino and USXB board outlines should be exactly the same (470th, nominal), the fact that there is a 30th difference between the two is somewhat disturbing.
- The LED color spread doesn’t do it for me. I was hoping for a nice rainbow spread from red to blue, but in MY world, the red, amber, yellow, and green are all pretty much identical.
- Another rookie error- the holes for the headers are just flat out too small. I can shove the header in far enough to solder it in okay, but that needs to be fixed.
- Same problem with the SSOP-28 footprint for the FT232 as USXB.
- In retrospect, trying to provide an arbitration scheme that keeps another power supply from being shorted to the USB 5V is unnecessary. This isn’t consumer grade stuff, it’s hobbyist electronics. Either the users will know not to short two power supplies together or they’ll learn a valuable lesson.
- A couple of the resistors are a little too close to the FT232. Not a problem for hand placing but it’ll never fly if we use a pick and place.
I haven’t yet tested the full functionality of the device- there may be some pins that are not soldered on the QFN-32 package of the Atmega328p. It does work, though- as far as the Arduino IDE is concerned, it’s a Deumilanove, and it programs just fine.
We got the first batch of PCBs today from, well, BatchPCB. I’m going to try, from here on, to keep my design notes as blog entries, so the whole world can benefit from my, erm, constructive misapprehensions of design.
Today we have notes primarily on the USXB board. Think USB to XBEE module adapter based on the FT232 chip. Sparkfun has one, of course (what DON’T they have) but ours has advantages that will become apparent as release time nears.
For now, though, I’m unfolding the mistakes I made. Strangely, they are minimal.
1. BatchPCB doesn’t seem to do high precision routing on the profile. Since this board plugs into the USB port itself rather than using a connector, that width is important.
2. BatchPCB uses a default 63 thou thickness on the PCB. This is standard- 1/16″ (1.58mm for you civilized folks). That’s not QUITE thick enough for a solid USB connection; a few strips of cellophane tape took care of that (I was dumb and didn’t apply the tape until AFTER I populated the board- remember, kids, cello tape generates high static voltages when pulled off the roll, and ESD kills!).
3. My silkscreens are almost unreadable. That’s a long-term problem, since they really can’t get TOO much bigger than they are.
4. I flubbed my version control. At least one of the three PCB designs I ordered (not including Pat’s) is wrong. Not sure how that happened.
5. I soldered my FT232 chip down backwards on the first board I populated. Rookie error. I have no excuse.
6. I totally botched the order quantity on passives. I don’t have enough of basically anything (except MAYBE 100nF bypass caps) to go around. That’s not a terrible problem, however- I’ve got boxes of SMT passives I scored from the trash at work that will get me by.
7. Some of the clearances are a little…iffy. Not so bad as to be a problem, but…iffy.
8. The pad size on the FT232 package (SSOP-28) needs to be increased. It’s not TERRIBLE, but they don’t stick out much away from the lead ends, which means trouble when soldering by hand. Fine for reflow, however.
I still haven’t verified 100% of the functionality- there are some LEDs on there I haven’t populated, and I haven’t populated the pull-down to use the RS-232 OOB signals to reset the XBEE. Also, haven’t tried pairing yet.
I HAVE tried it, and it works like a champ. I call this one a win.
Stay tuned for pics and further updates as I go along.
We’re just getting started here at No Cube Designs, we are a nascent electronic kit and open source hardware business.
If you happen to stumble across us before we have any content, please bookmark us or better yet add us to your rss reader. There is good stuff to come.