Wrapping up 'acceptance testing' of the DSKY substitute and working on AGC patch panel

COMPLETING ASSEMBLY OF DSKY SUBSTITUTE

Adding in serial link to drive external EL panel

The Arduino Mega has four serial ports, one carried over the USB cable but three more that can be accessed by the software and pins on the board. I chose Serial1, using pins 18 and 19. Now I have to add code to command the EL panel built by Ben Krasnow (Applied Science YouTube channel) to have it mirror the output of my own.

I haven't written or debugged the code to drive his board, something I will defer until next week. My first priority is getting the DSKY complete and fully tested in advance of wiring it up to the Apollo Guidance Computer.

Activating EL wire in my display

My display uses electroluminescent wire for the three horizontal green lines on the display that separate the outputs for registers 1, 2 and 3 from the upper displays. These wires require high voltage AC, which is generated by a driver module inside the acrylic base. The driver is switched on and off by a relay board.

The driver should only be on when the BPLUSSW (14V switched power) from the AGC is present. The AGC can be in standby mode, with no power on BPLUSSW, which causes the panel on the DSKY to blank out.

I have been sensing the BPLUSSW using a voltage divider on my PCB that produces a 5V signal when the computer is not in standby. This seemed like a perfect source for the drive to fire my relay board, however the Arduino has an input pin connected as well. The result is that the Arduino drags the voltage way too low because of how the resistances of my divider and the Arduino input are set.

The Arduino gets the signal because the driver on my PCB that lights up the legends under Verb, Noun and Program requires a ground level to turn on. Thus it is logically inverted compared to the output of my voltage divider - when no BPLUSSW, I light the legends and when the computer comes out of standby, I extinguish them.

I had to put in an inversion in the Arduino code and drive another output pin, so that when BPLUSSW is on, the output pin is pulled to ground and causes my legends to light. I now have to set up another output pin that is not inverted but mirrors the BPLUSSW voltage divider, since my EL wire driver board relay needs +5 to activate, not ground.

I do have spare pins on the Arduino Mega 2560, although they are not connected to headers on my PCB. I can insert a discrete wire (carefully) into the chosen pin and route that to my EL driver relay board. A quick update to the Arduino code and it was ready for testing.

Soldering the external female connector pins to the PCB wiring

The task of soldering my 'inside' connections - short cables that run from the header jacks on my PCB down into the acrylic base where they get connected to the solder lugs of the female 85 pin Bendix connector - was tedious and made slower by the constant double checking to be sure everything is right.

Completing the cable on the external male connector

Once I had all the wires extended the soldered joints needed to be covered with shrink wrap and then the entire cable wrapped in electrical tape to make for a neater wiring harness. As part of this job I tested all the connections through to the inside connectors where they would plug into the PCB, to be sure I had a solid set of circuits.

Each external wire was hooked to a continuity tester and I located the PCB connector where it terminated, then stuck on a label with the signal associated with the wire. Repeat 34 more times and I had all the signals and power lines identified and verified, ready for testing.

SETTING UP TESTING RIG

Testing the DSKY replica is complicated by the odd voltages used. My PCB and some minor boards are driven by the usual 5V DC, but we also have to provide 14V and 28V for testing. The AGC signals coming into the DSKY swing between 28V and ground. The computer as a 14V supply that is turned off when the AGC is in standby, thus we have to take the switched 14V into the DSKY as a sense input.

Incoming signals work by having 28V fed through my PCB interface circuits and the input pin pulled to ground to activate the signal (inverted logic). Outgoing signals pulls their output pin down to ground when activated (also inverted logic). Fortunately, I can feed whatever voltage I want on the output pins, so I chose to use pullup resistors on the tester side.

My 23 inputs to the DSKY are handling 28V, so I made use of banks of relays that will pull the signal to ground through a 2K resistor when the relay is activated. The relay trigger circuit is fired by the Arduino which I use for the test driver. The 8 outputs of the DSKY are hooked to input pins on the Arduino set with internal pullup. I use the serial link over USB to a computer to control the test and read results, in addition to observing the DSKY behavior.

I didn't have enough 2K resistors for the setup today - five 2K and 7 2.2K were all I could scrounge up - but I can test a fair amount of the DSKY with that, stepwise. As long as the codes for the digits don't have more than eight total ones out of the ten bits to be set in a relay command word, I have enough resistors. I can do a more complete test later this week when I get more resistors.

TESTING THE DSKY

My series of tests:

