3 ms·

Thanks for sharing your experience! What is the advantage of using single pair ethernet in for example cars? My company owns a largish drone and it has a regula

by tinco 5y ago

Thanks for sharing your experience! What is the advantage of using single pair ethernet in for example cars? My company owns a largish drone and it has a regular CAT5 network so surely it can't be weight or size.

mimentum 5y ago
Surprised it isn't running a CANBUS system.
- detaro 5y ago
  CAN is slow compared to Ethernet and really optimized for tiny payload sizes, so for plenty purposes the former isn't that useful. (Which is also why Ethernet is pushing into automotive)
zbrozek 5y ago
I've spent ten years designing electronics for cars. It's very often harness reduction under various motivations. The bundle needs to be small to fit through chassis holes (which are kept small to keep structures strong). Keeping the pin count low increases available connector choices and reduces connector costs (especially where they must be waterproof). Off in the distant corners of minds is weight. Your drone would probably do the same if the manufacturer had more engineers to spend on optimizing the design. But it's probably also sold in lower volume than car parts. Alternatively, maybe it's using CAT5 in a nonstandard way. For example, maybe two links or non-PoE power or even not Ethernet at all.
- sorenjan 5y ago
  How are car communication done in modern cars? Is there a single cable run from the ECU in the front to the cabin and one to the back, and then some kind of switch connects stuff like gauge cluster, AC, buttons etc in the cabin, and lights, camera etc in the back? How about fiber cable, is there any movement towards that? Some cars have fancy 360 camera systems that I imagine can use a lot of bandwidth.
  - tfigment 5y ago
    Cars use CAN for most controller networks. It can go up to 1 Mbps but lots of time maybe 250 kbps. It has advantage of being broadcast so all devices get messages at same time. The wiring tends to have noise reduction properties and floating reference voltages as i recall. For cameras i'd imagine they use something else for bandwidth and ease of use reasons.
    - sgtnoodle 5y ago
      CAN is content addressed rather than sender/receiver addressed. The address is also used to arbitrate transmit priority on every single message frame. This allows for messages to be sent with well controlled latency, which is important for stuff like drive-by-wire steering and braking. CAN bus wiring isn't floating in that it isn't isolated. The transceivers are required to deal with a large common mode voltage range, though, and there are isolated transceivers for specific use cases. The noise reduction properties are simply that the digital signal is encoded as the difference in voltages between two wires, and those wires are supposed to be twisted together. Also, the typical behavior is for a CAN controller peripheral to automatically re-transmit frames that didn't make it on the bus, for example, if there was too much noise that a receiving node got a CRC mismatch. A video feed from a camera would be way too much bandwidth to run over a typical CAN setup. For reverse cameras, it's probably HDMI or something. For more elaborate safety and convenience systems, it's likely either close enough to the computer that it's a parallel bus, or far enough from the computer that it's a differential high speed interconnect that's qualitatively similar to HDMI.
  - zbrozek 5y ago
    There's a lot of approaches for various subsystems. The cameras that you mention are quite-likely some kind of serialized MIPI (e.g., using some generation of FPDlink or GMSL to tunnel asymmetrical bidirectional data across a micro-coax cable). An SOC somewhere (often the same one driving the display) will receive the deserialized MIPI streams and do whatever video processing is desired and display the output stream. The display is typically eDP or sometimes HDMI. Old-school hardware that doesn't have large bandwidth requirements will usually use CAN, a multi-drop bus that is capable of up to 1000 kbps but is typically used at 125, 250, or 500 kbps. Its advantage is simple UTP cabling. Its disadvantage is that it's a planned bus - you need to have termination resistors in known locations and you have to plan the addresses of devices in advance. It's kind of brittle and the tiny packet size means folks jump through hoops to send larger blobs of data. This is probably one of the great barriers to being able to buy some random car part from a manufacturer as Joe Q Public and use it. The OEM is used to making lightly-customized firmware for every customer. A typical car is a mix of hub-and-spoke topology and a daisy chain. There will be a handful of CAN buses that go to various devices around the car. You might have a CAN-connected cabin controller that has a bunch of motor control chips for seat adjustments and seat heaters or window heaters and which daisy chains with door controllers and mirror controllers on the cabin bus. There might be another daisy chain in the engine compartment; one device might control the HVAC system and another controls the engine. Usually the hub is some higher-performance device or at minimum a gateway that taps each of the various low-speed buses and is used to provide a firmware flashing and diagnostic gateway. That's increasingly frequently the same computer that runs the infotainment system. So let's say you're at the end of the factory line, you can plug in a thumb drive via USB or drop an Ethernet connection to the car and rapidly upload all the firmware blobs to the infotainment computer and it'll run a program that passes all of them along to the various widgets. 10Base-T1{S,L} might start to displace CAN in some of these widgets so long as MCUs and PHYs are very cheap. 100Base-T1 has already seen some adoption in things like backup cameras that use chips that also implement video compression and streaming. I believe BMW and Mercedes started using standard Ethernet for their diagnostic gateway and then bridged to 100Base-T1 internally between their higher-bandwidth widgets since ~2007. Personally, I'd love it if everything ended up on faster IP networks and no longer needed custom firmware on a per-implementation basis. As of a few months ago, I am no longer in the automotive business.
