THIS ARTICLE CONTAINS SOME COMPUTER JARGON FOR THOSE READERS WHO ARE EXPERIENCED IN THE FIELD. THE FAILURE RATE NOTED IN THIS STORY IS QUITE EASY FOR NON-TECHNICAL PEOPLE TO UNDERSTAND, THOUGH. JUST COMPARE WITH SIMILAR HOUSEHOLD APPLIANCES.
It all started when an important printer stopped working, with a persistent alarm light. Turned out the ribbon had jammed so tightly that the button could not be turned without breaking the case. This was an excellent light duty printer, the Okidata 520 line 9-pin dot matrix.
[Historic Note: For three years, we had been experiencing this same type of ribbon jam on a much larger, more expensive printer (the Mannesman-Tally MT-661) where ribbons run around $100 CDN each. We have a scrupulously honest dealer and we use only factory original new ribbons.
We have returned to time of writing perhaps 200 of these ribbons as having jammed shortly after being put in service. We have probably had close to 50 service calls to check and adjust these highly reliable machines.
Listen to this: Our dealer reports that NO OTHER users of this ribbon type have ever returned a single ribbon as having jammed.
E-weapons victims know that one of the very most common physical effects performed by the weapon holders is to increase or decrease friction dramatically. The weapon holders can pinpoint a single hinge on a door, for example, and make it screech unnaturally AND UN-REPEATABLY.
In one instance they remotely pried apart the card edge contacts on an important computer plug-in card, and did the same thing at times to a company oscilloscope, which has quite a few spring contacts on it's selector switches. There is no doubt that the weapon holders are capable of causing ribbon jams.]
OK - we changed the ribbon. The repeated attempts to send [serial] data to the printer [at the moderate speed of 9600 bauds] did not cause the printer to budge.
Changed printers once - still wouldn't print.
Installed a 100-LED breakout box to watch the control and data pins as the attempts were made. Data DID arrive at the proper time, and the contol lines were all in "go" state.
Changed printer a second time - still no print.
Put a $3,000 cable tester on the cable. This cable had been in successful, trouble free service for over 3 years. Continuity: perfect Low, medium, and high line noise, 0-3 millivolts, which is a tiny fraction of the logic threshhold of + or - 3 volts, and an excellent reading. Line length about 100 feet. All undamaged category 5 (i.e. best grade) cable.
Took the original printer and connected it to the jack at the mainframe where the printer's normal cable is. The printer worked fine there, but was an inconvenient distance for the department's people to walk for invoices.
Went to work on the cable. Plugged the cable into a jack of another known-to-work printer and copied text files directly to the serial port (it's an Equinox SST system - highly dependable since it's installation 3 years ago.) Departmental printer didn't budge.
Checked setups of both the temporary printer (the original one doing emergency duty) and the departmental printer. Identical. All 3 Okidata printers fairly new and spares had recently been to repair shop for disassembly, cleaning, tweaking, and testing. All OK.
Changed RJ-45 terminators. Tested cable - still AOK. Departmental printer still would not print. (Invoicing all this time was being done on the short cable to a temporary printer stand at the computer room.)
Tried an automatic test suite on our $3,000 tester. (Testing before this had been done using individual functions, not the automatic suite of tests.) Automatic suite attempts wouldn't run - error message about can't find a portion of the testers firmware. ** Next morning, automatic test suite works fine.
We have no unusual sources of electrical noise in our building. Just fluorescent lights, and with a building outside dimension of 150 feet by 175 feet, and the computer room located centrally, cable lengths typically do not exceed 100 feet, well within the capability of category 5 cable at 9600 baud.
All equipment in the building has individual battery backup units (except LaserJets), plus, we have large [expensive] surge arresters on AC sub-panels. Each battery backup unit has a filter network in it. We've installed a duplicate set of gas tube surge arresters on all incoming telephone lines and the cable FM service.
We have repeatedly scanned line voltage for excessive noise visually, using an oscilloscope and found none. We have scanned the data at the ends of our longer cables with an oscilloscope and found crisp pulses with virtually no noise.
Boss gets anxious and orders new cable to be run. New cable checks out fine with the tester. Printer starts to print but has screwed up fonts, even though settings identical and repair shop tested recently AOK.
Printer testing, by the way, is always done after a power off/power on to fully reset the unit.
Moved original printer back to department. Even though it has identical settings to the one that had screwed up fonts, it worked. Now the main frame refused to RE-print invoices that were missing or printed with bad vertical alignment.
Programmer-consultant on site. Could find no problem with files or programs, and he's a real genius with a photographic memory.
Next morning: RE-printing worked FINE! ANOTHER "self-fixing", statistically impossible problem.
Next morning: The refused-to-work cable was tested with a 6-volt battery driving a 14-volt flashlight lamp at the far end. Even with reduced voltage, the lamp lit with no problem. The lamp drew 50 milliamps over a 100 foot #24 twisted pair, which is roughly the load which would be imposed by 100 of these serial printers. There is nothing physically wrong with that cable, and never was.
On the problem day, a daily download of data from one of our banks which has run reliably for more than two years suddenly could not get done. The computer crew at the bank put analyzers on the download at their end and told us it looked like our modem (a $5,500 ultra-high-quality gem) was prematurely dropping the connection. These attempts to download were carried on throughout the day while the invoice printer problems persisted. Around quitting time, when the departmental invoice printing started working again, we suddenly were able to do a successful data download. Another "self-fixing" problem.
On an earlier day, a critical UNIX host computer which is used to allow customers to remotely enter their orders suddenly stopped. Why? The adapter board INSIDE THE COMPUTER had popped itself out of it's slot. When I tried to re-seat it, there was NO FRICTION to hold it in. I did other things for half an hour, then came back and tried again.
THIS time, PLENTY of friction. Any reader who has worked with computers knows that card edge slot connectors if anything are EXCESSIVELY tight, as was this one after a half hour wait. Another impossible "self-fixing" problem.
While none of this actually PROVES that the e-weapon holders have exotic remote-manipulation capabilities, any technically experienced reader will have to agree that this chain of events does point powerfully in that direction.
Eleanor White, P. Eng., VE3LKE
Hamilton, Ontario Canada