something went wrong links - Mon, 2015-01-12 06:00
Categories: DorkbotPDX, Member links

Dusg with knobs

DorkbotPDX Flickr Group - Sun, 2015-01-04 19:01

xnorman has added a photo to the pool:

Dusg with knobs

Reseq with knobs

DorkbotPDX Flickr Group - Sun, 2015-01-04 19:00

xnorman has added a photo to the pool:

Reseq with knobs


DorkbotPDX Flickr Group - Sun, 2015-01-04 18:17

xnorman has added a photo to the pool:


Connects the pcb to the faceplate. The bracket is held on the faceplate by two parts which may be either a jack or a pot


DorkbotPDX Flickr Group - Sun, 2015-01-04 18:12

xnorman has added a photo to the pool:


needs tuning and knobs


DorkbotPDX Flickr Group - Sun, 2015-01-04 18:12

xnorman has added a photo to the pool:


Resonant eq

DorkbotPDX Flickr Group - Sun, 2015-01-04 08:44

xnorman has added a photo to the pool:

Resonant eq

Resonant eq

DorkbotPDX Flickr Group - Sun, 2015-01-04 08:44

xnorman has added a photo to the pool:

Resonant eq

[dorkbotpdx-announce] BUNK is comping dorkbot tonight

dorkbotpdx-announce - Mon, 2014-12-29 11:14
To show their appreciation and as an advance apology for booking a party for Jan 12th, BUNK will be comping us some free pitchers of beer and some sandwiches! It's not bottomless (I think we're capped at something like 4 pitchers and 15 sandwiches), but I think it's a nice gesture.  If you're comin
Categories: DorkbotPDX, Mailing Lists

VS1053 Troubleshooting - Fri, 2014-12-12 10:30

Last night, I looked into why Adafruit's VS1053 only works with Teensy 3.1 at 24 MHz, but not 48, 72 or 96 MHz.

Turns out, the library depends SD.begin() to reconfiguring SPI.  It also runs data transfer code from both main program & interrupt context (causing havoc if the interrupt occurs at the wrong moment).  Pretty amazing it's worked on AVR for so long, but apparently it does crash sometimes.  Faster processors increase the opportunity for the problem to strike.

Hopefully my edits from last night will fix these problems for good.


Categories: DorkbotPDX,

Christmas lights notes - Tue, 2014-12-09 22:28

PySerial will tell you that the following baud rates are supported:
(50, 75, 110, 134, 150, 200, 300, 600, 1200, 1800, 2400, 4800, 9600, 19200, 38400, 57600, 115200, 230400, 460800, 500000, 576000, 921600, 1000000, 1152000, 1500000, 2000000, 2500000, 3000000, 3500000, 4000000)

But it's lies, all lies!!  Well, some lies.  The fact of the matter is that by default the Raspberry Pi baud clock is set to 3 MHz, and the smallest baudrate divisor is 16, leading to a maximum baud rate of 187500, well below our target.  To remedy the situation we need to increase the base clock.  In order to do this, edit /boot/config.txt and add the following line:

init_uart_clock 100000000

100 MHz makes for a nice 2 Mbaud divisor of 50.

Categories: DorkbotPDX,

Improving Arduino's Serial Monitor Performance - Sat, 2014-12-06 20:57

Today I worked on the toughest Arduino bug... keeping the serial monitor from locking up or crashing with maximum speed printing from Teensy 3.1 and Arduino Due.

Here's Technical details and mini rant about Java performance.  Hopefully this (and other good work) will lead to future Arduino versions with a serial monitor that doesn't suck.

Categories: DorkbotPDX,

Strain Relief - Mon, 2014-12-01 00:50

I've struggled with appropriate wire-to-board connections over the years.

Here's one of OMSI's mainstays that I've co-opted that I'd like to share: 

all you do is

Step 1: add a hole in your printed circuit board

Step 2: route the wire through the hole

Step 3: solder the wire to the board

in this case its a 22 gauge wire, 0.1" through hole for strain relief, and a 18 gauge pin hole to solder to.

 Wire is strain releived at the board. Connector is off the board

Shift registers for 64 inputs/outputs and their wires.

Categories: DorkbotPDX,

Six Years of USB Development - Fri, 2014-11-28 13:54

Six years ago, in early Deceber 2008, I left the simple world of serial-based development behind and went native USB, releasing Teensy 1.0.  So much has happened and I've learned a lot in just 6 years.  I used to do everything by 9 pin RS-232 serial ports.  Those days seem so distant.

I'm now working on new and really awesome USB features for 2015...

Categories: DorkbotPDX,

Better SPI Bus Design in 3 Steps - Mon, 2014-11-24 18:11