1. Power up 5V, nothing should show
2. add 28V, nothing should change
3. Add 14V, the legends (Verb, Noun, Prog) and the three lines should light
4. Seven of the fourteen lights have discrete lines to trip them, toggle each
1. Stby
2. Restart
3. Temp
4. Key Rel
5. Uplink Acty
6. Opr Err
7. Comp Acty
5. set up the register value (M12-M15) for lights and toggle each of the next eight
1. Vel
2. Alt
3. No DAP
4. Prog
5. No Att
6. Gimbal Lock
7. Tracker
8. Prio Disp
6. With some of the lights lit, turn off 14V, verify they remain on, then turn on
7. Set up register value and toggle signs
8. Set digits in Prog display
9. Set digits in Verb display
10. Set digits in Noun display
11. drop 14, verify they turn off, turn 14 on, verify they are blank
12. Set up Verb, Noun and Prog, then turn on VNflash and observe
13. Oscillate VNflash
14. set digits in registers
1. R1
2. R2
3. R3
15. verify split register changes both R characters
16. flash key rel light
17. verify Pro key detected
18. verify keypress release works (on while key is depressed)
19. verify reset key discrete
20. verify all key codes sent

I ran through the tests and at step 3, I wasn't getting the electroluminescent wires lighting to switch on. That was because of the funky way I was inserting the newly added wire that drives the EL driver board relay - it kept popping out.

After I found a way to secure those wires down inside the headers on the Arduino but then discovered that the Arduino and the relay activation were cycling - as the relay flipped on due to presence of 14V signal, the driver pulled so much power that the Arduino reset. I realized I need a humongous filter capacitor to support the surge as the EL driver turns on. That fixed the behavior.

I modified the DSKY firmware to emit diagnostic information over the serial port. I will be able to see whether the input is ever checked and if it is detected. I saw that when I pulled down the Oper Error input, it was properly detected. The Caution/Warning lights illuminated too, thus this part of the test is good.

The COMP ACTY light did not illuminate with the 14V missing, which is correct. I then hooked up the 14V to the sense line to verify that when unblanked all will work well. The other lights behave in a way consistent with the real spacecraft.

Six of them are lit or dropped based on a discrete signal coming from the AGC, so they will turn off as soon as the AGC goes into standby. Eight of them are relays inside the DSKY that are only set or reset by writing to register bank 12 with specific bits on or off. If they were lit, they remain lit while the computer is in standby and don't turn off into the software writes to turn them off as part of coming out of standby.

Next up I tried to test the signs, which are turned on or off by writing a specific pattern to various register banks. I set up the wiring but I didn't see the sign words light. It was time to do some diagnostic output from inside my firmware and figure this out.

DESIGNING INTERFACE PATCH PANEL FOR AGC

The AGC communicates with the rest of the spacecraft (and the DSKY) through a 360 pin connector (A51). There are four main types of interface circuits for sending and receiving discrete digital signals and for sending and receiving pulses.

The spacecraft systems mostly operate with discrete digital signals which are 28V when logic high and near ground when logic low. Pulse circuits use approximately 10V for the on state of the pulse. My panel will convert those voltages down to levels that can be wired to TTL or LVCMOS digital devices.

The panel will be constructed as ground support equipment, fitting in two racks side by side. Each side implements half of the A51 connector signals; the connector is six rows of 30 pins, a break and 30 pins. Thus, one side will have six rows by thirty columns of receptacles for the patch cables.

The cables use 4mm banana plugs on both end. Above the rack panel with the 6 x 30 connectors hooked to A51 will be five sets of interface circuits, each with 26 interface circuits (8 type C, 7 type D, 6 type XT and 5 type Y).

Readying the DSKY substitute and preparing to interface to the Apollo Guidance Computer

PLANNING FOR AGC MAIN CONNECTOR AND SIGNAL INTERFACING

Reviewing and documenting signals

I spent about a dozen hours poring over different documents and schematics to be sure that I had a complete map of the interfaces between the Apollo Guidance Computer and the rest of the spacecraft. There are 360 pins on connector A51 that provide these connections between the interface modules A25, A26, A27, A28 and A29 inside the computer and the external systems.

Some of the pins are used for power connections, some are spare but the majority are important input and output signals that we may need to connect with in order to create a realistic reenactment of some portion of the Apollo 11 mission. In addition to the signals that operate the DSKY, there are 264 pins that implement 176 input/output signals.

One document I built lists all the pins, which interface module and circuit it connects, and the external system purpose of that signal. Another document lists each interface circuit in the five modules and cross references it to the A51 pin and purpose.

