Parallel port: http://www.linuxpcrobot.org/?q=node/5
I've attached a schematic in pdf form. On 11/08/2012 02:18 PM, Tom Metro wrote:
I'm using a 4-port IR transmitter with my MythTV server to control a pair of cable boxes. This worked fine for the first 3 or 4 months I had it deployed, then I changed the high-level code that was calling irsend and physically moved around the hardware a bit, and I started getting cross-talk from port 1 to port 2. The consequence is that channel change commands sent to port 1 are also picked up by the IR emitter on port 2 at least part of the time. I've documented the particulars of the various experiments I've tried to troubleshoot the problem in this ticket filed with the hardware vendor: http://iguanaworks.net/projects/IguanaIR/ticket/273 While the manufacturer says there is a known cross-talk problem with the hardware, the level off the cross-talk should be down near the noise floor, yet various experiments attempting to attenuate the signal show the cross-talk is suppressed at the same level of attenuation as the primary signal. Software is pretty much ruled out as a cause. In part because none of the low-level software (LIRC) was changed at the time the problem appeared, and in part because the nature of the cross-talk indicated a degraded signal - signals sent to port 1 are often not perfectly echoed on port 2 - which seems unlikely to be caused by software. Hardware failure was the next obvious cause, and so the transmitter was swapped out, and alternate emitters tried. The transmitter change made no difference. The emitter change did vary the frequency of cross-talk occurrence to some degree in testing, but in actual "production" the cross-talk problem seems to happen just as frequently as it did before different emitters were used. The proper next step here is to hook up a scope to observe what is actually being transmitted from both ports, and look at whether anything weird is going on with the USB supply voltage. But lacking a scope, that's not going to happen. This background is just to set the stage for the brute force solution I'm considering: routing port 2 through a relay. It would be putty easy to stick a few lines into my wrapper shell script that sends commands to the IR hardware to turn on a relay when port 2 was being used. So my question is, what's a good approach for controlling a relay from a PC that is a good compromise between cheap and least effort to build. There are hundreds of ways to accomplish this, and many ready built relay control boards, but I'm thinking a TTL compatible reed relay, like: http://www.nteinc.com/relay_web/reed.html wired to the parallel port (the server has one, and it is unused), and controlled with some software, like parashell: http://sourceforge.net/projects/parashell/ (More info on parallel port control here: http://www.epanorama.net/circuits/parallel_output.html ) You can't get much simpler than a relay, DB25 connector, a 3.5mm jack and plug, and some wire. The relays above even have an internal diode. (The other obvious choice is an optocoupler, but for the duty cycle this will undergo I'm not that concerned, and the mechanical relay provides the simplest interface to the emitter, where polarity, high-side vs. low-side, and voltages are irrelevant, and thus more apt to work the first try.) Anything simpler? Any skepticism for running the relay directly from the port without a buffer? Any recommendations to use a serial port control line instead? -Tom _______________________________________________ Hardwarehacking mailing list [email protected] http://lists.blu.org/mailman/listinfo/hardwarehacking
plprelay.pdf
Description: Adobe PDF document
_______________________________________________ Hardwarehacking mailing list [email protected] http://lists.blu.org/mailman/listinfo/hardwarehacking
