Building my Polysix Velocity Processor

Today it starts.  We've talked enough about my dreamy dreams of velocity sensitivity for my Korg Polysix.  It's time to get down to business.  It's time to apply what I've learned about its multiplexing and about its synchronization.  It's time to build something.  Let's smell the solder!

First Generation "Velocity Processor" Installed in my Polysix

Where to Insert My Circuity:  Before I solder anything, I need to figure out where I am going to insert my "Velocity Processor" into the Polysix circuit.  As discussed in my previous post, I want to put it after the multiplexer (IC24) but before any of the other envelope and VCF processing.  The figure below shows, notionally, how I'll use several of the signals associated with IC24.  What is the easiest way to get physically access to these signals?

Use the IC24's Socket!  When I opened up my Polysix and too a look at IC24 to see what connection points might be available, I was immediately struck by the fact that IC24 is socketed!  By pulling IC24 out of its socket, I now have instant, easy, and easily-reversible access to most of the signals that I need!

Here is the socket for IC24.  The perfect place for inserting my Velocity Processor.

Which Holes for Which Signals:  Looking at the Polysix schematic, I see that I can get almost all of my signals from this one socket: +5V power and ground, the three addressing lines (A,B,C), the inhibit line (INH) as well as a place to inject my velocity-modified, multiplexed envelope signal.

The signals that I will use for my Velocity Processor -- all available from the socket for IC24.

How to Connect to the Socket:  While the socket is a very convenient way to get signals without modifying the Polysix PCB, I still had to find the right hardware that would mate into the socket.  After trying a few options, I found that the legs on the Arduino-style "stackable" headers fit very nicely into the socket.  My plan, therefore, would be to mount the stackable headers to a protoboard, solder them in place, and have their legs reach down and mate to the socket.  Since these stackable headers have really long legs, they'll let the protoboard (with all of my other components) stand above the other components on the Polysix PCB.  It'll be great!

Arduino-style "stackable" headers fit into the Polysix IC sockets.

Why Not Use Regular 0.1" Pins?  Arduino fans may immediately wonder why I'm using these stackable headers when it appears that 0.1" male pins (also popular with Arduino projects) would be cheaper and less bulky.  In fact, I did try to use these pins.  But they don't fit in the socket.  After looking at the detailed geometry of these pins versus the legs on the stackable header (shown below), I found that the pins are indeed thicker than the legs on the stackable header (0.64 mm vs 0.40 mm).  That's the reason that the pins don't fit.  That's the reason I'm using these stackable headers.  [Note: If you really want to use pins, perhaps the 0.45 mm pins of the Samtech TS-108-T-A will work.]

The common 0.1" male pins are too thick to fit. But pins the stackable female headers are thin enough to work.

General Configuration:  After looking at the space inside the Polysix, and after looking at the size of the protoboard that I had on-hand, I decided to configure the basic elements of my Velocity Processor as shown below.  The stackable headers are shown on the bottom right.  The digipot is on the left.  The Teensy 3.1 microcontroller is on the top.  Now we just need to figure out the wiring.

Here is my high-level plan: a Teensy 3.1 plus a digipot plus a pair of stackable headers.

Connections to the Teensy:  Below is a picture of the Teensy with the pins labeled.  It shows which pins I'm going to use for the various connections.  Remember that the Teensy is only a 3.3V device whereas the Polysix's digital signals (the A,B,C addressing lines and the inhibit line) and the Serial connection from my Arduino key Assigner are all 5V signals.  Luckily the pins on the Teensy 3.1 are 5V tolerant, so I can attach those lines to the Teensy without damaging it.  Another side-effect of the Teensy being 3.3V is that its SPI connections to the digipot will also be 3.3V signals.  Therefore, the digipot will have to be provided with a 3.3V reference, which will come from the wire that I show attached to the Teensy's 3.3V supply.

Connections to my Teensy 3.1

Connections to the Digipot:  Below is a figure showing connections that I'm making to the pins of my digipot.  As mentioned above, the SPI logic signals are at 3.3V, so I connect the "VL" logic reference (pin 12) as well as to the other logic pins.  The multiplexed envelope signal (my "input" to the digipot), however, can span 0V to 5V.  Therefore I set VDD to +5V and VSS to ground.

Connections for the Digipot to handle the 0V-5V Multiplexed Envelope Signal