Most Arduino SPI tutorials show this simple but poor SPI bus design:

A much better SPI bus design can prevent conflicts.  3 simple improvements are needed:

  1. Use pullup resistors on all chip select signals.
  2. Verify tri-state behavior on MISO: use a tri-state buffer chip if necessary.
  3. Protect bus access with SPI.beginTransaction(settings) and SPI.endTransaction().

Click "Read more" for details on these 3 steps.

Step 1: Pullup Resistors for Chip Select & Reset Signals

When multiple SPI devices are used, and especially when each is supported by its own library, pullup resistors are needed on the chip select pins.

Without a pullup resistor, the second device can "hear" and respond to the communication taking place on the first device, if that second device's chip select pin is not pulled up.  This is easy to understand in hindsight, but it can be temendously confusing and frustrating to novice Arduino users who purchase shields or breakout boards without pullup resistors.  Each SPI device works when used alone, but they sometimes mysteriously fail when used together, only because both devices are hearing communication meant to initialize only the first device!

A simpe workaround for devices without pullup resistor involves adding code at the beginning of setup.

void setup() { pinMode(4, OUTPUT); digitalWrite(4, HIGH); pinMode(10, OUTPUT); digitalWrite(10, HIGH); delay(1); // now it's safe to use SD.begin(4) and Ethernet.begin() }


Step 2: Proper MISO Tri-State Behavior

Most SPI chips will tri-state (effectively disconnect) their MISO pin when their chip select signal is high (inactive).

However, some chips do not have proper MISO tri-state behavior.  Fortunately, checking MISO tri-state is easy, especially when prototyping on a breadboard.  Just connect two 10K resistors to the MISO line, like this:

When all SPI chips are disabled, the MISO signal should "float" to approximately half the Vcc voltage.  If any device is still driving the MISO line, you'll see a logic high (usually close to 3.3V or 5.0V) or logic low (close to zero volts).  This test is so easy, it should always be performed by designers of Arduino compatible products.

Arduino shields and breakout boards with poorly-behaved chips should always include a tri-state buffer.  Adafruit's CC3000 breakout board is a good example:


Step 3: USB SPI Transactions in Software

Newer versions of Arduino's SPI library support transactions.  Transactions give you 2 benefits:

  • Your SPI settings are used, even if other devices use different settings
  • Your device gains exclusive use of the SPI bus.  Others will not disturb you.

These improvements solve software conflicts, allowing multiple SPI devices to properly share the SPI bus.

A typical use of transactions looks like this:

SPI.beginTransaction(SPISettings(14000000, MSBFIRST, SPI_MODE0)); digitalWrite(chipSelectPin, LOW); SPI.transfer(mybyte1); SPI.transfer(mybyte2); digitalWrite(chipSelectPin, HIGH); SPI.endTransaction();

SPI.beginTransaction() takes a special SPISettings variable, which give the maximum clock speed, the data order, and clock polarity mode.  The speed is give as an ordinary number, expressing the maximum clock speed that device can use.  The SPI library will automatically select the fastest clock available which is equal or less than your number.  This allows your code to always use the best speed, even on board with different clock speeds.

If your code will ever call SPI library functions from within an interrupt (eg, from attachInterrupt), you must call SPI.usingInterrupt().  For example:

SPI.begin(); SPI.usingInterrupt(digitalPinToInterrupt(mypin)); attachInterrupt(digitalPinToInterrupt(mypin), myFunction, LOW);

If you are developing a library that must be compatible with older versions of Arduino, which lack these SPI transaction functions, you can use SPI_HAS_TRANSACTION to check for the new version.  For example:

#ifdef SPI_HAS_TRANSACTION SPI.beginTransaction(SPISettings(2000000, LSBFIRST, SPI_MODE1)); #endif


Please Share and Use This Information

Today many SPI-based products for Arduino do not work well together.  My hope is this information can help all makers of Arduino compatible devices to achieve much better compatibility.

Long-term, sharing of knowledge is needed.  Please share this information and ask makers of SPI devices and libraries to consider these suggestions.

This article may be shared and copied under the terms of the Creative Commons Attribution 4.0 International License.  Please, copy & share!  :-)



Categories: DorkbotPDX,

[dorkbotpdx-announce] Fwd: Byte Me 4.0 Call for Submissions

dorkbotpdx-announce - Sun, 2014-11-23 12:58
AFRU Gallery has an open call for works for Byte Me 4.0, their annual showcase of technological art. This is a great opportunity to polish up and show off a project you've been working on... Call for works is below: -------- Forwarded Message -------- Subject:         Byte Me 4.0 Call for Submis
Categories: DorkbotPDX, Mailing Lists

Making nRF8001 (Bluetooth LE) and SD cards play nice together - Sun, 2014-11-23 04:30

