Single Pair Ethernet (SPE) – a leap forward in technology (2020)
digikey.com
digikey.com
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:
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.
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.
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.
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.
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.
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.
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.
Marvel claims their 88Q211x PHYs can do that. No auto-negotiation.
[0] https://www.marvell.com/content/dam/marvell/en/public-collat...
[1] https://www.semiconn.com/ep91h1 [2] https://en.wikipedia.org/wiki/Telephone_hybrid
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.
There's really no goal for these to do anything other than PtP with these solutions.
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.
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.
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?
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.
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.
> 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.
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.
(Although it is an 18 month old article, so things may have changed since).
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.
>Most likely not. In the current state of development and standardization, SPE transmits 1 GBit/s only up to a distance of 40 meters. 8-wire Ethernet, however, up to 100 meters transmission length. In addition, a large number of interfaces and devices would have to be converted, which is not necessary. Ethernet via just one pair of wires is used where advantages arise through enormous space and weight savings. These are, for example, applications in the railway industry. Here, less weight means enormous cost saving potential.
Interestingly as I was looking up at single pair ethernet, there was even a standard for 2.5Gbps and 5Gbps Ethernet to bring Single pair working within 15M.
[1] https://blog.siemon.com/standards/ieee-p802-3ch-multi-gig-au...
The relevant standard is IEEE Std 802.3ch™‐2020 [1] This is actually the automotive standard for 10Gb/s over a single pair, but the industrial version seems to be the same thing with different connectors. The relevant section is 149.1.3, "Operation of 2.5GBASE-T1, 5GBASE-T1, and 10GBASE-T1".
It's a single twisted pair of wires, but with a grounded shielding braid. It's not an unshielded untwisted pair, like DSL, or unshielded twisted pairs, like CAT 5 and up. The shield is grounded through the connector. That keeps the noise level down to where 10Gb/s can work. The cables will be more expensive and will be harder to make up than CAT 5, etc. Cable length limits are rather short.
It uses a modem, of course. The basic signal is 4-level pulse amplitude modulation. There's echo cancellation, so sending doesn't blind receiving. That's how it does full duplex over one pair. One end is master, the other is slave, and this is negotiated automatically at startup. The master end provides the bit clock, and the slave end synchronizes to it. That simplifies echo cancellation; the interference is the same on every bit. (OK, symbol.) At startup there's a link characterization process, where each end finds out exactly what voltage levels it is getting from the other end, and adjusts for that. That's called "training" for historical reasons. There's 340 bits of forward error correction, because crosstalk from other cables might be a problem.
Although this is nominally a baseband system, actually all the information is in the 1GHz - 4 GHz part of the spectrum. The data is, as with most modems, XORed with a cyclic scramble pattern to eliminate the DC component. That leaves room for DC power over the same wires.
One cute feature - if the two wires are reversed, that's supposed to be detected at startup and corrected. But the connector, which came after the PHY layer spec, isn't reversible.
[1] https://standards.ieee.org/ieee/802.3ch/7058/ Requires an IEEE account.
You could trivially chop the 1000BASE-T standard down to 1 pair and get 250Mbps full duplex. That would be similar to what SPE does. Everything you just described applies to bog standard 1000BASE-T too - PAM, echo cancellation, error correction, scrambling, etc.
That topic reminds me of the interesting visualization posted for GPS 26 days ago: https://ciechanow.ski/gps/ (see "chips")
With the power over data line standard, it could be super easy. One side has a power input, a rj45 connector and a two pin screwdown (or whatever), the other side just the rj45 and the two pin. There's a product out there that's using an analog hybrid to run 10baseT over a single pair, but my run length seems to be just a bit too long for it to work.
Then again, for a gate controller, I would probably prefer to see if it used 900/433mhz and do that instead directly from the house instead of doing a 5GHz bridge. You could also use the existing pair as a serial bridge, or even an antenna for the 433/900.
0: https://store.ui.com/collections/operator-airmax-devices/pro...
There is and there isn't. The gate controller does have power, but the manual says not to tap into it, and it's fed low voltage a/c from a transformer elsewhere. The SDSL modems are usually too big to fit inside the box with the controller too (and it's metal, which makes wifi not an option). And, of course, it's only nice to have, so limited desire to make things fit or drill holes for antennas.
https://bitlair.nl/Projects/Ethernet_over_phone_cable
https://forum.openrov.com/t/teardown-of-a-homeplug-adapter/3...
https://rovmaker.org/product/tether-interface-board/
etc, HomePlug has been widely adopted in the ROV building community
Domestic, so <20m runs of cat5e/cat6. Don't need more than 100mbps per host.
[1] https://phytools.com/products/100base-t1-media-converter
0: https://store.ui.com/collections/operator-airmax-and-ltu-acc...
[1] https://store.ui.com/collections/unifi-network-switching/pro... [2] https://store.ui.com/collections/unifi-network-wireless/prod...
A proper 4-end-device-port media converter:
https://www.amazon.com/NETGEAR-5-Port-Gigabit-Ethernet-Unman...
I can't seem to find any charts (BW vs length) for SPE.
Damaged a CAT-8 a little while ago, trying to pull it into my office.
The best future proofing thing you can do in a living house is lay down at least x2 cable per drop.
I did an Y-splice for three computers, without switch/hub, it worked.
I saw a damaged link with 50% loss on 3com 905 on the server end, RDP was unusable. Replaced with RTL8139 (other side was the same lost to time noname unmanaged switch) - less than 5% loss with ICMP ping. RDP worked fine.
Not the best solution, and usually quite pricey, but it works. If your power cabling is not from 1900 too. *grin*
IIUC (this is speculative presumption, the worst kind :P) the Ethernet port may use a form of USB, or at least what looks like a USB-like connector, possibly to provide power to the module so it can do its <proprietary>-to-Ethernet thing. (I am of course boggled at how the proprietary thing is cheaper than just adding Ethernet full stop.)
It would seem sufficiently low numbers of users want an Ethernet port that this strategy is actually cost effective. I'm a little surprised at this to be honest, all the CPE (consumer premises equipment) junk/ewaste I've ever seen is typically littered with 100/1000Mbps Ethernet ports (usually four), regardless of Wi-Fi capability.
And this is not to mention the fact that StarLink is touted as a low-latency network, so wouldn't it only make sense to proactively maintain that status quo over the last few feet?
I definitely would get just a tad uncomfortable if I were ever handed eg a Wi-Fi only fiber modem...
I think their hope was that if the cord were to be yanked with enough force, it would not damage the expensive dish module and force the customer to mail that whole thing back for repairs.
If you yank hard enough on an RJ45 cable, it will probably damage the female jack. That jack is cheap and can be replaced, but not by customers in the field.
The dongle doesn't appear to have any kind of retention clip, so it should just yank out without any damage to anything. And if the dongle gets damaged it's cheaper and less expensive to ship overnight than a whole new dish.
This is just my theory.
The square Dishy v2 ships with no ethernet ports btw; you're supposed to use the proprietary cable between their router and Dishy, then use WiFi to the router. Yes, everyone hates it. You can buy an ethernet adapter for cheap but it's a few weeks to get it shipped. Speculation is this is all related to a parts shortage.
Details on the proprietary cable: https://www.reddit.com/r/Starlink/comments/s0rih3/gen2_dishy...
If you have a situation which needs relatively high-speed short-range networking between subsystems and is space-constrained for the wiring -- inside a vehicle, mostly -- these will be helpful.
Fiber is great at everything except installation and robustness, and if you know the distance you'll be going and/or can coil up extra, installation is solved with pre-terminated connectors.
Would be really cool if there were prefabricated Ethernet-to-<this> boards out there.
A quick check of Amazon finds 100Mbps Ethernet to fiber adapters for around the $20-40 range, but that doesn't cover the cost of the (mainstream) fiber cable they use.
- BASE-T1 PHYs and connectors are going to be more expensive than cheapo BASE-T PHYs and RJ-45s for a while.
- The entire industry is based around BASE-T, try finding off-the-shelf mobile imaging hardware (or other embedded sensors) that supports BASE-T1.
- BASE-T technology is less fragile, ultimately a single pair is more susceptible to signal loss / reflections and needs more complex encoding/transmission schemes to overcome this. (For example, 100BASE-T uses 25MHz, two states, four pairs. 100BASE-T1 uses a 33.33MHz, three states on a single pair. This reduces the tolerable noise floor and requires the use of better cabling. 100Mbit ethernet is damn-near indestructible I've found. (There is another alternative here which I will get to in a moment).
Despite these issues, SPE's benefits will win out for mobile applications that have Size and Weight requirements. GigaBit speeds (or even up to 10 gigabit) on a single pair is just too damn tempting and can translate directly into better products. Want an example? Imaging you're making a payload for a drone; you probably use slip rings and your electrical contacts are limited. Using SPE means you can cram more data down the same slip rings, resulting in higher resolution imaging compared to a competitor using standard ethernet.
My understanding is that 10BASE-T1L is designed for long reach applications like factory automation, to connect between clusters of devices using 10BASE-T1S (all sitting on the same pair of wires). 100BASE-T1 and 1000BASE-T1 are for ideally for mobile applications.
Anyway this is all theoretical, it so happens that I run a hardware startup called BotBlox where I design compact ethernet hardware. I've designed a compact 1000BASE-T to 1000BASE-T1 converter, partly as a working prototype to get used to this technology. I believe there needs to be affordable, compact bridging hardware BASE-T and BASE-T1, and I intend to develop it.
My current tests with 1000BASE-T1 is that the range is not near 40m, I managed to get around 10m before it dies. I need to do more testing on this to see whether it's the cabling, and the firmware I made.
I have a 10BASE-T to 10BASE-T1L board in manufacture because I'm ridiculously excited about the prospect of 1.6km copper transmission. We'll see how this goes.
Anyway, there's a link below. The chip shortage has destroyed my ability to scale up on this board, hence the high price. I expect once chip shortages abate, achieving a $100 price point on this kind of board is achievable.
https://www.botblox.io/products/tiny-single-pair-ethernet-co...
The encoding scheme here is OFDM, aka, break the signal down into multiple signals at different frequencies, and send it down the wire.
It's more robust than SPE, but it requires more costly and larger ICs than SPE. When you can define a connector and cable, SPE is still better in terms of cost and size I believe.
G.hn could have its uses in retrofitting older wiring systems.
What's this "standard ethernet"? Would that be the "standard" version that used fat coax and multidrop? (which happens to be two-wire)
I thought the essence of ethernet was the protocol, not the physical transmission media. You could set up an ethernet circuit using sound waves, microphones and speakers.