I changed it a bit by having the 4017 outputs drive transistors that switch current to the pitch pots (instead of turning on LEDS). Also, I triggered the chips RESET on step 4 instead of using all ten steps.

The sound is generated by a toy piano that I hacked up. Each of the four steps in the sequencer is routed through a 100K pot that varies the resistance to the piano and triggers different notes. I also threw in a touch point for garbling up the sound.

Here it is in action:

The basic schematics for the APC are pretty simple:

The entire thing is built around a cheap 556 dual timer IC. GetLoFi sells a kit, but I chose to get the parts from Mouser and wire it up on perfboard.

The APC is plenty noisy on it’s own, but I wanted to get a little more out of it: I replaced R1 with a photoresistor, added a touchpoint to pin 1 of the IC, and added a simple slide switch for toggling between two 500K pots for the main pitch control. I also removed the volume pot and went straight to a line-out because I’ll be plugging this into a mixer.

The mods give this APC some more character and make it way more fun to play with:

See you next week with a nifty DIY MIDI controller.

Here’s the first entry, a simple synth I built over a weekend based on a 555 timer IC. I used this schematic as a starting point:

I added a single 500K pot as a course pitch adjustment, and a board of resistors I pulled out of a toy piano to simulate some keys. I also converted the speaker output to a line-level output with a couple more resistors:

To play it, i have two probes from an old multimeter wired in line with the potentiometer. Touching the probes to opposite ends of something resistive (in this case, the resistor board contacts from the toy piano) cause changes in pitch.

Here it is in action:

The whole kit was pretty simple to put together, and DFRobot throws in a couple of nice extras like a toggle switch for power, and a female receptacle you can use for your charging system. All in all, it seems like a pretty sweet deal at ~$50.

I’m using the platform with an Adafruit Motor Shield and an Arduino to control the four included gear motors. This probably isn’t the optimal solution, because the yellow motors that come with the platform have a stall current of 1.5 amps at 3 volts. The Motor Shield has a max current of 1.2 amps per motor. I did some testing and couldn’t get the motors to pull more than 700mA so I should be OK, but it is something to consider.

The biggest hurdle in getting the platform working with the Motor Shield was the fact that the motors would not run consistently: they would stop and start at random intervals. After half a day of research, I came across this post describing exactly the symptoms I was experiencing. My solution was to solder .1uF caps across the leads on each motor. They’ve worked without a hiccup ever since.

My other big concern was load capacity. I’ve managed to carry about two pounds with the platform, but any more weight and it just won’t move.

My original steering plan for Pedro2 also would not work here. I had initially planned to rotate the robot by spinning the left and right wheels in opposite directions, like a tank. Due to the spacing of the tires, the four wheels actually work against each other when this is done and the tires will eventually work themselves right off the gear motors (they just press on to the motor nubs). My solution was to only slow the motors down on the side that I want to turn in. The turning radius is greater (no more turning on a dime), but the tires won’t pop off and all four motors will push the robot through the turn now.

So it wasn’t quite a plug and play solution, but it does look like this will be an adequate base for Pedro2. Here’s a quick shot of the upper level chassis I’ve put together paired with the mobile platform:

It was built only with an Arduino, a servo, and miscellaneous things I had laying around. The main body of the trap is made from two plastic Tupperware type containers. When the mouse enters the lower container to scope out the cheese and breadsticks I have in there, a small tripwire signals the Arduino to activate the servo. The servo has a string attached to it, which pulls a pin and allows the weighted upper plastic container to drop, effectively sealing the little invader and allowing me to humanely deposit it outside.

The trip wire is made from a flat piece of tin and a piece of small-gauge wire. The wire hovers over the tin by a fraction of an inch, and the slightest pressure forces it down to make a connection. It’s really just a super-sensitive homemade switch.

The code is pretty simple; really not much more than an adaption of the Servo code that can be found in the Arduino examples.

Arduino Mousecatcher source

I’ve got the trap situated in the corner I’ve seen the mouse poking around… now it’s just a matter of time.

Here’s the relevant specs of the system:

