Moving ahead on reader, pedestal and tabletop, week ending January 12

DOCUMATION CARD READER ADAPTER AND INTERFACE

I was initializing the chip for input board two incorrectly, setting up the interrupt on the first bank rather than bank B where the lines are wired. I corrected this and retested. With 2K resistors pulling up the lines, I had nice clean clock pulses and a low voltage of about .8V. With 4.7K resistors pulling up the lines, my low voltage dropped to .5V, but the capacitance of the long line is causing the pulses to ramp slowly on the leading edge.

Buffer chips would definitely help this and also permit me to go up to 10K resistors, further dropping the low level voltage. I am still resisting the need to take this step, but may relent if I can't find other means to resolve this. The link does appear to be working acceptably, in spite of the slow rise times, but only at the slowest 100KHz rate.

I see that the clock is high for 4us and low for 6 us, well within the specs for operating at 100KHz, losing about a microsecond due to rise time delays. At 400KHz, the clock should be high for 1.25microseconds, yet the ramp takes about 1 just to turn on, leaving only .25us for on time and 2.25 for low, way out of balance.

Thus the conundrum - to run at 400KHz, the link needs fast rise times, dictating very low pull up resistance, yet that raises the voltage for logic level 0 too high to safely operate. It is the total capacitance that slows the rise time, which is a function of distance. I have come to the conclusion that I must build and deploy the I2C buffer/extender circuits in order to preserve both the fast clock rise time and the wide voltage margins. I will order the parts and have designed the PCB which yields 12 of these independent small boards. I will manufacture these one night before the chips arrive and cut them apart.

I2C Buffer board layout with annotations and component values

In order to continue other tasks, I set the link back to 100KHz and will experiment with some active pull up using 4066 analog switches, just to see whether I can crisp up the rise time enough to work with 400KHz, at least until I get my real buffer chips and install those boards into the link.

My test bench is quite fragile and often some problem occurs in the testing setup that wastes my time investigating what seems to be a design or implementation problem with the interface itself. I had two of these distractions strike - first, the data line broke loose from the temporary harness attaching it to the fpga board, first causing intermittent contact and then full lose of the SDA line. Second, the SCL clock line only rises to half its target voltage - which may still be sensed correctly by the input boards but it shrinks the length of the 'on' part of the clock and delays its recognition, altering the timing of the data line manipulations.

I corrected the first issue by reattaching the wire. The second problem seems to be a classic transmission line effect due to the extended runs of plain wire to the trigger circuit and the scopes. I will test this by running with the clock to the circuit and only a scope probe right at the fpga terminal, no other wires connected, to see whether my suspicion is correct. If so, then the effect on the clock signal is an artifact of how and where I am observing it.

There was a little change, but not enough to explain the problem, so it was not transmission line issues. Coincidentally, a 'light bulb went off' when I noticed that the cycle time of the clock was just over 3 microseconds, which corresponds to a link speed of roughly 325KHz, neither the full 400KHz nor the target 100KHz. With the higher rate, the flattened slope and failure to fully reach the high level makes more sense. I am looking into my code where I thought I had adjusted the signaling rate down to 100KHz as that is evidentally not working properly.

I discovered that one of the output board lights would not work, because the pin for that channel on the MCP23017 chip was not soldered to the pad beneath it. I corrected that along with checking the remainder of the board for continuity and correct wiring. The output board uses FET transistors to level shift the I2C signals to the 5V power used with the output MCP23017 chip, but these will be replaced by the built-in level shifting capability of the LTC4313 component used in the I2C buffer boards I am building.

With the wiring and testbench fixed up, the code repaired and my scope set up, I ran the link up to 400KHz with the active pull-up board at the fpga end of the cable. The transmitted data values sporadically flicker a bit, maybe once every few seconds, when at the full speed. With a second active pull-up board added, this one at the remote end of the link, it should sustain the full speed rate with no issues.

I built the second active pull-up board with the 4060 switch, but ran out of time tonight to complete the test with it installed. When I switch over to the more powerful I2C buffer boards I am making using the LTC4313 chip, I am sure I will have bulletproof serial links at the 10-15 foot lengths needed for the 1130 installation.

The pull up board helps but it only kicks in once the signal rises to 2V, the threshold for detection by the 4066 chip enable pin. I really need this to fire up at a lower trigger level - have to see if I can dream up an easy way to do that with minor modifications, since I am going to have the 'real' I2C buffer chips and my board ready for service in just a few days.

Something is wrong with my code that writes to the MCP23017 chips, because it appears the control sequences that should flip the polarity of bits or turn on output channels are not being received. Interestingly, it reads correctly. I need to pour over the transactional code to determine what sort of problem might lurk there.

