[HH] cheapest/simplest way to control a relay from a PC

[Mark Woodward]

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
> Hardwarehacking at blu.org
> http://lists.blu.org/mailman/listinfo/hardwarehacking

-------------- next part --------------
A non-text attachment was scrubbed...
Name: plprelay.pdf
Type: application/pdf
Size: 5553 bytes
Desc: not available
URL: <http://lists.blu.org/pipermail/hardwarehacking/attachments/20121110/23cdd97e/attachment.pdf>