Archive for the ‘Dorkbot’ Category
5 lines about 36 Blinking Lights.
Wednesday, September 16th, 2009A while back I started thinking about a way to display stationary bike race results that didn’t require either a projector or a really complicated mechanical assembly. The thing that came to mind was a race tree like at the drag races. I asked Amanda who has been running bike events in portland if she could get me 12 lights. I wound up with pile of Bike Planet lights which required about a weeks worth of surgery.
From one of our led driving discussions a few years back I wound up with a tube of 74hc595s which I wired up like so.
While there are examples using bit banging to drive shift registers with the arduino they ignore the built in hardware capabilities of the AVR family.
Using the built in spi greatly simplifies your code and is remarkably fast. In the code sample below there are 5 bytes which represent the 40 pins from 5 shift registers. The main loop just toggles the bits and sends them out the door.
byte outbytes[5]={0x55,0x55,0x55,0x55,0x55};
//uncomment this for a standard arduino
//#define PIN_SCK 13 // SPI clock (also Arduino LED!)
//#define PIN_MISO 12 // SPI data input
//#define PIN_MOSI 11 // SPI data output#define PIN_HEARTBEAT 7 // added LED
#define PIN_SCK 9 // SPI clock (also Arduino LED!)
#define PIN_MISO 11 // SPI data input
#define PIN_MOSI 10 // SPI data output
#define PIN_SS 8 // SPI slave select
void EnableSPI(void) {
SPCR |= 1 << SPE;
}
void DisableSPI(void) {
SPCR &= ~(1 << SPE);
}
byte SendRecSPI(byte Dbyte) { // send one byte, get another in exchange
SPDR = Dbyte;
while (! (SPSR & (1 << SPIF))) {
continue;
}
return SPDR; // SPIF will be cleared
}
void RunShiftRegister(void) {
byte bitBucket;
int i;
digitalWrite(PIN_SS,HIGH);
EnableSPI(); // turn on the SPI hardware
for (i=0; i<5; i++) {
bitBucket = SendRecSPI(outbytes[i]);
}
DisableSPI(); // return to manual control
digitalWrite(PIN_SS,LOW);
}
void setup() {
pinMode(PIN_SCK,OUTPUT);
digitalWrite(PIN_SCK,LOW);
pinMode(PIN_SS,OUTPUT);
digitalWrite(PIN_SS,HIGH);
pinMode(PIN_MOSI,OUTPUT);
digitalWrite(PIN_MOSI,LOW);
pinMode(PIN_MISO,INPUT);
digitalWrite(PIN_MISO,HIGH);
SPCR = B01110001; // Auto SPI: no int, enable, LSB first, master, + edge, leading, f/16
SPSR = B00000000; // not double data rate
}
void loop(){
int i;
RunShiftRegister();
for (i=0; i<5; i++){
outbytes[i]= ~outbytes[i];
}
delay(1000);
};
Simple fast and easy.
Arduino Cult Induction 30 August 1-5 pm
Tuesday, August 25th, 2009
WiiWah
Thursday, August 20th, 2009
WiiWah demo from Donald Delmar Davis on Vimeo.
Collin Oldham came over before my gig in Spokane last month and brought a couple of patches and a few ideas on how to set up an effects chain using pure data. One of them was a patch using something called a “Formant” filter.
Wah.
I am not going to even pretend to understand it. But when I actually got to where I could play with it, it was really subtle and I didn’t like it. Then Collin explained that it needed some harmonics to work well.
Crunchy
Lucky for me Jason (breedx) showed me a really nice technique for getting distortion. Its still not as nice as my gz2 but its a pretty good demo of some of what can be done very easily in pure data.
Combining the two creates a really nice wah that is very vowel like as you can hear in the video above.
Connecting the Wiimote to pd on a mac.
My first attempt to connect to pd using the wii was using an OSC connection called musiccontroller using my intel mac. It worked though had the same issues that darwin remote has where in order to reconnect the wiimote to the you had to manually delete the binding that osx creats for the wiimote in the bluetooth control panel. The show stopper though was that it did not run on the machine I am targeting which is running tiger on a PPC.
Looking at alternatives I found a program called OSCulator which has ability to map multiple input sources and wiimotes, connects to the wiimote consistantly and with very little intervention and it has an extremely flexible mapping system for both osc and midi (though I never did get the osc part to work). It was however was neither open source nor free.
The solution I wound up with both simple and straight forward. It uses an open source application called wiitomidi and OSX’s IAC loopback device.
The pd source for all the patches put together is attached here. (http://dorkbotpdx.org/files/wiiwah.tgz)
Bumblebenito
Friday, August 14th, 2009
When I created the Benito I was working on a specific need for an arduino “programmer”. Since then several products have come out which are comparable and in some cases less expensive than the manual labor it takes me to build out and program the boards. One of these is the bumble-b. from Dave Fletcher. For this months arduino cult induction I will be evaluating the bumble-b as a possible replacement.
If you want to check out the bumble-b yourself I have 20 of them at a dorkbotpdx introductory rate of $10 which I will bring to Monday’s meeting.
See also
Buttons and sliders and stompswitches oh my!
Monday, July 27th, 2009
When I first built the box above I was trying to overcome the things I disliked about one of my better effect systems. It is a zoom bass pedal with several programmable subsystems (reverb/delay/distortion/a couple of lfos and filters) which you put together using an amazingly arcane system to get a huge variety of sounds. Of course once you unplug it it looses your programming and you are left with the factory presets. Which once you get over your loss isn’t so bad in itself since about a fifth of the “stock” sounds are all you would ever need. The thing that stinks is hunting and pecking for them.
I wanted to put together using pure data a similar “set” of sounds that I could select, combine and adjust easily. I started with a 4 button/slider prototype and laid out a 16 button/slider board which I managed to mess up in the gimp as to make it unusable.
So I put the prototype into production. I recycled the box that I originally tried to put all of the imic / gk-3 interface into (a disaster at best probably never to be explained before blowing up a mini itx motherboard in an attempt build out an audiopint, so it goes) and mounted everything as below.
All of the pots and lighted switches are actual musical instrument components. For the stomp switches I used the same interface (rca jacks) that the switches originally used to select effects on an old tube amp. For the expression I used an unmodified volume/pan peddle.
Then I went about getting it interfaced to pure data.
The easiest path to this was using Paul Stoffregon’s fresh port of firmata and a teensy++. I chose this because there are ample examples and it is established. Because the arduino is by default stupidly serial only I knew that I would be moving up the chain to something more usable like usb native midi but I didn’t have time to write the underlying firmware and then figure out how to use it to control pd.
Firmata delivered what it was supposed to with a few exceptions.
- No debounce on the switches.
- No pullups on the inputs.
- Its noisy and puts a lot of data out.
The first two were easy enough to fix. There is a de-bounce abstraction in pd extended that more or less works and I added the pullups to the input setup in the firmata. I would run this back up the source but first of all this is not the best solution and the last issue was pretty much a showstopper. There is a lot of meticulous work in the firmata library designed specifically to get data out quickly and when you combine that with a usb/serial implimentation that is not limited by actual serial speeds the result is a *lot* of data (95 percent of which you dont need). On a 2.1 Ghz macbook with 4 gig of memory, a noisy potentiometer would actually put out enough data to where there were audible glitches in the sound.
So I started looking at alternatives including Collin Oldham’s recent blog post (http://www.dorkbotpdx.org/blog/coldham/pd_and_arduino_or_whatever_you_call_it) until I found the link below.
http://kiilo.org/tiki/tiki-index.php?page=Arduino-PureData-MessageSystem
It wasnt perfect but it was close enough that I was able to make it fit my needs in a little over a day of hacking at it (with a little help from my friends of course).
The teensyduino code and the
pd patch are attached below.
Fabrication Workshop Followup.
Monday, June 1st, 2009First let me thank the group of people who came on sunday for the first crack at the fabrication and circuit board workshop. I realize that we spent a lot of time in eagle and not enough time actually doing the etch process. In the future I will probably do a separate workshop for eagle alone.
For this reason I will be available Sunday at TDIs workshop at 833 SE Main #125 for any of yesterdays participants who would like to go over the process of etching the board again and to get some hands on practice.
You are also welcome to come to the TechShop session on june 14th (before carpooling to the dorkbot event at about us).
I have also uploaded the folder with the Anderton superfuzz design files ( http://dorkbotpdx.org/files/fabclass.zip ) and the hobby design rules You should try to run the drc error check and you should notice that with the wider pads a few of the parts will need to be moved.
The 1458 can be replaced with any of the following low noise equivalents (the lt and ne parts are spendy).
* http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=296-1410-5-ND
* http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=LT1113CN8%23PBF-ND
* http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=OPA2134UA/2K5E4-ND
* http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=296-1812-5-ND
For those of you who missed the session because you were away there will be a second session at techshop in the afternoon before the evenings event at about us.
Reinventing the Wheel (watcher)
Wednesday, May 27th, 2009( this is a repost of http://blog.tempusdictum.com/index.php/don/uncategorized/reinventing-the-wheel-watcher)
Its not very often that you get to go back to old designs and make improvements. But when you do its nice. Recently I got to rework a design from last year and build on the collective knowlege of 2 design teams and 3 design cycles.
Does practice make perfect? We shall see.
The first run.
Last year I got to build the electronics for a stationary bike racing system. The system had a large ballfield style clock with four hands that were run by these monster stepper motors The initial design was for two bikes done by Percor: a company that makes excercize equipment. Their design used these industrial (expensive and very bulky) cherry hall effect sensors which they loaned us for a race at Lance Armstrong’s bike shop in Austin (http://www.mellowjohnnys.com/). My job for that cycle was to replace Percor’s pic based board with a 4 bike setup.
I broke the stepper driver section into four individual boards. For the processor I built a custom mega128 based board and did the programming in wiring.
Second iteration.
When the Austin race was over Percor needed their parts back so I got to rebuild the sensors. I found some allegra hall effect sensors which were a small fraction of the cost of the cherry’s (like (75c<$25.00)X4). As an attempt to get a zero indicator on the clock I experimented with a triangle based design 
While I never did get this particular part of the clock to work correctly the triange stuck as a shape that I liked working with.
I also wanted to replace the cat5 wire used in the Percor design with with less expensive phone cord. (I got a panicked phone call from Texas and had to remotely direct someone how to get some very expensive ethernet cable on a weekend: it was not cool). To do this I put a non inverting buffer on the sensors and since buffers come in 6s I put an indicator led on the sensors output. In the practice of setting this up for the next race, the blinking lights were invaluable.
Third Time Charm.
A few weeks ago I was asked about another race setup in SanFrancisco. They were going to use a system called open sprints for the display but the open sprints people were out of their hardware for the sensors. So I got a 3 week timeline to put together a sensor and hardware interface that would be compatible with open sprints.
Open sprints (www.opensprints.org) is an open source ruby based software which takes information from an arduino and presents the race data in a way that can be projected instead of having a physical race clock. The only thing that needed to be built was the input side.
So I went back to what I liked and didn’t like about my earlier design and compared and contrasted the opensprints, the percor and my designs to come up with a new system which I could then have fabbed by our local pcb fab (sunstone.com). Looking at the opensprints design I revisited the hall effect sensors and found a set of sensors to experiment with and began to lay out my boards.
I had intended to use the dart design with a through hole led and a throuch hole (sip) sensor and then have some laser cut transparent plastic which could then be “lit” up by the led on the board. A second piece of opaque plastic would be cut to insulate the bottom of the board.
After talking to some of my ee freinds I decided to replace the on board drivers with a single schmidt trigger on the other end of the sensor cable (the percor design used these as well) When selecting the parts I found myself looking at a few options for the rj11 connectors. I ordered a few of each as well as both sip and the origional smt sensor from last year.
Who needs plastic?
When I got the parts I started looking at these rj11 connectors and rethinking things. The connectors were surface mount and shielded. The shielding wasn’t needed but they matched the un-soldermasked boards in texture in color they were about 7 cents more expensive apiece but they looked futuristic.
I went back to surface mount only. If I got rid of the sips and used the surface mount rj11 mounts then the bottom of the board would be shield/ground no insulation needed. The metal from the surface of the board and cable connector would reflect the light from the led and if any attention were payed to the layout of the traces it would look cool!
Even in the hand rolled prototype!
Who needs an Arduino?
At this point given Paul Stoffregon’s (pjrc.com) “teensyduino” software and his 90usb based boards there is no reason to buy any other arduino or arduino clone. ( at least in cases where you need usb to serial solution — in cases where usb-serial is not needed the dorkboard rules 
My first thought was to do a carrier board for on of Paul’s boards and adapt the opensprints code for the inverted inputs. The opensprints code needs to be adapted to invert the input signal and to adjust the registers for the different processor but using the teensyquino codebase that should be simple enough.
In this application however, the board was so simple that it made more sense to just adopt the eagle design for my at90usb162 board (the benito).
Tomorrow I get the boards from sunstone and I should have the hardware built out by late friday. The customer will be in portland saturday.
Does practice make perfect? We will let you know by next week.
Using the dorkboard with other peoples programmers.
Thursday, May 21st, 2009When I developed the dorkboard I was working in conjunction with brian riley and paul badger. The dorkboard was an attempt to take the things I liked about the original really bare bones arduinofreeduino and refine them. Although I intended my design to be used with my programmer I tried to make it compatible with brian rileys programmers and the programming header pins are ordered according to the standard that paul and brian were working on. I will try to clarify some of this and show you how to use the dorkboard with other programmers.
DTR and the Auto Reset Hack.
The ftdi chipset that the arduino community adopted presetnts the dtr signal by default. The underlying standerd asserts dtr whenever a host computer begins to talk to a usb serial device. The device aserts dtr by pulling this signal low. If you pass this signal through a .1uf capacitor it gives you the pulse below.
The benito produces a straight pulse which is suitable to reset the avr directly.
The Dorkboard reset jumper.
The dorkboard was designed to work with either system. To use the dorkboard with the benito you simply jumper the reset directly using the solder jumper at the bottom corner of the board.
The pads of the jumper were designed to also accomodate a surface mount capaciter of the 805 size such as part 399-1168-1-ND from digikey . If you are using a programmer which just presents the dtr pulse then you simply solder the cap to the two pads as shown below.
confused at a highter level.
Tuesday, May 19th, 2009will write more here later.