TS1 Test Fixture

Regular readers of this blog have seen a few of the automated test fixtures I have built.

Another fixture I built a few years ago monitors NEMA TS-1 output signals on up to 8 boards under test. TS-1 outputs are based on an open collector circuit configuration, producing a binary "low" or "high" condition. In simple terms these signals can be thought of as a "contact closure".

This fixture, as seen in the photos, contains a microcontroller and a couple "mux" boards for handling all the signals from two plug-in card cages. The TS1 fixture and card cages were mounted in a standard 19" rack cabinet. Each of the two card cages had a 33-conductor cable which plugs into the fixture - hence the pair of DB-37 female connectors seen in the top photo. These cables each handled 32 TS1 signals plus ground.

This device, as with the serial relay controller and the automated mouse movement emulator described in earlier blog posts, was controlled by a PC running LabVIEW software on Windows XP.


The box is an aluminum LMB enclosure; I used a dremmel tool to make the cut-outs for the DB-37 and DB-9 connectors, and a drill press for the round holes. The two large PCBs were made at an outside "board house", then populated by in-house assemblers. I mounted everything in the LMB enclosure and installed the chassis wiring. The smaller PCB - measuring about 2" x 2" - is the microcontroller board. The smallest PCB, connected to the microcontroller board via a ribbon cable, handles its RS-232 and power supply connections.

I built several of these fixtures for both engineering and manufacturing testing.

Of "Walled Gardens" and Computing Freedom

In an article entitled Intel's Walled Garden Plan to Put A/V Vendors Out of Business, Paul Otellini of Intel explained the reasoning behind its purchase of McAfee Anti Virus. Otellini described Intel's vision of "only allowing trusted and signed code" to run on the Intel x86 platform. The article went on to describe a scenario where you would get your software in a manner similar to the Apple "App Store" used on the iPhone.

Granted, the current security model purveyed by anti virus vendors is very labor intensive, inefficient, and all too often fails to catch a threat before it causes damage out in the world. Intel's model would offer a few advantages and probably eliminate some of the above-mentioned problems. If AV functionality was integral to the system's architecture, it would eliminate the problem of computer illiterate users not taking proper care of their PCs. The end user would not need to worry about installing anti virus software any more. All that said, this whole idea is NOT without significant shortcomings and impacts to system usability.

Users need to consider the following before they unconditionally embrace Intel's vision of a security utopia:

1) Just like on the iPhone, you would not be able to conveniently run software that wasn't approved by Intel/McAfee. Granted that some folks have found hacks to bypass the iPhone controls, but they do so at risk of other issues including violating their phone warranties.

2) Since software developers would have to deal with some "trusted" signing authority to get their code approved to run on Intel x86, this could well cause problems for open source users and developers - as much of this software is created on a low budget and often distributed for free.

3) What about folks writing their own code, scripts, etc.? No code you or I write on our computer would run until/unless it were signed by the "trusted" signing authority. This potentially includes batch files and UNIX/LINUX shell scripts.

4) An outgrowth of point 2 above, folks wanting to run LINUX, BSD, or other open source software could be in real trouble. At the very least, we could be forced into paying major dollars for our software to one or two large vendors who could afford the signing fees.

5) As one reader posted in the comments section, just because your software is "trusted" and signed does NOT mean it is without security holes or that it still couldn't cause trouble by running malicious code buried in a file.

6) Early in my career as a Windows user, I stopped using McAfee because of the severe impact it had on system resources. Several IT industry professionals I've talked to recommend other anti virus software as being more effective than McAfee at detecting viruses. I shudder at the thought of EVER using their products again on any computer I rely upon for critical work.

In Summary:
Clearly, there needs to be a new paradigm for secure computing. Cyber crime and terrorism are both a growing threat in today's world. That said, we need solutions that work for everyone. We need solutions that do not interfere with our freedom to use our machines for whatever LAWFUL purpose we want. We need solutions that allow us to continue running whatever OS or applications we FREELY choose. We do NOT need a "Nanny State" or "Nanny Company" solution to the problem.