Been working on making Adafruit_nRF8001 and the SD library work together.  Details are on this forum thread, and also this one.

Categories: DorkbotPDX,


DorkbotPDX Flickr Group - Thu, 2014-11-20 11:16

atduskgreg has added a photo to the pool:


NaNoDrawMo 2014 #36


DorkbotPDX Flickr Group - Thu, 2014-11-20 11:16

atduskgreg has added a photo to the pool:


NaNoDrawMo 2014 #35

This is how we disappear - projection notes - Mon, 2014-11-03 16:03

I’ve been meaning to document my work on this project for about year now. TBA 2014 reminded me it is time to actually do it! So here it is:

For the past year and a half I’ve been working with a dance company called bobbevy. I’ve been creating graphics that go along with the dance performance called “This is how we disappear”. Here’s a review at Portland Monthly.


This is how we disappear - projection edit from Brian Richardson on Vimeo.


More behind the scenes information after the break!

Jesse Meija was doing music and got me involved with this project, I’m very grateful!

Version 1

Effects for the first set of performances:

  • A forest of trees created from a drawings by David Stein.
  • Particle effects that mimiced the dancers movement.
  • Particle effects that just fly across the screen

In order to accomplish this, I wrote a piece of software that would do the animation and handle tracking the dancers. There were two versions, the first version was used to perform a few times. Notably Dance+ in 2012 and as part of Experimental Half Hour XXXVII. It consisted of the following pieces:

  • Cinder, used as a framework
  • Freenect, used to interface to the Microsoft Kinect.
  • Control, used to control the software from an iPad

This version worked ok. Before I started using Control, I had been triggering all of the sequences with keyboard commands. It worked fine, but I had to have a cheatsheet that told me what keys did what. Also, each command just mutated the state of the program, so if you triggered things in a different order you’d end up in different states. This made some rehersals hard, because it was difficult to return the graphics to a previous state. However, with Control, it became easier to use the software. bobbevy performed in Milwaukee without me and was able to use the software just fine! For Dance+ the Kinect refused to work in the studio, I think because the temperature in the room was so high. So I ended up “drawing” the dancers with a multi-touch interface in Control.

For the particle effects that followed the dancers, I ended up using blob tracking and distingugishing blobs based on distance away from the Kinect. I liked the stateless design because the dancers would move in and out of view of the Kinect and I feel that keeping track of them properly would have been a nightmare. This created some surprising benefits though. The swarms move between the dancer when their relationship to the Kinect changes and it created some really nice animations. Also, this piece has a lot of tension between the dancers and the particles ended up expressing some tension when the dancers were about the same distance away from the Kinect.

Version 2

Additional effects for the second set of performances:

  • Static/simple projection mapped screens (similar to my Party House project).
  • Realtime projection mapped patterns on the dancers bodies

This second version of the software was used to perform at NW New Works Festival 2013 and at TBA 2013.

For the second version of the software, I used the following new pieces:

  • QTimeline, this is a timeline that allows one to control tweens of variables
  • QuNeo, as much as I liked Control using a touchscreen while not looking at it (I had to look at the dancers for my cues!) is not ideal. A physical controller allows you to rest you finger on the button/slider you need to push without triggering it. (The cool kids pronounce it keeen-wah).
  • LabMidi, used to interface to the QuNeo
  • For TBA, 3, yes 3! Projectors. Two of them were used to cover the wide background, and one was used to project onto the dancers themselves.

The timeline solved many problems for me. It took what I used to have hard code in the application (fade times, animation speed, etc) and moved it to a data format. The editing GUI was nice to have as well. A new version of Cinder that made using multiple displays easier to use was really nice to have as well. I didn’t need to mirror my desktop screen anymore, which meant I could display debug and other helpful info on my screen. The QuNeo also allowed me to directly control ramp parameters which meant I didn’t need to rely on predetermined fades as much. This also allowed me to be more engaged with the visuals which was really fun. I think the trick to this will be finding the right balance between direct control and triggers to presets. It is probably the same balance electronic musicians search for.

The newest effect for the second run was the projection mapped dancers. In order to accomplish this, I was going to have to find the dancers with the Kinect and then project onto them as close as possible. I used the vvvv patch from here as a starting point to learn how to calibrate my projector with the Kinect. In the end, I wrote my own calibration code because it fit the setup workflow a bit better.

The projection mapped dancers worked pretty well. I was really excited to see them turn into just an indistigushable mass at moments and then turn back into dancers the next. I think this is what projection mapping should do: transform objects and confuse you, then bring you back to reality. I hope to do more of this in the future!

Cross posted from my blog.


Categories: DorkbotPDX,
Syndicate content