The card reader and the Hough transform

We use the Hough Transform to find the straight lines in the image and finish getting the bits from the punched card.
Read more...

Allen organ project - getting stuff.

I also made a little time to do some rough-cut design for the card reader enhancement, at least enough to order some parts. The idea will be to have an Arduino in a box outside with a keypad and display to do operator interface (or perhaps "organist interface"), and a little box piggyback on the card reader to drive the LEDs.

Earlier posts in this series:

• Allen organ project - introduction


• Allen organ project - reverse engineering the card format


• Allen organ project - a software card reader


• Allen organ project - catching up

I was going to just put the LEDs in the inboard box, and drive them through a printer cable or some such, but my friend Steve made the good suggestion to run them off the RBBB that he gave me, and have a serial link joining the two boards. There's lots less wire that way.

I have on hand an Arduino (with the LadyAda protoshield), an RBBB (with the PC serial interface), and a suitable 9v wall wart - all also thanks to Steve, who had them as scrap from another project that turned out to be a little too big for them. So I'm tentatively looking at a block diagram like this:

The operator interface will use a telephone keypad for the input. It needs a reasonably large display, because there's a bewildering array of stops, with names like "Trompette en Chamade 8'" that need to be presented. So I'm going with 4 lines of 20 characters, which is the largest that the inexpensive HD44180 controller will support.

I need some reasonably bright white LEDs, 3mm diameter. (5 mm is a trifle too large to go into the holes on the card reader.)

So, significant items on the shopping list are:

• The LED's - 10 needed, plus a few spares.


• The display - it looks as if SparkFun's LCD-00256 (actually a Xiamen Ocular GDM2004D) is Just The Thing.


• A telephone keypad - I've got one in junk, but it's really crappy looking and I'd like the finished project to look halfway presentable.


• Some suitable connectors for the serial link. I'm also planning to power the operator interface box over those connectors. I'm thinking that a 6-pin mini-DIN, like a computer keyboard, should work nicely. And I've got a spare cable for that form factor.


• Oh yes, and some bits and pieces that I'm running short on (pin headers and the like).

(And to be honest, I ordered all of this stuff last week, and just didn't trouble to blog about it.)

Read more...

Allen organ project - catching up (UPDATED: Now with photo goodness)

Contrary to what you might think, I haven't been exactly idle on the Allen organ project. A few words on what I've been up to are probably in order.

Earlier posts in this series:

• Allen organ project - introduction


• Allen organ project - reverse engineering the card format


• Allen organ project - a software card reader

First of all, I've been busy getting the house ready to accommodate things without having a rat's nest of cables on the music room floor. This involved fishing two strands of speaker wire and a strand of Romex to each speaker. The two strands of speaker wire were for the audio and for 12VDC. The strand of Romex was for switched house current. That's what runs the motors that give the Leslie-like "gyrophonic" effects.

What's behind a speaker - Mini-Twist ML3 receptacle, an existing outlet, and a Keystone panel for audio and DC.

And behind the organ console, I fished up the other ends of all this. So behind each speaker I've got a Mini-Twist ML3 receptacle (I didn't want anyone plugging a lamp into it) and a 4-binding-post Keystone panel. Behind the organ console is a 6-binding post Keystone panel (left speaker, right speaker, and 12VDC to both), and a Mini-Twist ML2 inlet. (An inlet puts power into the wall, just as an outlet takes it out.) The arrangement that they had at the house where we got the organ was scary - the inlet was a lamp plug put on an outlet plate inside-out with some sort of putty; the low-voltage wiring was in the same box with the AC, and so on. The arrangement I have now at least isn't going to haunt my dreams.

What used to be behind the organ console - a cheap lamp plug mounted in reverse using some sort of putty, and two weird 6-pin speaker plugs, also puttied in place. How many code violations can you find in this picture?

The outlets and inlet were designed for panel mount rather than outlet box mount, so I made up nickel-plate switchplates with cutouts for them. A big "thank you" to Carl, K2YR for having the right Greenlee punch for the job!

As I did the ML2's for the various line cords, I discovered that all the AC wiring was badly deteriorated - the gutta-percha insulation unside the line cords crumbled at a touch. So I replaced all that, hacking up a hardware-store extension cord because that's a lot cheaper than the same length of 14 gauge stranded cable. I surely don't know why.