The Wiring Plan:  The figure below shows my wiring plan for the Teensy, digipot, and IC24 socket.  Of course, I still need IC24 itself to function within the circuit.  Therefore, I had the brilliant idea to insert another IC socket into the stackable headers!  Isn't that brilliant!?!  I happened to have a spare IC socket whose legs seemed just long enough to fit in the big holes of the stackable header.  So, I can build my velocity processor as shown below, insert the board into the vacated socket for IC24, and then stick IC24 into my board.  That's the plan, at least.

The First Wiring Diagram for my Velocity Processor.  Note IC24 sitting on top of the stackable headers in the bottom right.

The Wiring Reality:  Below, you can see the protoboard after I wired and soldered everything in place.  You can even see how I inserted IC24 in place.  On the underside of the board, you can see the pins sticking out that will fit into the Polysix's socket for IC24.

The first version of my Velocity Processor

Testing It:  At the top of this blog post is a picture of this first version of my Velocity Processor mounted within my Polysix.  While it did do something, I quickly discovered that my plan of sticking IC24 on top of the stackable headers wasn't working.  The pins of my add-on IC socket did not mate securely nor reliably to the stackable header.  Sad.

The New Wiring Plan:  The solution to this problem was to move IC24 off the stackable headers and down onto the protoboard.  I had resisted doing this because it mean adding 16 wires (one for each leg of IC24) between the stackable headers and the new spot for IC24.  It was going to be an annoying task, but I needed to do it.  <Sigh>

The Second Wiring Diagram for my Velocity Processor.  Note that IC24 has been moved and 16 additional wires have been added to connect it to the circuit.

The Completed Wiring:  Below is a picture of my Velocity Processor after moving IC24.  You can see it on the top right.  You can also see the rainbow of wires that I had to add to connect IC24 back to the stackable headers.  All those extra wires sure made it ugly.  But, the task is done.

By moving IC24 to its own spot on the top right, the extra wiring really made it ugly.

Plugging It In:  Below is a picture of my revised Velocity Processor mounted within my Polysix.  All of the signals that it needs come up through the IC24 socket into which it has been mounted.  The only exception is the serial communication signal that comes from my Arduino Key Assigner.  That simplicity is pretty nice.

My revised "Velocity Processor" installed in my Polysix. 

Next Steps:   I need to finish the software on the Velocity Processor and I need to write the companion software for the Arduino Key Assigner so that it conveys the velocity data from the keybed to the Teensy.  Then I can test it and make sweet, sweet music.  Stay tuned!

Update:  It lives!  Check out the demo here.

Velocity Sensitivity - Addressing and Synchronization

In my previous post, I explored how the Polysix multiplexes the VCF envelopes so that one circuit could affect the envelopes for all six different voices.  My goal is to modify each voice' VCF envelope intensity based on the velocity of the note's keypress.  If I am to modify the multiplexed VCF envelope signal based on each voice's velocity, I need to know which voice is on the multiplexed line at each moment in time so that I can apply the correct velocity adjustment for that voice.  The Polysix keeps track of this information via the addressing and synchronization lines used in the multiplexing circuit.  It is these elements that I'm going to explore in today's post.

My plan is to insert my "Velocity Processor" circuitry right after the envelope signals have all been multiplexed by IC24 onto a single line.  The trick is to know which voice is on the multiplexed line at any given moment in time.  This is handled by the synchronization and addressing lines generated by IC12.

Always Look at the Schematic:  When trying to understand the circuit, I always start with the schematic.  Below is an excerpt from the Polysix schematics that show the elements that process the envelopes for the VCF.  The multiplexer is down on the bottom right (IC24) which time-slices all six voices' envelopes to put them onto a single line.  The dark red line is the multiplexed envelope signal.  At the end of the dark red line is the demultiplexer (IC23), which breaks up the multiplexed signal back into the six individual VCF control signals that are sent off ot the six individual voices.  This multiplexing and demultiplexing system only works if the two elements (the multiplexer and demultiplexer) stay in sync.  Synchronization is effected through the addressing line (in blue) and the inhibit lines (in green). It is these signals that I will be looking at.

Korg Polysix VCF Envelope Processing Circuits.  Red line is multiplexed VCF envelope, which then becomes the general VCF CV.  To keep the multiplexer and demultiplexer in sync, the blue lines are the addressing lines and the green lines are the inhibit lines.

