Nobody ever tried to use CAN for streaming video, because that’s not the purpose of CAN?
> Tesla’s next-gen networking is all about timing - and unlike CAN, where two messages coming in at the same time can collide (resulting in neither reaching the node),
> CAN is like everyone yelling in a room
This is simply false. CAN uses bit arbitration and the lowest address wins.
> Nobody ever tried to use CAN for streaming video, because that’s not the purpose of CAN?
How do the reversing/parking cameras work then? I always thought the reason why their feed is so low quality even in new cars was because they transmit through CAN.
The cameras often have dedicated cabling to the front. Sometimes analog video (probably not so much today, or only on the cheap end), sometimes digital over Coax. In other cars its using Flexray (which is a high-performance bus-system designed to be able to also support video)
Similarly, PROFINET, the confusingly named EtherNet/IP (IP here stands for Industrial Protocol not Internet Protocol), POWERLINK, and others - all based on Ethernet but with a custom protocol layer replacing IP. "We need something that is high speed but also supports rapid deterministic communication" is pretty much a solved problem in the industrial space.
I wonder what Tesla's game is here: is it really just reinventing the wheel, or are they perhaps using higher speed Ethernet as industrial Ethernet tends to still be limited to 100Mbit? Or perhaps it's tightly linked with the proposal to communicate over 48V lines?
Industrial Ethernet uses 100Mb speeds because (and when) those are sufficient for their use cases. There is no technical limitation there. 1000base-T1 (and even 2.5, 5 & 10G SPE¹) show where this is going.
Huh, I didn't know single pair ethernet went up that fast - neat! We're still living in the 100Mbit world at my company - and, yeah, it's fast enough for pretty much everything we need.
Many microcontrollers come with CAN support natively, but no PHY for instance. So CAN is available for even the cheapest MCUs, not so with Ethernet.
There is also a lot more supporting hardware required for Ethernet compared to CAN, and the price for producing a cheap Ethernet capable board is many times that of CAN.
The galvanic isolation in Ethernet (magnetics) costs about 1W idle pr port, so the power budget is also on a whole other level.
I spent the previous decade in embedded, designing both CAN and Ethernet-capable cobtrol systems for industrial applications.
Ethernet is much more expensive than CAN, but can also be much faster etc.
CAN and Ethernet normally do not compete for the same applications :)
You're comparing CAN with classic Ethernet. You should be comparing CAN with SPE (Single Pair Ethernet), which was developed to replace CAN (among other things) and is in fact well on its way on doing just that - cars are getting built using it.
Even if we compare CAN to Single Pair Ethernet, most of my points still stand, do they not?
SPE is still more expensive and complicated than CAN, but also much more capable (higher data rates etc.). PHY power consumption is much lower compared to traditional Ethernet, but still on another level compared to CAN.
I’ve seen Ethernet chosen mostly when CAN (or RS485 etc.) is too slow or you want longer distances (cabling).
I mean to clarify my point - not to bicker :) I don’t think I disagree with any of your points
I'm not actually sure 10base-T1S (which is the closest equivalent to CAN) uses more power than CAN. The maximum current rating for some random T1S PHYs is actually lower than that of some random CAN PHYs, but actual power consumption depends on bus usage patterns…
Regarding being expensive and complicated… I'd say that's a question of proliferation. And the non-multidrop SPE variants are actually simpler than CAN in some regards I'd argue.
Okay, interesting! Thanks for enlightening me. I’ll look into SPE.
W.r.t. my point with “complicated and expensive”. Most IP-stacks require low double digit kilobytes of memory, where CAN can be much cheaper (can also be much heavier depending on the “CAN stack”), which rules out the cheapest MCUs.
When I was in embedded, most cheaper MCUs (32bit <100MHz single core, 16kb SRAM etc.) didn’t support Ethernet as a native peripheral. I.e. required a jump from a Cortex M3 to M4 for instance. I haven’t followed things for around a decade though..
I am aware that there's video usecases in cars, but why consider CAN for that at all? That's like streaming music via UART - yes, can be done, but why.
It's not about bandwidth; combustion engines used to be massive EMI disasters (due to ignition coils) wrecking electronic communications in their immediate vicinity. Fibre optics are plain noise immune. Not sure how much of this is needed with high power electric motors.
They're also lighter than copper cables, which can in fact matter in a car (though changing interconnect types and topologies also fixes that.)
Electric motors are - almost by definition - giant, fast moving magnets. That will generate current in any nearby wiring, and thus interference.
That said, this kind of interference is much easier to filter than the kind you'd get from 4 to 8 spark plugs firing in sequence. So it's pretty likely that this is easier to deal with.
Are fiber optic cables flexible and tough enough? Fiber optic seems to be good for fixed deployments but not exactly fit for a rough&tumble environment like a car.
Long answer: you need to choose appropriate connectors and fibre types. There's more to fibre than just OM5 and OS2 on LC connectors. Disaster recovery agencies as well as militaries use fibre cabling in temporary camp / communication infrastructure setups too, with ruggedized cables and connectors. There's 50+ years of history and experience to source from.
"Counter" answer: copper cables in cars also break.
No no no... Like Cybertruck, they're doing something amazing, so we should let them do whatever they do without limits. (obvious angry satire warning if it's not visible already).
Maybe they should add some efficiency in to the protocol, via their newly obtained cross-discipline expertise.
And the protocol shall have no logging capabilities.
> add any new, proprietary high-speed video stuff on the side
Dashcams just use regular USB-C with HDMI or DisplayPort.
And the electronics for this are cheap, plentiful and reliable since it is used extensively in hobbyist circles e.g Raspberry Pi. No need for anything proprietary or crazy. Just run another cheap cable.
This is just what we need: "From the same guys that brought you the Cybertruck, comes a new replacement protocol [for a tried and true thing that's been running for decades] ..."
I really hope the industry sits this one out or, if needed, comes up with something better.-
It's also "From the same guys that brought you the Tesla Model S, 3 and Y". It's easy to point the finger at a bad product a company has made and throw out all of the good.
The new CAN looks to include tried and trued protocols that have existed for a while but would allow for a much better system.
The combustion engine was tried and trued and didn't need changing until someone decided to do something better and electric engines are better.
But the arguments made against it seem quite biased towards Tesla:
"However, this entire test scenario is so out of left field… there is a good likelihood this same test would fool some human drivers as well"
When one of the major arguments of the video was about easy and affordable it was for the average LIDAR system to detect the wall. Of course human beings are not perfect drivers, which is why Tesla's attempt at mimicking human senses for its self driving capabilities is a bad idea. But the article seems completely ignorant of this IMO very clearly stated narrative in Mark's video.
> But the arguments made against it seem quite biased towards Tesla: "However, this entire test scenario is so out of left field… there is a good likelihood this same test would fool some human drivers as well"
The argument seems to be that running the test with FSD rather than Autopilot lead to much better results:
> During this test, many people noted that Mark was using Autopilot rather than FSD...Creator Kyle Paul over on X made a much better follow-up video, using both a HW3 Model Y as well as an AI4 Cybertruck. In a relatively unsurprising turn of events, the Cybertruck was successfully able to detect the wall, slowed down, and came to a stop. The Cybertruck was running FSD 13.2.8.
That seems like a valid point. Saying that you're testing Teslas self-driving car and not actually testing FSD but opting for the less advanced Autopilot feels misleading.
Okay FSD is better than autopilot. If we put aside Tesla-specific marketing terms, and you had an unnamed car company advertise a feature called autopilot, would you as a customer expect the car to stop when met by a wall? I wonder how it would fly in court.
CAN bus never was the only choice of automotive buses, it's the cheapest option. There were always competing standards like FlexRay and LIN buses, just like there were Rambus RDRAM against JEDEC SDRAM or IEEE1394 against USB.
It's what Mercedes pioneered, and what most high-volume manufacturers standardized on, including most Japanese and American brands. Some European companies like Volkswagen-Audi Group uses something else. I think implication of that is clear.
Nissan and Toyota had been shipping cars with automotive Ethernet since as early as 2019. Including Toyota's Hydrogen EV since at least 2022. I think implication of that is also clear.
62 comments
[ 3.2 ms ] story [ 125 ms ] thread> Tesla’s next-gen networking is all about timing - and unlike CAN, where two messages coming in at the same time can collide (resulting in neither reaching the node),
> CAN is like everyone yelling in a room
This is simply false. CAN uses bit arbitration and the lowest address wins.
And in doing so it prioritizes important messages and enables deterministic timing.
How do the reversing/parking cameras work then? I always thought the reason why their feed is so low quality even in new cars was because they transmit through CAN.
(You're also technically wrong: both LIN and -T1 Ethernet can share power and data onto a minimum total of 2 wires.)
I wonder what Tesla's game is here: is it really just reinventing the wheel, or are they perhaps using higher speed Ethernet as industrial Ethernet tends to still be limited to 100Mbit? Or perhaps it's tightly linked with the proposal to communicate over 48V lines?
¹ Single Pair Ethernet
Time triggered Ethernet is used in aviation though.
Many microcontrollers come with CAN support natively, but no PHY for instance. So CAN is available for even the cheapest MCUs, not so with Ethernet.
There is also a lot more supporting hardware required for Ethernet compared to CAN, and the price for producing a cheap Ethernet capable board is many times that of CAN.
The galvanic isolation in Ethernet (magnetics) costs about 1W idle pr port, so the power budget is also on a whole other level.
I spent the previous decade in embedded, designing both CAN and Ethernet-capable cobtrol systems for industrial applications.
Ethernet is much more expensive than CAN, but can also be much faster etc.
CAN and Ethernet normally do not compete for the same applications :)
I was talking about vanilla Ethernet and answering a questions about “The most common standard known to mankind”, so I stuck with that.
I limited myself to traditional Ethernet because most people think of that when they say “Ethernet”, but sure, it could technically be all of 802.3.
SPE is still more expensive and complicated than CAN, but also much more capable (higher data rates etc.). PHY power consumption is much lower compared to traditional Ethernet, but still on another level compared to CAN.
I’ve seen Ethernet chosen mostly when CAN (or RS485 etc.) is too slow or you want longer distances (cabling).
I mean to clarify my point - not to bicker :) I don’t think I disagree with any of your points
Regarding being expensive and complicated… I'd say that's a question of proliferation. And the non-multidrop SPE variants are actually simpler than CAN in some regards I'd argue.
W.r.t. my point with “complicated and expensive”. Most IP-stacks require low double digit kilobytes of memory, where CAN can be much cheaper (can also be much heavier depending on the “CAN stack”), which rules out the cheapest MCUs.
When I was in embedded, most cheaper MCUs (32bit <100MHz single core, 16kb SRAM etc.) didn’t support Ethernet as a native peripheral. I.e. required a jump from a Cortex M3 to M4 for instance. I haven’t followed things for around a decade though..
Growing trend of it for certain use cases:
* https://en.wikipedia.org/wiki/Ethernet_over_twisted_pair#Sin...
* https://www.keysight.com/blogs/en/tech/educ/2024/automotive-...
* https://www.keysight.com/blogs/en/tech/2024/02/8/how-is-10ba...
* https://www.analog.com/en/signals/thought-leadership/why-10b...
* https://www.graniteriverlabs.com/en-us/technical-blog/automo...
In some ways this is going to Ethernet's roots with a common transmission medium (Thicknet, Thinnet).
Rear video feed
Maybe use CAN for what it was intended and add any new, proprietary high-speed video stuff on the side?
Ruggedized eyes.-
PS. Wonder if such a thing exists in nature ...
... but for goodness sake, leave good enough alone for critical stuff.-
The limiting factor is the available compute not bandwidth.
They're also lighter than copper cables, which can in fact matter in a car (though changing interconnect types and topologies also fixes that.)
That said, this kind of interference is much easier to filter than the kind you'd get from 4 to 8 spark plugs firing in sequence. So it's pretty likely that this is easier to deal with.
Long answer: you need to choose appropriate connectors and fibre types. There's more to fibre than just OM5 and OS2 on LC connectors. Disaster recovery agencies as well as militaries use fibre cabling in temporary camp / communication infrastructure setups too, with ruggedized cables and connectors. There's 50+ years of history and experience to source from.
"Counter" answer: copper cables in cars also break.
https://defence-blog.com/drones-guided-via-cables-change-bat...
Maybe they should add some efficiency in to the protocol, via their newly obtained cross-discipline expertise.
And the protocol shall have no logging capabilities.
To DOGE.- /s
Dashcams just use regular USB-C with HDMI or DisplayPort.
And the electronics for this are cheap, plentiful and reliable since it is used extensively in hobbyist circles e.g Raspberry Pi. No need for anything proprietary or crazy. Just run another cheap cable.
I really hope the industry sits this one out or, if needed, comes up with something better.-
The new CAN looks to include tried and trued protocols that have existed for a while but would allow for a much better system.
The combustion engine was tried and trued and didn't need changing until someone decided to do something better and electric engines are better.
(Ex model S owner - would never touch another thing they went near again)
This article for example was written to debunk Mark Rober's video on Tesla and collision avoidance: https://www.notateslaapp.com/news/2609/new-wile-e-coyote-wal...
But the arguments made against it seem quite biased towards Tesla: "However, this entire test scenario is so out of left field… there is a good likelihood this same test would fool some human drivers as well"
When one of the major arguments of the video was about easy and affordable it was for the average LIDAR system to detect the wall. Of course human beings are not perfect drivers, which is why Tesla's attempt at mimicking human senses for its self driving capabilities is a bad idea. But the article seems completely ignorant of this IMO very clearly stated narrative in Mark's video.
The argument seems to be that running the test with FSD rather than Autopilot lead to much better results:
> During this test, many people noted that Mark was using Autopilot rather than FSD...Creator Kyle Paul over on X made a much better follow-up video, using both a HW3 Model Y as well as an AI4 Cybertruck. In a relatively unsurprising turn of events, the Cybertruck was successfully able to detect the wall, slowed down, and came to a stop. The Cybertruck was running FSD 13.2.8.
That seems like a valid point. Saying that you're testing Teslas self-driving car and not actually testing FSD but opting for the less advanced Autopilot feels misleading.
It's what Mercedes pioneered, and what most high-volume manufacturers standardized on, including most Japanese and American brands. Some European companies like Volkswagen-Audi Group uses something else. I think implication of that is clear.
Nissan and Toyota had been shipping cars with automotive Ethernet since as early as 2019. Including Toyota's Hydrogen EV since at least 2022. I think implication of that is also clear.
> Tesla replacing common bus with wide range of somewhat interoperable tools with own proprietary bus no one else will be able to talk to