theincredulousk 5y ago
Having single-pair vs. cat5 is kind of a bonus, for wiring simplicity and weight. I could also see the power delivery part being useful for things like sensors and other oddly placed/small powered devices. The main benefit is Ethernet. It has already started, but in the next few model years of cars, there is a large transition happening from CAN -> Ethernet as the primary communication bus. The simplest reason for that is software + bandwidth + integration. To implement semantics like an RPC call across two modules in car via CAN, it is kind of ugly and almost always results in awkward software interfaces and extremely inflexible implementations. Whereas with Ethernet now you can do something like use gRPC and protobufs, which is entirely flexible and results in well-defined/formed software interfaces. CAN will still be used for a while for what it is best at: low-level, reliable, low-bandwidth chatty data interfaces that make sense for electro-mechanical parts - especially those that don't have (or need) anything more than a very bare-bones microcontroller. Cost is still a huge factor in automotive design, because a $1 difference x 1 million cars blah blah it makes a difference. Bandwidth is obvious. CAN can't do video, and in practice audio either (although theoretically possible I guess). Cars have lots of audio and video devices now, and it is unnecessarily complicated to always have command/control and media data on separate buses. Imagine if your computer used one physical network interface for HTTP requests and another interface for streaming video. Sure it'd work fine but you'd have a bunch of extra cables, ports, hardware, and software complexity to make it work.

by tinco 5y ago

mimentum 5y ago

Surprised it isn't running a CANBUS system.

detaro 5y ago
CAN is slow compared to Ethernet and really optimized for tiny payload sizes, so for plenty purposes the former isn't that useful. (Which is also why Ethernet is pushing into automotive)

zbrozek 5y ago

I've spent ten years designing electronics for cars. It's very often harness reduction under various motivations. The bundle needs to be small to fit through chassis holes (which are kept small to keep structures strong). Keeping the pin count low increases available connector choices and reduces connector costs (especially where they must be waterproof). Off in the distant corners of minds is weight. Your drone would probably do the same if the manufacturer had more engineers to spend on optimizing the design. But it's probably also sold in lower volume than car parts. Alternatively, maybe it's using CAT5 in a nonstandard way. For example, maybe two links or non-PoE power or even not Ethernet at all.

sorenjan 5y ago
How are car communication done in modern cars? Is there a single cable run from the ECU in the front to the cabin and one to the back, and then some kind of switch connects stuff like gauge cluster, AC, buttons etc in the cabin, and lights, camera etc in the back? How about fiber cable, is there any movement towards that? Some cars have fancy 360 camera systems that I imagine can use a lot of bandwidth.
- tfigment 5y ago
  Cars use CAN for most controller networks. It can go up to 1 Mbps but lots of time maybe 250 kbps. It has advantage of being broadcast so all devices get messages at same time. The wiring tends to have noise reduction properties and floating reference voltages as i recall. For cameras i'd imagine they use something else for bandwidth and ease of use reasons.
  - sgtnoodle 5y ago
    CAN is content addressed rather than sender/receiver addressed. The address is also used to arbitrate transmit priority on every single message frame. This allows for messages to be sent with well controlled latency, which is important for stuff like drive-by-wire steering and braking. CAN bus wiring isn't floating in that it isn't isolated. The transceivers are required to deal with a large common mode voltage range, though, and there are isolated transceivers for specific use cases. The noise reduction properties are simply that the digital signal is encoded as the difference in voltages between two wires, and those wires are supposed to be twisted together. Also, the typical behavior is for a CAN controller peripheral to automatically re-transmit frames that didn't make it on the bus, for example, if there was too much noise that a receiving node got a CRC mismatch. A video feed from a camera would be way too much bandwidth to run over a typical CAN setup. For reverse cameras, it's probably HDMI or something. For more elaborate safety and convenience systems, it's likely either close enough to the computer that it's a parallel bus, or far enough from the computer that it's a differential high speed interconnect that's qualitatively similar to HDMI.
