We've been experimenting with pushing differential drive logic signals over CAT6A ethernet-type cable. We'd like to move packets of data in the form of a burst clock on one pair and data on two other pairs. Speeds range from 100 MHz clock (200 Mbps) at 20 meters to 10 MHz at around 80 meters. The eye diagrams are marginal as-is, but it looks like some fairly simple transmit-end pre-emphasis might make things a lot better.
formatting link
Has anybody done stuff like this? It's not very amenable to simulation, because the Spice lossy txline model doesn't include skin effect.
My first approach would be to get the eye more open just by doing simple pre/de-emphasis on the send side.
The linear receive equalizers that the FPGA people use in their serdes would be easy to do, too.
You'd probably never need to implement a decision feedback type of system at your data rates and cable lengths, but those DFE's really do help at 10Gbps. I'm about to find out how they work at 25Gbps.
Bob
--
== All google group posts are automatically deleted due to spam ==
In the early 80s, there were plenty of papers on twisted pair equalization. My recollection was they synthesized a response that was the square root of frequency. I think they had models for the cable in the papers as well.
Generally you want a matched filter (i.e. both ends), but for a wire channel (i.e. not likely to have additive noise), I suppose putting all the pre-emphasis on the transmit side is fine.
Yes, a very long time ago (1974) for transmitting digital television signals over multi-pair telephone wire. It is very important to ensure you do not have long runs of 1s or 0s in the data stream because doing so will make you vulnerable to frequency dependent dispersion.
The propagation velocity in the twisted pair is slightly frequency dependent, so if the spectrum of the data is very different to that of the clock the data transitions will become time-shifted relative to the clock. This can then cause data-dependent glitches.
Manchester coding is a good way of overcoming this problem.
Possibly, but the data eye diagram still needs to be open. But the decision to use the burst clock and the two data lanes was made by our customer, and it's not worth a battle to change it. We have other fish to blacken.
I had in mind that some small number of R-C networks could be switched in with low-resistance CMOS switches under software control, with the selection depending on the known cable length... no tweaking. The intersymbol distortion looks to be almost tolerable without equalization, so a direct shot should work, without adaptive equalization or tweaking.
If we use three or four RC peaking networks, and maybe allow more than one to be switched on simultaneously, the solution space gets huge.
How about putting a really big preemphasis edge on the TX end, and diode-terminating the RX end?
Cheers
Phil Hobbs
--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC
Optics, Electro-optics, Photonics, Analog Electronics
160 North State Road #203
Briarcliff Manor NY 10510
845-480-2058
hobbs at electrooptical dot net
http://electrooptical.net
I have a short run in a fairly benign environment, and can start with a huge transmit signal (like 0/+5 on each wire, 10 volts p-p ahead of the source terminator) so BER isn't much of a concern. And the receiver is already built, so I have to equalize at the transmitter.
In general, it is a bad idea to use separate channels for clock and data for longer distances at high speeds, if you do not have absolute control over path lengths and dielectric constants (propagation velocity), there are going to be clock/data skew, worsening the decision point.
It is usually better to use some self clocking protocol, such as Manchester coding, as already suggested. This should not only eliminate any clock/data timing glitches, it also removes the low frequency components, simplifying equalization.
The lack of low frequency components also makes it possible to use signal transformers and hence reduce any common mode voltage problems.
The speeds are not that high for those distances. As a reference, even Profibus DP (which is essentially NRZ RS-485 multidrop network) works reasonably well at 12 Mbps at 100 m with some attention to details. The transceiver chip on each slave has to be very close to the connector and on the cable side, series compensation has to be used within each connector on the passing through line, to compensate for the stray capacitance of each slave stub. However, with such long cables, the receiver common mode voltage issues can be serious and you should either use optoisolation or signal transformers (for self clocked signals) to get rid of common mode DC/50/60/150/180 Hz issues.
I know all that stuff, but the customer has a "requirements document" about how this stuff has to work, and as I noted I have better battles to wage here.
They do currently do stuff like this at lower speeds using conventional RS422 transceivers with no equalization. I'm allowing for
6 or 8 volts of common-mode difference, which should be enough. And I'm allowing for a reduced clock rate if we need it, like if there is too much skew between cable pairs.
At 20 meters, prop delay is around 100 ns, and 1% of that is 1 ns, which is not great but OK. I'm guessing the relative prop delays in the CAT6A cable pairs are within 1%. I suppose we should verify that.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.