Building and testing the DSKY substitute
I had two driver boards for the sign digits, because I naively assumed that was how many I needed. The boards each came with a pair of dual-digit modules. I can't break apart a dual-digit module, thus each dual-digit module has to sit in front of one of the three registers. Based on that, I assumed I needed two boards to drive three dual-digit modules.
After studying the internal layout of the 14 segment display dual-digit module and thinking about what I was using them for, solely to show a plus or minus sign, I realized I could cut the wiring way down. I needed only five wires per dual-digit module, to light the four segments that form the + and -, as well as the one common cathode for the right hand digit in the module.
I cut away the excess wires in my working sign for R3, then began wiring the next two sign modules to the other driver board. Once done, I found that nothing worked. The board was now dead, although it had tested okay back when I removed the dual-digit modules and installed header strips. None of the four digits controlled by the board would light.
It was then that I had my epiphany. The dual-digit module has shared wires for all the segments, plus two common cathodes to light the left and right digits respectively. I could use a single driver board to light all three sign displays. The board handles two different dual-digit displays. The four segment lines from the right hand side of the board went to the dual-digit module for R1 and were jumpered over to the dual-digit module for R2.
The right and left common cathode lines went to R1 and R2 dual-digit displays, each hooked to the righthand digit of the dual digit display. Thus, this one board could drive three right hand digits in the three dual-digit displays (and could have driven a fourth if I had needed it). It took five wires to the R3 dual-digit module and six wires to handle the two dual-digit modules for R1 and R2, since they shared the four segment lines between them.
I wired up the first 8 relay module to the Arduino. This will handle the five keycode lines, the key release line, the PRO button line and the KeyRel button line. I hooked up one of the keyboards to test out my decoding of the button presses. All seemed well, as I could see the activation lights for the relays whose bits were set on in the keycode and those light patterns matched the codes that should be emitted for the keys pressed.
I did have a problem because this relay module is activated by a logic LOW from the Arduino. The problem is that I had used pin 13, which is connected on the Arduino board to an LED.
Thus, when the PRO line is in its inactive (HIGH) state, the LED is illuminated, it drops the voltage, and my output to the relay board is indeterminate. I can see the relay board driver LED dimly lit, but it should be off entirely.
Even worse, I had already assigned pin 13 to the flash control for the OprErr indicator. The pin may work fine as a control for flashing OprErr, although the paralleled LEDs (on board and one the caution/warning panel) may cause problems. In reality I am short two pins, for OE flash and for the PRO button.
I was using pins to control the flash circuitry in addition to the wires that lit the LEDs, but I realize this is superfluous. The same wire from the expander module that lights the OprErr LED can be routed to the flasher control NAND gate to enable the flashing, saving a pin. The same pertains to the KeyRel flasher, saving a second pin.
Now, I can reuse one of those pins (pin 12) for the PRO button and have no need to use pin 13 with its inboard LED. All is good in the world again!
I built the breadboard to handle all the flashing control. It has a quad NAND gate and the flasher module attached. The three gates are hooked to expander board 0x20, pin P0 (OprErr), pin P1 (Verb/Noun flash) and pin P3 (KeyRel).
Wires for triggering OprErr and KeyRel also run to the LEDs on the main breadboard panel. These gate the 1.5Hz to two relays which interrupt the high power to the OprErr and KeyRel LEDs.
Four relays will interrupt the common cathode line between a 7-segment display unit and the driver board when activated. The flasher circuit will activate and release the relay on a 1.5Hz square wave as long as the Verb-Noun-flash line is active. When the Verb-Noun-flash line is inactive, the relay stays open and the common cathodes are controlled by the driver board (lit up).
My second breadboard panel, a large metal plate with a number of breadboards attached, will hold the sign driver board and the two keypads. Lower down, I will affix the Arduino itself. Other connections, including to the AGC voltage conversion circuit boards, will be made here.
I installed pin headers and wired up two breadboard PCBs to hook to the 7 segment driver boards for registers R1, R2, Verb and Noun. Some testing confirmed that these worked properly. They will be tucked away to the right of the main board or underneath, the three PCBs plugged into a small breadboard. This small breadboard is there to wire up +5, ground and the three sets of three wires (clock, data and load).
I had a moment of panic when one of the 7 segment driver boards, when mounted on the breadboard PCB, had no connectivity to one pin. Try as I might, I couldn't get solder to flow well enough to establish a connection. Fortunately, I remembered that there are two sides to this board, intended for a quad digit display on each side. The signal for the bad pin (3) was present on the other sides pin 3.
I hooked up both keyboards, all three registers and Verb, Noun and Program. The three sign displays were turned on as well. I ran a test to see how everything worked. Everything was good, so I began to solder things together to make the connections more solid.
Tomorrow I have to solder together 25 circuits to accept an input signal from the AGC and present the result as a 5V TTL logic level to the Arduino. MIT developed this circuit for interfacing to the AGC and it was used by the various contractors such as North American Rockwell and Grumman Aerospace Engineering Corporation who had to tie their systems into the AGC.
It is called a type D circuit in the documentation. AGC signals are 28V for high and 0V for low, with certain expectations for impedance, load and thresholds of the equipment connecting to it.
The D circuit consists of a PNP transistor with its emitter hooked to 28V from the AGC. The input signal runs to the base through a 10K resistor. A parallel combination of a 10K resistor and 0.1uf 50V electrolytic capacitor are connected between the emitter and base. The collector output runs to ground through a voltage divider of a 220K and 47K resistor in series. The center tap is the 5V output to the Arduino or other board.
For signals I will send into the AGC, I am driving a relay board with the Arduino or other board and switching 28V through a series chain of two 510 ohm resistors to the AGC. This provides the 28V input expected by the AGC with exactly the same resistance and structure as the keyswitches in the DSKY.
I began to write a test program for the Arduino Uno that will drive the input lines to my DSKY, in place of the AGC, to test out the behavior. This will have a terse command language to let me set any digit of the displays, the signs, the Computer Activity lamp, the flashing of the Verb and Noun displays, and any of the Caution/Warning lights.
I had two driver boards for the sign digits, because I naively assumed that was how many I needed. The boards each came with a pair of dual-digit modules. I can't break apart a dual-digit module, thus each dual-digit module has to sit in front of one of the three registers. Based on that, I assumed I needed two boards to drive three dual-digit modules.
After studying the internal layout of the 14 segment display dual-digit module and thinking about what I was using them for, solely to show a plus or minus sign, I realized I could cut the wiring way down. I needed only five wires per dual-digit module, to light the four segments that form the + and -, as well as the one common cathode for the right hand digit in the module.
 |