And while I was working inside the speakers, I noticed that the belts that drive the moving parts were also rotten - so I'm going to have to order a new set. OK, so I disassembled the shafts, so that I could unthread the belts to measure them. And as I was taking the brushes off the slip rings, I discovered that they were broken. Oh joy, that's a job that I'll have to get a factory service tech to do - because I can't find that part anywhere. It's a silver graphite brush, 0.125" by 0.25" by 1" with a bevel for the slip rings and a long spring. Oh well, brushes ought to be a maintenance part, so I bet the Allen tech can still get them. I hate to call a tech in for a job I can do myself, though.

So I soldered in a bypass to get power to the speakers (with quick disconnects everywhere so that I just need to yank it out to have the old arrangement back). I can live without the motion effects for a while.

I also tried replacing the burnt-out lamp in the card reader with a junk-box green LED (and current limiting resistor). Nothing doing; the thing still doesn't read cards. Next step on that device will be to replace the green LED with one of the white ones that I just got. More on that in the next post.

Pictures another time. My daughter has got my camera. [UPDATE: I got it back.]

Read more...

Allen organ project - a software card reader [UPDATED]

Earlier posts in this series:

• Allen organ project - introduction


• Allen organ project - reverse engineering the card format

First things first. I can live without alterable voices for a short while. But these IBM cards are getting yellowed and brittle. They're 35 years old, and it's not going to be many more years until they crumble to dust. How to get the data off them? Transcribing by hand, the way that I did the first couple is not going to work. I know myself, I'll make too many errors and get eyestrain. There has to be a better way.

I don't want to make any electical modifications to the organ until I know more about it. I don't want to find myself frying some key irreplaceable part. So cobbling some interface to the card reader on the organ is Right Out. Similarly, the handful of services that are still out there who will read card decks are getting Really Expen$ive - I don't want to go that way either. So, what do I have that will read cards?

How about my document scanner? It'll read anything. (No, I haven't scanned my nether regions. It's been a long time since I was a college kid, and about as long since I'd have thought that was funny.) But I have experimented with scanning photographic negatives (only mixed success), coins (too much reflection), and pressed flowers (left residue that was hard to scrub off the glass). Maybe I'll have better luck with IBM cards.

Immediately, I make the executive decision to put the card on the glass face up. All the printing on the card will add visual clutter and confuse any image recognition that I try to do. The back of the card is cleaner, albeit not nearly pristine. But let's give it a try. I also decide to try to give the card a clean, contrasting background. I riffle through my stash of coloured papers and pull out a sheet in robin's-egg blue that contrasts nicely with the yellowed paper of the card. I set the scanner for color at 150 dpi resolution, push the button, and out comes:





Not bad, there's plenty of contrast. There are also a lot of specks of schmutz on the card. Let's hope that doesn't make for a bad read.

Believe it or not, from here things ran pretty much in a straight line. Everything I tried worked once it was debugged. (Of course, I have had to do computer vision at several points in my career, so my educated guesses about what to try are usually pretty good.) Here's an outline of how the program took shape:

1. Segment the image.
I used the k-means algorithm to divide the pixels into three categories: cardboard, background and schmutz. To seed the clusters, I started with an initial guess that cardstock is yellow, background is cyan, and schmutz is black. The algorithm converged quickly (only about ten iterations), and resulted in a segmentation that looked quite usable:



(In the image, white is cardboard, black is background, grey is everything else.) Again, it looks usable; the vast majority of pixels are classified correctly.

2. Extract edges from the image.
Given the segmentation, extracting the edges simply means highlighting pixels that differ from their neighbours above or to the left. Easy.

3. Find straight lines among the edges.
We're trying to find a frame of reference for the card so that we can lay the grid of holes over it, despite the fact that the position on the scanner glass was uncertain. A first step is to find straight lines. To do this, I use an integral transform called the Hough transform.

The Hough transform works by shooting bundles of parallel rays through the image, at angles ranging from zero to π. It counts the number of pixels marked as being 'edges' on each ray.

Update: One colleague called me on the lack of mathematical rigour in this discussion. Another praised me for an immediately-graspable physical analogy. To the first, I say: I could have begun the discussion with a sentence like, 'The Hough transform is the integral,

.'
But I didn't."

