10BASE-T1S is the missing Ethernet link for automotive communications
analog.com
analog.com
Astonishingly, not only did it work the first time, it worked well enough to stream video. I'm hoping to see a more standardized PoDL interface crop up so that I can use two wires for data and power combined, for lower-power subsystems.
There's a lot of application for this standard, I hope it catches on enough that I can keep buying chips for it for a long time.
The reason I wanted to use it is power consumption. I had previously planned to use 100BASE-T (normal 100Mbps ethernet) in a robotics project but it turns out that it uses about 0.8W per port (1.6W per cable) so it was using by far using more power than my various microcontrollers. Faster ethernet uses even more power. There is a standard for low power ethernet but it's not a huge improvement and you really have to go out of your way to select components to use it.
I ended up using CAN, but it will be really nice when these standards become well-supported.
IEEE802.3da is working to add PoDL on 10Base-T1.
objective 9. Specify optional plug-and-play power distribution over the mixing segment
objective 10. PSE shall only energize the mixing segment when at least one PD is connected
objective 11. Support addition and removal of a node or set of nodes to a continuously operating powered mixing segment
And also, its approach to time-division multiplexing is more like DOCSIS cable modems, where a schedule determines whose turn it is to transmit.
So it's going to be cheap and high utilization, and the max latency will be under control, but the min latency might not be wonderful.
There are lots of thing, which distinguish it from the good old Coax days with required proper termination of 75 Ohms.
Not requiring termination definitely seems like a good thing. Somehow they're always fiddly.
more seriously, this is ethernet over a single twisted pair. fascinating.
https://en.wikipedia.org/wiki/Ethernet_over_twisted_pair
There is another interesting one 10BASE-T1L up to 1km.
The main warts in the standard are dynamic PLCA node ID allocation and the fact that PoDL is undefined for non-point-to-point topologies, besides how odd it is to implement SCCP for PoDL.
I've been thinking that a way around the PoDL aspect is to ignore SCCP and to just use periodic square wave pulse trains with a certain frequency to indicate to the PSE that it should switch power on. Basically an "I know what I'm doing" indicator to prevent sniffer adapters and unterminated connections from being provided live DC voltage.
It's also possible to have another set of emergency stop signal wires side by side with the digital communications in case there's an issue.
--------
My understanding is that 10BASE-T1S is a replacement for CANbus. Whatever CANbus does, 10BASE-T1S should do it better. It happens to be Ethernet (albeit a much slower Ethernet), but Ethernet/IP/TCP is something modern programmers understand better than UARTs / CANbus.
That said, both technologies are just prototypes and expected availability is in about 3 years.
OnSemi claims to have a production 10Base-T1s MAC-PHY now.
https://www.onsemi.com/products/interfaces/ethernet-controll...
10BASE-T1S is also kind of interesting in the same way, especially if it's potentially possible to use an existing linux network stack on top of it.
This different to all other Ethernet-based solution, which requires some sort of switch either central or distributed within each device. When something fails here, it has much deeper impact. About 5 years ago GM thought about this and required switches within each and every device. Then signals should be transmitted redundantly parallel over different links. The problem here is the proper dedublication and verification of the data. Because that costs ressources in terms of time and compute power and memory.
https://www.panduit.com/content/panduit/na/en/landing-pages/...
... so, a single pair PHY layer and a connector I have not seen before ...
I don't care what you replace Ethernet RJ45 with, but make it a standard that is only used for Ethernet.
At the end of the day it's someone's job to actually run cable, terminate and test it, and attach equipment to it that people are responsible for. You have to remember that the physical cable plant is infrastructure itself whether it's connected to live equipment or not. There's already a big enough problem with people trying to do things like route display cables through buildings, for example - the workaround that I'm seeing a lot is that people are using specialized signal converters that send HDMI/DisplayPort over a pair of Cat5e/Cat6 cables, just so that structured cabling can use normal cabling/networking supplies (i.e. keystone jacks, patch panels, conduit sizes, testing/tools, etc.) without wasting so much time with planning for projectors/displays ahead of time etc.
RJ45 is for twisted pair cabling. It's not specifically for Ethernet. 802.3cg only uses 1 pair. If you use the center pair then it works for TIA-568A, TIA-568B, or USOC. It's great for experimenting since everyone already has twisted pair patch cables to play with. Barring that, just give me screws that I can put the wires into so I don't need to think about connectors at all.
See: USB over D-SUB, serial over RJ45, the wide range of proprietary protocols that cheap IDE cables were (and probably still are) use for today, and weird edge cases like reusing the sturdy DMX ports to power sex toys.
8P8C is fine for ethernet, it doesn't need replacing. Nobody uses it for telephony modems anymore and very rarely will an average user encounter a compatible plug that wasn't made for ethernet.
I'd rather see fringe use cases like serial over RJ45 use a better connector than to have to cut off, strip, and wire up a new connector for every new network appliance I'll buy in the next 10 years.
It's purely an analog device. Presumably they used USB because the cables are cheap, shielded, and have enough conductors for what they needed. (Probably ground plus signal wires for two linear pots and a pressure sensor.)
I hope they designed it so it doesn't fry something if you connect it to a real usb device, but I'm not inclined to try it.
I'm almost certain that serial has been in common use on 8P8C longer than 100BaseT.
Personally, I'll stop believing in that connector when it stops being useful.
Everyone (including me) still calls it RJ45 because "8P8C modular connector" is far too long a name.
Because in cars that are at least 1000kg, a few grams definitely matter.
I've posted this before in more detail, but the short version is that when I was working at Ford Motor Co in the late 90's I remember seeing some internal documents championing how they saved ~$200 off a production Taurus (at the time a ~$20,000 vehicle) via a bunch of $10 and $20 individual cost savings. It was a big deal, added up to real dollars.
Besides the material savings of less actual wire, you most likely have labor savings on the harness build, and possibly on the installation if the new harness is easier to install based on the reduced overall weight and complexity.
The networking methodology side would likely not be overly complex. We already have CANbus device networks, and the associated software stacks. Changing to an ethernet based approach is a well-understood transition that would not require major changes, at least not beyond the incremental updates and other things that the engineers are already likely to be working on.
Alone Ford at one point sold over 6.6 million vehicles a year.
https://hackaday.com/2022/07/27/the-surprisingly-manual-proc...
By having just one wire to transmit data and power to components in each zone it will be a significant cost savings. It also makes the various automotive engineer's jobs a lot easier.
So does that mean every PCB and subassembly/controller in a car will be daisy-chained? Would one single broken wire disable the entire car or just the downstream modules? Do you create a "backbone" down the length of the car and fan the signal out like a nervous system?
>Would one single broken wire disable the entire car
Not in this case but try shorting the two CAN bus wires together in an older vehicle.
The multidrop feature of this standard means that in a car, you could have a main harness that rarely needs any updates, and as features are added to the next model of car, most updates could be handled with a local wire harness update.
A harness mistake(s) cost Airbus billions on the A380 program.[1]
[1]https://www.nytimes.com/2006/12/11/business/worldbusiness/11...
https://buildings.honeywell.com/us/en/products/by-category/b...
The only other thing I don’t understand is if each node has the opportunity _not_ to transmit, that seems like it would cause jitter in late and see if he bunch of nudes sometimes transmit and sometimes don’t. Not sure what I’m missing
The standard should be written, and let the devices decide what speed they want to speak. If sender and receiver of a packet both want to speak 1Gbit over the link with clever QAM and adaptive channel coding, then let them do that... And if another device only supports 10kbits with a single mosfet and pull up resistor, then thats fine too...
The purpose of the standard should be to define who gets to speak when on the link, and how those speeds should be negotiated, and how devices can fairly share the capacity and be functionally compatible.
Just like the RS-232 serial standard originally was 300 bps, but now people use functionally the same protocol to talk 9600 bps, 57600 bps, 1000000 bps, 25,000,000 bps, etc... The original RS-232 standards group is long dead, yet the standard keeps going on because people can use the same spec (with a few tweaks along the way) faster and faster for 6 decades!
As soon as you give programmers something capable of TCP/IP, they'll want to send large globs of JSON back every few milliseconds...
Now your network link is full.
This has already been evaluated and re-evaluated over the past 10+ years.
https://en.wikipedia.org/wiki/SocketCAN
https://en.wikipedia.org/wiki/FlexRay
Infotainment is more likely to go with less fault-tolerant, cheaper-to-implement standards, but you can bet critical systems will never.
Here a wikipedia article https://en.wikipedia.org/wiki/Ethernet_over_twisted_pair