I used those to look for holes in the lists - interface circuits that aren't listed in some document or pins that aren't understood. I am down to two pins on the A51 connector, one of which I know has a thermistor wired to it for analog temperature sensing; likely the other has a similar analog monitoring role.

From these documents I moved on to look for discrepancies. As an example, the schematic for module A26 has different interface circuits hooked to the wires in the spacecraft used to turn the LM Ascent or Descent engines on and off, compared to the other documents I have been using.

Fortunately, the interface circuits are associated with known software locations thus I can look to the Luminary code to determine which set of interface circuits is correct. The engine is either controlled by channel 12, bit 7 or the on and off lines are controlled separately by bits 13 and 14 of channel 11. In fact, this was a late change and the proper signals are controlled by bits 13 and 14 of channel 11.

The control signals for the landing and rendezvous radars were misdocumented in some places but the schematics and LM wiring showed the correct assignments, which I rolled into my master spreadsheets.

Listing needed interface circuits for AGC signals

I also built a spreadsheet listing the AGC pins that get routed over my cable through the 85 pin connector to make use of the DSKY substitute when running the real AGC.

CONSTRUCTING BASE OF DSKY SUBSTITUTE AND WIRING CONNECTORS

I installed the connectors for the AGC and modern power cables into the acrylic panels and glued together the base upon which the aluminum enclosure will sit. This gives me plenty of room inside for the Electroluminescent wire boost converter and driver circuits, plus room for the cabling between the PCB up inside the aluminum enclosure and the external connectors down in the acrylic section.

New acrylic base and external connectors

I installed wiring for the signals between the AGC and the DSKY that are relevent to me. Some provide 115V 400Hz and other power feeds which aren't necessary with my replica. Others activate relays fit inside the DSKY whose contacts are routed back out to external spacecraft circuits but never affect the DSKY operation. These I didn't implement; if necessary we can wire them externally to the AGC and house the relays elsewhere. 

AGC connectors and chance to use Applied Science EL panel

DSKY SUBSTITUTE FOR THE APOLLO GUIDANCE COMPUTER

Bottom case

The DSKY aluminum case is not deep enough to comfortably fit the power supplies for the EL wire and any connectors I add. Thus, I designed a 3 1/2" box that will fit underneath. On a side note, the resulting combined size is closer to a real DSKY.  I designed this from 9mm thick acrylic and sent the work out to Ponoko.

For connectors to the outside world, I chose to use a very similar connector to the one selected by MIT in their design of the DSKY. It is a Bendix 85 pin circular connector, readily available on eBay and on its way to me. I chose a similar but smaller two pin connector for my main 5V supply to the unit.

Power connector - total overkill for 5V supply

Connector to AGC signals and power

Planning for possible replacement EL panel

Ben Krasnow created a true electroluminescent panel as a replica of the one used on the MIT DSKY, as announced on his (watch video) Applied Science YouTube channel. He has loaned it to us and I now need to find a way to make use of this marvelous creation in the short time left before we are again working on the AGC.

Once I pick it up, I will see if its size is suitable to fit inside the aluminum enclosure I am working with on my DSKY replica. If it is, then I can remove my 7-segment display parts from my PCB, drop the mounting of the PCB lower and place his panel in the enclosure opening. His replica is programmable over USB serial link, which I should be able to accommodate from my Arduino in my replica.

The worst case situation is that I can't fit it in, thus we will need to use my replica as built with his panel sitting beside it and linked over USB cable. More on this soon, once I have completed the measurements and detailed planning.

Restoring and testing the Core Rope Simulator boxes for the Apollo Guidance Computer

Testing the Core Rope Simulator boxes

Ken Shirriff and I have been testing the two Raytheon built boxes that provide the Core Rope functionality for the AGC. We have been using some pulse generators and power supplies to send in the signals that will come from the AGC as it attempts to read a word of core rope memory.

One of the two core rope simulator boxes; Dipsticks on left, cordwood modules on right

There were a few problems we found and fixed early - a couple of broken off wires we resoldered, a screw that failed in one of the IC chip holders (DipStick), materials failure in the DipStick holders that compromised connectivity of chip leads to the holder terminals.

The early testing of the input side, where we introduced the various address bits and control signals coming from the AGC,  went well. All our address, module and strand selection signals, plus the set and reset control signals, were properly detected in the simulator boxes.

We then focused on the outputs from the simulator boxes to the AGC - 16 differential signal pairs representing the 15 data and 1 parity bits of the word that was being read. The last data bit, number 16 as the AGC numbers memory bits, did not produce a good pattern.

