Hacker News Reader

Comment by myself248 | Hacker News Reader

So that's three separate single-pair standards that I'm aware of, and I can't get _anyone_ to tell me if they interoperate. Perhaps they're different names for the same thing? Perhaps the wheel just keeps being reinvented?

One is the Single Pair Ethernet industrial partner network mentioned in this post:

https://www.single-pair-ethernet.com/en

which seems to be standardized as 802.3cg and calls itself 10base-T1L.

The second is the One-Pair EtherNet (OPEN) Alliance:

http://www.opensig.org/

which seems to be standardized as 802.3bw and calls itself 100base-T1 and 1000base-T1. I believe this is the one I see deployed in production cars today.

The third is HDMI Ethernet, which rides pins 14 and 19 of the HDMI connector. It is absolutely impossible to find information on. Does it have a standard? Does it use a standard MAC? Where can I buy the PHY?

What a stinking mess.

View on HN

100base-T1 and 1000base-T1 are indeed the old OPEN, and are indeed what's deployed in production cars. 100 Mb PHYs are available from multiple vendors, and are mature and quite pleasant to work with (built in TDM for detecting wiring issues, etc). 1000 Mb PHYs are rarer (I've only seen Broadcom in person), but it's clearly coming. The 100- and 1000- protocols are pretty different; both are really focused on allowing cheap crappy wiring, but this is hard enough for 1000- that things like FEC are added. The equivalent of PoE for -T1 is PoDL (power over data lines), which is much more civilized than PoE (no transformers); and since 1000- runs at a higher lowest frequency than 100-, it's significantly easier to get power over it with smaller inductors.

I'm not too familiar with the current state of -T1L, but the little I've seen about it in the past was a focus on taking the advantages of -T1 (low wiring cost, simplicity, robustness, PoDL) and applying it to industrial applications, where MUCH longer cable runs than in automotive are desired. While I was following this was mostly done by adding in a 10base-T1L physical layer, giving up an order of magnitude of speed in exchange for an order of magnitude or two more run length. Don't know if there's any intent to have faster -T1Ls, haven't followed that far.

10base-T1L, 100base-T1, and 1000base-T1 are all pretty different physical layers, although they share some principles. I /think/ the Broadcom 1000base-T1 PHY can run in 100base-T1 mode, and maybe even auto-negotiate (yuck), but they're quite different under the hood.

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.

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.

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.

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.

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.

Yes, pretty much. There are usually 5-10 different CAN or FlexRay strings, each for a "topic" (Powertrain, Convenience / Controls, Sensors, Infotainment, etc.), all linked together by a Gateway module.

Then for high bandwidth needs there is a separate set of buses, usually optical. For audio this has been fiber-optic MOST for years. For video it's a grab-bag of weird optical standards with occasional LVDS links being used for shorter runs.

Besides lights which are still often driven by a centralized Body Control Module with a huge number of wires coming off of it, most analog wiring is localized to a much smaller area than in old cars. For example, now you'll have a Door Control Module which connects to the window switches, locks, mirrors, and window motor, instead of a bunch of wires running between the door and relays under the dashboard.

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.

Surprised it isn't running a CANBUS system.

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)

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.

> I think Broadcom 1000base-T1 PHY can run in 100base-T1 mode

Marvel claims their 88Q211x PHYs can do that. No auto-negotiation.

[0] https://www.marvell.com/content/dam/marvell/en/public-collat...

Putting HDMI ethernet channel thoughts here, since I have no first-hand experience with it. My understanding is that it's basically 100base-TX under the covers, and that's vaguely confirmed by [1] and others. The big difference, as you mentioned, is that it uses a single pair, instead of separate RX/TX pairs like 100base-TX usually does. Rather than doing the 1000base-T trick (share the lines with echo cancellation), it looks like it uses an analog hybrid [2]. Still never seen it in the wild though.

