Readied PCB to build DSKY Substitute for Apollo Guidance Computer

PREPARING DSKY SUBSTITUTE PCB FOR FABRICATION

Adjustments to design and components

While I had initially thought that the five pins I needed to connect out of the 16 on the alphanumeric display components were situated so that they don't conflict, upon a double check I found that pins 1 and 8 are both involved, foiling my plan to stack the three signs close enough in a vertical line.

I found a different alphanumeric display component, this one surface mount, that is not as tall. The three fill fit so that the plus/minus signs are aligned with row 2 digits, slightly low on row 3 and slightly high on row 1, but close enough to proceed. It has some contacts that are underneath the component, like a ball grid array, but I think I can manage these with my reflow oven.

The bonus with this part is that it was common cathode. I can drop the separate driver chip and just drive these with the one unused position on each of the eight digit MAX7219 chips. If I wired up the five wires properly, I can light minus by sending a 1 digit to the chip and by sending a 4 digit I will get the plus sign.

Ultimately, however, I discovered that there was not enough room to stack these vertically and fit in the size of a row on the DSKY. If they were pushed together so close that they didn't look badly out of alignment in rows 1 and 3, they could not be routed. I pulled them out and inserted small surface mount LEDs in the pattern of the plus and minus sign.

I dropped out some more connections, mainly by the decision to have the keyboard circuit (yet to be designed) produce the eight output signals that go to the AGC - a five bit keycode plus reset, keypress and proceed/standby. If I had to decode the keyboard it would have taken thirteen signals linked to the Arduino and then the eight outputs, but with the keyboard doing the heavy lifting, the Arduino need not be involved at all, saving 21 pins

Routing of the PCB

My attempted routing was failing even with a 10 layer board, in large part because of all the vias that are generated attempting to route the connections between all the parts. I burned about a dozen hours on the laptop attempting to get a complete routing solution.

To ease the job, I would look at intermediate routing attempts, find components whose orientation could be changed to avoid vias and to simplify the paths. This is iterative with long routing runs in between.

After yanking the 14 segment alphanumeric displays and directly configuring the plus and minus signs, the routing work got slightly easier but several very dense areas continue to cause problems. For example, there are three rows of five 7-segment displays side by side, making it hard to connect the same pin of all five together in the narrow space between pins. This ends up using space on other layers and adding vias in the narrow ridge between one row and the next.

The solution to this was to hand route the pins of the digit displays, also to organize and route all the legend, line and Comp Acty LEDs to minimize via use. I worked on just a few of the driver transistors and relays, but then let the autorouter try to complete things.

My trace sizes are not aggressive but not too conservative either. Minimum signal of 5 mils and power traces at 20 mils. Could go quite a bit lower with the signal traces and a bit smaller on power, but I think the vias are the limiting factor not trace width. After shrinking the vias commensurately, I was able to get a nearly complete routing.

I had a few dozen errors, like trace to trace flaws, trace to via flaws, three connections that weren't completed and quite a few vias stuck in the middle of a pad. Finally, I had a board ready to send to the fab.

Projected view of front of the PCB (courtesy of DesignSpark)

Verification and testing

I began to breadboard the exact wiring I have built on the PCB, checking that it worked properly. First up were the relays with their driver circuits - using the same components I proved out its operation. Second, I verified that the AGC interface circuits correctly resolve the 28V spacecraft level inputs to inverted TTL outputs that my code in the Arduino expects.

I have three more breadboard checks to make - I2C driver chips hooked to LEDs, the MAX7219 driving two 7-segment displays and the custom plus/minus sign, and the various light emitting devices to determine the appropriate resistors to balance out their brightness. These will be done tomorrow.