Tuesday, May 21, 2019

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.

Friday, May 10, 2019

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.

Monday, May 6, 2019

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. 

Sunday, May 5, 2019

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.

Wednesday, May 1, 2019

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.

Tuesday, April 23, 2019

Physical construction work for IBM 1130 console display panel alternative lighting

Mounting the power supply components

I have four components to the power supply for the panel, three of which can be mounted with a screw onto the posts conveniently provided on the swing-down rear door of the panel enclosure. None of the holes in the components line up well with the posts. The fourth component is a fairly large filter capacitor, a cylinder shape without mounting points of its own.

The classic method to mount the filter capacitor would be a clamp that circles the capacitor and provides screw holes. The cylinder would project upwards from the door, the axis of the cylinder at right angles to the door, way too tall to fit inside the relatively shallow enclosure. Instead I want a mount that places the axis of the cylinder parallel to the rear door, so that the capacitor projects outward only by a bit more than its diameter.

The challenge will be fitting everything between the board and the swing door. There is a bit less than 2" clearance from the back of the PCB to the swing door, but the posts and a raised lower ridge on the door eat into the space by up to 5/8".

Assuming that I can fit the capacitor between posts, a clamp can be attached to one of the posts to secure it in place. These are 1 3/4" diameter capacitors, which can be mounted with a bracket that I just ordered from Digikey. These should just fit. In a few days I will have the hardware here and can mount the capacitors onto their final position on the swing door.

Filter capacitors used for power supply
The two buck converters needed adapter plates since neither of them have mounting holes that directly match the posts on the rear swinging door of the 1130 enclosure. I am having the adapters laser cut at Ponoko out of 1/16" plastic.

Interfacing with the computer wiring system involves connection to the 7.5VAC main lighting power, ground and the 155 discrete signals for 154 lights and the lamp test control. There is a terminal strip on the left side of the enclosure (viewed from the front) which provides the 7.5V on the top two lugs, common ground on the middle two lugs, and lamp test signal on the bottom two lugs.

The way that IBM designed the 1130 computer, they have a 7.5V AC transformer wired with one side tied to ground, so that the other side swings to both positive and negative excursions during every cycle. This does present problems with my initial power supply design, which was going to use a full wave bridge rectifier to give me DC for the buck converter boards. However, if one side of the input is tied to the negative output, the full wave design won't work properly.

AC feed tying one side of transformer to ground
Supply connections inside light panel enclosure
Instead, I must use it as a single diode of the component to rectify, producing only positive half cycles. This requires a filter capacitor to smooth out the more substantial ripple I will be experiencing.  I selected 9000 uf caps for the output of the rectifier diode and again for the output of the 5V buck converter.

To attach properly to the barrier strip inside the 1130 enclosure that provides the 7.5VAC, ground and lamp test signals, I have to create wires with lug ends to fit on the strip. My wire has to be bigger than 20 gauge (or two somewhat smaller wires, each attached to a barrier strip terminal) to properly carry the max current. I chose 18 gauge stranded wire.

The lamp test wire can be much thinner, since I am simply detecting the voltage level with a PCA9505 multiplexer chip. I do need to put a push-on connector for the lamp test to fit it over the pin on my PCB for this connection.

The power connections are flat solder plates thus only one end of the ground wire needs a lug end. The other solder plates run to the buck converter boards supplying 3.3 and 5 VDC. A lug plate is needed on the wire to provide the AC to the rectifier diode. The two filter capacitors need lugs on one end of the wires connecting them to the rectifier and the buck board, otherwise connections are soldered.

Since I must wait for the adapter plates to mount the two buck converter boards, I figured I could complete everything else and wait for the final physical assembly when they arrive next week. I installed the rectifier and two capacitors along the swinging rear door, but left the two converter boards dangling so they can be screwed onto the plates later.

Adding insulation and support material to the rear of the panel

The honeycomb behind the front panel is actually a number of blocks that are glued together and then anchored to the face plate by two threaded studs rising along the mid-line of the face plate. A metal plate extends across the mid-line and is held in place with two screws.

The PCB has solder mask and no components along the line where it will sit atop the metal plate and screws, but with time the screw heads may dig into the solder mask and eventually short. Further, since the PCB is planar but the screw heads make elevated points on the rear of the honeycomb, the PCB wobbles and won't sit flat.

My solution is to overlay the metal plate and screws with a long narrow foam strip. Small pieces of the foam will be applied at various points on the rear of the honeycomb to cumulatively provide a planar support onto which the PCB can rest.

Padding/insulation between honeycomb face and PCB face
Minor repairs to the IBM panel before installation

