Panasonic PIR Breakout Board

 On 2014-05-02 and filed under: pir breakout


I’ve been working on some motion sensing stuff and stumbled across Panasonic’s PIR sensors. They’re not raw sensors, but come as a mostly all in one TO-5 package.

Since the package has slender, non-breadboard friendly pins, working with it was quite unwieldy, and required alligator clips (which got tied up in knots, required careful positioning, etc).

So here is a tested breakout board for the Panasonic PIR sensors. All the good bits of information (which sensors have been tested, vendor links, etc) are in the repository’s README (just scroll down).

If you prefer to use OSHPark’s fabrication services for purpleization, a link is included to a shared project. All you need to do is to click order.


Avrrrinator Rev. A Updated

 On 2014-03-10 and filed under: avrrinatorA avr


A mostly visual update to Avrrrinator Rev. A has been pushed to its repository.

There isn’t much to update with a straight Bus Pirate (3) to AVR ISP breakout, so the changes are mostly visual. A new BOM part now allows mating directly to the Bus Pirate 3, so check that out too.

As before, you can do as you like with this board under the CC0 Public Domain license.


Stop, blink and roll*

 On 2013-05-13 and filed under: timelapse attiny buspirate contest bb313 buspirate3

A little bit of the cat got out of the bag some time ago:

6 seconds of AVR flashing

You’re looking at ~24 hours of continuous AVR flashing compressed down into 6 seconds.

While I won’t be releasing the connecting PCB just yet (i’m still beating down a few issues and refining the BOM), I thought it would be good to supply the scripts I used to do the actual time lapse since it was non-obvious from a “oh dear, the contest entry is due in <48 hours isn’t it..” point of view.

Parts and Materials

  • Teensy3: Attached to the system doing the programming

  • SSD1306: OLED display showing how many times the AVR has been programmed

  • Bus Pirate 3: Acting as an AVR programmer

  • Avrrrinator Rev B: Bus Pirate to 2x AVR ISP adapter (this is the super secret “prototype” I mentioned in the YouTube post)

  • BB313 boards: Breakouts for easily attaching AVR ISP cables

  • ATtiny4313: tiny AVR for programming

  • ATtiny85: tiny AVR for programming

  • Assorted LEDs: Status indicators/Lighting

  • Logitech C920 Webcam: Takes all the pictures

Taking a picture

The small bash script invoking the gstreamer toolchain (without reading the documentation this is pretty much magic) took on the duty of taking a picture every minute. It then copied everything out via rsync to another machine with tons of spare space.

This is not properly done since my start time edged uncomfortably close to when I had to stop, edit and ship (24 hours later).

Note that this constantly writes over the same file. It stops the local disk from being clogged up by continuous snapshots. It also does not check and do anything reasonable if the rsync transfer fails.. like move the file aside/retry.

In my case, losing a few minutes worth of snapshots wasn’t a big deal for 24 hours compressed down to 6 seconds. I actually deleted quite a few frames before rendering out to video to eliminate periods of darkness (they show up as jarring sub-millisecond transitions to darkness).


while true; do
gst-launch -e v4l2src ! video/x-raw-yuv,format=\(fourcc\)YUY2,width=1920,height=1080,framerate=5/1 \
! ffmpegcolorspace ! pngenc snapshot=true ! filesink location="frame.png"

# Yup, this is talking to an actual rsyncd daemon on a NAS
RSYNC_PASSWORD="super_secret" rsync -avP frame.png rsync:[email protected]/frame-`date '+%s'`.png

sleep 60;

Video out

After all the frames were assembled, I manually went in and pruned a bunch that were completely dark due to the lights being off. Compressing the video down a bunch to 6 seconds took a bit of playing around, mostly with the framerate:

mencoder 'mf://*.png' -mf fps=145:type=png -ovc lavc -lavcopts vcodec=mpeg4:mbd=2:trell -oac copy -o ~/Desktop/output-yt.avi

At this point, the video quality kind of sucked, but I had to ship it.

Here is the completed video:

Code doing the programming

This is the script that refreshes the display you see. It calls avrdude to flash the AVRs and records the return code.

If it is zero, then the success counter for the AVR is incremented.

From there counts are then written to the serial port where the Teensy 3 can handle persisting the display and refreshing it with new results.

#!/usr/bin/env python
# requires pyserial (pip install pyserial)
import subprocess
import serial

counter_4313 = 0
counter_85 = 0

failures_4313 = 0
failures_85 = 0

ser_port = serial.Serial(port='/dev/tty.usbmodem12341', baudrate=9600)

