Electronic – Comprehensive way to indicate error code using single LED

Rather than transmit the marker ID code from the marker to a central receiver, perhaps it would be simpler to transmit the marker ID code from a central transmitter to the marker.

The central transmitter (perhaps a 38 kHz IR transmitter or some wireless transmitter) would send, in effect, "Marker number 22, please turn on for the next 20 ms on my mark: NOW". (Ideally, while that marker is glowing for those 20 ms, the central transmitter is sending out the ID of the next marker to turn on).

Since that one central transmitter is controlling the timing, you won't have to deal with markers getting out-of-sync and accidentally transmitting at the same time.

Hopefully you can place that central transmitter close enough to the position tracker, so that if any marker can't see the commands sent by the central transmitter, that marker wouldn't be in the visual field of the position tracker anyway.

That also gives you the flexibility of using the data you get back from your position tracker to dynamically adapt which markers you select:

• If some markers seem to be motionless or extremely slow-moving, perhaps you only need to check on them once every 3 seconds or so.
• Perhaps you can check up on the latest positions of more than one marker at a time; something like "OK, marker number 22 and 23, please turn on for the next 20 ms on my mark: NOW".
• If some markers are not visible from this vantage point, perhaps you only need to check if any of them have re-entered the visual field once every 3 seconds or so.
• The time slots you free up with the above techniques could be used to track the remaining markers at a somewhat faster update rate than you could if you simply cycle through every marker in a fixed pattern.
• If, say, marker #22 is so close to marker #23 that receiver of #23 is blinded when marker #22 is active, you could shuffle the order you turn on the markers so that the "#23 please turn on" message happens a few slots before the "#22 please turn on" message.

First off getting access to the parallel port in Win7, Vista and even WinXP is a major effort. Microsoft took away the ability for normal user code to be able to directly access the hardware registers. Instead they virtualized the accesses and if you try to do they they normally appear to have executed but they do not end up touching the hardware. To get access some special device driver solutions were devised, InpOut32.DLL is one example, that let user code indirectly access the port because the driver runs in system mode. I have previously used InpOut32 for some experiments and found that it adds quite a bit of latency to the accesses such that even on rather high speed machines the fastest available toggle rate of parallel port pins was on the order of less than 22KHz. When I used it I was coding in an unmanaged coding environment.

When you start writing code in something like VS2012 using managed code under Microsoft's .NET framework you have to jump through a lot of hoops to get add-on drivers such as InpOut32 to work (and it is not even certain that that particular driver is even workable in Win7's 64-bit environment). I have not attempted it in my current 64-bit environment because it is just not worth the effort to try to eek it into functionality because there is an additional loss of performance when calling an unmanaged driver from managed user code. One's time is much more well spent using one of the multitude of USB choices available to get access to external I/O via a USB bridge I/O device.

[EDIT: Added USB Port Output Idea]

One really easy little board that you can build into project and connect to a PC with a Mini-B USB cable is the USB Bit Whacker from Sparkfun Electronics. This little board shows up on the PC as a virtual Comm port and is able to accept very simple text commands that will toggle the outputs on and off or monitor the inputs.