The signal from the AGC requesting to read some address is a 1 microsecond pulse. If the differential data coming from the external system over the 85 pin connector is a binary 1, then the pulse from the AGC causes a pulse in a transformer for that bit position. The other side of the transformer produces a 500 millivolt differential signal, one side of the winding going negative while the other side goes positive.

What we saw on the 15 working bit transformers was such a differential signal, but the failing transformer showed us zero volts on one lead and a much larger positive voltage on the other lead. It still added up to 500 mv, but it wasn't swinging the two leads in opposite directions like the other transformers.

Blue and green signals are not moving in opposite directions

After some thinking and some investigation, we realized that one of the output leads of the transformer had to be shorted to ground. Both the transformer and the resistor that is connected to that lead are sitting in a cordwood module in the simulator box, with no visible connection to ground.

Cordwood stacks components between two end plates, with the parts fitting perpendicular to the plates. This allows resistors, capacitors, transistors, transformers and other parts to be fit very close together, like bottles of soda sitting in a carton, with a plate at the bottom and top of the bottles. Wires connect the parts only on the outside, along the two end plates.

While the end plates we could see were made of nylon, with the wires from a transformer routed out of the hole in one end plate and connected to resistors or other parts, for heat dissipation reasons, the transformers are actually set in drilled holes in an aluminum body that is only covered on the ends with nylon.

Thus, we realized that the lead from the failing transformer was stretched taut in its connection from transformer to its associated resistor in the adjacent cordwood module. Somehow, we thought, the insulation has rubbed on the edge of the aluminum body and caused a short.

Ken tested the short while I manipulated the transformer lead with a toothpick. Immediately, the short went away! Our permanent fix will be to glue a small bit of insulating plastic under the lead to keep it from rubbing against the aluminum body.

Now that we had proven that all the inputs and outputs between the AGC and core rope simulator modules worked correctly, it was time to test the interior logic. That is some timing and control circuits, the conversion of module, strand and core to linear addresses, and the interaction over the thick cables with Ken's external system.

We began setting up conditions and testing the parts of the linear address generation, but soon found another problem. The generated signal for an even numbered strand worked properly for 5 of the 6 even values, but strand 10 did not work.

There are some diodes and a transformer involved in this process, so we began checking continuity and diode voltage drops. The diodes and wires were fine, but the transformer output was not operating. Again, we did some testing and a lot of thinking. Finally, we began looking at the wiring from the transformer, wondering if we had another short.

One of these orange transformer wires has a failed weld at the  left resistor post

However, we instead saw that a weld had failed. The wire from a transformer stuck up through the end plate of the cordwood module, where another wire was tack welded to carry that signal off to other circuits. Our toothpick moved the other wire, which was not in contact with the transformer lead. Next time we work on the module, we will solder the contact back, verify that our problem is resolved, then move on to the remaining interior logic of the simulator boxes.

When they are checked out, Ken can test his external system and its interaction with the core rope simulator boxes. The final test will have to wait until Jimmie comes to visit with the AGC and we can test the entire system - AGC, core rope simulator boxes and Ken's external system - and get it all working properly.

Recap of Core Rope Simulator function

The Apollo Guidance Computer (AGC) uses Core Rope Modules to store its read-only programming. Each of the six modules hold 6K words of memory, each word being 15 data and one parity bit. The programs are 'stored' in the core rope during its construction when wires are woven either through or around the cores to permanently set the value of that bit to 1 or 0.

During development of the programming it would be too cumbersome to wait many weeks for the weaving of new core rope modules anytime a change is made to read only memory contents. Several methods were used to avoid the delay, by simulating the read-only core rope using some type of regular computer memory. One such method installed two Core Rope Simulator boxes into the AGC in lieu of the six core rope memory modules it normally uses.

The Core Rope Simulator box is connected by two thick cables to some ground-side racks of machinery. The simulator box will intercept the address and control signals that come from the AGC to the core rope modules, communicating those requests to the external system which in turn feeds the word of data that is associated with that address.

One of the two 85 pin connectors on the core rope simulator boxes

The simulators never fly into space, but are used on the ground either for development or testing when rapid changes of the read only memory contents are needed. The AGC we are restoring was installed in the Lunar Module Test Article 8, which is a Lunar Module built by Grumman for ground testing purposes. The LTAs were too heavy and not fully qualified for operation in space.