The IBM panel is a plastic front with honeycomb segments glued to its rear. Two plastic blocks are glued to the sides of the honeycomb outside edges. These are screwed onto vertical metal brackets to hold the light panel in place inside the enclosure. Both of the plastic blocks have broken free from the honeycombs due to deterioration of the glue used for manufacturing at IBM.

Edges of honeycomb where plastic blocks detached due to adhesive failure
 The bracket is attached to the top and bottom of the enclosure and has two screw holes facing sideways into the plastic blocks. However, getting a screwdriver in the enclosure to install or remove those two screws is quite difficult.
Plastic block attached to its bracket
The only effective method is removing the two end switch panels to get access. These metal plates have threaded studs on the rear that fit into an enclosure hole and are tightened with a nut you can reach from the rear. I have to remove the 4 nuts and swing the two plates out of the way, allowing me to put a stubby screwdriver in from the front and access the screw holes for the plastic blocks.

Re-gluing the plastic blocks to the honeycomb sides using epoxy
After removing both plastic blocks, I used epoxy to glue them onto the honeycomb sides. Once this was firmly set, and the standoff insulation applied to the honeycomb rear faces, it was time to reinstall the honeycomb.

Light profile tweaking for IBM 1130 console replacement display

Improving the incandescent simulation

I chose to wire up one of the incandescent lamps from the 1130 and subject it to testing, using both direct visual comparison and a light sensor to record the brightness over time. I picked up a TSL2591 light sensor module from Adafruit, which operates over an I2C link to an Arduino. I configured it to record the intensity of the light as ran the lamp through its paces.
  1. Turn the lamp full on from a cold condition, recording the brightness curve
  2. Turn the lamp off from a fully on condition, recording the brightness curve
  3. Iterate with 1 to 60 half-cycles of power out of each second, at a steady state
  4. for each state above, record the brightness
  5. For each of the states, adjust the color of a Neopixel until they subjectively match
  6. (optional) Test that the incandescent performs the same whether the on half-waves are contiguous or spaced throughout the second; verify that the only factor is number of on half-waves
The incandescent lamps are installed onto long narrow PCBs that host the SCRs used with the IBM lighting circuit. They are all soldered to a common wiring harness, thus I will be powering all 154 lamp positions in this test, but only energizing one of them.

The boards receive common voltages of .ground reference, 7.5VAC and lamp test state. The lamp test state biases the gate of the SCR thru an internal 6.8K resistor in each SCR package. The logic signal that controls the gate is fed through a 6.2K resistor external to the lighting PCB.

This set of resistors forms a voltage divider delivering 52.4% of the signal voltage to the gate of the SCR. It is built that way because when Lamp Test is desired, the voltage on that rail is +3V, thus even with a logic signal that is off (0V), the resulting voltage divider delivers about 48% of the 3V on level.

Thus, with the Lamp Test rail held at ground, all logic signals are either 0V or 1.572V at the gate due to the voltage divider action, but when the Lamp Test rail is pulled up to 3V, all gates are either at 1.44V or 3V depending on the logic signal state. This ensures that all bulbs fire when LT is on.

I only need to connect the 7.5VAC wall-wart transformer to the 7.5V and ground reference terminals of the lamp boards, while tying the LT rail to ground. Then, if I apply a voltage level above about 2V to the input pin of any SCR, it should fire the attached bulb. My Arduino provides the 'logic signal' to control the SCR.
My test circuit to drive IBM incandescent lamp boards
My first runs were with the naked eye (and video of the bulb). These do allow me to figure out the bloom and fade time of the bulbs. Capturing video on my iPhone and trying to time it, the speed of the fade is noticeably slower than the time to bloom on. That makes sense, as the filament has to lose heat primarily by radiation in order to cool back down, while turn-on involves the increase in resistance as the bulb turns on. The surge in current causes relatively rapid heating.

I wanted to hook up the sensor board and record the actual brightness curves to get a more accurate view. I quickly discovered that the Adafruit TSL9251 board is far too slow to capture enough slices during the bloom and fade. It appears to take about 100ms, reducing me to a slice each 1/10th second in a process that may be complete in less than a slice for bloom and just over two for fade. Not a big loss at $7 for the board.

The outcome of this testing was intended to produce a table of the brightness and color for all 31 levels, from 0 to 30 half-wave cycles on per second. Further, I had the brightness curves for a full turnon and a full turnoff to compare against the values of the 31 levels.