| Dual-digit module and connections to driver board |
It was then that I had my epiphany. The dual-digit module has shared wires for all the segments, plus two common cathodes to light the left and right digits respectively. I could use a single driver board to light all three sign displays. The board handles two different dual-digit displays. The four segment lines from the right hand side of the board went to the dual-digit module for R1 and were jumpered over to the dual-digit module for R2.
 |
| Connections to three dual-digit displays to show + and - signs |
I wired up the first 8 relay module to the Arduino. This will handle the five keycode lines, the key release line, the PRO button line and the KeyRel button line. I hooked up one of the keyboards to test out my decoding of the button presses. All seemed well, as I could see the activation lights for the relays whose bits were set on in the keycode and those light patterns matched the codes that should be emitted for the keys pressed.
I did have a problem because this relay module is activated by a logic LOW from the Arduino. The problem is that I had used pin 13, which is connected on the Arduino board to an LED.
Thus, when the PRO line is in its inactive (HIGH) state, the LED is illuminated, it drops the voltage, and my output to the relay board is indeterminate. I can see the relay board driver LED dimly lit, but it should be off entirely.
Even worse, I had already assigned pin 13 to the flash control for the OprErr indicator. The pin may work fine as a control for flashing OprErr, although the paralleled LEDs (on board and one the caution/warning panel) may cause problems. In reality I am short two pins, for OE flash and for the PRO button.
I was using pins to control the flash circuitry in addition to the wires that lit the LEDs, but I realize this is superfluous. The same wire from the expander module that lights the OprErr LED can be routed to the flasher control NAND gate to enable the flashing, saving a pin. The same pertains to the KeyRel flasher, saving a second pin.
Now, I can reuse one of those pins (pin 12) for the PRO button and have no need to use pin 13 with its inboard LED. All is good in the world again!
I built the breadboard to handle all the flashing control. It has a quad NAND gate and the flasher module attached. The three gates are hooked to expander board 0x20, pin P0 (OprErr), pin P1 (Verb/Noun flash) and pin P3 (KeyRel).
Wires for triggering OprErr and KeyRel also run to the LEDs on the main breadboard panel. These gate the 1.5Hz to two relays which interrupt the high power to the OprErr and KeyRel LEDs.
Four relays will interrupt the common cathode line between a 7-segment display unit and the driver board when activated. The flasher circuit will activate and release the relay on a 1.5Hz square wave as long as the Verb-Noun-flash line is active. When the Verb-Noun-flash line is inactive, the relay stays open and the common cathodes are controlled by the driver board (lit up).
 |
| Caution (left column) and Warning (right column) LEDs |
 |
| What Caution/Warning panel should look like |
I installed pin headers and wired up two breadboard PCBs to hook to the 7 segment driver boards for registers R1, R2, Verb and Noun. Some testing confirmed that these worked properly. They will be tucked away to the right of the main board or underneath, the three PCBs plugged into a small breadboard. This small breadboard is there to wire up +5, ground and the three sets of three wires (clock, data and load).
I had a moment of panic when one of the 7 segment driver boards, when mounted on the breadboard PCB, had no connectivity to one pin. Try as I might, I couldn't get solder to flow well enough to establish a connection. Fortunately, I remembered that there are two sides to this board, intended for a quad digit display on each side. The signal for the bad pin (3) was present on the other sides pin 3.
I hooked up both keyboards, all three registers and Verb, Noun and Program. The three sign displays were turned on as well. I ran a test to see how everything worked. Everything was good, so I began to solder things together to make the connections more solid.
Tomorrow I have to solder together 25 circuits to accept an input signal from the AGC and present the result as a 5V TTL logic level to the Arduino. MIT developed this circuit for interfacing to the AGC and it was used by the various contractors such as North American Rockwell and Grumman Aerospace Engineering Corporation who had to tie their systems into the AGC.
It is called a type D circuit in the documentation. AGC signals are 28V for high and 0V for low, with certain expectations for impedance, load and thresholds of the equipment connecting to it.
The D circuit consists of a PNP transistor with its emitter hooked to 28V from the AGC. The input signal runs to the base through a 10K resistor. A parallel combination of a 10K resistor and 0.1uf 50V electrolytic capacitor are connected between the emitter and base. The collector output runs to ground through a voltage divider of a 220K and 47K resistor in series. The center tap is the 5V output to the Arduino or other board.
For signals I will send into the AGC, I am driving a relay board with the Arduino or other board and switching 28V through a series chain of two 510 ohm resistors to the AGC. This provides the 28V input expected by the AGC with exactly the same resistance and structure as the keyswitches in the DSKY.
I began to write a test program for the Arduino Uno that will drive the input lines to my DSKY, in place of the AGC, to test out the behavior. This will have a terse command language to let me set any digit of the displays, the signs, the Computer Activity lamp, the flashing of the Verb and Noun displays, and any of the Caution/Warning lights.
No comments:
Post a Comment