while True:
        ret_4313 = subprocess.check_call(['avrdude', '-v', '-p', 'attiny4313', '-c', 'buspirate', '-P',
        '/dev/tty.usbserial-AE01J4Q7', '-U', 'flash:w:blinky313.hex', '-x', 'reset=aux'])
    except subprocess.CalledProcessError:
        ret_4313 = 1

    if ret_4313 == 0:
        print "ATtiny4313"
        counter_4313 += 1
        failures_4313 += 1

   # Report statistics to the LCD screen
    report = "313:%s\n\n85:%s" % (counter_4313, counter_85)
        ret_85 = subprocess.check_call(['avrdude', '-v', '-p', 'attiny85', '-c', 'buspirate', '-P',
        '/dev/tty.usbserial-AE01J4Q7', '-U', 'flash:w:blinky45.hex', '-x', 'reset=cs'])
    except subprocess.CalledProcessError:
        ret_85 = 1

    if ret_85 == 0:
        print "ATtiny85"
        counter_85 += 1
        failures_85 += 1

   # We do this twice to make it look more live
    report = "313:%s\n\n85:%s" % (counter_4313, counter_85)

On the Teensy 3, the data is received and pumped out to the display. Not the greatest code, but decent enough to run for 24 hours without much of a hiccup.

Note that there are several small issues when using the SSD1306 library with the Teensy 3. I just stomped out the relevant sections after chasing down errors from the compiler (which were unrelated to SPI operation, and mostly due to i2c support).

* Flash Counter!
* Teensy 3.0 attached to a 128x64 SPI-driven OLED display
* Vendor: Adafruit
* IF YOU GET COMPILE ERRORS (you likely will!)
* Stomp out the compile errors in Adafruit_SSD1306.cpp line by line
* and everything should be OK (most of them are i2c related).
#include <Wire.h>
#include <Adafruit_GFX.h>
#include <Adafruit_SSD1306.h>

#define OLED_DC 11      // All pin numbers correspond to
#define OLED_CS 10  // the 'gray' labels on the welcome to
#define OLED_CLK 14     // Teensy 3 card
#define OLED_MOSI 12    // SSD1306 labels this as: "Data"
#define OLED_RESET 9