With the maximum brightness of the LEDs dialed down, so too the current consumption dropped. The Arduino testing, with all positions lit to full on state, drew under 3A total. This is a side effect, although the power supply is capable of driving full white brightness of all LEDs.

At this point I have some design decisions to make. I can cheat a bit since lamps which have a mix of logic states applied during a second might be matched to the average brightness and color of that average value. Thus, for lights that are flickering, I would get a realistic appearance this way. However, this won't work for rapidly brightening or fading lamps, particularly the edge cases of full on to off or full off to on.

I am toying with changes to the algorithm, such as taking dimming steps of the index value 3.5 times slower than brightening steps. This would adjust for the differences in bloom and fade speed of the filament. If I sample the logic states 38 times per second, then I can step up the index value for brightness 7 levels when the logic level is true and step down 2 when the logic level is false. That gives me a full bloom of about .13 seconds and a full fade of about .42 seconds.

The other change I have to make is in the color of each level. I am going to drive the incandescent to roughly 32 steps of brightness from off to on, then use the Arduino to tweak the LED color and brightness to match by eye. This is going to be a bit more complicated test setup, but I should be able to complete this by the end of this week.

Saturday, April 20, 2019

more refinements of the replacement console panel lighting for the IBM 1130 - bitstream, PS test, fidelity test

Loading the FPGA bitstream

I had completed the logic design (VHDL code) while on holiday, checking its operation with the simulator, so I was ready to configure the Spartan 7 based board that will drive the console lights. The toolchain provides everything needed to load the board, so it was a relatively quick and easy process.

Power supply testing

My power supply takes the 7.5VAC from the 1130 lighting circuit, rectifies it and, using two buck converters, generates both 5V and 3.3V to power the LEDs, I/O multiplexer chips and the FPGA board. The cumulative draw of 154 LEDs comes to 7.4 A with them all at full brightness during a lamp test; if they were turned on to white instead of yellowish the draw would be more than 9.24 A.

The enclosure on the 1130 that houses the control panel has a swing down door on the back for access. I will mount the power supply elements on that swing down door, making use of several raised posts with screw hole taps that are spread across the rear of the door.

I first set up a test of the power supply components I will be using. I found a wall-wart transformer that outputs 7.5VAC, allowing me to power the big bridge rectifier and the two buck converters that generate the 3.3 and 5.0VDC for my PCBs. The test confirmed that everything was good up to the current limit of the wall-wart, which is far too low to power the fully lit display panel but does permit a limited number of LEDs to be active.

Testing rectifier, buck converters and such driven by a 7.5VAC wall-wart
Next up, I hauled out the scope and monitored the ripple and noise on the DC power, both from the bridge rectifier and from the buck converter boards. While the output of the converters was good, as I expected, I do need to add a filter capacitor on the outputs of the main 5V converter. It will also provide some buffering of power closer to the LEDs that running through the 1130 all the way back down to the 7.5VAC supply.

Mechanical assembly

I had to add an extension that will raise daughter board higher off the rear of the main PCB, This gives me room to fit the signal wires from the 1130 logic onto the pins on the main board underneath. I simply used a set of Arduino shield socket strips to form the extension.

Daughterboard raised with extensions to allow access to signal input pins below it
Establishing the realistic filament characteristics

My first check of the reasonableness of the incandescent behavior simulation was to switch various LEDs on and off using an Arduino program. The effect looked good, in real time, to my eye and memory. The next check was to display all 32 steps from full off to full on, letting me judge the color shift and apparent brightness changes.

Displaying the 32 steps from full off to full on

Thursday, April 18, 2019

Finishing the 1130 console display board

Building the main PCB

The board was complete except for mounting the 154 LEDs, but my vacation got in the way a bit. Now that I am back, I began soldering it chains of LEDs. These are installed and soldered over the honeycomb assembly, which ensures that the PCB with the LEDs will fit properly when all done.

I did the first chain, which has 15 LEDs for the IAR register, another 15 for the SAR register, and 8 LEDs for the T clock states T0 through T7. After examining the solder joints under the microscope and testing for shorts or unusual conditions, I was ready to drive these with a simple test program running on the Arduino.

I did see all positions light, but there was some color shifting late in the chain which I attribute to inaccuracies in the timing of the Arduino driving the serial data. The library for the Arduino was made for a faster controller chip than the APA106 used in my bulbs, but in addition the timing requirements of the controller chip are different.

A few bulbs in a row will tolerate the inaccuracies bu these multiply as the chain grows longer. When I adjusted the library parameters to emit at a 400KHz rate, consistent with my chips, the outcome was perfect.