1. Intel Core 2 Duo T7500
2. Behringer UCA222 USB Audio
3. Broadcom 1395 WiFi
4. NVIDIA 8400M GS 128MB Video
5. Windows 7 Enterprise

The posts I linked to above have several solutions that have worked with varying degrees of success for different people, but nothing seemed to quite work for me. After spending most of a Saturday tinkering with this, I was able to find a solution.  Here’s what I did:

Download DPC Latency Checker. This little utility shows a scrolling bar graph that indicates the DPC (Deferred Procedure Call) performance of your computer.  The glitches in the audio stream are very clearly indicated by the big red sky scrapers.  This is what mine looked like:

The Broadcom 1395 WIFI adapter seems to be a recurring theme when it comes to DPC problems with this laptop, and unfortunately that’s the one I have installed. The first thing I did was download and install this hacked driver for the Broadcom adapter.

You need to choose ‘Browse my computer for driver software’ and then choose ‘Let me pick from a list of device drivers on my computer’ to get to the ‘Have Disk’  button that allows you to manually install the drivers.  Searching for the driver or allowing Windows to pick the best driver for your hardware won’t work.

After updating the driver, the audio glitches seemed to occur a little less frequently, but they were still there.  Time to break out the analysis tools and find out what was actually going on.

I downloaded and  installed the Windows Performance Toolkit which contains a few command line tools that allow you to analyze system performance at an individual process level. I have Windows 7, and this is part of the Windows 7 SDK. After installing the SDK, the WPT installer is located here:

You will have to navigate to that folder and double click the msi file to install it.

After everything is installed, open an Administrator command prompt by clicking Start -> All Programs -> Accessories, right clicking on Command Prompt and choosing ‘Run as administrator’. In the console window, start xperf with this command:

The performance monitor starts running in the background, logging data about all the running processes on your system.

The next step is to start DPC Latency Checker, and watch the pretty scrolling bars until you see a latency spike.  You should let it run for at least 20 seconds or so. After you see a spike, go back over to the console window and stop the performance monitor with this command:

This will stop the monitor from logging data, and write the results into the file trace.etl. At this point, you’ve got all the data you need to diagnose your DPC latency problem. 

Start the Performance Analyzer to view the results with this command:

You’ll see your trace data in a pretty line graph:

Scroll down to the DPC CPU Usage line chart, right click on it, and choose Summary Table.  You’ll see a summary of the processes that were captured in your xperf trace.  Click on the Max Actual Duration [ms] column heading to sort the processes by descending maximum duration. The process at the top (with a ridiculously high number) will be your culprit. (This screenshot is just an example, no offending processes here…)

In my case, it was dxgkrnl.sys with a max actual duration of something like 32 milliseconds, which is way out of line. It turns out that this process belongs to my NVIDIA 8400M GS laptop video card.

After some more research, I learned that Powermizer is the culprit. This is an NVIDIA service that toggles the speed of the graphics adapter based on need, so when you aren’t doing anything graphics intensive the clock speed drops.  A great idea in theory, but in practice you get a massive DPC latency spike when the switch is flipped.

My solution was to turn off Powermizer.  Apparently there is a utility to do this, but it’s nowhere to be found on my system after installing the latest NVIDIA driver package.  There are also some registry keys you can modify, but once again I don’t have those keys in my registry. The easiest way to add the Powermizer registry keys and set them to the correct values is to use the Powermizer Switch utility by xsmile.

I ran the utility, rebooted, and fired up DPC Latency Checker.  No spikes!

I’m using it for developing animations for an old school Sierra-style adventure game that I’m working on, but I started thinking that it would be an interesting way to interact with music software via MIDI. The tablet registers pressure as well as X and Y location, so that’s three potential control values I can transmit in realtime to Ableton or some other piece of music software.

After a weekend of work I came up with MidiStylus. You can download it here.

The program interface is pretty simple:

You just drag the stylus around the large gray workspace in the middle of the window. The status bar at the bottom will show you the MIDI values that you’re transmitting to the three controls specified in the settings window:

The program can be set to transmit any MIDI control value on any MIDI channel.

I’ll be hooking it up to AudioMulch next weekend and posting some of the experiments here. Check back soon.