- zbrozek 5y ago
  There's a lot of approaches for various subsystems. The cameras that you mention are quite-likely some kind of serialized MIPI (e.g., using some generation of FPDlink or GMSL to tunnel asymmetrical bidirectional data across a micro-coax cable). An SOC somewhere (often the same one driving the display) will receive the deserialized MIPI streams and do whatever video processing is desired and display the output stream. The display is typically eDP or sometimes HDMI. Old-school hardware that doesn't have large bandwidth requirements will usually use CAN, a multi-drop bus that is capable of up to 1000 kbps but is typically used at 125, 250, or 500 kbps. Its advantage is simple UTP cabling. Its disadvantage is that it's a planned bus - you need to have termination resistors in known locations and you have to plan the addresses of devices in advance. It's kind of brittle and the tiny packet size means folks jump through hoops to send larger blobs of data. This is probably one of the great barriers to being able to buy some random car part from a manufacturer as Joe Q Public and use it. The OEM is used to making lightly-customized firmware for every customer. A typical car is a mix of hub-and-spoke topology and a daisy chain. There will be a handful of CAN buses that go to various devices around the car. You might have a CAN-connected cabin controller that has a bunch of motor control chips for seat adjustments and seat heaters or window heaters and which daisy chains with door controllers and mirror controllers on the cabin bus. There might be another daisy chain in the engine compartment; one device might control the HVAC system and another controls the engine. Usually the hub is some higher-performance device or at minimum a gateway that taps each of the various low-speed buses and is used to provide a firmware flashing and diagnostic gateway. That's increasingly frequently the same computer that runs the infotainment system. So let's say you're at the end of the factory line, you can plug in a thumb drive via USB or drop an Ethernet connection to the car and rapidly upload all the firmware blobs to the infotainment computer and it'll run a program that passes all of them along to the various widgets. 10Base-T1{S,L} might start to displace CAN in some of these widgets so long as MCUs and PHYs are very cheap. 100Base-T1 has already seen some adoption in things like backup cameras that use chips that also implement video compression and streaming. I believe BMW and Mercedes started using standard Ethernet for their diagnostic gateway and then bridged to 100Base-T1 internally between their higher-bandwidth widgets since ~2007. Personally, I'd love it if everything ended up on faster IP networks and no longer needed custom firmware on a per-implementation basis. As of a few months ago, I am no longer in the automotive business.

theincredulousk 5y ago

Having single-pair vs. cat5 is kind of a bonus, for wiring simplicity and weight. I could also see the power delivery part being useful for things like sensors and other oddly placed/small powered devices. The main benefit is Ethernet. It has already started, but in the next few model years of cars, there is a large transition happening from CAN -> Ethernet as the primary communication bus. The simplest reason for that is software + bandwidth + integration. To implement semantics like an RPC call across two modules in car via CAN, it is kind of ugly and almost always results in awkward software interfaces and extremely inflexible implementations. Whereas with Ethernet now you can do something like use gRPC and protobufs, which is entirely flexible and results in well-defined/formed software interfaces. CAN will still be used for a while for what it is best at: low-level, reliable, low-bandwidth chatty data interfaces that make sense for electro-mechanical parts - especially those that don't have (or need) anything more than a very bare-bones microcontroller. Cost is still a huge factor in automotive design, because a $1 difference x 1 million cars blah blah it makes a difference. Bandwidth is obvious. CAN can't do video, and in practice audio either (although theoretically possible I guess). Cars have lots of audio and video devices now, and it is unnecessarily complicated to always have command/control and media data on separate buses. Imagine if your computer used one physical network interface for HTTP requests and another interface for streaming video. Sure it'd work fine but you'd have a bunch of extra cables, ports, hardware, and software complexity to make it work.