DJ Delorie wrote:
It's not the drivers that mess up, it's the octal latch.
if the existing latch is in the interface with ribbon cable to the PC -
there's your problem.
You could probably fix it with something gross like series R in the line
and a bypass cap to ground (the ground the latch sees - the chips pin
10) right at the octal latch.
assuming the latch is cmos, you can use any amount of R, but you don't
want it to get too high impedance. 100-1k seems safe. Pick a time
constant related to the latch strobe width. iuS? would yield say 1nF.
More if you can go slower.
The rest of the suggestions are all valid - but if you are only trying
to keep EMI _out_ of the digital switching, seems like serious overkill.
A somewhat easier solution could be to use a USB io in the interface box
- but that does not get rid of the beige box.
Throwing a PIC or the like into the existing interface box,
extracting the parallel port wires from it locally, and routing
filtered rs232 , (or even better rs485) a long way to your home server
is another way. Then cron does the work. Works for me here. I have not
seen a glitch (with a simple crc on the data packets) (and retry) in a
bunch of years.
((I'm not counting the lightning strike as a glitch here. that was smoke.))
I have been reading a lot about small series resistors on fast lines.
I don't know if 32MHz signals qualify, though. None of the app notes
mention them. The xscale requires them at high clock speeds.
its not the frequency that matters - its the dv/dt of the edge. And
whether the receiver can respond to the ringing that this source
termination resistor otherwise attenuates.
They can also reduce ground bounce inside the chip a little bit.
I was planning on FETs for the same reason; the high impedance on the
gate (inherent and resistors) provides a lot of isolation; I don't
*need* opto isolation just for the electricals; it's all +5 signaling.
A fet gate is only high impedance at DC. All that gate-drain capacitance
matters.
john