[1] https://www.semiconn.com/ep91h1 [2] https://en.wikipedia.org/wiki/Telephone_hybrid

One of the key differentiators is that most of these standards are point-to-point--they only connect 2 devices. So, it doesn't work very well for replacing things like CAN.

10Base-T1S is multidrop on single pair--which is basically a CAN replacement.

Unfortunately, I haven't seen much movement at all in the T1S space.

I have yet to see a reasonable case for CAN replacement, as it's good enough. Maybe we'll get more wireless connectivity from the IoT space, but that's probably not immediate.

There's really no goal for these to do anything other than PtP with these solutions.

CAN doesn't scale to high data rates.

But the underlying RS-485 has nice noise rejection and is dead easy to manage.

Are you confusing CAN with ModBus-RTU perhaps? The wires are similar, but RS485 uses differential encoding for both 0 and 1 while CAN only uses it for 1. In CAN, 0 is represented by lack of difference between the two wires.

Correcting myself, actually CAN is the opposite: 1 (recessive state) is lack of difference, 0 (dominant state) is presence.

Yes, I more recently used modbus and lazily conflated them in my memory.

CAN is lousy if your messages are larger than 8 bytes. And, invariably, your messages eventually end up larger than 8 bytes. Then you have to deal with CANOpen and your life becomes hell.

I also find some of the CAN architecture decisions kind of questionable nowadays. A lot of stuff like ACK and retransmit in the hardware made sense back when microcontrollers were expensive. Nowadays, its just something that chip implementors are likely to screw up that you can't fix with software.

Module reflashing. The effective data rate of a 1Mbps CAN network is about 180kbps of payload. Barely faster than dialup. And CanFD doesn't improve as much as you'd think, because all the overhead still runs at 1Mbps.

If you've ever moved a few meg of firmware over CAN, you know how agnozingly slow that turns out to be in practice. Which is fine enough in development, okay, go get a coffee and chat with the other engineers for a bit, it'll be done soon enough. But in the field, incentives change:

At the dealer, reflashes are usually not paid by the customer, so time is money in the negative sense. Get the car done as fast as possible and go back to work that pays.

For over-the-air reflashing, it's even worse. You have to guess that the car is gonna be parked for a while (or get user consent), and perform the reflash before they change their mind and decide to go for a drive again. A 2-minute reboot on a phone is obnoxious enough, a 20-minute reflash for one module is a death knell for OTA, and if you need to update several modules at once in order for their versions to be in sync, that can well take an hour or longer. Absolutely unacceptable.

PtP is fine because it's just one pair, and you're running back to a gateway module anyway. The gateway module houses the flash memory lake that stages the OTA update packages. When you get the go-signal, blast those out to all the affected modules, finish in 2 minutes, and the car is driveable again.

This is HUGE. Everyone on HN mocks automakers-other-than-tesla for not having OTA figured out yet, and Ethernet is a key enabling technology for it.

The use case for 10BASE-T1S isn't quite clear to me. I get that you can do multidrop ethernet, which would simplify things a lot; no need to add switches or daisy chain anymore. And it's also not too slow, and you only need two wires.

But are microcontrollers with ethernet common? How cheap are they? A MAC needs a lot of pins compared to CAN which will increase footprint. And to really take full advantage of ethernet, you need a good networking stack and a solid set of utilities and applications on top. So Linux is the way to go in that case. But then you need a big processor with external RAM, eMMC, PMIC, several layer board, and don't forget a couple of Linux weirdos (speaking as one) who can actually develop in that environment. A lot of embedded guys can understand CAN pretty easily; show them gRPC and their heads may explode.

So I guess the use case is: embedded system with a lot of Linux boards that don't need that much bandwidth? Does that accurately reflect the architecture of a modern car?

> But are microcontrollers with ethernet common? How cheap are they?

Define "common". However, they are available. I see some right around $4 from ST.

> A MAC needs a lot of pins compared to CAN which will increase footprint.