I instrumented a record of when the remote chips signaled an error back (NACK) while running at the reliable 200KHz rate and will look into what common characteristics exist in any transactions that experience errors. It appears that I have some issue with the output board, based on the errors, but am also getting sporadic errors on reads.

I need some method of ensuring that a bad read doesn't corrupt the state of my card reader adapter by temporarily and incorrectly raising a signal that changes the adapters state. Therefore, I added code to condition the update of data fields on the state of the error flag from the I2C module.

xxxxxxxxxxxxxxxxxxxxxxxx

I2C Buffer cards ready for installation

The I2C buffer chips arrived and I printed the circuit boards to install them.  I have two good boards in hand and proceeded to solder the components on the PCB and wire them up. After installing these on the two ends of the card reader serial link, I ran tests at the current 200KHz and at the target full speed of 400KHz.
The clock and data signals are almost perfect square waves going through the bus at 200Hz as well as at the fpga, which is excellent. The data was not getting out of the remote end board and into the input boards.

I had the boards built symmetrically, assuming that the OUT port always faced the bus, but instead the OUT port is always further from the master. That means the remote end should have the long cable hooked to the IN ports and the input boards atttached to OUT. I will make the change, which also requires me to swap the pullup resistances, then resume testing.

After making the correction, I was extremely pleased with the quality of the signals at 400KHz. You can see the beginning of the rising edge at a slope until the I2C buffer chip kicks in and swings that edge almost vertical. It also pulls the line back down to 0 very rapidly. The high level is 3.3V, exactly the supply voltage, and the low level is almost zero. Much, much nicer than the unbuffered link.

400KHz clock pulses at the remote end of the link.

I also did a quick look at the data lines, although I didn't bother to hook up my special triggering circuit which would trigger at the 'start' bit of each I2C transaction. As a result, I am triggering at any rising edge which is why the data is blurred across the screen. However, you can see the high and low voltage levels and the shapes of the rising and falling edges, which are quite lovely to behold.

Scope on data line to view voltage levels, rising and falling edges. 

There is a bit of ringing because my connections to the buffer boards are makeshift with individual wires, not the token ring cable or other cable more suitable to the high frequency components of the square wave and the transmission line effects. I expect much of that will go away, but even if it remained at current levels it is extraordinarily far from the noise margins of the digital logic; it would not cause any false transitions.

I put together the remote relay board that will fit inside the card reader logic cage, along with the other small board I build that blocks the faux read error these machines produce when reading cards whose top right edge have a diagonal cutaway.

Modification to Documation reader to allow right-side tabbed cards to read without errors 

Remote relay to 'press' the reset button remotely on command from the card reader adapter

I did see that I am still having some protocol issue raising errors on a few of the transactions. Some are caused by the lack of the output board, meaning that every transaction aimed at that chip will NAK out. It did make me realize that I need a bit more sophistication in my transactional engine - if I receive a NAK to the initial transmission on the I2C line, which is the chip address and register address, then I should not submit any further output for the transaction. 

It also hinted to me where I am having problems that caused errors on the first transaction after a failed one to the missing output chip, which highlighted a weakness I have to resolve. In some cases, after a failure, e.g. if the chip is not working, I will send additional data which can be interpreted by other chips on the serial link as data meant for them. It may be that my FSMs are getting out of sync with each other due to unusual conditions occuring during errors. 

An I2C write transaction to the MCP23017 chip involves sending a start bit, writing a first byte containing the chip address and a second byte selecting a register, then writing additional bytes followed by a stop bit. If the chip is not present, the error is flagged by a NAK from the chip to that first byte. I should abort the rest of the transaction, but presently my code presses on sending any additional bytes. Nobody should pay attention to these other bytes, up through the stop bit which ends the I2C transaction. 

An I2C read transaction is a bit more complicated. It begins the same way, writing a start bit, the chip address byte, and a register address byte. However, it then sends a special restart bit, writes again the chip address, then reads until it is through which it signals by sending a stop bit. If the initial part of the transaction fails (writing the chip address and register address), I would still issue the restart bit and do reads.

A restart bit is actually a contiguous sequence of a stop bit and a start bit. Along with the start bit that is embedded in the restart, we write the chip address again as part of the request for a read. Somehow, sending a restart to an address that wasn't active leads to problems with the next transaction. 

I have updated the logic to abort transactions at the first NAK, latching a flag that informs the caller (my main card reader logic) whether the transaction was successful or not. It will allow me to implement more sophisticated error recovery mechanisms if they are needed. Initially, I will just reinitialize all the chips if a severe error is detected. 

I produced some more boards for the I2C buffer and populated one to drive the MCP23017 in the output box. I can use the level shifting capability to replace some transistor based level shifters I built onto that board, as I run the chip in the output board at 5V unlike the input boards which operate at 3.3V.  

