brainwagon

Over the years that I’ve been interested in computer graphics and telescopes, I’ve managed to pick up a bit of knowledge about optics in general, and specifically about camera lens design. In the past, I’ve been particularly interested in old cameras and photography, and in a kind of photographic minimalism. But it has remained mostly an academic interest, with no real practical results.

Until recently.

I was recently asked to provide a little bit of background on camera lenses and lens design at an informal workshop. The purpose of the workshop was for each participant to build and use a camera of their own construction. I’ve taken similar courses before where we did pinhole photography. Here’s the apex of that experiment, a picture of my desktop:

Taken with this camera. Note the curved back, which results in the odd panoramic distortion of the previous picture.

But this time class was a bit more ambitious. We were going to make cameras that would shoot on 4×5 film, and use a real lens (or lenses) to give us faster focal ratios and interesting distortions and other effects. We ordered some lenses with focal lengths of around 150mm from Surplus Shed for a few bucks apiece (favoring some positive meniscus lenses, as well as some with about 300mm that we thought we’d experiment with some symmetrical lens arrangements, got some 4×5 sheet film holders, and a pile of black foamcore and gaffer tape. Each person’s camera was a bit different. Here’s mine:

It’s a pair of boxes about 7″ across which telescope together. To create a bit of a light trap, there is both an inner and an outer box in the back, and the section which holds the lens slips in between those two, and also provides a rough focussing mechanism. The lens is a meniscus with about 150mm focal length, and about 50mm in diameter. It’s not an achromat, just a simple lens, configured as a Wollaston landscape lens. I constructed a small box to hold it about 1 inch behind the front of the camera, and then punched a 1/4″ hole in some black paper to serve as a stop. Instead of a true shutter, I decided to just make a little trap door. For our first tests, we were going to image directly onto photographic paper, which had an ASA rating of around 3 or 4. With the 1/4″ stop in place, my camera operates at around f/24. To make my first “selfie” in room light, I guestimated an exposure time of 30 seconds. The first exposure was far too light. I then caved and used a smartphone app to give a better estimate, and it suggested a three minute exposure time. I shot this on ASA 3 positive paper. I triggered the shutter myself, then sat down and tried to be as still as possible. When the time was up I got back up and closed the shutter. Into the darkroom… and bathing in the rinse!

I cropped the picture and scanned it, cropped it, did a very tiny exposure tweak to darken it a bit (probably should have left it in the developer a touch longer), and here’s my selfie:

I’ll try to get some new shots next week. But it’s a fun project, I urge anyone to give it a try. These simple lenses are more effective than you would think.

In my previous article pondering sensors for my garden, I shamefully neglected a viable and interesting choice, the JeeNode JeeNode is available here in the U.S. from Modern Device. It’s sold as a kit, which is unusual, but not particularly scary to assemble. It’s just a few through hole parts. It’s a pretty bare bones processor, but does interestingly include a wireless module. It uses the RFM12B modules running on either 433 or 915 Mhz. But what really makes the JeeNodes interesting to me are that they abandoned the (I submit) broken shield model of Arduino shields, and instead group the output pins for the Arduino into a collection of identical Ports which can be accessed using their JeeLib library. Each port consists of six pins (one ground, one Vcc, and four data pins) and all can be used to implement an I2C bus in software to access peripherals. Very cute, and much nicer than the hodge podge of existing code for the Arduinos.

But the website at JeeLabs has a bunch of other cool stuff. Like details on one of their JeeNodes that’s been transmitting data wirelessly for over eight months, powered by just a coin cell. Or this Dive Into JeeNodes which is a tutorial on interfacing JeeNodes to a Raspberry Pi to make a house monitoring system. While the blog isn’t being updated anymore, it includes all sorts of good stuff, including this rather clever article on VCC Measurement (a software only way for an Arduino to determine it’s own input voltage). Great stuff.

Building my full sized quadcopter is going rather slowly (sigh) but in the mean time I picked up a little Hubsan X4 to play with. It’s cheap, and because it has a very low mass, it’s pretty hard to destroy. After more crashes than I can count, I’ve only managed to ding up one propeller (and replacements are pretty cheap and easy to get). But I must admit that one of the reasons I’m interested in quads and RC vehicles is to shoot video from them. While it is possible to get microquads that carry cameras, or even allow FPV, I kind of like the idea of home brewing something. Often, such projects are aided by following in the footsteps of giants, looking at how others have solved problems helps a bunch. It’s also inspiring. That’s why I was particularly enthused to find this article:

Build a micro-sized first-person-view quadcopter

A couple of things I like about the article:

• It suggested the Vitality H36 quadcopter. It has one really interesting feature: it’s compatible with the Flyky/Turnigy radio transmitters. It would be cool to use my big transmitter with the tiny quad.
• Provides good hints on the video camera, transmitter and receiver module that you might want to use.
• Good links to circularly polarized antenna construction details.
• It’s an existence proof that it can be done! Awesome!

It looks like a complete hoot!

We’ve started a garden at our house in a pair of raised beds. I’ve been pondering about possibly creating a set of sensors to monitor the dryness of the soil in the beds as well as in the container that I have a dwarf Meyer lemon tree going in. I was trying to figure out what a good sensor would be. Ideally, I want a simple, low power computer, which is fairly cheap and easy to deploy. I’ve got more than a few Arduino variants around (Uno, Fio, RedBoards, Nanodes, and Wildfires) and they have more than enough horsepower to do what I anticipate (reading temperature, humidity and moisture settings) but there are two things that make them less than completely satisfactory to me:

• They don’t have any kind of wireless link. You could certainly add one of several kinds, but…
• That adds to an already fairly expensive board. Unos are about twenty five dollars. That seems like a lot. There are simpler boards of course, such as the Pro Mini. Sparkfun has those for about ten dollars.. You can also order Arduinos from Chinese manufacturers to drive the cost down, but a board cost of about ten dollars about the minimum you can get.

It seems to me that a complete node has a minimum cost of around $20 when assembled this way. It’ll include a Pro Mini, a small wireless board, and a couple of cheap sensors. Making the node solar powered would probably cost a few bucks more. But while digging around, I discovered that Low Power Labs had a really cool little board: the Moteino. It’s a very cool little board, offers a choice of different RF choices, and includes versions with and without USB. Do I really need another different Arduino clone?

Sigh. Maybe.

Moteino from Low Power Lab

At work, we have an informal group that is interested in drones and quadcopters. Every third Thursday, we get together and fly. Today we went over to Cesar Chavez Park for a bit of flying. I was hoping that I’d have more of my own quadcopter completed, but instead I just observed Mark fly his Bixler and his One Piece Quad, while John flew his Phantom 2 around. They should have some footage up in the next few days. To tide you all over, here is some footage that Jeremy shot on two previous drone lunches, one filmed at work, and the other at the top of Mount Diablo. Enjoy.

Pixar Drone Meet from Jeremy Vickery on Vimeo.

Over the last couple of years, I’ve spent a little bit of time making fixed wing aircraft from Dollar Tree foam. The results have been interesting and fun, but I’ve found that the need to find relatively large areas to fly means that it’s harder to go fly than I would like. On the other hand, multicopters require relatively less area, and I suspect I could do some test flights almost anywhere. So, over the last few months I’ve begun to accumulate the necessary parts to put one together. As this project continues, I’ll write up some more.

But one of the things I thought about today in between World Cup matches was putting some LED lights on the quadcopter. Besides just looking cool, they are especially useful on quadcopters because they allow you to see the orientation of the quadcopter more easily.

My RC mentor Mark Harrison has some notes about he wired up LEDs on his quadcopter. The basic idea is to get some LED strips, and then power them from a brushed ESC (like this one for $4.95) driven by a spare channel on the RC receiver. It’s a pretty good way to go.

But I wondered if I could do better. I’ve made a Christmas hat with LEDs before, driven by an Atmel ATTiny13, surely I could homebrew something…

So here’s where my thought is: I want to create a small pc board with just a few components. It will be powered from the receiver, and will read the servo control channel, and will use an Atmel ATTiny85 (I have a dozen on hand that I got from Tayda Electronics for about about $1.12 each, and they have 8K of memory, plenty for this application). At it’s simplest, we want the program to configure one pin as an input, and one pin as an output. The servo control signal looks like this:

The pulse will be somewhere between 1ms and 2ms long. The ATTiny just needs to monitor the channel, and if the pulse is longer than 1.5ms, it will set the output high, otherwise set the output low. And that is pretty easy.

In the past, I’ve used avr-gcc to program these tiny chips. For the ATTiny13 with just 1k of flash, that’s pretty understandable. But it turns out that with a bit of work, you can use the Arduino environment to program the ATTiny85s. This website gives most of the details. It’s pretty easy, and I got my MacBook all configured in just a few minutes. Then, I entered and compiled this (as yet untested) code:

[sourcecode lang=”cpp”]
/*
* I thought I would dummy up a simple RC controlled switch using
* an Atmel ATTINY85 processor, but code it all in the Arduino
* environment. The idea is to use pulseIn() to read the data signal
* from the RC receiver, and threshold it, setting an output pin
* if the pulse length is > 1500 ms, and clearing it if less.
* Very simple. It should be able to be powered directly from the
* receiver, and if we had some kind of FET we can switch large loads
* (like a strip of LEDS).
*/

int inputPin = 0 ;
int outputPin = 1 ;

void
setup()
{
pinMode(inputPin, INPUT) ;
pinMode(outputPin, OUTPUT) ;

// if we never get a pulse, we want to make sure the
// ourput stays switched off.
digitalWrite(outputPin, LOW) ;
}

void
loop()
{
digitalWrite(outputPin,
pulseIn(inputPin, HIGH) > 1500 ? HIGH : LOW) ;
}
[/sourcecode]

Couldn’t be much easier. If you hooked up an led with a current limiting resistor to pin 1, you can test this (I’ll put up some video once I get it going). To power a larger 12v string (like this red LED string I got for $8.90 for 5m from Amazon) you’ll use that output to power a FET to switch the much larger current, but that’s dead simple too. I can probably run the ATTiny off its internal oscillator at just 1Mhz.

But as cheap as that is, it’s probably not worth the cost of home brewing one.

But of course, you don’t need to stop with this stupid application. You have a total of five or six pins, so you can easily control multiple strings. You can also implement more sophisticated controls: instead of just using an on/off signal, you can look for short switch flips versus long switch flips, and change into different blinking modes. A short flip might make the landing lights blink. A long one turns them on steady. You could even use the ATTiny to drive RGB addressable LEDS (check out this Instructable for details). Different flips might turn on different colors, or switch between Larson scanner modes… blinking… the skies the limit.

I’ll let you know when I get more of this done.

This week began with a visit from Pat Hanrahan, currently a professor at Stanford and formerly at Princeton, where I was lucky enough to meet him. He came by to talk about probabilistic programming languages, which are an interesting topic that he and his students have made some interesting progress in solving difficult problems. I don’t have much to say about it, except that it seemed very cool in a way which I’ve come to expect from Pat: he has a tendency to find interesting cross disciplinary connections and exploit them in ways that seem remarkable. I haven’t had much time this week to think about his stuff more, but he did mention this website which gives examples of probabilistic computation and cognition, which seemed pretty cool. I’m mostly bookmarking it for later consumption.

Long time readers here should know that I have a bit of a fascination with strange, retro computing devices. While I haven’t done anything significant in this area myself, I love to see them, and at yesterday’s MakerFaire, I saw Simon’s Relay Calculating Engine. I’ll let Simon explain it to you:

My own impressions: it’s brilliant. In the front it has a real presence. The cabinetry is beautiful. The interface is crazy in its retro feel: a rotary dial and metal pushbuttons, with Nixie tubes for output. There is even an awesome mechanical cam in the front that generates the two-phase clock signal. And the back is equally impressive, a maze of wiring connecting dozens of relays. Very cool.

Over on Facebook, fellow Pixarian Arun pointed out this story on a problem I encountered in my undergraduate schooling as “The Marriage Problem”, which I also heard of as “The Secretary Problem”. The idea is that you are supposed to find a wife (or secretary) out of a list of $n$ possibles. Each one is assigned a score, but are presented to you in random order. You look at each possible spouse (I’m gonna stick with the Marriage formulation from now on) and can see what her score is. You then have a choice: either propose, or lose her forever and go on to the next applicant. The goal is to maximize the odds that you will find the best spouse.

This was presented to me as part of a programming assignment when I was an undergraduate. Luckily, I recalled that Martin Gardner had covered this topic in one of his Mathematical Games columns for Scientific American as The Game of Googol. He described the problem thusly:

The numbers may range from small fractions of 1 to a number the size of a “googol” (1 followed by a hundred 0’s) or even larger. These slips are turned face down and shuffled over the top of a table. One at a time you turn the slips face up. The aim is to stop turning when you come to the number that; you guess to be the largest of the series. You cannot go back and pick a previously turned slip. If you turn over all the slips, then of course you must pick the last one turned.

I’ve given you some pointers, you can either work on the problem or go find the answers with Google. But the basic idea is that you can solve the problem thusly: find the maximum score for the first $n/e$ items in the list, then propose to the next applicant whose score exceeds that value. A little bit of tricky (but not impenetrable) math will show that this is the optimal rule, and that the odds of selecting the best spouse is $1/e$. Rather than do harder math, I wrote simpler simulations, and graphed all potential cutoffs, running 10,000 trials, and graphing the number of times the best mate was selected for each threshold. Voila:

But Arun was confused, and so was I. After all, if the best spouse was in the first $n/e$ items, you can’t win. And if the second best is in the first $n/e$ items, you can’t get the second best, and so on. So what was the average performance? After all, perhaps you are one of those people who don’t believe that there is one best person for you. Twisted as that is (I can say so, since I found my optimal mate) maybe your goal would be to pick the threshold to select the best average mate. If you run the same calculations, but instead graph average score, you get something like this:

In other words, if you want to get the best wife on average, you should come to your conclusion much faster. It isn’t quite clear to me what the optimal setting for this parameter is, but I’m too tired to do the math right now. But perhaps I’ll follow up.

The other day I was watching the 1939 movie The Adventures of Sherlock Holmes, a rather fun film staring Basil Rathbone and Nigel Bruce. Early in the film, the maniacal Professor Moriarty (played with great zest by George Zucco) is menacing his butler Dawes for allowing one of his prize orchids to wither while he was in jail awaiting trial for murder. He laments the injustice of him serving six weeks in jail for murdering a man, while a more suitable punishment for murdering one of his flowers would be to be “flogged, broken on the wheel, drawn and quartered and boiled in oil”.

Great stuff.

Immediately after, he takes on of his orchids and presses it meaningfully into a copy of Baedeker’s London and Its Environs. I love old books, so I looked i up on archive.org. And, of course, they have digitized it, at least the 1901 version. It’s a traveler’s guide, carefully documenting all the kinds of things you might want to know about when visiting London at the turn of the last century. Neat! What’s also cool is that Moriarty puts the orchid at a place where there is a map or diagram on the left side of the book. A few minutes of perusing reveals that it’s a map of the Tower of London, which plays a key role in the story. Nice bit of foreshadowing! Digging around, it kind of makes me wish that I had a copy, and as luck would have it you can get a digital version of the 1899 edition for your kindle. It also appears you can get facimiles of original Bradshaw railway guides for about the same. If I ever return to working on my Sherlock Holmes story, I’ll have some useful references.

Scott Haley mentioned my old Hellduino post on Facebook: a simple project that used an oscillator powered by an Arduino to send Hellschreiber, a kind of simple fax mode invented by Rudolf Hell in the 1920s. I did this mainly as a simple test, inspired by Steve Weber, KD1JV’s “temp2morse” project. But unfortunately, that page seems to be gone, so the schematic isn’t available. It’s not a huge deal: almost any Colpitt’s oscillator would do in its place, with the main power rail being powered by a digital output on the Arduino, but I thought I’d see if I could find one suitable. I’ve built this low power oscillator documented by Hans Summers before, it’s probably overkill (it’s meant to drive a 50ohm antenna, and actually radiate some single digits worth of milliwatts). K7MTG’s HF Thermometer project was the inspiration for Steve’s, so is probably a good place to start. If you look at his schematic, you’ll see it has no antenna, and no power amplifier. It is actually a bit more sophisticated than my first test circuit was: L1 and C3 form a tuned circuit, which probably makes the waveform a bit more sine-like (if you look at my video, you’ll see the waveform isn’t ideal). To convert this circuit to send Hellschreiber is just a question of software, since Hellschreiber is (like Morse) just sending dots at the right time.

Addendum: Jeff Kellem was nice enough to do some heavy lifting and find a copy of the original schematic for Weber’s temp2morse project:

He found it on LB3HC’s blog. The original article (without images) is archived via the Internet Wayback Machine: click here to enter time vortex.

I’ve been doing a bunch of reading about digital ATV operations lately. I was originally motivated by hearing about the HamTV project aboard the ISS. Back in 2007, I got re-energized into ham radio by learning that for the 50th anniversary of Sputnik, the amateur satellite AO-51 would broadcast a cool message that I heard with a simple HT. I’m wondering if I’m having that kind of a moment now: the idea of creating a station to broadcast digital television seems challenging but doable.

While reading up on the necessary bits for a HamTV downlink station, I found that this little satellite receiver which sells for less than twenty-five dollars could be used to decode signals from the ISS. It receives DVB-S signals, which are used by direct satellite broadcasters like Dish Network. But in thinking about how to go forward with the project, it seemed to me like trying to aim directly for a satellite downlink station was likely to be a frustrating endeavor. It requires a number of different subsystem to work together, but trying to receive the DVB-S from the ISS (given an intermittent schedule) would be difficult to test together. So, I started looking for resources that I could use to build a similar terrestrial station, including both a transmitter and receiver.

A couple of cool links:

The DATV-Express board is a $300 exciter board that is in limited production. It seems very cool. Reading the Tech Talks on this site yielded a lot of good information, I’m particularly pondering the information in this one, about designing a digital TV station.

Another similar project, but available more as a board/kit is the Digilite project. An interesting variation of this project is the DigiliteZL project, which makes for a compact and interesting setup.

I also like the CQ-DATV magazine. It’s got lots of cool information, published in a series of magazines available in a variety of e-book formats. They also have a broad collection of interesting articles on the Digilite project, which I’m currently reading over.

I’ll probably stick to more experimentation with SSTV, but this stuff fascinates me, and I may have the opportunity to do something interesting with it in the future.

I like it when my life’s experience and interests toss me an opportunity, and out of the blue last week I received an invitation to help with a class a colleague is trying to put together to help people build their own cameras, and he wondered if I could give an hour or so introduction into camera lens design. It’s really odd that I know anything about camera lens design, but when I was really into building telescopes, I acquired and read a fair number of books on optics and cameras, and in my job it’s proven occasionally useful. (I even managed to be a coinventor of a light field motion picture camera.) But really, it’s always been pretty much just a hobby.

Which isn’t to say it isn’t fun, and interesting, and an opportunity to build some cool stuff.

The history of camera lens design is actually pretty nifty, and goes back over two centuries, even predating the invention of film (early lenses were used in camera obscura). I remember reading (and subsequently forgetting a great deal) of the history of the camera lens in a borrowed copy of Kingslake’s History of the Photographic Lens (a great work, I should someday purchase a copy of my own). But I do have copy’s of Conrady’s Applied Optics and Optical Design. This book was written in 1922, and detailed the mathematical design methods used to design a variety of optical instruments. In particular, I recalled a particular design consisting of a “stop” in front of a simple, concave forward positive meniscus lens. I couldn’t recall the name, but a few minutes of Googling reminded me that it was called the Wollaston landscape lens.The lens is, well, just lens and a stop, but can yield surprisingly good images. The simplicity also makes it a great lens for experimenting with simple primitive cameras. The lens is typically mounted in a barrel that accepts cards with different size holes for the stop, about 15% of the focal length in front of the meniscus. When the lens is stopped down to about f/16, the performance can be quite good over fields of about 45 degrees or so. Conrady’s book covers the design of such a lens, and tells you exactly how to optimize the system, but frankly it probably doesn’t matter that much. I’ll probably review that material, but I doubt doing any math is called for in this class. I suspect we’ll just select some roughly appropriate lenses from Surplus Shed and have at it.

A former Pixarian and colleague, Craig Kolb (along with Don Mitchell and Pat Hanrahan), did a really nice paper back in his Stanford days entitled A Realistic Camera Model for Computer Graphics which showed how you could simulate more complex camera lenses which have many subtle effects not usually captured by the simple pinhole projection model used by most rendering software. I can’t remember if I reviewed the paper for SIGGRAPH, or if I just talked to him about it, but I always thought it would be cool to try to simulate one of these simple camera lenses and show how the “defects” of these simple lenses could be appropriately simulated in CG. He never did it, and neither did I. It still remains on my list of projects to do.

One good thing about looking at these old designs is that a lot of information can be had from materials which you can get for free online. A bit of googling revealed this nifty little book (digitized by Google and available on Google Play) which has a lot of good information about the Wollaston landscape lens, and other simple lenses of the day. It’s conveniently out of copyright, so free to all.

Bolas and Brown’s The Lens

Hopefully more on this to come.

Addendum: Bolas and Brown’s book is not without it’s problems: I saw this diagram while reading it, and realized that it’s not accurate. Off axis parallel rays should be focused, well, off axis, this diagram shows them coming to focus on the optical axis. Whoops!

Nothing too exciting going on, but minor bits of code and play have been done, so I thought I’d update.

First of all, there is a program for decoding SSTV on the Pi, called QSSTV. I don’t have a proper sound setup on the Pi yet, so I couldn’t test it live on the air, but I did take one of my pregenerated Martin 1 images and asked it to decode, which it did quite well:

Not bad at all. While investigating qsstv’s capabilities, I discovered that the latest 8.x versions suppert digital SSTV. Well, except it isn’t built into the qsstv version (my guess is that the Pi doesn’t have quite enough oomph to do the necessary math in real time). But that’s pretty cool: I’ll have to check that out sometime soon.

But anyway…

I also coded up a Scotty 1 encoder, so now I have encoders for Martin 1, Scotty 1, Robot36 and Robot72 modes. I found this great book online which had many details about the different modes. It was quite helpful. It actually documents the modes a lot better than the ARRL Image Communications Handbook and is, well, free. Awesome.

One question I’ve been interested in for a while is “which mode is best?” Of course, we have to define what we mean by “best”. After all, Robot36 sends an image in half the time of Robot72, and about one quarter the time as Martin M1. My question was: how much better image can we expect from Martin, given that it takes 4x as long. Another question was “how much bandwidth does each mode use?” In the ARRL Image Communications Handbook, they have a formula which computes bandwidth but it didn’t make a great deal of sense to me.

I don’t know how to precisely answer either of these, but I thought I’d write some code to simply compute the power spectra of a bunch of some sample sstv recordings. So I did. It basically just loads the sound samples from the SSTV file, window it (I used the Blackman-Nutall window, for no real reason) runs an FFT (using the fftw3 library) and compute the power spectrum. It’s pretty easy. I then encoded a simple color bar image in three different modes, and graphed them all up using gnuplot.

Staring at it, well, they don’t seem that different really. I should figure out the frequency bounds that (say) cover 85% of the total energy, but just eyeballing it, it doesn’t seem that bad.

I also did some minor tweaking to add in additive white Gaussian noise, but I haven’t gotten that entirely working so I could do an apple to apples comparison of how each modes does in total power at various levels of noise. And I’m looking for an HF path simulator too.

That’s about it for now. Stay tuned for more.

Inspired by this webpage, I decided to write a simple zero-crossing analyzer, just like his. The code turns out to be remarkably simple, and would allow me to reverse engineer modes that aren’t adequately documented. I called this program “analyze”:

[sourcecode lang=”C”]
#include <stdio.h>
#include <stdlib.h>
#include <math.h>
#include <sndfile.h>

int
main(int argc, char *argv[])
{
SNDFILE *sf ;
SF_INFO sfinfo ;
float *inp ;
float t, dt ;
float x ;
int i ;
float pcross=0, cross, freq ;

if ((sf = sf_open(argv[1], SFM_READ, &sfinfo)) == NULL) {
perror(argv[1]) ;
exit(1) ;
}

fprintf(stderr, "%s: %d channel%s\n", argv[1], sfinfo.channels,
sfinfo.channels > 1 ? "s" : "") ;
fprintf(stderr, "%s: %dHz\n", argv[1], sfinfo.samplerate) ;
fprintf(stderr, "%s: %lld samples\n", argv[1], sfinfo.frames) ;

inp = (float *) calloc(sfinfo.frames, sizeof(float)) ;
fprintf(stderr, "::: reading %lld frames\n", sfinfo.frames) ;
sf_read_float(sf, inp, sfinfo.frames) ;
sf_close(sf) ;

dt = 1.0 / sfinfo.samplerate ;

for (i=0, t=0; i<sfinfo.frames-1; i++, t+=dt) {
if (inp[i]*inp[i+1] < 0) {
/* we have a zero crossing */
x = -inp[i] / (inp[i+1]-inp[i]) ;
cross = t + x * dt ;
freq = 1.0 / (2 * (cross – pcross)) ;
printf("%f %f\n", cross, freq) ;
pcross = cross ;
}
}
}
[/sourcecode]

The code is dead simple. It loads the sound file into memory and then figures out (via linear interpolation) the location of all the places where the signal crosses zero (via simple linear interpolation). Each time we have a zero crossing, we compute the frequency of the signal, which is just the reciprocal of twice the difference in the two latest crossing times. This program dumps out the time and frequency of each zero crossing, which you can then easily visualize with gnuplot. Like this:

Next step: generate some example sound files, and use them to reverse engineer some of the less well documented modes.