LTA-8 was the unit used to certify the follow-on LMs for use in space. LTA-8 was set in a large vacuum and thermal test chamber in Houston, where astronauts worked with the machine to ensure that the flighty-ready LMs were safe for human flight.

A core rope module implements the 6K words of 16 bits each using only 512 large cores in a module. Each core stores the data for 192 bits (12 words). It does this by weaving the wires for all 12 words through the single core if that bit is to be a 1, otherwise the wire is woven outside of the core ring.

Connectors representing three of the core rope modules; these plug into the AGC

The address coming from the AGC is broken up to select one of six core rope modules, one of 12 strands (word number inside a core) and one of the 512 actual core rings. The selected core ring in the chosen module is set to the on magnetic state, while the other 511 are left in the off state.

When the control signal requests the reading of the content, the core ring is reset. Any wires that are woven through the center of the core ring will see a pulse as the core ring is rest, while the wires bypassing the core don't see any signal.

The strand number selects which of the 12 words of that core are to be channeled back to the sense amplifiers inside the AGC. Thus, the address and control signals are pulses that select and set cores, then reset them to cause the core to send pulses back to the sense amplifiers.

The core rope simulator boxes we are restoring do not have actual core rings, nor are they organized into six modules or 12 strands of words or 512 core ring addresses. The box has to interface with the same circuits that normally set, reset and select core rings, which it does by using small transformers that electrically act like the cores.

While the core rope modules are organized into six modules, 512 core rings, 12 strands and 16 bits to the sense amplifiers, the actual memory address inside the AGC is a linear range of 36K continguous word addresses. The external system connected to the core rope simulator boxes also sees a linear range of 36K contiguous word addresses, not modules, strands and cores.

Thus, the core rope simulator box accepts pulses from the AGC that would, in real core rope modules, set or reset a core ring at specific times. It has to save those module, strand and core addresses from the six sets of pins where the six real modules plug in. It will convert the addresses back to the linear range and send that address out to the external system.

The external system looks up the contents of the linear range address it received over the thick cable and sends that word back to the core rope simulator boxes. The box will then take the 16 bit value and use it to generate signal pulses via transformers that will look, to the sense amplifiers in the AGC, just like a pulse that was generated by a real core ring resetting.

We received the core rope simulator boxes with the AGC, but did not have any documentation at all about them. No schematics, no diagrams, no description of how they worked. Worse, we didn't have the ground based external system or the thick cables that run between external system and core rope simulator modules.

Ken had to reverse engineer the two boxes, understand their operation and build schematics. He then had to design and build an external system that would connect via thick cables and work properly with the simulator boxes. It had to recognize the linear address coming from the boxes, interact with the control signals at the right time, and feed the desired word of data back to the simulator boxes in time for them to pass the data into the AGC.

The external system is built around a Beaglebone and a custom printed circuit card, makes use of the same 85 pin aerospace connectors that are on the outside of the core rope simulator boxes, and will allow us to hold onboard all of the known versions of Apollo software, so that we can select which version is active to the AGC. For example, we can pick Luminary 210 which is the software that flew in the LM on Apollo 11.

DSKY closed up and ready for testing with a purpose built test rig

DSKY SUBSTITUTE FOR THE APOLLO GUIDANCE COMPUTER

Assembly

After detailed examination of the space available inside the DSKY enclosure, I decided that there was insufficient space to arrange the power board - boost converter, relay and EL driver module - without compromising the remaining components. I therefore decided to mount this board externally, on the outside bottom of the enclosure.

I was ready to assemble when I detected that one lead of the cable to the EL wire had broken loose. That needed to be repaired before I could install the display board with all its cabling. It was soon fixed.

The display PCB was screwed into place inside the enclosure. I did the epoxy gluing of the light dam over the PCB, then worked on covers and panels to get them glued together and onto the faceplate. Now that everything fits together nicely, I can put on the front screws and some mounting standoffs on the  bottom of the enclosure, to complete the physical construction.

Testing

I had designed a test fixture driven by an Arduino Uno, leveraging 24 relays and other circuitry to act in place of the Apollo Guidance Computer, sending control signals to the DSKY and receiving the results of operator keypresses. I had to wire this up and set up a triple power supply with 5V, 14V and 28V sources that are required by the DSKY substitute.

A real DSKY would have 28V and 14V, as well as 115V 400Hz AC, but not 5V. That last voltage is needed to power my modern components inside the DSKY substitute. The 115V supply illuminates bulbs under the keycaps of the real DSKY, but is not used on my implementation.

I began wiring together the relays in the text fixture and connecting it to the DSKY cables. 