I moved on to solder in the second chain, which implements 16 LEDs for SBR register, 16 LEDs for the AFR register, and 8 LEDs for the X clock states X0 through X7. My test program drove these to validate the correct operation of all the new lights.

The third chain implements 16 LEDs for the ACC register, 16 LEDs for the EXT register and 8 LEDs for the DEBUG lights. Again, using the test program I drove these to confirm the wiring and solder joints. My test program produced one serial output but I jumpered them together to the three chains, so that the lights on all three chains behaved identically. This helped me test out all the bulbs and the behavior.

The last chain was completed and tested. It supports all the miscellaneous lights:

  • 5 LEDs for op code
  • 5 LEDs for the tag bits
  • 3 LEDs for the index register
  • 6 LEDs for the interrupt levels
  • 6 LEDs for the cycle counter
  • 2 LEDs for Carry and Overflow conditions
  • 1 LED for the wait state
  • 2 LEDs for parity bits 1 and 2
  • 3 LEDs for ADD, Add control and Subtract control states
  • 3 LEDs for the conditions ZR, TC and AS
Board completed with all LEDs soldered in place
The PCB with the LEDs rests atop the honeycomb, but across the middle of the honeycomb is a metal plate joining the top and bottom halves together, plus two metal screws that attaches the plate to the rest of the console panel. 

Honeycomb structure with metal plate and screws across the midline
PCB with LEDs inserted into honeycomb
I chose to put an insulating layer across the top of the plate and screws. A few other points on the edges of the honeycomb received matching spots of insulation to provide an even surface for the PCB as it is placed against the honeycomb. 

Watch a video of the Arduino test program stepping each chain through all lights then simulating flickering partial illumination - Click here for video

Saturday, April 13, 2019

Designing and testing the FPGA logic for the 1130 control panel

Writing VHDL for the FPGA

During my holiday away in the Bahamas and Florida, I wrote all the VHDL code for the FPGA. It consists of eight autonomous sections - four each for reading the state of 1130 logic signals and for driving the four chains of LEDs on the panel.

Coding in the Bahamas
The logic signals are read using PCA9505 chips that have 40 input pins connected to up to 40 of the 1130 logic signals. These are read over an I2C chain, which I implemented using some open source I2C master code and layering on the protocol to address and read from a chip.

As I read the signals, I use the state I just read to adjust the lamp level index. This is an integer running from 0 (fully off lamp) to 31 (fully on). I sample the signals 60 times a second and increment the index when the signal is one, otherwise decrement it. Of course, I never get the value get below 0 or above 31.

The LEDs employ APA106 controller chips inside which implement a single wire serial chain. The protocol is pretty simple - a reset burst of 60 us of logic low level readies the chips, then I send out the stream in GRB order starting from the first and ending with the last LED on the chain.

Each APA106 latches in the 24 bits intended for that LED, 8 bits of brightness each for the Green, Red and Blue color. It strips off the 24 bits and passes along the remaining signal stream to the subsequent chips. Thus, a string of 480 bits will provide the brightness and color to drive 40 LEDs in the chain

By varying the duration of the on and off times of the serial wire, I am modulating either a 1 or a 0 bit value for each of the 480 bit cells above. I can control the timing very precisely to ensure fault-free operation.

I built up logic to generate a sequence of the reset interval then up to 40 LEDs worth of color/brightness, repeating infinitely. As I begin each LED, which represents one of the 1130 logic signals, I use the lamp index produced by the sensing circuit above to select the proper GRB value for the index level.

Thus, if I have calculated a lamp is off, I get all-zeroes, while any lit level gives me the GRB that simulates an incandescent bulb at that brightness.This also simulates the color shift towards red as the lamp is dimmer.

The final two parts of the code are the startup reset controller and the lamp test logic. I hold all the finite state machines in reset for 63 clock cycles, also generating a reset signal that runs out to the four PCA9505 chips that sense the logic state. When the Lamp Test signal is on, I override the selection of color/brightness data to produce a full on white value in all LEDs.

Testing using simulation

Since my FPGA is a Xilinx Spartan 7, I used the Vivado design suite as the tool chain to write and synthesize the VHDL into the bitstream for the FPGA. This suite provides simulation capability, which I used to debug the logic that drives the LED chains. I worked with a single copy of the LED driver logic until it was producing the correct output under the simulator.

Simulating in Florida
Once it passed muster, I replicated the logic for the other three LED chains. I designed the LED chains to match the four PCA9505 chips sensing logic states. I could have chained all the sense chips together on one I2C link and chained all the LEDs together on a single serial line, but chose to break it up into four independent sections because, with an FPGA, hardware is essentially free and this further reduces the chance that anything will operate too slow and cause erratic behavior.

