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

Mark Woodward markw at mohawksoft.com
Sat Nov 10 07:56:54 EST 2012


On 11/10/2012 07:44 AM, Mark Woodward wrote:
> Parallel port:
> http://www.linuxpcrobot.org/?q=node/5
Sorry, ps2pdf nuked my schematic, postscript version here

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.blu.org/pipermail/hardwarehacking/attachments/20121110/393da014/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: plprelay.ps
Type: application/postscript
Size: 26349 bytes
Desc: not available
URL: <http://lists.blu.org/pipermail/hardwarehacking/attachments/20121110/393da014/attachment.ps>


More information about the Hardwarehacking mailing list