Addressing:  If I am to manipulate the multiplexed signal based on the velocity of each note, I need to know which note (which voice) is on the multiplexing line at every moment in time.  The Polysix maintains this information on the blue address lines (A,B,C) that you can see originating from IC12 and that connect to both the multiplexer (IC24) and the demultiplexer (IC25).  The signal on each address line can be either HIGH (5V) or LOW (0V).  Between these three address lines, there are eight different combinations of HIGH and LOW, which means that there are enough combinations to each of the six voices to be associated with one of the eight possible HIGH/LOW combinations.  A particular combination of HIGH/LOW signals, therefore, is an "address" that defines which voice is currently being serviced.

Which Voice For Which Address?  The address signals themselves are generated by IC12, which is a simple binary counter (datasheet).  As a result, you can think of the (A,B,C) address as a 3-bit binary number, where a HIGH voltage corresponds to one for that bit and a LOW voltage corresponds to zero for that bit.  IC12 keeps incrementing that 3-bit number from 1 to 8, over and over, in a never-ending loop.  [Well, actually, it loops over 0 to 7, not 1 to 8, but you get the idea].  As might be expected, the first address points to the first voice, the second address to the second voice, and so on.  Note that the last two addresses are unused -- they exist simply because the dumb binary-counting IC12 is not smart enough to skip address codes that might be unused.

Responding to the Address Lines:  To correctly modulate the multiplexed envelope signal, my Velocity Processor needs to know which voice is being serviced at each moment in time.  Therefore, my Velocity Processor will have to tap into the addressing lines in order to stay synchronized with the mulitplexing.  To interpret those addressing lines, my Velocity Processor must have some sort of "smarts" in order to generate the correct response based on the current address (ie, voice) being indicated.    In other words, my Velocity Processor will have to include a microcontroller that listens to the address lines.

Velocity Processor Configuration:  My Velocity Processor will have two parts -- a microcontroller to respond to the address lines and a digital potentiometer to actually apply the adjustment to the multiplexed envelope signal.  This combination of microcontroller and digipot will be my "Velocity Processor".  As shown in the figure below, I am going to insert my Velocity Processor right after the multiplexer (IC24).  It is a convenient location to get access to both the multiplexed envelope signal and to all of the addressing lines.

Conceptual Design for Attenuating the VCF Envelope Based on a Note's Velocity

How to Change the Multiplexed Signal:  As discussed in the previous post, my plan is to attenuate each voice's VCF envelope based on the voice's note velocity.  The slower the note's velocity, the more attenuation that I am to apply to that voice's envelope.  The digipot is a perfect component to do this function because attenuation is what potentiometers do, and because it is digitally controllable from a microcontroller.  The challenge is for the microcontroller and digipot to keep up with the rapidly-changing multiplexed envelope signal.

How Fast Must The Microcontroller Respond?   If my Velocity Processor is to manipulate the multiplexed signal, it has to to keep up with the multiplexing rate.  More specifically, the multiplexing circuitry includes a "deadband" window of time where it switches between voices -- it is within this deadband that the Velocity Processor must start and finish its task of applying the correct per-voice envelope manipulation.  In the Polysix circuit, this window for action is defined by the INH ("inhibit") signals sent to the multiplexer and demultiplexer.  When the multiplexer and demultiplexer are inhibited, it is our time to act.

Analyzing the INH Signals:  A close look at the schematic shows that there are two INH signals -- one that goes to the multiplexer (IC24), and a different one that goes to the demultiplexer (IC23).  The screenshot below shows these two INH signals over several multiplexing periods.  Whenever the INH signal is HIGH, that's when the output signal is blocked, and that is our time to act.  As can be seen, the multiplexer is inhibited for a short period of time (6-7 microseconds), while the demultiplexer is inhibited for a longer period of time (20 microseconds).  Somewhere in between is the right requirement for my Velocity Processor.

The "Inhibit" Signals Driving the Multiplexer (IC24) and De-Multiplexer (IC23).  These signals define how quickly my new velocity processor circuit must respsond.  It must respond in at most 20 usec, and preferably within 6-7 usec.

It Can Respond Feast Enough:  Lucikly, in a recent post, I showed that my Teensy 3.1 could update my digipot in under 2 microseconds.  Therefore, my Velocity Processor is definitely fast enough.  That's great.

Pulling it All Together:  My plan is to implement a velocity sensitive VCF envelope by manipulating the multiplexed envelope signal.  I found that a set of address and inhibit lines are used by the Polysix to keep the multiplex process synchronized.  If my Velocity Processor is to also be synchronized, it must include a microcontroller that listens to those address lines and responds based on the specific voice being indicated.  I then looked at the timing of the multplex-demultiplex "deadband" window and found that my microcontroller is indeed fast enough to make its changes within that constrained period of time.  As a result, I'm feeling really confident in my approach.