Normally the pins on the connector are far more critical than the pins on the microcontroller. RMII takes up 9 pins on the microcontroller.

> And to really take full advantage of ethernet, you need a good networking stack and a solid set of utilities and applications on top. So Linux is the way to go in that case. But then you need a big processor with external RAM, eMMC, PMIC, several layer board, and don't forget a couple of Linux weirdos (speaking as one) who can actually develop in that environment. A lot of embedded guys can understand CAN pretty easily; show them gRPC and their heads may explode.

You are WAY too high-level. UDP works just fine for a lot of applications and takes next to nothing in terms of resources. And TCP doesn't require as much resource as you think (remember TCP dates back to the 1980s when memory was scarce). Even straight HTTP isn't too bad.

The biggest problem is HTTPS. That invokes a whole crapload of overhead.

It's able to supply power over the same two wires (in the point to point case and the multidrop case), IEEE calls it PoDL (power over data line) and I think it supports about 100W in total for one pair. Even in the point to point case, this could offset the demerit of losing multidrop. Multidrop with 100Mbps and 100W of power would be a gamechanger.

About 2 years ago I tried to make a prototype using 100baseT1 with PoDL but most of the components weren't on the market yet. I did manage to get samples of some but not all parts, and gave up and kept using this[1] tiny switch. There's also a 1000base-T version.

One thing to note about using ethernet in embedded applications, and also the reason why you can't find many small microcontrollers that support it, is ethernet uses a lot of power. About 0.5W per port (meaning 1.0W per line) for 100Mbps, 0.7W per port for 1Gbps, and 4W per port for 10Gbps. There are low-power standards that work by idling when not in use, but I've yet to see any devices that support it. The 2 wire standards are designed for much, much lower power consumption.

[1]https://gadgetsmyth.com/product/ethos-lite/

Lots of the PHYs I've seen are 2-port switches for daisy-chaining. Cost about 50% more.

> One is the Single Pair Ethernet industrial partner network mentioned in this post:

> which seems to be standardized as 802.3cg and calls itself 10base-T1L.

> The second is the One-Pair EtherNet (OPEN) Alliance:

> What a stinking mess.

One is high speed point-to-point, to replace expensive proprietary crap like MOST, FLEXRAY, etc. Another to replace slow buses, like CanBus, ModBus.

There's also EFM/2BASE-TL which was a sort of IEEE rebadge of the ITU DSL standards with the OAM layer replaced with Ethernet OAM. I never quite figured out if there was any point to it beyond NIH.

For what it's worth, I clicked some links on the posted page and the first datasheet I opened was for a 10base-T1 transceiver. So I believe this "single pair ethernet" encompasses both T1 and T1L, with L probably standing for "long distance". It's confusing but it is nice to have a family of standards that hopefully work the same, but have different physical layer for different use cases.

The key differentiator here is reach.

10Base-T1L (the subject of the article) is really an industrial/sensing application and supports cables up to 1km in length.

The 100Base-T1 and 1000Base-T1 standards are targeting the transportation market with cables <50m in length.

The article states that the technology being referred to is 1Gbps, plus power, over a distance of up to 40m.

(Although it is an 18 month old article, so things may have changed since).

Good luck finding any consumer products that ever supported HDMI Ethernet Channel (HEC). In contrast, HEC capable HDMI cables with pins 14 and 19 in a twisted pair were widely available to the confusion of many.

Audio Return Channel (ARC) uses the same pins as HEC. Enhanced ARC (eARC), available on some newer TVs and AV Receivers/preamps/soundbars, takes advantage of the twisted pair to support greater audio bandwidth and surround channels (ARC was limited to 5.1), so it’s a happy ending for folks who bought HEC compatible HDMI cables.

T1S is a thing, but the only chip on the marked is bugged beyond being usable, and Microchip wanting $4 for it.

Reply on news.ycombinator.com