With the new buffer board installed in the output box, I hooked it up to do a test run from the 1130. The output board is still not working, nor are all the transactions completing without error on the inputs board. My code to invert the state of certain bits is not taking effect in the MCP23017 chips either. I have to dig in further to the various logic that is involved in the link, so that it does more than just read data from the boards.

On the assumption that I am violating setup or hold times for the inputs to the i2c_master logic from my transactional logic i2ctransaction, I changed the code to ensure all values are set up at least one cycle before i2c_master is triggered to grab them and they are held at least one cycle past where it flags receipt. 

Testing with this change yielded promising results. The writes all completed with no errors reported, but now the three reads were being flagged. I looked through my logic in i2ctransaction and everything looked clean. Still hunting down the causes.

I see that the output board buffer card is freezing the bus (or the output board itself is doing that), which is why it doesn't yet work. This could occur if the pullup resistors aren't taking the data and clock lines high, or if there is something wrong with the buffer card or chip. I will do some diagnostic work now. 

The diagnostics showed that the cable connections were broken at the connector, which I fixed with replacement connectors and a more substantial physical support. In addition, the board was not working properly, which I suspected was a problem with the chip. I built another buffer card, swapped it in, and I know have the link working with the output board.

My test run still shows errors flagged on the reads and writes, also the Ready light is lit on the 2501 panel but not the Power lamp. I suspect that my means of detecting errors is flawed; I will dive into this first, so that I have good diagnostic information with which to debug the rest of the link issues. 

DOCUMENTATION IMPROVEMENT

I spent time to carefully update and extend the documentation for the connections of the LEDs on the display pedestal and the black plate, as to which cable, which pin, what logical address on the MCP23017 chips, and what field is displayed on the lamp. It helped me in the design and construction of the replacement PCBs for the display light panel. 

As well, I have made a number of changes to the card reader input and output boxes and all the cabling linking them. I went through the various documentation related to the card reader and updated it. 

DISPLAY PEDESTAL COMPLETION

I trimmed off the sections of the interior light panel where they would interfere with the secured pins holding the external plexiglass panel onto the face of the enclosure. The parts of the light panel that had come loose were epoxied to hold together.

As well, I completed fixing the plexiglass panel in place on the front of the enclosure, using my axle stops on the acrylic rods that serve as attachment pins. A small area where the black paint had been scraped off was fixed by placing some black electrical tape over the spot on the inside face of the panel.

I set up the display but it is operating strangely at this time - may be a result of the simultaneous activity on the I2C serial link overstressing the power supply and ground paths, since it seemed fine a few days ago. I will remove power to the I2C and see whether the lights operate more sanely, or I may shift back to a slower I2C link speed for the interim which may also allow the panel to work better.

Slowing the card reader link to 200KHz returns the card reader communication to solid dependable operation, but I need to hand check the wiring and LEDs in the panel on the workbench before I start chasing down wrong alleys looking at electrical interference or programming flaws or other potential causes. Once I eliminate any physical problem I can take on those other aspects.

Working on the light panel has always been touchy, since it is perfboard with the LEDs inserted and lots of wire buss soldered in a matrix, plus more than 48 wires hooked to the boards and culminating in six 8-position molex and one DB9 connectors. It is easy to push wires into contact causing shorts, I have had to layer tape and other insulators to try to keep the system working, but that only makes diagnosis and repair of damaged or shorted lights more challenging.

I spent ten minutes trying to understand why I have a near short circuit in a section. I isolated the small segment from everything else, but I am at a loss to discover why it is causing problems. As a result, and due to the very fussy nature of the assembly of this kludgy perfboard and wire with the black plastic separators that isolate each lamps light and with the stands and positioning plates, I decided it was time to switch over to a printed circuit board implementation of the lights and matrix wiring. This will greatly reduce the chances of future problems and make it much easier to get the assembly together and installed.

I designed three PCBs to implement the three sections of lights. I have manufactured the first of the three already, the right hand board. The traces are too thinned out, nonconductive in quite a few places, even though I drew large and heavy traces. I will have to bridge this with wire soldered along the traces, which is still going to be more secure and reliable than the prior perfboard.

I made several attempts to make the other two boards, resulting only in a barely usable left board, because I had too much resist left on the board which blocked the copper etchant. There were big areas of copper that should have been gone from the board which were shorting multiple traces. I was able to scratch away grooves in those copper areas to isolate each area so they no longer shorted traces that should remain independent. The last try for the middle board looked very good while developing, but the traces themselves dissolved away.

I soldered wire bridges across all the thin or disconnected traces on the right board, after which it will be usable, just not pretty. I scratched isolating grooves in all the bridged copper on the left board, but I will also need to scratch the remaining copper to isolate areas where the LED wires go through the board to solder to the reverse side. Once done, that board will be usable although even uglier than the right board.