My "Velocity Processor" will be a new element added to my highly-modified Polysix

Building It:  I've already prototyped the digipot + Teensy, so I know that it works and that it is fast enough.  Now I have to figure out how to physically insert it into the Polysix's signal path.  Then, I have to wire it all up, write some software, and start testing.  I'm wicked excited!

Update:  I've built it.  Check it out here!

Velocity Sensitivity - Understanding the Multiplexing

As discussed in my previous post, I have a dream of adding velocity sensitivity to my Korg Polysix.  My replacement keybed already generates the velocity data, I just have to figure out how to use the data.  My plan is to have the velocity affect the intensity of the envelope applied to the filter (VCF).  The harder I hit the key, the more of the envelope signal is applied to the VCF.  Should be easy, right?  Well, it turns out that the Polysix uses a lot of multiplexing to handle its polyphony, including its VCF control.  This post is about understanding the multiplexing so that I can adjust the envelopes based on note velocity.  Let's go!

The Simplified View:  To figure out how the VCF envelope is applied to the VCF, I looked at the Polysix schematic.  Being a six-voice synth, one might expect that six individual circuits are used to apply six individual envelopes to six individual filters.  But this is not the case.  To save money, the designers used multiplexing so that a single circuit could be used to service all six voices.  When I look at the schematic, I do see that there are six circuits used to create the six envelopes.  But then, at IC24, I see that these six envelope signals are multiplexed into a single time-sliced signal.  The single multiplexed signal is then passed through a circuit that combines the envelopes with the VCF cutoff, the VCF key tracking, and the VCF LFO modulation.  At the end of the circuit, IC23 demultiplexes the time-sliced signal back into six individual control voltages that go off to the filter circuit for each voice.

The Detailed View:  With that overview, I have excerpted the real schematic below and highlighted the signal path specific to the VCF envelope.  As can be seen, the six envelope signals enter at the bottom left.  At IC24, they are multiplexed, at which point the time-sliced envelope signal follows the thin red line through the modulation circuit.  Finally, it ends up back at IC23, were it is demultiplexed back into six control signals for each voice's VCF.  Somewhere in this signal path,  we will make a modification to allow us to modify the VCF envelope based on the note velocity.  To decide where and how to make that modification, I need to better understand how the multiplexing works.

Korg Polysix VCF Envelope Processing Circuit, with Annotations

What Does the Multiplexed Signal Look Like?  I hooked up my oscilloscope to the multiplexed signal line shown in the schematic above.  I hit two keys on the keybed and saw what the multiplexed envelope signal looks like.  In the screenshot below, you can clearly see that two envelopes were triggered.  You can also see that the two envelope signals have been sliced up and interleaved.  This is what multiplexing does, it slices up multiple signals and interleaves them onto a single line.  Looks pretty straight-forward, eh?  Let's zoom in, just to be sure of the details.

Voltage at R58.  Two envelopes are multiplexed onto one line.  The second envelope was triggered 6 msec after the first.

Zoomed View:  The picture below is a zoomed in view of the multiplexed envelopes.  As can be seen, there is a repeating signal that contains two two non-zero voltages.  The first voltage value corresponds to the envelope for Voice #1 at a that specific moment in time.  The second voltage corresponds to the envelope for Voice #4 at its moment in time.  In the time between those two voltages, the voltage is zero because none of the other voices are active.  If the other voices were active (as shown later), there would be signal here.  Since the notes are off, there is no envelope, so there is no signal in that time slot.  Easy.  [As a side note, we see that the mutiplexed signal appears to have a cycle of ~310 microseconds, which means that each voice's envelope gets updated at a rate of 3.2 kHz.  I'm actually a bit surprised that it is that slow.  I expected faster.]

Zoomed in view.  Two envelopes on one line.  The second envelope is the Polysix's voice #4 (out of 6).  Note that the pattern repeats every 310 ms, which means that the envelope for each voice is only updated at 3.2 kHz.

All Six Voices Active:  To further illustrate how the envelopes are multiplexed, the screenshot below shows the multiplexed signal when all six voices are active.  In this case, all of the envelopes were triggered at the same time (Unison mode!) so all of the envelopes are showing approximately the same (non-zero) value.  The critical detail here is that we see six period's worth of non-zero signal.  Those are the six voices.  Curiously, we also see two periods of zero signal.  These extra two slots ("slot 7-8") are, in my opinion, purely an artifact of how the addressing is done to keep the multiplexing and demultiplexing in sync with each other.

