Why would not having shielding save copper? Shielding is usually made out of a metal foil or mesh, often aluminium. I've never seen shielding out of copper.

The NSA (read money is no object) has copper in the windows of its main building to shield them from TEMPEST style hacking.

These are 2 fundamentally different things. In twisted pairs, shielding is there to prevent interference from changing a signal. In TEMPEST protection systems, shielding is used to prevent radiance of transmissions that could be intercepted. While there is some overlap in conductive materials that could do both (prevent interference AND radiance), the methods employed and benchmarks used to measure performance differ significantly.

Sounds like money well spent

It is actually. I've seen hazy images recovered from your monitor by collecting the radio emissions of the cable. The signal traveled through windows, walls and an airgap of about 15 meters. The antenna used in that attack was only about half a meter long I think. I imagine you could put a much bigger antenna (or a dish) inside a van in the parking lot and spy on some analysts or something...

A good-sized antenna at range works, and so does a tiny device at close range! There are Van Eck listeners small enough to conceal completely that can still eavesdrop table-to-table at a cafe. The conference debut involved hiding one in a piece of pita bread, where it could sit right out in the open.

https://t2.fi/tag/van-eck-phreaking/

It's possible to collect it from status leds for instance: http://www.applied-math.org/optical_tempest.pdf

Jeez, at this point we might as well assume you can collect information from anything. I bet someone has made something that can restore the image on your screen by the vibrations on the windows that the sound of the power supply makes as the data flows in.

I think the copper savings in 1000BASE-T1 come from running GigE over a single pair versus the more-typical 4.

Has this become standardized yet? I've got a bunch of multi-drop CAN stuff that I would LOVE to move over to single pair ethernet with multi-drop a la 10BASE2. Unfortunately I haven't see a 10BASE2 compatible PHY in 20+ years.

IEEE had a working group on this but I hadn't seen any actually shipping chips that mortals could get their hands on.

(Edit: Apparently still vapor. Still can't find a source for the Marvell 88Q1010 & 88Q2112.)

(Edit: Only thing available seems to be this which is almost certainly some gigantic FPGA solution ... https://beyondstandards.ieee.org/connected-vehicles/intrepid...)

If you're OK with 100 mbps point-to-point over a single wire pair, there's stuff like the TJA1100[1].

10Base-T1 might be a real thing someday. You might just want RS-485.

[1] https://www.nxp.com/docs/en/data-sheet/TJA1100.pdf

What are your bandwidth and latency requirement? More than once I've pondered 6LoWPAN over RS485 using token passing.

My biggest problem is software stack performance--not physical layer performance. Most protocol stacks in the embedded space other than TCP/IP are mind-blowingly bad.

Being able to obliterate USB, CAN, and RS-232 (to a lesser degree--RS-232 is really reliable but the problem is generally in frequency drift if you don't have a crystal anywhere) in all of my designs and replacing it with ethernet will dramatically improve the reliability of my hardware. The only places I don't currently have ethernet in my designs are where I'm limited to a single pair of wires.

As for RS485, it doesn't really offer me anything that I don't already get with CAN.

What do you work on?

Lots of industrial stuff related to various types of testing. Performance matters some, but I'm not hard real-time.

However, everything has to work, reliably, in less than ideal environments--mostly high-voltage spikes caused by differences in ground potentials.

USB is a PITA because while data is differential, connection detection is not. So, spikes cause USB disconnects and drivers never cope with that.

CAN is a PITA because it is limited to 8-bytes per message. Good for transducers and 8 bit microcontrollers--not so good for complex control and 32-bit microcontrollers.

Ethernet hits a really great sweet spot of fully-differential and nice single packet size for a 32-bit microcontroller--program like it's 1989, baby.

I absolutely agree that Ethernet is ideal and the correct solution for modern systems. Have you worked with EtherCAT at all?