The result is a plot of pixel counts, with the horizontal axis being the angle of the ray and the vertical axis being the distance of the ray from the centre of the image. The rays that go right down the edges of the card have a great many edge pixels on them, and show up as brilliant white spots in the plot in Hough space.



In this plot of a card in Hough space, you can see the angle of the short edge of the card as a vertical column of points near the center of the image. The short edges of the card are represented by brilliant white spots near the top and bottom. You can also see the spots representing other vertical lines on the card (vertical rows of holes) in the same column, giving us a way to measure hole spacing, since the vertical axis is measured in pixels. The long edges of the card fall in a column near the right-hand border, and once again you can see other lines (the card rows) of 'edge' pixels in the same column (and therefore representing parallel rays). These are the rows of the card, and again give us a convenient ruler for laying out our grid.

4. Lay out a grid parallel to the card axes.
Given the maxima in the Hough image, which represent the card edges, it's a simple matter of trigonometry to locate the card corners and create a grid to search for holes, given the known dimensions of an IBM card.

Update:A colleague asked me how robust this process is in the face of card misalignment. I took a near-worst-case misalignment (the card canted about 30° from the correct angle), and did a quick hack to the code to overlay the computed grid in red. It's not perfect, but that's mostly because the card edges are modelled as parallel lines - and are not quite parallel (or indeed, quite straight) in real life.

5. Count up how many 'background' pixels are in each hole location, and threshold on the background-to-total-pixel ratio.
This operation gives us the location of the holes. And it worked first try! (Well, once I fixed the typos in the dimensions of the card, it worked. The algorithm was fine, the numbers were wrong. Garbage in, garbage out.) As a little bit extra, I added a decoder for the Hollerith data at the right side of the card (Allen's part number, plus some number whose significance so far eludes me.) The resulting program prints out an ASCII picture of the card, and saves the 16 words of binary data.

         11111111112222222222333333333344444444445555555555666666666677777777778
12345678901234567890123456789012345678901234567890123456789012345678901234567890
--------------------------------------------------------------------------------
      8  8  8  8  8  8  8  8  8  8  8  8  8  8  8  8               20.0 S00R1305
                                                                     ]          
                                                                           ]    
              ]        ]        ]  ]     ]        ]        ]        ] ] ]]]   ] 
     ]     ]  ]  ]     ]           ]           ]  ]        ]                ]   
     ]  ]  ]        ]  ]        ]        ]     ]           ]       ]    ]       
           ]     ]     ]  ]     ]     ]        ]  ]        ]         ]       ]  
           ]           ]     ]  ]  ]        ]     ]        ]                    
     ]           ]     ]              ]  ]        ]        ]                   ]
     ]           ]     ]        ]     ]           ]        ]                    
                                                                                
      ]  ]  ]  ]  ]  ]  ]  ]  ]  ]  ]  ]  ]  ]  ]  ]                 ]          
     ]  ]  ]  ]  ]  ]  ]  ]  ]  ]  ]  ]  ]  ]  ]  ]                        ]    
--------------------------------------------------------------------------------

Beautiful, it exactly matches the punches. Now to try recovering more cards!

Read more...

Allen organ project - reverse engineering the card format

Earlier post in this series:
Allen organ project - introduction

It looks as if a necessary first step here is to figure out the format of the data on the cards. Fortunately, the data didn't seem too difficult to reverse engineer.

Here's a bad picture (I'm far too lazy to shoot a better one, since this shows what we need to see) of two of the voice cards. To my ear, both of them sound nearly like sine waves, the Blockflöte at eight-foot pitch and the Flûte at 4-foot pitch.