View at R58 with all six voices active.  Note the empty space, which implies a voice #7 and #8 (which don't exist).

The Vision for Velocity Sensitivity:  Now that I see how the multiplexing works, I can also see how I can modify the envelope signal based on the velocity of each key press.  I think that I can work directly with the multiplexed signal.  In my illustration below, the left portion of the figure is the multiplexed envelope signal as created by the Polysix.  Each color represents the time slice that is associated with each of the six voices.  My idea is that I can introduce a new circuit -- my "Velocity Processor" -- which can attenuate the envelope signal for each voice, depending upon the velocity of the note assigned to that voice.  As long as my Velocity Processor responds fast enough to keep up with the multiplexing, it can affect each voice independently of the others.

Hardware Configuration:  I like this plan -- to simply modify the multiplexed envelope signal based on each notes velocity.  Looking back at the Polysix's hardware, it looks like the right place to introduce my Velocity Processor would be right after the IC24 Multiplexer, as illustrated in the simplified view below.  This location gives me access to the multiplexed envelope signal, but it is before the signal gets too complicated by the rest of the VCF CV processing, where the cutoff, key tracking, and LFO modulations are applied.

Next Step:  The key to this approach is that I want to independently modify each voice in the multiplexed signal stream.  This means that I need to know which voice is on the multiplexed line at each moment in time.  As a result, I really need to dig in and learn about the synchronization and addressing scheme used by the multiplexer.  Figuring this out will be the topic of my next post.

Update:  I figured out the addressing and timing of the multiplexing.  Check it out here.

Update:  I finished the mod.  Behold: Velocity Sensitive Polysix!

Velocity Sensitive Polysix - The Dream

As regular readers know, I've done many modifications to my Korg Polysix.  Probably the biggest change was when I swapped out the original keybed for a new one (Fatar, FTW!).  My goal with the new keybed was to add aftertouch to my Polysix, but a side-benefit was that the new keybed was also velocity sensitive.  Unfortunately, the velocity capability has gone unused because the Polysix had no obvious way of including its effect.  Today, though, that begins to change.  Today, I plan out how to add velocity sensitivity to the Polysix.  Behold, the VelocitySix!

Dreaming a Dream of a Dreamy, Velocity-Sensitive, Korg Polysix.  (Fake Graphic)

What Do I Want Velocity to Do?  This is the first question that I asked myself.  What do I want the velocity to affect?  In other synthesizers, the two most traditional answers would be to affect the intensity of the filter (VCF) envelope or of the amplitude (VCA) envelope.  Personally, I've always been a bigger fan of velocity-sensitive VCF, so that's what I decided to target (first, at least).  My idea, therefore, is to add circuitry that will scale the envelope based on the velocity of the keypress.

Scaling the VCF Envelope Based on the Note Velocity

Adding More Hardware:  As can be seen in the figure above, what I need is some hardware that can scale (attenuate) the existing envelope signals.  As discussed in my recent posts, my plan is to do this velocity-dependent attenuation using a digital potentiometer that is driven by a Teensy microcontroller.  I'll simply send the MIDI velocity value for each voice to the Teensy and it will drive the digital potentiometer to adjust the overall amplitude of that voice's VCF envelope.  I'll call the Teensy + digipot my "Velocity Processor".

Piecing it All Together:  The figure below shows all of the components that I've added to my Polysix.  For the addition of velocity sensitivity, I've added my new "Velocity Processor" and highlighted it in yellow.  It is important to realize that I can add this velocity sensitivity only because of my previous modifications.  Without having replaced the built-in keybed with my own keybed and keyscanner, I wouldn't have the velocity values in the first place.  And, without having replaced the built-in "Key Assigner" CPU with my Arduino Mega, I wouldn't know which velocity value to associate with which voice.  It is only through my prior work that this new modification is possible.  [Note: the DAC on the right side of the figure is irrelevant to the velocity sensitivity, but it is crucial for my portamento and detuning modifications.]

My Highly-Modified Polysix.

Building and Testing:  My upcoming posts will discuss the details of how I will manipulate the envelop signals, how I built and tested the new electronics, and how it all sounded when I was done.  This is gonna be fun!

Update:  I've worked out how the Polysix multiplexes its VCF envelopes.

Update:  I've worked out how the Polysix multiplexing handles addressing and synchronization.

Update:  I've wired up the Velocity Processor.

Update:  It works.  It's sweet.  Here are the demos!

Teensy with AD5260 Digipot

