First faults found on Documation readers

 QUICK RECAP

The two card readers are connected via a microcontroller based external interface over USB to a program on a PC that will drive the reader and capture the card images. The M600 has a large clunky external interface I have successfully used in the past but the PC application complains that it can't communicate with the interface box. The M1000 has a small interface I am building into the machine so that it will offer a USB socket on the rear for connection to a PC. That reader won't pick (read) cards in local mode, nor through my interface. 

DOCUMATION M600 TROUBLESHOOTING

The link over USB uses a simple protocol devised by Brian Knittel, with a single letter transmitted from the PC to request status, pick (read) a card, reset the interface, clear a prior pick request or to clear the End of File status. The interface returns a single ASCII character indicating the status as well as the card image when it is being read.

Using a simple serial terminal program (PUTTY) I issued the S command to request status and see a valid empty status character coming back. Invalid commands get an error character '?' back. However, the status is always off even when there are indicators such as Hopper Empty on the reader. Further, the reset command is sent an error response. 

This tells me that the USB to serial converter board is working and the microcontroller is at least partially working properly, but I suspect that the 82C55A Peripheral Interface Controller chip is not working correctly.  This requires more debugging but since the interface was cobbled together on breadboard with discrete wiring, it is probably more effective to just properly build a new one.  

DOCUMATION M1000 DIAGNOSIS PHASE 1

When I had swapped the PCBs from my M600 into the failing M1000, it did pick a card when switched to local mode. However, with its own card complement, it never attempts a pick. The Reset button lights green which indicates that the reader control logic thinks it is error free and ready to read cards. 

I looked over the logic involved in issuing a pick and began to check the various input signals that control this function. It is awkward to clip leads on IC pin legs and string the wires out of the cage with the cards inserted, but there is a motherboard that routes 34 signals between all the PCBs. These are the major signals and are easily accessible from the back of the card cage while it is powered up. These signals are numbered 1 to 18 across the top and A to V across the bottom of each card connector - some letters like G, I and O are omitted in the sequence. 

Motherboard routing common signals to all six PCB sockets

Each PCB has another 38 position connector that is unique to the function of each board. For example, the Reset pushbutton is routed to one of the boards which handles the reset function, but the outcome of that button, the RESET signal is also propagated on the motherboard

Card specific connections on the other connector set

The pick logic is reset by power on reset, the reset button, and the completion of reading the prior card. With the switch in Local mode, pick should be continuously requested. If the reader is not in READY status, for example because an error condition exists, the pick won't take place.

I examined the signals going into and coming out of the pick logic, testing the state of the various motherboard pins associated with READY, POR, RESET, GPR, etc. I quickly discovered that the RESET signal is asserted.

I swapped in the same board from my M600, verified that RESET should be low, and found that the M1000 would now pick one card when switched into Local mode. The next step is to find the bad component generating the erroneous reset state. 

Snippet of schematic for the Reset signal

The RESET signal that is on the motherboard pin 2 is produced by a fairly simple circuit. One complication is that the Reset button must be blocked while a card is in the midst of being read - that is the purpose of the Reset Inhibit flipflop at bottom middle. If that inhibit state is on, then RESET will not be generated. We have a RESET so the flaw cannot be in that flipflop or its preceeding signals. 

The state of the Reset pushbutton is captured by the other flipflop. This one is forced on using its Preset pin and forced off using its Clear pin, with those pins hooked to the ResetSw and notResetSw wires from the physical button. Ground is connected to one of those at a time, with the wires pulled up to high by a resistor. Thus normally the switch would have the notResetSw line grounded, which activates the Clear pin of the flipflop and forces it off. If pressed, the button grounds the ResetSw line, activating the Preset pin to turn on the flipflop. 

The output of the flipflop is passed through a NAND gate, whose output only goes low if the Reset flipflop is set high and the ResetInhibit flipflop is set low. This low output is then passed through an inverter to produce the RESET signal on the motherboard connector. 

There can only be four components that might be bad. The inverter may be failing. The NAND may be failing. The Reset flipflop may be failing. Finally the pushbutton switch may be failing or miswired. Next time I go to the workshop, I will hook up some leads to the board with the problem and hook them to my logic analyzer. I should quickly identify the bad part which I can then replace from my spare parts inventory. 

PCB generating false RESET signal

Logic analyzer connectors ready to be wired to the PCB

x