I did take some time off to watch the SpaceX Falcon Heavy launch, ensconced at the nearest viewing site in Kennedy Space Center, just outside the Apollo/Saturn center and across the creek from launch pads 39A and 39B. It was an awesome experience, although I can't throw any shade at the rest of the trip.

Tuesday, April 2, 2019

building the IBM 1130 console display main PCB

Building main PCB

I had the final corrected board fabricated by AllPCB.com due to their relatively low pricing, good results I had with prior orders, and promised quick turnaround of 3 days to build and 3 days DHL Express shipment.

As I mentioned in the last post, something went wrong as they were cutting up the panel into individual boards such as mine. They started from scratch building the board at the point where it would have been heading out to DHL. That did cost a full three days delay in receipt of the PCB.

All the parts were here, waiting for the board to complete the assembly. In the interim, I wired up the power supply parts to install inside the 1130 console enclosure. The back door of the panel enclosure had a row of threaded standoffs along the width of the box, which were used in some models to hold small boards holding several SCRs.

I will use these to mount three parts of the power supply. The incandescent lamps of the IBM design are fed with 7.5VAC, through an SCR. This only allows conduction on the positive going half cycles, thirty intervals out of sixty in a second. If the signal from the 1130 logic is above 0.8V at the SCR input, it cause it to conduct during that half-cycle.

The filament integrates the power delivered during half-cycles to an average that determines how brightly the filament glows. In addition, the frequency of the light is determined by the average power; more power means hotter tungsten and a shift towards the blue. In practice, this moves the bulb between red-orange and almost yellow.

My first thought was to make use of the 7.5VAC supply, through a full wave rectifier and then a buck converter to produce 5V for the main board and another buck converter to produce 3.3V for the FPGA pin level shifters . This plan fell apart because of a few realities once I did some analysis:
  1. 154 lamps, which can each draw about 45ma when fully on with a yellow-white color, draw about 7 amps of current
  2. The buck converter I have is capable of delivering only 2A of current
  3. I also need power for the FPGA and four multiplexer chips, but that is minor
  4. The rectifier is rated at 50A which is sufficient but it yields an overvoltage without a buck converter or other limiter (see point 4 above)
I can still use the rectifier to produce DC since it has plenty of current handling headroom. If I had a higher capacity buck converter I could generate the 5V for the main board, but in any case I can use the other buck converter board to give me 3.3V for the voltage shifter reference.

In the worst case, full on white for all bulbs, the current requirement of the main board would be about 9.5A, 47 watts consumption. I found and bought a good buck converter rated at 12A/100W  which gives me plenty of headroom. I believe it will work well with the output of the rectifier, using a suitable capacitor to smooth the 120Hz pulsating DC.

I set this up on a testbench once the new buck converter arrived, watching and measuring to prove out my approach to powering the new display. First I fed 10.5 VDC from a bench supply and adjusted the buck boards to 5V and 3.3V respectively. That worked great, but there wasn't much doubt.

Later I used a 7.5VAC wall-wart supply to check the quality of the DC both into and out of the buck converters. Using a big electrolytic filter capacitor I selected across the bridge rectifier, I wired the buck boards up to power with AC.

The AC adapter produced about 8.5 or more volts AC. The two buck boards delivered the voltage levels they were set to produce. The scope showed that the inputs and outputs were free of excessive ripple or transients.

The PCBs boards looked great when I inspected them on arrival. Oddly, there were only 3 even though the minimum which I ordered was 5, but better to get 3 that work than be further delayed waiting on five. I can't recommend AllPCB.com due to my experiences with this order. With the parts collected around me, I began to solder up the board.

The first items I soldered on were the pull-up resistors for each of the four I2C based chips, since the SDA and SCL lines must have this to work properly. Next was the set of headers into which the daughter card with FPGA will plug.

Installing the 52 pin PCA9505 chips was the most demanding work due to the very fine pitch of the leads. I started on those first. For each one, after I verified that all leads were firmly soldered and that no visible solder bridges existed, I then did careful continuity tests to the end destinations as well as power and ground.

I hooked up an Arduino to the I2C chain of each chip as they were installed and used a quick and dirty program to show me the results as I set each input pin to high and low values. That verifies that each does work as intended.

I had apparently bad connections to some of the input pins, which I couldn't figure out since there was continuity. I then noticed that in all four cases it was pin 39 of the respective chip, the last pin, that was not detected. Now I suspect that the Arduino library I am using to do the quick and dirty is defective.