Yesterday, I showed how I soldered a surface-mount digipot, connected it to an Arduino Uno, and got an update rate of just over 60 kHz.  It was pretty fun to get the whole thing working so well.  For my envisioned use of this thing inside my Korg Polsix, however, I need a microcontroller with a little more speed than the Arduino.  It needs to be able to drive the digipot at high speed and do other tasks like listen to messages coming over the serial line.  This post is about using a Teensy to drive the digipot instead.  How fast can it go?

Showing my Teensy 3.1 in the foreground.  It is indeed small.  In the back right is my digipot on its Adafruit SMT-to-DIP adapter board.  An Arduino Uno is in the back left, but it is just being used as a power supply to provide 5V.

What is a Teensy?  Teensy is family of microcontroller boards, like the Arduino is a family of microcontroller boards.  Teensy is aimed at folks who like the Arduino approach but who need something more capable.  In my case, I'm using a Teensy 3.1, which has a 32-bit processor that can run up to 96 MHz.  This is a lot more capability than the 8-bit, 16 MHz processor in the Arduino Uno.  Raw speed, however, isn't my only concern.  The Teensy is appealing to me because you can program it through the Arduino IDE and not have to learn some new way of programming microcontrollers.  Re-using what I know, yet getting more capability.  Sounds like a win-win situation.

Wiring the Digipot for 3.3V Operation:  One somewhat-important difference between an Arduino Uno and a Teensy is that the Teensy operates at 3.3V instead of the Uno's 5V.  This means that the whatever is connected to the Teensy (like my digipot) must be able to respond to the lower voltages.  Lucikly, my digipot is compatible with either 3.3V or 5V logic, so everything should work fine.  The biggest difference is that the output of the digipot (because of the now-smaller 3.3V input signal) will be limited to 0-3.3V, instead of the 0-5V signals seen with the Uno.  For this test, the smaller voltage output is not a problem.  This test is about speed.

Signals to use for testing the digipot with a Teensy 3.1, which uses 3.3V logic.

Wiring to the Teensy:  From the picture above, I'll drive the digipot by providing it power at 3.3V and by sending it commands over via the Teensy's SPI pins.  Looking at the pin map for the Teensy 3.1, I easily see the location of 3.3V and gnd.  Looking for the SPI pins, I see "CS", "SDOUT" and "SCK" on pins 10, 11, and 13, just like on the Arduino Uno!  Maybe that's by design, or maybe it was by coincidence.  Either way, it's comforting to see things being so similar.  So, overall all, as seen below, the wiring is basically the same as it was for the Uno.  Great.

Wiring a Teensy 3.1 to the my digipot via a solderless breadboard.
I connected power (3.3V), ground, and the three lines for the SPI bus.

Teensy Add-On for the Arduino IDE:  With the hardware elements all arranged, it's time to program the Teensy.  Since I want to do this via the Arduino IDE, I needed to first download the "Teensyduino" add-on from the maker of Teensy.  It's pretty painless.  During installation, the installer provides you the option to pre-install a bunch of libraries that Teensy supports.  I chose to install them all, but for this test, you probably just need to install the SPI library.  Either way, it's easy.  Once the Teensyduino software completed its installation, I started the Arduino IDE like normal.  Once it was open, I went under the "Tools" menu (as shown below) and told the Arduino IDE to target the Teensy 3.1 instead of the Arduino Uno.  Done.

I'm switching the Arduino IDE to target my Teensy 3.1 instead of my Arduino Uno.