void setup() {
  pinMode(13, OUTPUT);

  // Display setup


void loop() {

  // Persist the display until we have something to display
  if( Serial.available() > 0 ) {
  display.println("AVR Program Count");
  while ( Serial.available() > 0 ) {
    digitalWrite(13, HIGH);
    char c =;

    if (c == '\n') {
    } else {
    digitalWrite(13, LOW);


And of course, blink programs. The ATtiny4313 and ATtiny85 each had their own. They’re pretty generic, (the one for the 4313 is from the BB313 website).

cheers (and drink, if thats your thing)

Hardware Volume Controller

 On 2013-05-11 and filed under: volume control hardware atmega32u4 lufa

(5/11/13) - Hey fantastic reader: This is an old how-to (from 4/2/12!) that existed in its own self-contained repository. Reflecting back, this hack was kind of silly, but i’m porting it here to keep everything in one place.

And if you’re curious about the long-term viability of this build.. it is still kicking. The detents are a little less crisp now, but everything works a treat. (And now, back to your regularly scheduled post re-run!)

It wasn’t too long ago that volume control on a keyboard was a foreign concept. After it became a ‘feature’, that control seemed pretty normal. There is however, a slight modern exception now. Many mechanical keyboards (which have been coming back into style) don’t have them.


In response, I hacked this together. It’s a volume controller which parses a rotary encoder’s input and controls the volume (tested on OS X/Windows/Linux so far).

Parts/Bill of Materials:

  • Altoids Gum sized tin - A slick enclosure. Scratches easily though.

  • Rotary Encoder - I’ve tried a bunch. A lot of them either failed over time, or the ‘clicks’ (detents) became mushy. This one comes with a cool looking knob and is panel mountable too.

  • Adafruit Atmega32u4 Breakout - Brains of the operation. Comes with headers. For this particular project, just keep the headers for a rainy day.

  • Wire - Will need these to hook up the rotary encoder. Stranded wire is preferable since it can bend and flex.

  • Perfboard - While you can go without, the perfboard is nice to relieve the stress on the rotary encoder pins. I haven’t run across an economical source of cuttable copper-clad perf; they’re usually so large that I feel guilty slicing them apart. These seem to be the right size, but are rather thick (I haven’t sliced these apart yet). Use anything that works.

Optional (or you already have these if you’re thinking this is a good weekend project):

  • Sugru - I used this stuff to attach the board to the tin. Anything non-conductive works (determine the amount of adhesion based on your projected re-use of these parts).

  • Soldering iron + Solder - Needed to join all the parts together.

  • Mini-B USB cable - This is the cable type that the breakout board accepts.

  • Drill/set of bits - To make a hole so that the encoder can poke out of.

  • Something to cut with - For perfboard cutting, wire stripping, prying the enclosure, etc.

Electronics assembly

Start by cutting perf for the rotary encoder. Put on your safety glasses (and quite possibly a dust mask just to be extra cautious). Cutting perfboard (and other things too!) can cause pieces of it to fly into your eyeballs.

To cut the perfboard by hand, score 5-7 times along the holes that mark the edges of the cut (make sure to dry fit before cutting). I had better cuts by scoring along the entire length of the perf (although this means some perf ends up being wasted).

Once you’re ready to cut, take a pair of shears (dull diagonal cutters work too) and clip a notch where your scored lines meet the edges. This should serve as a guide for your snap (the concept is similar to tearing a notch in a piece of folded paper before ripping it apart cleanly). Slowly bend the perf where the score is and the perf should snap apart. If it resists or seems like it won’t snap along the score line, score some more and repeat.

If that fails, break out a dust mask, a pair of safety glasses (you should already be wearing these!), and just start hacksawing. It won’t be very pretty, but it should work.

The next step is to solder the encoder in. Insert the encoder and tack a leg with solder to hold it in place. Ensure everything is aligned the way you like it (check that there is room for the wiring below), and solder the rest of the pins in.

The wiring can be deceptively tricky. Measure out enough wire so that you can open/close the box. Cut, strip and tin the wires. You’ll need 5 wires.

Here is the wire mapping (looking from top to down at the rotary encoder, with three pins on top and two on the bottom):

Volume Up/Down (three pins, top)

Wire color Pin on Atmega32u4 Pin on encoder
White D0 Left-most pin
Black GND Middle pin
Red D1 Right-most pin

Mute On/Off (two pins, bottom)

Wire color Pin on Atmega32u4 Pin on encoder
Black GND Left-most pin
White B0 Right-most pin

Solder all the wires together. Once the wires are attached to the perf, blob some solder to bridge the wiring and the encoder pins together.

encoder wiring


To drill a hole for the encoder, find a bit size that matches (the datasheet says it is 6mm / .236 inches or just around a 1564 drill bit (.234 inches)). Measure for dead center on both axes (or like a professor once told me: ‘eyeball it until your OCD stops’). Mark the drill point.

If it makes it easier, it is possible to remove the lid from the body. Simply bend the hinged tabs outward and the lid will slide off. Reverse to fit the lid back on.

You may need to brace the back of the drill area with a block of scrap wood to prevent warping. Drill from the outside in (so that all the unsightly edges are hidden somewhat). Don’t apply too much pressure (you won’t be able to undent things easily).

Once you’re done, dry fit the encoder but don’t screw it into place yet.


For the USB port, buttress the breakout board against the bottom of the enclosure and mark an approximate outline. Using a drill, begin drilling into the case (the hole won’t be large enough, but we’ll fix that in a bit). With the hole made, take your shears and carefully pry to make an opening wide enough for the USB plug to poke out. Continue to check the fit while slowly prying. Don’t worry if it looks too ugly. The USB plug covers up most of the mess.

Final assembly

Before adhering the breakout board (permanently, depending on your preference); lets test everything.


Unfortunately I haven’t had all that much luck compiling on OS X (using Homebrew packages), and I haven’t tried on Windows at all. Only Linux has worked so far. All hope is not lost however, you can manually program the breakout with avrdude! Read on to ‘Skipping all of that’.

These are the packages I have installed for Fedora which are needed to compile:

$ sudo yum -y install avr-libc avrdude avr-gcc avr-binutils git

Next, grab a copy of the LUFA git repository that includes the necessary modifications:

$ git clone git://
$ cd lufa-lib
$ git checkout -b atmega32u4-mediacontroller origin/atmega32u4-mediacontroller
$ cd trunk/Projects/MediaController
$ make all

If the compile was successful, connect the breakout board to your computer. Type the following into your console, hit enter, but don’t type in your password yet.

$ sudo make program

Going back to the breakout board, hit the white button (a green light should slowly start fading in and out indicating that the breakout is ready to be programmed). Type in your password and watch it go. If avrdude had problems finding your 32u4 breakout, run dmesg and check the output for something along the lines of ttyACM. The last part should be a number. Modify the makefile with the new port and re-run the line.

Here is what my dmesg looks like:


Skipping all of that:

If you’re on OS X or Windows.. or just don’t like compiling, get the hex file, press the white bootloader button, and run the following (a working example for OS X):

$ avrdude -p atmega32u4 -P /dev/tty.usbmodem621 -c avr109 -U flash:w:MediaController.hex

Change /dev/tty.usbmodem621 as appropriate for your platform. On OS X, if at first /dev/tty.usbmodem612 doesn’t work, use tab-completion to fill in the remaining section. Enter /dev/tty.usb and tap tab to get relevant entries when the bootloader light is active.

Finishing up: Do volume up/down and mute (pushing down on the encoder) work properly? If so, time to finish up! If not, make sure that the board is programmed (it shows up as LUFA Media Controller in dmesg, and similarly under the OS X System Profiler). Also ensure the connections between all the parts are nice and solid.

If everything is finished, open a pack of Sugru (or the adhesive you’re using), and stick things together. Next, poke the rotary encoder through the hole on the lid. Then secure it with the hardware provided and add the nice looking control knob to top it off.

Here is what mine looks like now; it is magnetically attached to the keyboard (no ill effects yet).



This project uses code and examples provided by LUFA (which is MIT licensed). Thats by Dean Camera. The code to read the rotary code comes from a posting by circuitsathome here.

Improvements, chaos, and cost reductions:

From a performance and cost perspective, the breakout used for this project is overkill; building an ATTiny breakout might be more worthwhile. Also, it might be possible to just rip the guts out of an old keyboard and use its media controller functions with some modding.