I tinned the power leads and tacked on temporary wires for testing purposes. Eventually these will be hooked to the power supply I am building. They must be able to handle 7-9 amperes. The main supply had electrolytic filter capacitors installed to complete the power input.

I had to install 155 individual header pins, as these are the connections for the 154 logic level signals from the 1130 computer plus the lamp test logic level. I had already verified connectivity to the expander chips so this didn't need anything more than a careful inspection by eye.

Board, ready to install the LEDs

Tuesday, March 26, 2019

Nearing the finish line on the physical assembly of the DSKY substitute

DSKY SUBSTITUTE FOR THE APOLLO GUIDANCE COMPUTER

Display

The acrylic panel for the EL side is only 1/8" thick but my cover anticipates a 1/4" stack. The indicator side is built on a 1/4" panel so that is good as it sits. I had a 1/8" clear acrylic piece cut at Tap Plastics and with that could complete the glue-up of the two panels in their covers.

The panels I produced fit into a cover plate, with a bottom plate that will hold the acrylic panels in place inside the cover assembly. I used a dab of acrylic glue to anchor the panels into the covers, then more acrylic glue to hold the bottom plate to the rest.

Panels glued into cover assemblies with base plates
These will need 24 hours to set up strongly enough for insertion and gluing onto the aluminum faceplate. I intend to use Epoxy for that step since they have to bond to metal. I coated the panels with a clearcoat of paint to protect the surface of the lettering for both and the light mask on the indicator panel. The result wasn't as nice as I expected - a kind of pebbly finish to the clearcoat. In addition, streaks of the acrylic glue fell on the surface creating unintended lines on the surface.

Also, the acrylic glue wasn't bonding to the cover - whatever plastic used in the 3D printing service doesn't melt with the same solvent as acrylic. I will have to epoxy the panels into the covers, before epoxying the entire covered panel into the faceplate.

Keyboard

The glue on my coil springs had firmly set, allowing me to put together the PCB and honeycomb assembly. The bolts holding together this sandwich are part of longer standoffs that will position the top of the keyplungers at the right height.

I needed to do some minor modifications to the bottom of the honeycomb to better fit the PCB underneath it. One of the rows of pins for the Arduino Nano jut up  and impinge on the bottom rail of the honeycomb. In addition, a rework to the PCB placed two wires that run left to right under other rails of the honeycomb. I had to dig out space for all of these to allow the remaining rails to sit flat on the PCB.

The goal is to have the top of the plunger level with the underside of the DSKY faceplate. The keycap itself will add a bit of height and bring the key face that is touched by the user to the proper recess into the faceplate. I measured, fine tuned the supports, and assembled it all.

I checked the behavior of all the keys and was quite pleased. They move realistically, with the same downward travel and resistance as the real DSKY. All that remains to do here is to add the keycaps and this part of the project is complete.

I temporarily put on the faceplate so that I could glue on all the keycaps themselves. To do this, I need the plungers in their final location and the edges of the openings in the faceplate will let me register the keycap with uniform gaps on all four sides.

Keycaps glued in place on plungers
Assembly

The display section was ready for its final mounting in the enclosure. After checking the height of the mounting posts one last time, I attached all the cables, routed through the hole in the back.

I did another test of the circuit that detects the presence of the switched 14V (BPLUSSW) from the AGC as it is used to blank or light the EL side of the DSKY. It is properly delivering 5V to the Arduino pin when the 14V is present and dropping to 0 when it is off.

Next I had to test the relay that switches on to illuminate the legend text on the EL panel - VERB, NOUN and PROG - as those must switch off when 14V is not present. This too worked perfectly.

Finally, I had to verify that the boost board and driver for the electroluminescent wires are switched on and off when 14V is changed. I used a small relay to drive the power to the boost board. The boost converter board, relay and EL wire driver module had to be mounted to an insulated carrier, something I implemented with plexiglas.

The relay and boost boards screw down directly onto the plexiglas while the EL driver module needed epoxy to hold in place. I then had to develop a way to hold the plexiglas board down on the bottom of the enclosure, under the DSKY display PCB. I used some plastic screws thru holes in the bottom of the enclosure.

EL power assembly
Before I finalize the cables and the EL power assembly, I dropped the display board down and maneuvered its screw ends through the holes in the bottom of the DSKY enclosure. After it was arranged in the proper position, I laid the cover over it to ensure that all was aligned properly. All looks good.