Programming the Teensy:  With the Teensyduino add-on, my hope was that I could rely on all my Arduino knowledge and not have to learn a new command set just for the Teensy.  Relying on this hope, I simply opened up my existing digipot test program (written for the Arduino Uno) and told the IDE to recompile (Verify" in the language of Arduino).  It was successful!  It recompiled without any changes needed for the Teensy.  Fantastic!  Now, to actually transfer the program down to the Teensy hardware, one has to hit the pushbutton that's on the Teensy board.  When I did that, the program zipped down to the Teensy and I was good to go.  Very smooth.  Very nice.

Driving the Digipot with my Teensy:  With the Teensy programmed and ready-to-go, I hooked up all the wires between my breadboarded digipot and the Teensy according to the figure that I showed earlier.  I then plugged the Teensy into its USB cable (to provide power) and connected my oscilloscope to the output of the digipot.  I saw step-wise changing output voltages, just like I expected.  It worked!

My test setup.  Teensy on the bottom left.  Digipot on a solderless breadboard on the bttom right.  My oscilloscope shows a very quickly changing output signal from the digipot.  It works!

Is it Faster?  How fast could the Teensy change the pot's value?  Very fast.  Very very fast.  As shown in the screenshoot below, it was able to change the value six times in 8.1 microseconds (usec).  That's a mere 1.35 usec per change.  That's an update rate of 741 kHz!  By comparison the Uno required 16 usec, which was an update rate of 62.5 kHz.  So, the Teensy was about 12 times faster for this task.  That's fantastic.  Interestingly, the ratio of the their clock speeds (Teensy = 96 MHz, Uno = 16 MHz) is only 6x, so by actually showing a 12x increase in speed, it appears that the Teensy is much more efficient per clock cycle at this task than the Arduino.  Very cool.

[Note: Based on questions I've received...yes, I did disable the println() and delay() commands when testing at full speed.  I love that you folks are reading in this kind of detail! :) ]

Screenshot of the output of the digipot when being driven at full speed by the Teensy.  Note that it completes a six step cycle in 8.1 usec, which means that each step is only 1.35 usec, which means that the Teensy can drive the digipot with an update rate of 741 kHz.  Fast!

Extra Capacity for Other Tasks:  If I use this Teensy+Digipot setup in my nefarious plans for my Korg Polysix, I do not need it to update this fast.  At worst, I'll need it to update every 20 usec, which means that the Teensy can do its update at its native 1.35 usec speed and then wait around for the other 18.65 usec and do other tasks.  In other words, it'll only be busy (1.35/20) = 7% of the time.  The other 93% of the time, it'll be free to do things like servicing in-coming Serial messages.  I like having that much margin.  It gives me confidence that the Teensy can perform all of its tasks dependably.  My conclusion is that I've found my winning hardware combination for my Polysix modifications.

Surface Mount DigiPot with an Arduino Uno

For an upcoming modification to my Korg Polysix, I need to be able to attenuate an analog signal in response to the user's inputs.  This is a perfect task for a a digital potentiometer.  If I can, I'd like to control the digipot from an Arduino, because an Arduino is so easy to program.  There are two challenges with this plan, however.  First, my preferred digipot is only available as a surface mount device.  Second, I'm worried that the Arduino is too slow to drive the digipot quickly.  Well, I do like challenges, so let's just dive in and see where we can get!

Driving my digipot with an Arduino Uno.  How fast can it go?

Choosing my Digipot:  There are many digital potentiometers on the market.  For use inside my Polysix, I might need to put digipot in a place where it would need to control voltages ranging from -5V to +5V.  Most digipots cannot handle this kind of bipolar voltage range (most are just 0-5V).  Of the choices that I saw on Digikey for bipolar digipots, I chose to buy an Analog Devices AD5260 (link).  As you can see it in the picture below, it's a tiny little surface-mount device.  Scary!  (actually, don't be scared...it'll be fine)

Analog Devices AD5260 Digital Potentiometer.  Surface Mount!  Tiny!

Surface-Mount Adapter Board:  Because I'm usually just hacking stuff together, and because through-hole components are much easier to hack with, I don't have nearly zero experience soldering surface-mount components.  If I made my own circuit boards, I would certainly use more surface mount components because they save so much space.  For this hack, however, I need flexibility to plug, unplug, and reconfigure my circuit.  Therefore, I'm going to put my surface mount device onto a an adapter board that gives it legs like a through-hole component.  My digipot is a TSSOP-14 package, so I bought a TSSOP-14 adapter board from Adafruit.  It comes as a pack of 6, so I have spares in case I make a mistake.  :)

Mounting my surface-mount digipot to a through-hole adapter board.

Soldering Surface Mount ICs:  How do I actually do the soldering?  I talked with a co-worker who is extremely experienced in this area and he gave me a pile of good advice.  Two parts of that advice were: (1) use very fine (thin) solder and (2) use lots of flux.  Unfortunately, by the time I got around to soldering (days later), I had forgotten these two important details.  As a result, using my too-thick solder and using no extra flux, I created many solder bridges between the tiny legs of this tiny IC.  This is not what you want to do.  But, through perseverance, and through extensive use of solder wick to remove excess solder, I finally got the IC soldered no shorts or bridges.

Magnification (Or, How to Look Cool):  One piece of my colleague's advice that I did follow was to use some magnification.  He let me borrow an "OptiVisor" (see picture below).  It doesn't feel like it provides much magnification, but it is enough to give a clear view.  And, I'm learning that if you can *see* it, you can solder it.  The OptiVisor provides that.  They're also quite fashionable (that would be sarcasm).  

It definitely helps to use some magnification so that you can see what you're soldering.

Add Legs for Breadboarding:  The Adafruit adapter board has through-holes on either side for attaching pin headers.  As you can see below, I used a regular piece of 0.1" break-away pin header.  I broke off two seven-pin segments, temporarily placed them into my solderless breadboard, put the digipot board on top, and soldered the pins on.  This through-hole stuff is easy!

Soldering the pins to the breakout board so that I can easily prototype with the digipot.
Using a solderless breadboard keeps everything aligned while you solder.

Deciding How to Connect:  With the digipot's adapter board finished, I had to figure out how to wire up the device.  Below is a picture from the digipot's datasheet with my own labels added to show what I would connect to each pin.  All connections were going to my Arduino.  As you can see, there are a bunch of 5V and Gnd connections.  Commands are sent via the SPI bus, so there are also the three SPI connections (theSDO line is not needed as there is no communication needed back to the Arduino).  Finally, for the pot's input, I'll simply apply 5V, which means that my output will be a DC voltage that is scaled between 0-5V.

Signals to use for testing the digipot with an Arduino, which uses 5V logic.

Wiring to the Arduino:  The wiring plan shown above requires 12 connections.  Since I am usually prone to error when doing my wiring, I choose to draw up a little picture to fully illustrate to myself how I should use my solderless breadboard to make all of these connections.  This extra "design" effort really made the wiring process much easier.  It also made the wiring process more reliable.  Once I got the Arduino software working, the wiring of the hardware worked on the first try!

Wiring an Arduino Uno to the my digipot via a solderless breadboard.

Writing the Arduino Software:  To change the value of the digipot, I had to write some Arduino code to send commands to the digipot via the Arduino's SPI pins.  I started with the Arduino's built-in example called "DigitalPotControl".  While that code is simple and easy to understand, I wasn't sure if it runs the SPI bus as the fastest possible setting.  Speed is critical for using this in my Polysix, so this detail was worth a little effort.  After Googling around, I found the correct Arduino commands to control the SPI bus speed and I wrote my test program (SPI mode is zero!).  My program is shared on my GitHub here.

Initial Test:  My test program steps through a range of the digipot values.  It stops at each step for three seconds, which gives me enough time to confirm that its output is correct.  Because the input of my digipot is connected to +5V, my output will be between 0V and 5V.  For the picture below, the digipot was at a value of 125 (out of 255), which resulted in an output voltage being 2.47V.  Given that I expected (125/255*5) = 2.45V, I got pretty decent agreement.  In other words, it works!

First test.  It successfully created a voltage half-way between 0-5V. 

Testing for Speed:  Now for the full speed test.  I commented out the delay() and println() commands and restarted the system.  If used in my Polysix, there will only be 15-20 microseconds (usec) to change value of the digipot.  This means that the Arduino + digipot must support an update rate of 50-67 kHz, which seems pretty fast for an Arduino.  To see how fast my system was actually running, I connected the output of the digipot to an oscilloscope.  The full setup is shown at the picture at the top of this post.  A screenshot from the oscilloscope is shown below.

The Uno is changing the digipot as fast as it can.  It takes 16 usec per step, which results in an update rate of 62.5 kHz.

How Fast is It?  The picture above shows that the digipot is only being updated every 16 usec, which means it has an update rate of 62.5 kHz.  This is within my 50-67 kHz requirement.  So that's good, right?  Well, no, not exactly.  I am a little uncomfortable with the fact that there is no margin.

The Need for Margin:  In achieving this 62.5 kHz result, the Arduino is doing nothing but updating the value of the pot over and over endlessly.  That is all that the Arduino is doing.  In my envisioned hack for Polysix, however, my Arduino would need to do a few other tasks, as well.  For example, the Arduino will need to listen to its Serial port so that it can receive commands as to what values to use for the pot.  If the Arduino is running flat-out just to maintain a high update rate, it probably wouldn't have enough spare cycles to service the serial port.  That would be unacceptable.  So, while it is exciting that I got the system to operate this well, I think that the that the Arduino Uno isn't quite fast enough.  I need to try something else

Trying a Teensy:  My next step is to try a faster Arduino.  Or, an even better plan would be to step up to the fastest Arduino-like board that I know: Teensy 3.  But I think that'll have to wait until my next post.

Update:  My results with the Teensy are here.  The Teensy is *really* fast!