The first thing I notice is that the large blank area at the middle right of each card is where the reading stops. (The card doesn't go into the reader any farther than that.) So only columns 6-52 (1-5 are blank) appear to be significant for the voice. (The remaining columns are Hollerith-encoded and appear to have a part number for the card and perhaps a few characters of additional information).

The bottom two rows, rows 8-9, of each card appear to have some sort of timing information. (See below - there's more insight to be had here.) On every card, they appear in a regular pattern: 9, 8, space, 9, 8, space.

The only other rows that are punched are 0-6. 7, 11, and 12 are always blank. On the Blockflöte card, you can sort of see a sine wave pattern running in the shape of the punches. This immediately made me guess that row 6 is the most significant bit of a 7-bit binary word. Plotting out the Blockflöte with this assumption gave a graph like:



Looks as if I guessed nearly right, except that this is only half a cycle. Let's see what happens with the flute. Here, row 6 is doing something strange, but I notice that the blank columns above it are moving in a sinusoid? Making the guess that it's two's complement, I plot out the binary numbers there:



Wow, a perfect sine wave!

I'm going to guess from the half-cycle of the 8-foot stop that the electronics in the organ use symmetry to make another half cycle from the samples that are supplied. For the resulting curve to be continuous and smooth, the second half cycle would have to be both inverted in level and reversed in time, so that the complete Blockflöte waveform would be something like:




We'll see whether I'm right if I ever try to make my own voices.

Now what about those timing tracks? I'd have a hard time designing circuitry to clock accurately a card being pushed and pulled by hand - it would be like clocking hand-sent Morse code (a difficult problem!). But wait a minute. Suddenly I remember that when I took a look at the card reader, the lamps seemed slightly
askew. It seemed awfully sloppy construction for a top-of-the-line (for its time) organ like this one. Looking back at the picture, I see:





I can see that rows 11 and 7 are unused, as I expected. Row 12 has a lamp over it; I'm guessing this row is used as an indicator that there's a card in the slot.
Certainly, with that lamp burnt out, no cards are reading, even if they have
no punches in row 12. Row 8 is displaced by about half a column from the others? What will this do to the relative timings? Aha! With the displacement, the row 8 signal will slightly overlap the row 9 one, giving a quadrature encoding that should be completely self clocking! Clever fellows, those Allen engineers. I'll have to remember that when I start blinking LEDs at the thing. I also make an educated guess that the reader is designed to operate on the pull, rather than the push. It's nearly impossible to push the card in evenly, but it's easy to pull smoothly.

Read more...

Allen organ project - introduction.

Those who know me will most likely already have heard that this spring, I bought an Allen church organ - one of the very earliest digital organs made. (A similar one is in the Smithsonian; the model is that significant to the history of organs.)

Well, let's just say that it's a very fine instrument, but showing its age in several small ways. Like any engineer, I have the attitude: "If you don't like the world, modify it!" So I've got a big fun project to keep me occupied for the summer. (In whatever spare time I'm not spending in trying to learn to play the thing!). So let's have a look at what I'm looking to do.

One particular period feature of the organ is that the alterable voices (wavetables in the early 1970's were novel technology!) are programmed with IBM cards, inserted manually into a little slot to the right of the manuals. Each card has a binary encoding of the waveform produced by a specific style of organ pipe.



I have dozens if not hundreds of cards for it, and they're getting rather fragile. 35 years ago, they weren't making punch cards to last for the ages. Moreover, the card reader has acted up twice for me. The first time, it was just dust and dirt obstructing part of it, and a can of air repaired it nicely. More recently, it's just quit. Time to investigate.
Getting to the card reader was a fairly simple matter once I found the two screws (one on each side) that hold the lid of the keydesk in place. The lid then swings up. If you try this, make sure you latch the music desk in the 'down' position first!

Once the lid is up, the stopboard is held in with two screws, one under the Pedal stoptabs and one under the Great.




With these screws out, it swings up out of the way.





Now the Swell manual simply lifts up:



Lifting the Swell manual reveals the card reader underneath it. The reader is held in with a card-edge connector and four screws. A quick test with the power switch reveals that one of the row of incandescent lamps on the top of the reader is burnt out.

Well, obviously that is one piece of technology that can be upgraded. Put LED's in there instead, and never worry about another burnout. But now a light bulb (or perhaps an LED, this is the twenty-first century) goes on over Kevin's head. This little lamp bar, easily removed, is the key to eliminating the deteriorating IBM cards without any electrical modifications to the organ. Pull out the light bar, and replace it with an LED bar with the LED's sequenced by a microcontroller as if the card was being inserted and withdrawn. And thus is born the Allen Organ Card Reader Upgrade.

Few good ideas are truly new. A little bit of trolling through the search engines shows that this idea is the subject of U.S. Patent 4,416,177. Fortunately, that patent is expired, and so there should be freedom to operate here. I'm essentially replicating exactly the device shown there, only with modern components.

Read more...