Test fit with display PCB inside and panels/covers in place
With the keyboard assembly ready and in place inside the enclosure, all the visible parts of the DSKY are now in their final configuration. Next up is securing the El power assembly to the inside of the enclosure, wiring it to the display PCB, epoxying the panel/covers down, and installing the faceplate.

Designing the light panel for the IBM 1130 (LED replacing incandescent display lamps)

Daughtercard PCB build

I had designed a daughtercard that plugs into the FPGA socket on my main board. Its purpose is to host level shifters so that I can use an FPGA board with 3.3V I/O pin levels to interface with the main board which operates on 5V levels. The card has an offset socket into which the actual FPGA is plugged, the conversion circuits and a set of pins that fit into the FPGA socket on the main board. 

The board is a 4 layer sandwich with 5V and ground planes inside. The real FPGA is powered by 5V even though its IO pins are 3.3V, plus the four level shifter boards need 5V supplied to one side and 3.3V to their other sides. This was a very simple design with signal lines routed on one face and the 3.3V reference source on the other face, which is routed to the four level shifter boards. 

Daughterboard to provide level shifting for FPGA board

Main PCB construction

The main PCB is also a 4 layer sandwich, with 5V and ground planes inside. The two outside faces carry the signals.
Display panel in its enclosure atop the IBM 1130 computer

Display panel with 154 lights behind it
155 single pins are installed on the board and the signals routed to four multiplexer chips that can handle up to 40 signals each. The PCA9505 multiplexer chips are connected on an I2C serial chain, with unique addressing set for each chip. 

The FPGA drives the I2C chain and samples the states of the 154 logic signals from the 1130, plus the lamp test signal. Inside the FPGA, each signal is tracked and the color and intensity of its associated LED is set to mimic what an incandescent lamp would be doing on the original IBM display panel. 

The FPGA drives four single wire serial chains hooked to the LEDs. Each LED is directly and individually addressable on its serial chain. The board hosts the 154 LEDs, which are four-wire components. Two pins connect to the 5V and ground planes, One pin is the serial input and the last pin is the serial output to the next LED in the chain. 

Routing wasn't difficult, in spite of the presence of 155 pins, 154 LEDs, four multiplexer chips and the FPGA socket. Largely this is because the LEDs require only a single trace running from light to light in its chain; power is delivered directly from the inner planes. The bulk of the routing complexity comes from running the signals from all the pins to the four TSSOP sized surface mount multiplexer chips.

My first shot at the PCB included errors in the spacing of the lights on the far right of the console panel, when viewed from the front. I had to fix the design and submit it again for fabrication. I watched eagerly as my new board went through each step of fabrication, happy when it was ready for the final quality control and packing steps.

Alas, when next I checked, instead of a shipment notice I found that they had begun again from scratch. The great news is that their circuit testing and quality control process is good enough to spot problems and they won't ship poor quality PCBs. The bad news is that the estimated shipment is therefore delayed as will be the delivery of the board to my doorstep. 

Soldering down the four multiplexer chips needed the microscope and a lot of care - 56 pins, 28 per side, in a chip that is just over an inch long, thus very easy to create solder bridges or misalign the pins.

Pad for one of the PCA9505 multiplexer chips
Hooking up the LEDs was done on top of the plastic honeycomb of the front panel, ensuring every LED is in the best position as it is soldered down.

PCB laying over honeycomb, as it will when I solder in 154 LEDs
I did a test using three of the APA106 thru-hole LEDs placed on the board that was too short, while waiting on my final version of the PCB. I used an Arduino to play around with various parameters of timing and color shift to see how the LED looked compared to the incandescent bulbs they were replacing.



Monday, March 18, 2019

Preparing DSKY keyboard for final assembly

DSKY SUBSTITUTE FOR THE APOLLO GUIDANCE COMPUTER


Keyboard

I turned the honeycomb upside down to expose the inner, bottom portions of the 19 plungers. Each will have a spring glued in place, so I proceeded to add epoxy glue and insert each spring into position. These need a day for the glue bond to become fully hard, so I set this aside.

Epoxy of springs into recesses in key plungers
The keyboard is almost ready for final assembly at this point. I have all the shims in place between key plungers and along the sides and bottom of the enclosure. I though the top of the board needs shims but it does not have a surface to apply them, being an open framework. That would have required some additional plastic pieces to close in the open segments and provide the base to mount the remaining shims.

Fortunately for me, the guide slots in the honeycomb restrain the top five plungers from moving in the direction of the open gaps. It is not necessary to fill in those areas or add shims; the keys will move properly as they are.