I ran out of time on Saturday night getting a middle board produced, but was able to come up with a very clean board tonight (Sunday). I was able to spend Sunday morning drilling out all the holes on the left board and finishing the bridging wires on the right board.  The afternoon included an hour of meticulously unsoldering LEDs from the old perfboard panels in order to install them on the new PCBs. Interspersed with that work was an hour scraping grooves around the holes where LED leads will pass through to be soldered on the other side.

After investing all that time to harvest only 16 of the 148 LEDs, and given that 200 LEDs can be bought and shipped for just over $10 on ebay, I decided my time was worth more than $1 per hour. I am abandoning the reclamation effort, have ordered new LEDs and will assemble the boards when the lamps arrive Wednesday.

Next week I will drill out the holes in the middle board, mark and cut all three boards down to their final size, attach the wiring harnesses that run to the LED Driver board. Once the new LEDs arrive, they will be soldered onto the boards, the boards mounted and the entire assembly tested before installation.

During the making of the last PCB, I discovered what has been causing my erratic results, sometimes parts of a board don't develop, other times the entire board barely seems to register. The exposure of the PCB is done by a flourescent light on a stand, made especially for this PCB system. The stand is two legs, one on either end of the light fixture, which implies that the PCB and mask should be centered under the fixture between the legs. Not so! The PCB has to be out in front otherwise part of the UV rays from the lamp are blocked by part of the fixture up inside the bulb housing. Not obvious, but clearcut based on the outcome today.

TEKTRONIX SCOPE WORK

I have two probe pods for the 7D01 logic analyzer plug in, ready to go as soon as I get the readout function operating in my scope. This is waiting on availability of cables long enough to connect the readout board with the other logic boards inside my 7603. I had salvaged the readout board from a 7633, but the board sits in a different location in the 7633, closer to the other boards and thus the cables from the 7633 are not long enough for my use.

My Tektronix made cables with the Peltola connectors will arrive around mid month. In the interim I am creating cables using SMA connectors and a F-F coupler on a pair of existing cables from which I cut off one of the Peltola connectors. This gives me a longer line, but with the extra connectors/coupler, which I can use to check out the condition of the readout board earlier.

Coupler and SMA plugs used to string together cables with Peltrola (Tektronix) connectors

The permanent cables were shipped on Tuesday from Greece, estimated arrival in 8 to 10 days, dependent upon customs clearing as well as normal shipping delays. I am able to see its tracking within Europe as well as once it hits the US. It is already showing that it was picked up by the shipping organization and on its way. Once the package clears US customs, it will be visible to the USPS tracking system and I will get a better estimate of the actual arrival day. These will arrive after the end of this project week, in any case.

MAIN TABLETOP OF 1130

The main tabletop was previously cut to size, the opening for the black plate (holding the keyboard, buttons and lamps) cut away, and white formica glued onto the board. It was time to attach the aluminum bar that is used to hold papers or manuals from sliding off the tabletop, since it sits at an angle on the 1130. I believe the angle was dictated by the keyboard mechanism, which was built for the 029 keypunch but leveraged to use on the 1130.

The keyboard of a keypunch has a slope from the lowest at the front at the spacebar, rising to the rear row that has the number keys, this slope is manufactured into the mechanism itself. To place the keyboard under the black plate and tabletop with a uniform height for each row of keys required that the plate itself be sloped at the same angle. Finally, for cosmetic reasons, the tabletop is at the same angle as the plate, thus the plate is the same depth below the tabletop everywhere.

I had to attach the aluminum bar to the tabletop, which I did by drilling and tapping two holes in the bar, then passing a machine screw up from the underside of the tabletop to screw into the newly tapped hole. The machine screw has a roughly flat bottom which allows it to blend in with the bar as much as is possible. I tapped these to use 4-40 screws, to maximize the threads of contact in a 1/8" thick bar with a reasonable diameter for holding the bar in place.

4-40 machine screw in the hole I drilled and tapped in the aluminum bar

What the hole looks like from the top as seen by users of the 1130

It is now mounted in place, although later I will remove it to polish it to a nicer finish. The tabletop mounts on hinges that pivot from the bottom, closest to the user of the machine, but the exact positioning of the hinges and tabletop will depend upon the exact position of the black plate assembly on the frame. That in turn should wait until I have finalized the sheet metal of the top of the machine, since the sheet metal on the sides is the rest for the tabletop when in its normal closed position.

Tabletop with aluminum bar installed, to hold papers/manuals from sliding off

I was forced to use pop rivets to hold on the button and lamp assemblies that run along the left and right sides of the plate, but these would be visible to the user as the tabletop is currently cut away. I bought some black rubber to use as a gasket, much as IBM did on the real 1130, that rubber will hide the rivets and blend in more. The rubber I bought was outgassing some very unpleasant odors, but after months sitting outside it is stabilized, not reeking and ready for application.