Refining the incandescent simulation: measuring the real bulb behavior

Refining incandescent simulation

I set up the Arduino to attempt to produce 32 steps of illumination for the incandescent bulb, simultaneously setting the LED to the same step number. Each would illuminate for 2 seconds, giving me time to compare both brightness and color of the two light sources, side by side.

On my first try, I didn't get great results. My method of driving the bulb was too crude - X milliseconds on followed by Y milliseconds off, for example 2 on and 3 off. Clearly this didn't work well. Also, I could see that my LED, even at half brightness level, was noticeably brighter than the real incandescent bulb at its maximum brightness.

I adjusted the spreadsheet to produce the exponential curve across 32 steps from 0 to 100% on at a max brightness level of 15% of the LEDs maximum. . I did an abbreviated test with the LED and the bulb both full on. It looked roughly identical, but I will use a phototransistor to measure more accurately later.

With the top of the curve set, I needed a better ratio between turn-on and turn-off time of the filament. Too, if I can refine the shape of the curve as it turns on or turns off, that will make the LED levels even more realistic.

My existing measurement tools weren't working - the original photosensor board with its ADC is too slow to sample the bulb and even at slo-mo speed with the iPhone video, I don't have enough resolution. Too, judging brightness in video frames is hard. Ken Shirriff suggested using a phototransistor connected to a scope, where I could capture and freeze the curves, getting good speed and brightness percentages.

I bought one and continued the testing with the simple cases of bloom from full off to full on, and with fade from full on to full off. These gave me a very nice exponential curve for the fade - taking about 300 ms to fade completely.

Phototransistor trace (inverted illumination level in blue) for switching off the bulb

The trace for the bloom of a bulb from cold to a full on illumination was less ideal. While you can roughly fit the data points to an exponential curve of shorter duration, perhaps 100 ms maximum, the shape is distorted by reversals in direction.

I looked for the cause of this distorted shape, thinking about flaws in my experimental method, the possibility that illumination of a filament exhibits very complex physics, and the nature of the IBM lighting circuit driving the bulb.

The bulb is powered by 7.5 VAC connected through a Silicon Controlled Rectifier (SCR) and the bulb. This means that the SCR will only conduct on the positive half cycle of the AC and switches on when the input lead is above a threshold and the instantaneous AC voltage is above the diode junction voltage drop.

This means that even with a full-on logic signal applied to the SCR input, the bulb will see a varying positive voltage over approximately 8.35 ms, with a slightly longer period of zero voltage as the AC swings down and through the negative half cycle. Since power changes as the square of voltage, there is a dramatic oscillation of power through the filament.

When I looked at a shorter timescale I could see that the reversals or irregularities in the trace do appear to fit a 16.7 ms cycle time. Thus I have to conclude that the console lamps of IBM 1130 and 360 systems will turn on with the odd illumination pattern seen in my scope capture.

Turn-on of filament with shorter timescale seems to match the 16.7 ms period of 60Hz AC

My simulation of turn-on would need to be quite a bit more complicated than a simple exponential curve to capture this effect. Whether that is necessary to fool the human eye and brain is an open question, but I will build the initial implementation with solely exponential timing.

Working on installation of the IBM 1130 light panel using LEDs to simulate incandescent bulbs

Wiring and assembly of power supply

I have the two filter capacitors mounted on the swing down rear door, along with the bridge rectifier module. Next I assembled the two buck converter boards onto the laser cut adapter plates I made. These were also mounted on the door.

I did discover that the filter capacitors were too tall to fit in the orientation I expected, but if I swing them 90 degrees they could be oriented in the long (width) direction of the enclosure and fit properly. I did some test fitting of the adapter plates and components until I was satisfied with their fit.

Components of power supply in place across rear door of panel enclosure

With all of these installed in place I could finalize the lengths of the wiring and begin wiring them together. These are soldered in some places such as the PCBs, attached with lugs onto screw terminals in others, and inserted into screw tightened terminal blocks for the remaining connections.

The use of lugs permits removal of the PCB along with the harness and supports replacement of any modules that may fail in the future. I made use of color coded wiring - black for ground, yellow for 7.5VAC, blue for rectified unregulated voltage, green for 3.3VDC and red for 5VDC. A white wire connects the Lamp Test voltage from the computer to the signal input pin on my PCB.

After completing most of the wiring harness, when I was ready to solder the last few connections, my Weller soldering station expired. Something went wrong in the tip (PES51) and the station is dead in the water. Replacement coming later this week, thus will continue wiring power supply at that time.