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.
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.
> 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.
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.
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.
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..
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.
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)
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.
I really hope the industry sits this one out or, if needed, comes up with something better.-