Design considerations for (2m) long signal lines

Sounds like a job for RS485 drivers and receivers. Look for MAX485 and equivalents.

--
John B

Is there anyway to do this without overcomplicating things? It seems like too simplistic an application to bother with any but the TX line, which I'm guessing _could_ be done, but then how would I clock the latch?

Yes, it is way to complicated and not likely to be needed. For modest speeds and modest lengths of cable you can use the following:

The drivers are HC buffers with a resistor between its output and the cable. The resistance of this resistor should be something like 1/3 the characteristic impedance of the line.

The receiver end has a pair of Schottky diodes clamping the signal to the rails and then perhaps a small resistor (50R) to the input of a

74HC14.

For a lossless line with correct matching, the swing on the two ends are equal. The 1/3 Z0 resistance would make the swing at the cable end 3/4 of the Vcc if the far end was correctly terminated. The far end is in fact allowed to swing by Vcc making the line appear to be mismatched at the far end. You get some reflections on the cable as a result but they are not enought to cross the boundary of the 74HC14.

Sorry, I think you misunderstood me. I just meant translate to RS485 levels for the long cables as below. OK, so it's not a cost effective solution, but will be totally reliable and noise immune. It really depends if the OP is just making a one-off.

|\\ RS485 levels |\\ Clock In | \\------------------------| \\ Clock Out ----------| \\ | \\---------- | / | / | /------------------------| / |/ |/

|\\ RS485 levels |\\ Data In | \\------------------------| \\ Data Out ----------| \\ | \\---------- | / | / | /------------------------| / |/ |/

|\\ RS485 levels |\\ Latch In | \\------------------------| \\ Latch Out ----------| \\ | \\---------- | / | / | /------------------------| / |/ |/

(created by AACircuit v1.28.6 beta 04/19/05

--
John B

Probably.

Absolutely. Even better if you put an r-c lowpass filter at the input of each schmitt, to nuke any cable ringing. Use HC-type schmitts.

If you run single-ended, unterminated, and use maybe 1 us tau r-c's in front of schmitts, figure 200 kbps is safe, 2.5 us high/low levels. A hundred feet of cable would be OK, if you don't have ground loop problems.

If you need to go faster, more care will be required, preferably terminated differential levels.

John

I think cat5 is around 5ns/m so that shouldn't be a problem and all signals will be delayed the same anyway.

if have fast edges and the cable isn't terminated correctly you will get reflections that might result in the receiver seeing multiple clocks for every clock edge.

if you slow down the edges noise right as it goes through the threshold. might result in the receiver seeing multiple clocks for every clock edge. using Schmitt triggers on the clock inputs should help on that

the data signal shouldn't matter, the value should have settled before the clock edges

-Lasse

I'm with you on this. I don't see that the other methods suggested so far offer a substantial savings at all, and I think they may be considerably underestimating the data rate (which seems to be at least

100kbps based on the description). And once you double everything (cable length, data rate) for the inevitable future expansions the case gets even better.

Well, if you're going full-goose bozo, you might as well use twisted-pair ribbon cable:

[Mind the wrap: I've put the brackets but it still might not be clickable; just copy/paste if that's the case.]

But it still seems like overkill for 6 feet. I'd be happy to drive 6'(2M) of ribbon cable with HC logic, interleaving signals and ground, albeit it takes the same number of conductors, but they don't have to be twisted. (and all the standard goesinta-goesoutta interfacing schtuff.)

Cheers! Rich

I understand what you're saying. I would only say that once he adds the HC drivers on the PIC side and the Schmitt trigger (and maybe some RC) on the shift-register/LED side, it's hard to see that as _much_ simpler. On top of that I did automatically double the specified length and assumed a fairly high data rate (figuring he didn't want to spend all of his time just outputting bits, but rather wanted to squirt them out pretty quickly and get on to other processing tasks). But it's only to the good to have the different suggestions all spelled out, and he can decide which one he wants to try.

Like I said, I am genuinely interested in other people's suggestions as well.

No, I didn't misunderstand. Note that the OP has 3 meters of cable, and signals from a micro. The cable is short.