Boston Butt Telemetry

Another slow-cooked pork weekend...

We were given a Big Green Egg by Martin & Andrew Farach-Colton. The Egg is great at high-temperature grilling like steaks, but comes into its own for slow cooking, like pulled pork. Last time I did this and posted progress on Facebook, Bharat Mediratta wanted more data: specifically, a chart of temperature versus time. Last time, I bought a Redi-Chek (see how appealing a product name is when you misspell it in several ways?) remote thermometer: the transmitter has a probe that goes in the pork, and you can keep track of the internal temperature within a hundred or so feet with the remote. This time, I used Gawker, time-lapse software for the Mac, to track the temperature overnight, then replayed the movie (yeah, low-tech) to fill in a Google spreadsheet.

Here's the temperature chart:

Link to the original data and chart.

You can see the plateau at about 170˚F from 4:30am to 8:00am. According to collected wisdom on the internet, this is when the fat and connective tissue break down. I prefer to think of it as a phase change of the Pork molecule, analogous to heated water pausing at 100˚C while all the energy goes into creating water vapor. I don't know the chemical formula for pork, but it sure must involve some tasty elements!

This time around, I had the Egg configured just right, so it maintained a constant 215-ish˚F all night, and I didn't have to wake up multiple times to adjust the vents. It was done in less than 12 hours, so must have been a bit smaller than the one I cooked last time.

Oh, and it tasted great...

P.S. Why a pork shoulder is called a Boston Butt.

Beautiful Coffee

Inspired by the new "bottomless" ("naked", "crotchless") portafilters at Google New York, I bought one for home. Seeing the espresso emerge from the filter in its syrupy, chocolate-flecked-caramel essence is a thing to behold. I highly recommend clicking on the images for the full effect:

Digital Music Stand: electronic paper edition

(followup to Digital Music Stand)

The Kindle 2 has an 800x600 4-bit electronic paper screen, good enough (just) for reading music from a couple of feet away. After a few tweaks, my pipeline produces appropriately-sized 4-bit PNGs. Amazon provides a free email service to convert them to the Kindle proprietary format format, provided that you transfer them from a computer via USB.

Click on the images for higher resolution:






The difference in lighting isn't this extreme—the Kindle relies on ambient light, and this photo was taken late on a dim day. But the size comparison indicates that it's perhaps not the perfect gig solution.

Olympic Medals per Capita

As you scan the Olympic medal tally, one thing stands out: larger countries tend to win more medals. An obvious exception, especially in 2008, is Australia, who won the sixth largest number of medals with a population of 21 million, 39th largest of Olympic countries. The obvious next question, which has been taken up by a variety of commentators, including Chuck Culpepper of the Los Angeles Times, is: who leads the world in medals per capita? I became frustrated with the lack of up-to-date statistics, so I built http://www.medalspercapita.com/, which is updated daily during the Olympics, to answer this question. In addition, it calculates the leaders in gold medals per capita, as well as a weighted medal count where gold is worth three points, silver two and bronze one. Finally, it's a little unfair to ignore the relative wealth of countries, so the site counts medals relative to GDP. My bias? I'm originally from New Zealand, which has consistently been in the top half-dozen or so countries for total medals and gold medals per capita, trading positions back and forth with geographic neighbor Australia.

Frames inside TabPanels in Google Web Toolkit (GWT)

I'm building a little app in GWT, and put an iframe into one of the tabs. I wanted the browser to fill the whole panel:



Unfortunately, this doesn't work:

tp = new TabPanel();
tp.add(mainTable, "Table");
page = new Frame("http://www.google.com/");
page.setHeight("100%");
tp.add(page, "Web")

It results in:



After a tedious investigation, it appears that the problem lies in the underlying iframe: setting the iframe style to "height: 100%" doesn't work in HTML in general. You can set the height in pixels, but it's up to you to figure out how many pixels high it should be to fit properly. There's a related but different problem for the TabPanel: 100% seems not to respect other widgets that it's packed with, so it ends up too large, resulting in a vertical scroll bar where you don't want it. Incidentally, "width=100%" works fine in both cases.

Here's a (slightly hacky) solution:

class ResizeListener implements WindowResizeListener {
public void onWindowResized(int width,int height) {
tp.setHeight((Window.getClientHeight() - tp.getAbsoluteTop() - 50) + "px");
page.setHeight((Window.getClientHeight() - page.getAbsoluteTop() - 10) + "px");
}
}

...
Window.addWindowResizeListener(new ResizeListener());
...