Tomorrow I will put the honeycomb/plunger assembly atop the PCB and screw together the two halves. The four mounting posts will be attached to allow this to be installed inside the enclosure. I decided that the PCB is bowing a bit in the center from the combined spring pressure, so I need some legs to epoxy on, to support the bottom of the board.

Underside of keyboard PCB with Arduino Nano and cable in place

Top of keyboard PCB with keyswitches that will be pressed down by coil springs


Sunday, March 17, 2019

Finally completed all decal work for the DSKY substitute

DSKY SUBSTITUTE FOR THE APOLLO GUIDANCE COMPUTER

Display

Having realized my error in skipping use of the hot air gun to remove moisture, I set up again and prepared for another decal of white dots. The clear film came out of the water bath intact and I left it to air dry rather than blotting.

Underside of decal, waiting to air dry before adhesive spray
I gently sprayed the adhesive over the film and began to add blue painters tape to form handling and protective masks before touching this down over the target acrylic panel. This worked well and I was able to apply the three upper dots to the target.

Panel with center dots applied
With those dots successfully applied, I made up the left and right side decals in the same manner and left them to air dry. One worked well but the left side one had the clear mylar bond to the cover layer of clear mylar in the bonding carrier that runs through the laminator, instead of to the colored image on the paper,

Decal for right hand dots, a bit rough but usable
A second try on the left hand version produced a decal which floated off without one of the dots. On to the third try I did get a good decal which was left to air dry. These two were masked with blue tape and laid down over the target acrylic panel.

Underside of decal for left hand dots
Water bath with a decal soaking to release from paper
The result was a panel that looked just like I wanted and was quite similar to the real DSKY panel. I will have to insert that panel inside the 3D printed cover and glue the sandwich together. The final step will be to glue the sandwich into the front cover of the enclosure, but I have to fine tune the height of the display board before I do these steps. 

The indicator panel decal was prepared, air dried and ready for application. The challenge is to have the right acrylic panel as the target. I frosted some, but they are sufficiently thick that they cut down the light substantially. My only clear panel had text permanently bonded to it during a prior session. Attempting to clean the text off with acetone gave me a streaky damaged finish.

Indicator panel decal ready for application
I chose the panel with the lightest frosting and applied the decal to the front surface. It looked good, particularly when stacked with the light mask and cover. Similarly to the EL side, I will need to glue up the indicator panel side to have it ready for mounting.

Text in place on frosted panel for indicator lights
I did a quick and loose stack of the parts just to see how it is going to look when everything is fully assembled. This is satisfactory to me and will meet the relaxed goals of a DSKY substitute, versus an exact replica.
Display panels, not yet glued together or fasted to the front cover

More futile attempts to produce the last few decals for the DSKY panel

DSKY SUBSTITUTE FOR THE APOLLO GUIDANCE COMPUTER

Display

It occurred to me that one change from the early work where the decals transferred to the later work that didn't is that I ran out of the roll of paper towels I had been using and switched over to a different brand. Perhaps these didn't generate as much static charge as the original towels were capable of.

I made up another of the white decals, this time trying to use different clothes to establish the static charge. If I had solved the inadequate static cling with my test piece of white dots, I could quickly produce and apply the remaining text.

Setting up for work on the decals takes some time and I have to organize adequate workspace. I need water baths, drying areas, the laminator warmed up, cutting areas, and all the supplies in place. Therefore at the same time, I went ahead and prepared the black indicator text through the stage of fusing on black mylar.

The clear mylar peeled off the paper nicely, the dots and border all intact. HOWEVER, the next step is to dab the water off the bottom of the decal before spraying it with glue. It was at this point that one of the dots transferred to the blotting towel. It was perfect before I touched it.

My next try was to just leave the clear mylar decal to air dry, without any blotting, then hit it with the adhesive spray. That should retain structural integrity until I am ready to rub these onto the target panel.

Once again, the gremlins struck. During the step where I put the white dye mylar over the printed image and fuse them in the laminator, for some reason the white fused to the entire page surface, not just to the dots or the lines. Completely useless as a decal, it was a pure white rectangle.

White fused everywhere, useless

Black toner is only where white should fuse 
Frustration rose to the point where I put this aside again. I will work on it after regaining some motivation. Having used this system for a large number of decals when building my life sized replica IBM 1130 (see. IBM1130.blogspot.com if curious), I just can't understand why it is being so cantankerous with these final decals.

Late breaking news - after shutting down and clearing up, I realized I had missed a key step in the procedure. It is essential to use a hot air gun to remove all the moisture from the paper before fusing the colored mylar on the image, but I forgot to do this. I speculate that the moisture in the paper turned to steam and melted the white mylar onto the paper.