1

I need to transmit data (less than 5Mbps) point-to-point over 100 ft. I prefer not using Ethernet due to the complexity. I can use low-scale FPGAs or similar chips if needed for functions like error correction control. I'm considering UART over RS-485/422, but I'm not sure if it can provide such performance. Do you have suggestions on not-too-complex solutions? Thank you.

fiedel
  • 193
  • 1
  • 2
  • 10
  • Depends on baud rates, but RS-485 is specified for much longer distances. – Eugene Sh. May 25 '18 at 13:53
  • 2
    See the Maxim RS-485 distance/baud rate app note here https://pdfserv.maximintegrated.com/en/an/AN3884.pdf . An RS-485 driver with an FPGA or other data I/O logic should work fine. – crj11 May 25 '18 at 14:20
  • What kind of data you are sending and how fast you actually need it will determine what interface you can use. 4Mbps is a tall order without using a high-level comm system like Ethernet. Is the data unidirectional or bidirectional? Can the data be paralleled over multiple links or does it have to stream? – vini_i May 25 '18 at 14:20
  • I'm sending motion control data in serial up to 5Mbps. There will be separate links for Tx and Rx as bidirectional buses may suffer from delays. If more signal paths are available (like in cat6 cables), I can make a simple SERDES for the transmission. – fiedel May 26 '18 at 02:13
  • How will the receiver know when to sample each bit? – analogsystemsrf May 26 '18 at 15:18

3 Answers3

3

It's mostly down to the cable - I've had cat7 cables running 600 Mbps over 35 metres down one pair with power down another pair. I've had 100 Mbps running 500 metres over a single (but very decent) coax. This was a single ended driver and cable-compensating receiver chip.

Choose your cable wisely and you can easily get the distance you want especially if you use a differential driver and receiver.

Andy aka
  • 456,226
  • 28
  • 367
  • 807
  • What physical protocol did you use for such high speed transmission? Was it just baseband? Did you apply error correction? – fiedel May 26 '18 at 02:14
  • @fiedel the data was baseband and scrambled to ensure edges were present quite often. This made it a synchronous transmission and the clock could be extracted from it. For your application I would consider Manchester encoding/decoding. – Andy aka May 26 '18 at 08:54
0

UART on RS-485 is a good first approach, but the standard says 2Mbps@50m, I wouldn’t fight against it. Have you considered optical communications? You can use the protocol of your choice above the physical layer, just choose a decent pair of tx/rx transceiver and you’re good to go.

PDuarte
  • 1,389
  • 1
  • 13
  • 16
  • I've never used optical before except for dealing with SDH long ago. That gave me the impression that optical is complex. I could be wrong. How simple/cheap can today's optical transceivers be? – fiedel May 26 '18 at 02:16
0

I think you should use Ethernet even if you think it is complex. Today there are very competent IP that you can use in low end FPGAs like Spartan or Artix that do all Ethernet stuff that you need like TCP, UDP, DHCP etc.

There are even free cores and you will have a link up and running in a very short time. I have implemented both 485, optical and Ethernet applications and my opinion is that Ethernet is almost always the better choice. It is scalable, very good infrastructure, very good support by small boards like Raspberry Pi and so on.

Holminge
  • 139
  • 1
  • 2