Allen organ project - card reader enhancement is done!

The hardware for the card reader enhancement is built! Excuse me while I crow.



It sits there on the organ console, looking as if it was built to go there. Well, it was.

Mounting keyboard and display was a matter of screwing in a whole bunch of #2-64 screws and nuts:



Then wiring the circuitry was a pretty routine perfboard job. The front of the board (toward the front panel) has sockets for the keypad and display, and mounts the trimpot that controls display contrast. It also has most of the actual wiring. There's a little scorch mark on one wire that would not stay out of the way of the soldering iron. Nobody's going to see it inside the box, and it's not near anything that's going to short it, so I'm just going to leave it alone. Nobody's perfecʇ.


The back of the board (the side that faces the inside of the box) mounts the RBBB, the DIN jack for the PS/2 keyboard cable, and a 4-pin socket where the serial interface goes for flashing the firmware.


Of course, I wound up making up some circuit modifications while I was wiring it up.

First off, I rearranged the pin assignments to give a neater layout on the perfboard with the RBBB turned sideways.

Next, I added a 470 Ω resistor and green LED to provide a 2.5 Hz "blinky light" status indicator that shows the firmware's main scan loop is running. (I've half a mind to have it send the firmware revision number in Morse.)

Finally, I decided that driving the LED backlight for the display - which is rated for 240 mA at a 4V forward voltage - off of the voltage regulator on board the RBBB was a losing proposition. Instead, I put together a little current regulator circuit. The 2N3053 transistor (good for a couple of Watts of collector dissipation) is switched with base current supplied from an RBBB pin via the 2.2K resistor. The 2.7Ω 2W wirewound resistor (it's mismarked 2.4Ω, which is why it turned up in surplus!) senses the emitter current. When the drop across it exceeds the Vbe of the little 2N2222A transistor, the little transistor turns on and robs the base current from the big one. Result is that the LED is driven at a 240 mA constant current, and then is pulse-width modulated for brightness. It's both brighter than the 6.8Ω resistor made it, and more stable with supply voltage and temperature fluctuations. Only thing is that the 2N3053 pass transistor was getting a little warm (on the borderline of exceeding the safe operating area of the "fingertip thermometer"), so I added a little homemade heatsink cut out of aluminum foil from a pie plate in the recycle bin. This technique works pretty well for medium-size devices as long as you use lots of grease to get good thermal contact with the foil.


The board goes into the project box, held in place by the keypad and display sockets in two corners and #4-40 screws, nuts and washers on fiber standoffs in the other two corners.


So now I try to flash the firmware (with the revised pin assignments). And ... nothing! Nada! Bupkis! The TX light flashes a couple of times, and avrdude refuses to sync with the chip. Several hours of puzzlement ensue.

Oh, [Nixonian expletive deleted once again]. I already made this mistake once, with the other RBBB inside the organ! And I've gone and done exactly the same thing again. I have RX and TX interchanged. (RX on the Ladyada serial interface goes to TX on the RBBB, and vice versa. Only this time, when I correct it - still nothing. Yes indeed, I've blown the chip. It's pretty forgiving, but this was too much for it.

Oh well, I still have one more Atmega168, sitting in the Arduino. (And I've been wanting to upgrade that one to a 328 anyway). So I swap chips...

And the display shows the menus nicely, and programs the organ.



I won't say that the firmware is done, but it's getting there. The big pieces that I want to add are that there's nothing behind menu #5 (where I want to put Hammond drawbar registrations), and I want to add an interface for scaling stops (making them louder or softer). Aside from that, though, it's more usable than the card reader - I don't have to worry about cards falling apart and lamps burning out.

I'm a happy camper for the moment.

A big thanks to Steve for getting me started with his surplus Arduino stuff, and to Carl K2YR for the fabrication assistance (and circuit sanity checking and general willingness to serve as the teddybear that I explain things to).

And, of course, thanks to Mary Ann and Cathy for putting up with all this geekiness.

Read more...

Allen organ project - display terminal front panel

Once again, I've been spending time doing the project and not writing about it. I've come up with a front panel layout for the display terminal, and cut some holes in the project box.




I started by printing a template on paper and putting it on the panel with spray glue. That gave me all the cut locations neatly laid out. As I did the template, I even remembered to displace the display unit a little bit upward so that the pins of the display and keypad lined up to holes on 0.1 inch perfboard.

Next came drilling some 5/16" holes in the middle of the two rectangular cutouts that hold the keypad and display. Then it was crunch-crunch-crunch with an Adel nibbling tool making rectangular cutouts that were (intentionally) a shade too small. (I can cut away more material, but it'd be real hard to put any back!) Then, with a file and patience, I enlarged the holes until they gave a snug fit for the components. (The keypad has a radius on each corner, and I just made that with a Dremel tool).

I used the components themselves as templates to mark the locations for #42 holes for the 2-64 mounting screws that hold the keypad and display, and drilled holes to mount the perfboard and to provide screwdriver access to the display contrast control. The screw holes came out a little ragged, what with being drilled from the wrong side, but the screw heads will cover that up anyway.



The fit of the perfboard inside is "perfect enough." If you click through to the original photo, you can see the socket pins lined up with the holes. That'll give me a base to wire on. The two nylon studs are for mounting the RBBB. [UPDATE: Decided not to use them, and just mount the RBBB flush to the perfboard.]

I also machined a slot into the side of the box below the keyboard to hold the DIN connector for the PS/2-style keyboard cable, and a mating groove on the connector. That one worked out nicely. The connector feels like a rigid fit even without backing it up with hot glue, which I plan to do anyway.



And I got another RBBB built. I soldered a 6-pin female connector to go to the DIN connector breakout. This box draws its power from the DIN connector and has the data lines going to two of the digital inputs. You can see where I ground away the breakout board so that the slot in the project box can engage the groove on the connector body. (Grinding a FR-4 fiberglass board takes patience and a dust mask.)

Plugging the DIN connector into the LED controller, the pilot light on the power supply lights and the Vcc pins check out at 5V, so I guess I got that part right.


Read more...

Allen organ project - proof of concept achieved. Facepalm.

Now that the LED control is integrated with the card reader, it's time to see if it actually can program a stop!

Open up the organ, and in it goes. Take the breadboard display terminal, select "Blockflöte 8'" and send it over.

WOOHOO! First try!

Try again - Octa-Bell. "Bing bong bing." Kinura. "Blaaaaat." Festival Trumpet. "ta-ta-ta-DAAAA!"

Time to close up the organ and work on suitable packaging for the terminal.

Oh dear. Oh dear. Oh [Nixonian expletive deleted].

The two rotary switches above the card reader leave absolutely no clearance behind the lamp strip.
There's no room for the rearward extension of the board.

Oh dear.

Fortunately, there's plenty of room underneath the card reader. Back to the bench.

I cut the card reader perfboard in half, and rewire everything so that I have two halves joined with a strip of ribbon cable. I'm a little worried about switching noise getting into the audio, so I try to control it some by having each LED have an independent ground return on an adjacent conductor. (Desolder all the LEDs and resistors. Solder in both ends of all 20 conductors of the ribbon cable. Replace the LED that I overheated in the rework process.)

After all this rework, Frankenreader goes back in the organ and looks like this:


From the rear. The logic board extends a little way under the reader.


From the top. The ribbon cable clears all the hardware above.

Read more...

Allen organ project - integrating with the organ

With the LED control apparently working on breadboard, it's time to get it aboard the organ. Mounting the LEDs and resistors, the RBBB, the programming port, and the PS/2 connector is a fairly simple matter of perf-board construction. (You'll notice that I replaced the voltage regulator on board with a heat-sinked 7805. The current draw of the LEDs was making the itty-bitty 5V regulator that comes with the RBBB get, uhm, kind of toasty. The 7805 is nice and cool.)



The LEDs need to be on quarter-inch spacing, while the perfboard hole spacing is 0.1 inch. But quarter-inch spacing is easily done by mounting every other LED on a diagonal pair of rather than a h0rizontal pair. The row 8 LED (second from top in the picture) is mounted vertically, which displaces is 0.05 inch toward the rear of the organ.

With a little tweaking, the LEDs fit the holes in the card reader beautifully:

The LED pin numbering was a little inconvenient for the perfboard layout, so I did a quick firmware flash to renumber them.

And the PS/2 communications crapped out. I'm getting spurious interrupts.

After a couple of evenings of very frustrating debugging, I finally get it. When I put in the keyboard cable, rather than the short wires on the breadboard, I added enough capacitance that the LOW->HIGH transition got really sloppy (remember, these are open collector outputs!). Adding a line of code to drive the pin HIGH at low impedance for a brief period (just long enough to change the pin mode to INPUT) makes the transition clean enough that the spurious interrupts go away. The data transmission looks solid as a rock.

And as I was testing to make sure that the card slot was unobstructed, I realized.

The photocell for LED 8 is displaced to the rear. Not the front. So it's not in quadrature with the others. Instead, it gets fired independently when all the others are off. A quick bout of editing and another few firmware flashes. (Slow the clock down again, to watch the lights blink, and then speed it back up. Plus debugging.)

The firmware is now at http://kbk.is-a-geek.net:2303/ci/95f796cc4d.

And it's time to try this thing out for real!

Read more...

Allen organ project - lighting the LEDs

Last time, I breadboarded the LED controller and got its serial communications working. Now it's time to fire those LED's.

When the controller is idle, all the LED's are on, as if there is no card in the slot. (Among other things, this convention allows me to continue programming the organ with cards, if I wish.)



Wow, those LED's are bright.

Now, let's look in detail at what happens when a card is inserted and removed.

[Update: I was wrong about the quadrature signal. The next post explains.]

• First, the paper blocks all the lamps (LEDs are all off). This condition persists until column 6 lines up with the photoresistors.
• Next, for each group of three columns, the row 9 hole, and the data in rows 0-6, come into view. LED 9 and the data byte are lit.
• The row 8 hole comes into view early, because its photocell is displaced half a column. LED 8 lights.
• The data column leaves the photocells (LEDs 0-6 and 9 go off).
• The timing column leaves the photocell (LED 8 goes off).
• About 1 1/2 column of blank space (all LEDs off) passes over, and then the cycle repeats for the next fifteen data bytes.

Once all this is done, the LEDs stay off for a short pause (the card blocks the light from all of them, andt then the entire cycle repeats, reversed in time, as the card is withdrawn. Finally, all the lamps are lit as the card exits the reader.

http://kbk.is-a-geek.net:2303/ci/41508259dd has the code baseline that does this. With the clock rate slowed down to where my human eyeball can track what's going on, the data look right.

Now to move the thing onto the card reader and try it out on the organ!

Read more...

Allen organ project - communicating with the LED control

In the last post, I cane up with a schematic for the LED control for the organ card reader. It was obvious from the schematic that an Arduino with a prototyping shield would be total overkill (and an excessively large form factor), so I decided to use an RBBB instead. The RBBB is cheap, tiny, and fully firmware-compatible with the Arduino Diecimila or Duemilanove. Breadboarding the project is simple:

From left, the major components are a serial adapter for flashing the firmware, the RBBB itself, and the LED array. For the breadboard, I didn't bother to attach the PS/2 connectors, instead directly wiring pins 3/4 between the Arduino and the RBBB, and the power supply rails (note the jumpers at the right hand edge). The LED pins in the picture were chosen for convenience on the breadboard and aren't the final pin assignments on the reader.

The first task is to make the LED control respond to commands from the display unit. This means firmware changes for both the boxes, of course.

The code baseline for these changes is over at http://kbk.is-a-geek.net:2303/ci/ac332e3e60, if you want to follow along.

I'm letting the display box play "keyboard", and the LED control play "computer". I'm following the PS/2 keyboard protocol loosely (not bothering to implement things like retransmit request, and of course, keyboard scan codes will be meaningless in this application). But the wire protocol is pretty much the same.

When the line is idle, both ends have DATA and CLOCK pulled to +5 through (nominally) 15K resistors. (I'm using the internal pullups on the microcontroller.) We're simulating 'open collector' ports, so from the Arduino's perspective the HIGH state is:

   pinMode(pin, INPUT);
 digitalWrite(pin, HIGH);  /* high impedance with pullup */

while the LOW state is:

   pinMoode(pin, OUTPUT);
 digitalWrite(pin, LOW);   /* low impedance pull to ground */

When the keyboard sends a byte, the procedure is shown in the diagram below. (In this case, the terminal is sending an ASCII 'U', 0x55.)



The terminal begins by pulling the DATA line LOW, to request to send. It waits for at least 50 microseconds, and tests that the host has not pulled the CLOCK line LOW to forbid transmission. (The host can do this at any time, and the terminal checks before pulling it LOW and after returning it HIGH.)

The terminal then sends an 11-bit data frame. Each bit (except for the 'start' bit, which is already there) is placed on the DATA line on a LOW->HIGH transisiton of the CLOCK line. The host clocks the bits out on the falling edge of the CLOCK line, when the terminal is holding them stable.

In order, the bits are:

• 1 : Start - always '0'
  
• 2-9 : 8 data bits, present least significant bit first
• 10 : A parity bit, chosen so that there is an even number of '1' bits in bits 2-10.
• 11 : Stop - always '1'

Following the STOP bit, the DATA and CLOCK lines are left at 1, which is the IDLE state.

The clock speed can be anywhere from 10 to 16.7 KHz, so the transitions are spaced anywhere from 30 to 50 microseconds apart. The terminal just uses 'delayMicroseconds' to insert the necessary time delays. The LED controller attaches an interrupt to the falling edge of the clock, and has a timeout activated from its scan loop to detect incomplete data frames.

There are four possible errors that the controller can detect when a data byte arrives.

• Parity error - an odd number of '1' bits was present in the frame - the number should be even.
• Framing error - the stop bit was a '0' - it must always be a '1'.
• Timeout - the data frame did not complete within 150 ms.
• Overrun - there was no buffer space available to store a newly-arrived byte.

For ease in debugging, I decide to make the commands sent from terminal to controller be ASCII, newline-terminated. Initially, I envision four commands:

• 'S' - Set stop. The 'S' is followed by 32 hexadecimal digits giving the wavetable from the punched card.
• 'T' - Test. The 'T' is followed by arbitrary text. The command is simply echoed to the serial port. It's there for debugging.
• 'W' - Wake up. This command brings the controller out of its 'standby' state - which means turning on the LEDs and delaying briefly for the organ to detect that the card slot is unobstructed. No data are expected between the 'W' byte and the newline.
  
• 'Z' - Zzzleep. This command brings the controller into 'standby' after the display has been idle for 30 seconds. It turns off the LEDs to save power. No data are expected between the 'Z' byte and the newline.
  

A test harness using the 'Serial' class shows that all these bits are working. Onward to firing the LEDs!

Read more...

Allen organ project - the LED controller

Once again, I find myself with a list of things to put in the build log, to try to catch up to what I've been doing. I'm really, really lax about keeping this thing up to date, because - well, frankly, it's more fun to build than to write about building! But if I'm ever going to remember how my modifications to the card reader work, I'm going to have to write stuff down.

The last post described the operator interface box's electronics in nearly finished form. Now we need something to sit in the organ and fire the LEDs. It turns out that it looks pretty easy to do such a thing, because the existing card reader lamps are mounted on a little PC board that is just held in with a couple of 6-32 screws and spacers - and that board is just connected with a couple of wires that provide 8 volt power. Mounting to its mounting points looks a snap.


Taking off the board and looking underneath, I see that the "grain of wheat" lamps stick into holes in the reader case underneath. The holes look to be #29 drill on 1/8 inch centers , and there are holes for the unused card columns (where no lamps are present in the picture). #29 holes are a nice loose fit to T-1 (3.0 mm) LED's. The LED body will go in the hole easily, and the base will not. OK, so what I need is an array of 10 white-light LEDs in that size. As I noted previously, lamp number 8 is displaced toward the rear of the organ.

Aside: I tried a high-brightness green LED for the burnt-out one, but it didn't work. The fact that it didn't wasn't really a surprise. CdS photoresistors - which is what it appears that this device is using - mostly need blue light.

Not having anything suitable in junk, I went and ordered a bunch of white LEDs from All Electronics (Their part number is LED-83.) The data sheet for those says they're supposed to get 20 mA drive current. (Good! An Arduino output can drive them.) And they have a 3.5-4 volt forward voltage. OK, that says that we want to scale the resistor so that it'll source 20 mA when dropping a volt and a half - 68 or 75 ohms ought to do it. The resistor will just be dissipating about 30 mW, so an eighth-watter should be just fine. And I just happen to have ten 68Ω resistors in my junkbox.

The only other I/O that should be needed is some sort of communication with the display unit. My criteria for this: a reasonably thin cable, a fairly robust, small and readily available connector, and no tying up the on-board UART on either the terminal or the LED controller. (I want to have access to the 'Serial' library when debugging!) A little bit of headscratching, and I decide that an old PS/2-style keyboard connector should be perfect. The PS/2 keyboard protocol is fully synchronous (with the keyboard generating the clock), so there's no need for accurate timing on the receiver - just shift in the bits on an interrupt. (That also means that I want at least the clock line on an interrupt-capable pin, so pins 3 and 4 become the PS/2 interface).

With this much settled, I've got a complete schematic.


The pinout on the PS/2 port is standard with one exception: I've changed the Vcc lead from +5 to the unregulated 9V input. That'll give me a ready way to power the display terminal through the cable, even though there's an LED backlight (240 mA) to run.

I also do identical wiring for the PS/2 connector over on the display side. So now I've got a communication channel. Next comes programming that channel.

Read more...