-
I'm considering a project where I'd like to forward a ~2Mbps data from a uP down a long length of CAT5 cable (kinda set on the cable because it's cheap, available and already installed...). The most obvious approach would be to use Ethernet + UDP/IP or something, but I was looking into the framing overhead of all that and I'm concerned about the latency and throughput limitations that might introduce on a 10Mbps link. Ethernet MAC + IP + UDP looks like almost 50 bytes of overhead, and my actual payload is unlikely to be any more than 50 bytes.
I've started thinking that maybe I should ditch Ethernet and run just the "Ethernet" PHY. This is purely a point to point link, between only exactly two pieces of equipment so I don't really need any of the "networking" bits as far as I understand and it seems a shame to practically halve my throughput and latency for features I'm not really using... However, I personally don't have any experience with this low level Ethernet and my thinking could easily be misguided. I'm curious if anyone is aware of other options for a situation like this, or can see any obvious gotcha's using the PHY chips like this... -
You should be able to use CAN transceivers (or similar) and whatever protocol you want.
-
You didn't mention the distance you need but would RS-485 work? Wikipedia says it can do 2 Mbps over a 50m cable and it uses differential signaling over a twisted pair.
-
Sorry I should have been more specific about distance. I'm hoping to go pretty far (a little flexible but the 100m spec for cat5 Ethernet is an attractive target...)
CAN and RS485 are good suggestions, but I didn't think they could cover as much distance. -
It probably doesn't help given you already have an ethernet cable run, but Single Pair Ethernet is an interesting newer option that can go beyond 100m.
I can see what got you considering creative solutions with ethernet PHYs. -
2Mbps will go a very long distance on CAT5, even longer with equalization applied.
-
See https://www.digikey.com/short/2qqmz9nn
Example ISL3159 (max 5.5v) , ISL3179 (max 3.6v)
https://www.renesas.com/us/en/document/dst/isl3159e-datasheet or https://www.renesas.com/us/en/document/dst/isl3179e-isl3180e-datasheet
from datasheets (page 12 in 3159)
According to guidelines in the RS-422 and PROFIBUS specifications, networks operating at data rates in excess of 3Mbps should be limited to cable lengths of 100m (328ft) or less, and the PROFIBUS specification recommends that the more expensive “Type A” (22AWG) cable be used. The ISL3159E’s large differential output swing, fast transition times, and high drive-current output stages allow operation even at 40Mbps over standard “CAT5” cables in excess of 100m (328ft). Figure 18 on page 10 details the ISL3159E performance at this condition, with a 120Ω termination resistor at both the driver and the receiver ends.
Note that the differential signal delivered to the receiver at the end of the cable (A-B) still exceeds 1V, so even longer cables could be driven if lower noise margins are acceptable. Of course, jitter or some other criteria may limit the network to shorter cable lengths than those discussed here. If more noise margin is desired, shorter cables produce a larger receiver input signal as illustrated in Figure 17 on page 10.
Performance should be even better if using the “Type A” cable.
The ISL3159E may also be used at slower data rates over longer cables, but some limitations apply. The Rx is optimized for high speed operation, so its output may glitch if the Rx input differential transition times are too slow. Keeping the transition times below 500ns, (which equates to the Tx driving a 1000ft (305m) CAT 5 cable) yields excellent performance across the full operating temperature range.
To minimize reflections, proper termination is imperative when using this high data rate transceiver. In point-to-point, or point-to-multipoint (single driver on bus) networks, the main cable should be terminated in its characteristic impedance (typically 120Ω for “CAT5” and 220Ω for “Type A”) at the end farthest from the driver. -
RS-485 PHY see the many TX/RX/transcievers for RS-485
j -
It really depends on the length, and of course the quality (shielding) of the cable. Before going for some extra research and building, just crimp two connectors to the ends (crossover pinning, or use a switch) and do a large transfer with two devices. I am pretty certain, the cable is easily good enough for 10Mbit, likely even 100Mbit, which should be fast enough. Check for linkage drops and frame drops though.
-
100m is the radius of the collision domain, point-to-point distance is 200m.
These distances are determined by the speed of propagation of the signal in the cable to detect collisions - the simultaneous start of transmission of two nodes.
The hardware capabilities of saving the physical ethernet signal are much greater.
The Ethernet frame is very simple: it contains 2 addresses and flags. You can simply fill this frame and send it to the PHY chip.
IP protocols not only have additional headers, but also perform a same approvals before transmission begins, for example, they request the MAC address of the IP address owner.
Nevertheless, RS-485 is fairly recommended to you. You will simply send data to the UART and receive it on another one in the same form.
But you will need to take care of verifying the authenticity of the data yourself, control transmission errors, they may occur.
CAN, in my opinion, is most suitable for your conditions. It works quickly, ensures the safety of data and performs all the approvals on its self.
It's almost Level 3 Ethernet. And it is just designed for small portions of data.
With only two nodes, this protocol will provide a good continuous data flow.
You need to decide for yourself whether you want to pay with excessive traffic for convenience and transfer the exchange authority to IP protocols, or do everything yourself.
-
Wow, I didn't realize that "in practice" rs-485 had so much more link margin than the standard requires, thanks for pointing that out! I'm definitely going to spend some time evaluating that option, seems like a good one.
I don't think this is necessarily a hard requirement, but anyone have good hints for running rs-485 through a magjack? I'll continue to do some research, but it looks like the standard answer is to buy an ic with built in isolation which seems like it has some penalties (cost, distance, rate).
I wasn't able to find much on 100m, 2Mbps CANBUS. -
IIRC, G.703 E1 (2 Mbit/s) runs up to 2 km with telephone wire.
-
I don't think this is necessarily a hard requirement, but anyone have good hints for running rs-485 through a magjack? I'll continue to do some research, but it looks like the standard answer is to buy an ic with built in isolation which seems like it has some penalties (cost, distance, rate).
You don't, if you need isolation, use a high speed optoisolator. -
What about Wiznet modules? They have RX/TX buffers built-in, and many have configurable Nagle time limit, so that instead of separate frames, you can treat the link as a pair of full-duplex TCP/IP byte streams. ~2Mbps ≃ 180×1460-byte payload datagrams/second, so if say 5ms Nagle TCP_DELAY (latency) is acceptable, you shouldn't have any problems over a dedicated 10Base-T TCP/IP link. The main benefit of this is bog-standard hardware.
-
What about Wiznet modules? They have RX/TX buffers built-in, and many have configurable Nagle time limit, so that instead of separate frames, you can treat the link as a pair of full-duplex TCP/IP byte streams. ~2Mbps ≃ 180×1460-byte payload datagrams/second, so if say 5ms Nagle TCP_DELAY (latency) is acceptable, you shouldn't have any problems over a dedicated 10Base-T TCP/IP link. The main benefit of this is bog-standard hardware.
What is the point of using the IP protocol for a fixed point-to-point connection?
And any PHY will provide RAW exchange at the frame level. -
Wow, I didn't realize that "in practice" rs-485 had so much more link margin than the standard requires, thanks for pointing that out! I'm definitely going to spend some time evaluating that option, seems like a good one.
I don't think this is necessarily a hard requirement, but anyone have good hints for running rs-485 through a magjack? I'll continue to do some research, but it looks like the standard answer is to buy an ic with built in isolation which seems like it has some penalties (cost, distance, rate).
I wasn't able to find much on 100m, 2Mbps CANBUS.
Look at the ADM2582E chip.
It has everything you need, you just connect it to the UART port of the MCU or send bitstream in another way, even the SPI port can be using if another one chip for CLK.
And control the pin send/receive. If the transmission is constantly in one direction, then physically set this pin.
I have used this chip a lot, with long distances, more than 500m.
It is very convenient and reliable, built-in secondary power source and ESD protection.
https://www.lcsc.com/datasheet/lcsc_datasheet_1811132113_Analog-Devices-ADM2582EBRWZ-REEL7_C39494.pdf
But I repeat once again - you need to independently verify the accuracy of the data in the program.
Transmission errors are possible.
-
What is the point of using the IP protocol for a fixed point-to-point connection?
Automatic TCP retransmission, without the main MCU having to care about it. -
What is the point of using the IP protocol for a fixed point-to-point connection?
Automatic TCP retransmission, without the main MCU having to care about it.
In point-to-point protocols on a physical dedicated line, there is no point in such guarantees, confirmation is easy to obtain if necessary and it is not a one-way flow.
I did not use the w5500 as TCP client, as server only and do not know is there confirmation of delivery (request to server from its side) when the socket is open for transmission.
Do you know that?
CAN does retransmission too, isn't it? -
As a fun experiment you can always try it with a 6N137 on both ends of the cable and just use the serial port of a MCU.
Did not use them for high speed, but 1-wire and tested it on 90 meters of cable. (Was what I had available as loose cable). Did not work with the 6N138 though, so the buffering and high bandwidth of the 6N137 were needed. Don't forget the decoupling capacitors though. They tend to oscillate. -
In point-to-point protocols on a physical dedicated line, there is no point in such guarantees, confirmation is easy to obtain if necessary and it is not a one-way flow.
Here is the idea behind my suggestion:
[MCU]≣[W]=====[W]≣[MCU]
From the MCU's point of view, the module [W] is a reliable direct connection to the other MCU, just with some random latency (I'd say up to 10ms given OP's situation, using 10Base-T).
The purpose is to simplify everything, and isolate as much of the complexity to the separate module as possible.
Sure, you can use plain Ethernet frames. The module (or MAC, if you use an MCU with Ethernet support) inserts the preamble and start frame delimiter (8 bytes) and appends the interpacket gap (12 bytes). The header for 42 to 1500 bytes of payload adds 14 + 4 bytes, with many modules/MACs calculating and appending the 4-byte checksum. In wire terms, the overhead is 38×8 bit times per payload chunk, so it varies from 47.5% for 42-byte payload to 2.47% for 1500 bytes of payload. For 2Mbps data payload stream, it's in all cases less than half the theoretical bandwidth of 10Base-T, so should work fine. You would need to consider how to handle e.g. occasional data garbling (due to transient EM-coupled noise, perhaps) yourself.
Given a suitable Wiznet module, the MCUs only need to configure the modules, and then they can treat the 10Base-T cable run as a reliable transport between the modules, and only worry about talking to the module (which is simple). They ensure that data in the TX buffer of one module will end up copied to the RX buffer of the other, handling very short interruptions and noise via retransmission automatically; anything major, and the MCU will see an error. So, while not in any way optimal solution, it is a low-cost and simple one.
Personally, I'd use my Teensy 4.1's with Ethernet instead, and most likely raw Ethernet frames. I don't know SuperFungus' preferences as to how deep into the software they want and are able to go, but I do believe the Wiznet option is much easier to implement than the Teensy one is. Simply put, I suggested something I thought might be useful to consider, even though I myself would choose a different path.
-
Look at the ADM2582E chip.
Thanks for the suggestion. That does look like a very nice part - at a very nice ADI price Regardless, I'll put that at the top of the list for isolated RS-485 options.What about Wiznet modules? They have RX/TX buffers built-in, and many have configurable Nagle time limit, so that instead of separate frames, you can treat the link as a pair of full-duplex TCP/IP byte streams. ~2Mbps ≃ 180×1460-byte payload datagrams/second, so if say 5ms Nagle TCP_DELAY (latency) is acceptable, you shouldn't have any problems over a dedicated 10Base-T TCP/IP link. The main benefit of this is bog-standard hardware.
I actually bought a couple cheap WIZnet modules for this that just arrived today. All the reasons you give for this option make sense to me and seem very practical. I was (and still am a little) worried about the latency incurred by all the various framing the overheads, but if I can run them full duplex at 100Mbps this is a much less significant issue right off the bat. I don't know what my spec for latency is, but I want it to feel transparent to a user interacting with it. TCP with appropriately set Nagle is a good first step, maybe the 5ms is enough like you say. I can also take the same HW and do UDP (maybe with a 1/2 rate code or something) if I discover I need faster updates. Thanks for talking through all that, definitely now back towards leaning towards trying this approach first.
The other thing in the back of my mind is that this 2Mbps input stream is has not yet been fully defined to me, but I really doubt it's continuous - I've somewhat given up on getting written docs for this and am just waiting to measure physical hardware. That said if I think if my uP can understand some basic framing on this stream coming in, that will also probably suggest some optimizations...
I'm a little embarrassed to say how long I spent reading about EtherCAT and getting excited today before I realized there's almost no benefit to a point to point duplex link... oh well haha
Thanks again for everyone's suggestions, a lot of angles here I probably wouldn't have considered on my own. This has already been very helpful.