You also need to call both these functions initially as part of the setup code. This seems to be an unfortunate case where you need to know more than GWT's surface: you need to understand the underlying HTML implementation to solve the problem.

Digital Music Stand

I wanted to get rid of the big stack of music books by my piano. Also, the binding on most of the books was driving me mad—the glue binding that is common with Hal Leonard books doesn't sit flat, and makes it hard to turn pages. I decided to scan all my books and replace them with digital music stand.

Scanning

• cut the spines off all my music books
• a few minutes per book
• only had a guillotine/paper cutter that could reliably handle 25 pages at a time, so it was pretty tedious
  

• scanned them using a Canon Imagerunner 5570
• about 5 seconds per double-sided page
• sheet feeder was good up to 150 pages at a time, so most books took two runs
• about 5-10 minutes per book
  
• scanned at 600 dpi black and white to PDF
• set the paper size to Legal—most music books are about 9"x12". The 8.5" width captures the music OK, and we trim the extra 2" later in software.

Image Processing

• pdfimages from http://www.foolabs.com/xpdf/ to extract the pbm files, one per page, from the PDF
• pbm_findskew from http://sourceforge.net/projects/pagetools to detect the skew of the pages, usually less than 1˚
• installed netpbm
• pamflip to rotate the images clockwise (the scanner output them landscape)
• pnmrotate to remove the skew:
  $angle = 0 + `/Users/craignmnew/bin/pbm_findskew $finputpbm`;
  `pamflip -cw $inputpbm | pnmrotate $angle > $deskewed`;
• Installed ImageMagick
• convert -trim to remove the extra 2" of white
• here's my perl script to run all of these from beginning to end
  

Hardware

• I wanted a good-looking, high-quality display for the stand, with minimal cables, so bought an Apple 23" Cinema Display
• The 12" vertical size of the viewable area matches the size of a music book
• The 19" horizontal size matches two pages side by side
• The display has a single cable out the back, carrying power, video, USB and FireWire, which minimizes the cable mess
• The screen is VESA mountable, which means you can easily remove the stand. I did this, and built tiny black feet out of Premo, a polymer clay that bakes hard. The feet have a small lip around the front of the bottom of the screen, and are molded to the ripples in the piano music holder. There is one more Premo “peg” at the back of the screen, holding it at the right distance from the back of the music holder.
  

• I hooked the display to a 1.5GHz 512MB Mac Mini I had
• Put the Mac on the wireless network, and enabled screen sharing and file sharing (Leopard), so I could control it and transfer files without a keyboard or mouse connected.
  
• I looked for a very fast image viewing program—the Mac Mini graphics are pretty wimpy. Came across Xee, which has the full-screen mode and speed I was looking for.
• For control (remember, no keyboard or mouse,) I bought a Griffin Powermate, which is the most beautiful peripheral ever made. It's a programmable knob, beautifully machined. I took the knob off, and removed the fabric that provides friction for control. This made the knob easy to spin. Thanks to Dan Egnor for this insight. I set the driver to emit command-arrow keystrokes, which causes Xee to move forward and backwards through the page images when the knob is turned clockwise and counter-clockwise respectively. I also mapped "push" to forward, so that I can go to the next page just by tapping the knob.

• Once I had this all working, I realized that I needed foot control, so that I could turn pages without taking my hands off the keyboard. Most foot switches I found were for dictation machines, were expensive, and individual. After a lot of searching, I found the CME GPP-3, which simulates grand piano pedals, and has USB output. It talks MIDI, though, so I had to find some way of making the MIDI events drive Xee, the display program. I eventually found midiStroke, which is free, and translates MIDI events to keystrokes. This setup works like a breeze!
  

Some more image processing

• To obviate the need for Xee to do any scaling, and to reduce the filesizes:
• pnmscale -linear to scale each page to 1200 vertical pixels, the resolution of the screen. Without -linear, pnmscale tries to be clever with gamma, and the scaled version ends up too light. Gamma in a bitmap. Hmmm...
• convert +combine to combine pairs of pages into one image, side by side
• I'm torn about whether I want to be able to "turn" one page at a time -- move the right page to the left, and bring a new page on the right. This doubles the number of images, and takes longer to flip through them, but does enable page turns to be done before they're absolutely necessary—this insight due to Tim Bell, who has his own, much more sophisticated, Music Stand project.
• finally, pnmtopng to produce the final image file.
  
• The filesizes are surprisingly large—1.5MB—and after some investigation, it appears that something is causing the PNG to have a depth of 16 bits. There's really not that much information there, and the video card can only support 8-bit grayscale, so pamdepth should fix this. 8-bit PNG files are around 350K.