A deep dive into Single Pair Ethernet
electricui.com
electricui.com
1) PoDL is substantially lighter, smaller, and simpler (though not necessarily cheaper) at 1 Gb than at 100 Mb, due to the increased frequency separation. Just like with other Ethernet protocols, the lowest frequency of comms is basically DC; it's only statistically brought above that by the scrambler, but there's no useful true lower bound. Having an order of magnitude more separation, such as it is, allows a more reasonably sized filter to stomp over less (ideally, approximately none) of the data.
2) Only the 1 Gb protocol includes FEC, 100 Mb is a simpler, non-error-correcting encoding. This means that even though the maximum frequency on the twisted pair goes up by an order of magnitude to ~660 MHz, requiring better cabling, better twist spacing, etc... it allows a "sloppier" job at both high and low frequencies, since the FEC really does hide a few errors. This can be spent on even worse filters for PoDL, on frequency-specific interference (e.g. an RF amp running nearby), etc.
Basically, I was surprised to find that 1 Gb was not only not more challenging at the system design level, it was often simpler. (I haven't played with 10 Mb in either of its two incarnations seriously yet.)
This was one of those wonderful "oh of course" points for me: when you read something and it's blindingly obvious, but until reading it my intuition pointed the other way (easier to deal with lower frequencies rather than unnecessarily high data rates).
It was also a nice excuse to get some macro shots of the PCB assembly process, including some nice footage of solder paste melting and the interesting surface tension interactions.
(I can't seem to get the videos to render in a format that iOS Safari will play, if anyone knows the ffmpeg incantation, please let me know, nothing I've tried has worked on my iPhone...)
The videos worked for me on my iPhone. Always nice to see a bit of solder reflow :-)
I don't comprehend how you made no mistakes on the journey after drafting the PCBs and writing drivers. From my POV as a software developer, C has so many pitfalls that it is incomprehensible to me that things will Just Work, especially in the context of something that is meant to run for a very long time and not be "restarted."
Why do sensor things at all? What is the ROI for the person who needs that stuff? I mean this in no derogatory sense, I really admire this work.
But the academics who need something something hardware are either so rich they use something commercial / the paid core or so poor they'll use someone else's refuse or a grad student to do it 10x worse & 10x slower for free. Lab equipment, sensors, whatever.
If it's for an industrial purpose, the ultimate consumer for hardware 2 guys can make is the government, as far as the eye can see. Like the people who have a business stake in e.g. the ocean ecosystem are fishermen, oil people, shippers, whatever, and they're only doing this because of a government regulation or threat thereof or whatever. I view government needs as worthwhile, they are a worthy customer, it's that the ROI is essentially imaginary, it's whatever the payer values government compliance and that can be infinitely large or small.
My background in this is very limited, I didn't take "How to Make," I don't know how to use anything in a fablab, but in an intellectually honest way, the audience for "polished, well working gizmo with bug-free firmware" is 1,000,000x larger when it's a coffee machine than any academic or industrial purpose. Why not make "the perfect espresso machine" or "the perfect bike" or whatever? There are $3m Kickstarters for coffee machines whose #1 actual obstacle to successful execution is writing firmware. There are e-bikes that are 10x expensive or 10x crappier because ultimately it's too challenging to make a single firmware and controller to make disparate commodity parts work together cohesively.
I am not at all raining on this parade, because this little blog post was so mind numbingly impressive; and I'm not saying there aren't 10,000 people toiling on dead-on-arrival consumer hardware, be it Oculus peripherals or connected emotive robots or whole divisions at Google. My question is: why? Why not, with your skills, make a thing and fucking sell it?
> I don't comprehend how you made no mistakes on the journey after drafting the PCBs and writing drivers. From my POV as a software developer, C has so many pitfalls that it is incomprehensible to me that things will Just Work, especially in the context of something that is meant to run for a very long time and not be "restarted."
You aren't meant to make no mistakes, just only make recoverable mistakes. In a lot of cases you can rely on your hardware for this. Watchdog Timers are specifically intended for this. You set up a watchdog when you deploy the device and your software has to periodically "pet" the watchdog or the system triggers some action. In practice this is used to verify that the software never gets stuck or else it triggers a recovery/restart sequence and maybe sends out an alert. The end goal shouldn't be bug free but "even with bugs it eventually recovers and keeps working unless the hardware physically dies".
> Why do sensor things at all? What is the ROI for the person who needs that stuff? I mean this in no derogatory sense, I really admire this work.
Once again not the OP but I could see this being useful. They are recording wave patterns on or around a reef. That could be used for modelling how reefs can buffer water conditions (ex: for the purpose of constructing man made analogues) or as part of a greater sensor suite for documenting how "weather" impacts reef ecosystems.
And you would want a system you can deploy and leave unattended for long periods of time since every trip out costs money and depending on what you are specifically researching, simply returning to the site could interfere with/disrupt the experiment.
Process, design and architecture play a larger role in the bugcount than language choice.
I wrote munitions control software in C; many of the systems that would cause loss of human life were written in C for decades.
The recent meme of "if it's written in C it must mean unreliable" is inaccurate - all the most reliable systems, for decades, were written in C.
Thank you for your kind words!
> I don't comprehend how you made no mistakes on the journey after drafting the PCBs and writing drivers.
As jacoblambda said below, it's about making mistakes recoverable, and failure modes graceful. Scott put a hell of a lot of effort into planning and design, making sure in the end we could get what we needed out of the hardware. During the process, there's a constant stream of problems that are fixed or worked around in pursuit of the end goal. One nice thing about this kind of project is the scope is fixed and known, and scope creep won't happen. We can build safe guards for attaining the known scope instead of predicting future scope creep. Originally we wanted a turbidity sensor in there as well, but we just didn't have the time to get it working.
On one of the boards we reflowed, something happened with the solder paste (it was probably a bit old) and it started exploding (in a small way), sending components flying across the board. Scott had to jump in with tweezers and put stuff back in real time on the hot plate. Unfortunately I had the macro shot set up for the other side of the board so I didn't get to capture it.
Shooting the top down macro shots, it would take literally 6+ minutes for the rig to stop wobbling visually in the footage, so every top down shot is 6+ minutes of swaying footage before the action. It took so long we only did a couple of these shots.
We thought it would be very dark underwater, and brought a camera that could do 12800 ISO base, but it turned out it was actually surprisingly bright on the day, and we ended up way down at ISO 640 for the shoot.
We couldn't get the camera to focus underwater when zoomed to a focal length of 70mm, so there's a whole setup of footage that just didn't work. But since everything had already been shot at 35mm, it wasn't a big deal in the scheme of things.
The camera rig was incredibly buoyant underwater, I had to steal weights from our other divers just so I could get neutrally buoyant.
> Why not make "the perfect espresso machine" or "the perfect bike" or whatever? Why not, with your skills, make a thing and fucking sell it?
I think I can sum up my personal drive as "I like making things", essentially no matter what the thing is, be it hardware or software. I saw that "inventor" character in the movies, and that's who I wanted to be growing up. In most engineering jobs you'd probably be happy to spend 20% of your time making stuff, with the other 80% spent in paperwork. We're trying our best to flip those percentages for ourselves.
We've worked on several projects with hardware together over the years. From multicopters, to camera gimbals, to an entire space ship set for a short film. Time and time again, we found ourselves building user interfaces from scratch, and that was amongst the hardest parts. So we figured maybe there's a business here, and we started Electric UI - tooling for engineers to build user interfaces for their products, both during development and for production. Selling software must be easier than hardware, right?
It turns out it's unfathomably difficult to market products effectively to the right audience, especially if you don't have millions of dollars to blow on targeted advertising. We're constantly seeing the success stories of good marketing and we intrinsically don't see the thousands of shots that didn't work out. There's just a lot of luck involved, hitting the right people at the right times, even assuming you have perfect product-market fit.
We figured our best chance is to go back to our roots and just build stuff that we find interesting, and document the process. Hopefully people will come along for the ride, and other engineers out there will see our user interface software and the next time they're building something that could use a UI, they'll think of us.
That's going to introduce a lot of people to the joys of outdoor long wires and their interaction with lighting. I've seen the induction current from ground surge turn 25 pair cat3 into vapor ... there's fun to be had there.
I’m in New Zealand and our sun just destroys everything. The UV eats everything up and I’d not expose a cable to sunlight.
Plenty of places are hotter or have more UV but also have air pollution which blocks UV. Our relatively clear air lets the UV come ripping through.
At least sunlight won’t toast my switch though.
Other common issue with novices running outdoor cabling are people running belowground cables strung outdoors on poles in the open air - UV degradation can take such cables (or rather, their insulation) apart in a matter of less than a year. Or silicone cables that end up in stagnant water, which can dissolve them (don't ask me about specifics, but it's a hotbed of issues in PV power plants). Or people not burying their cables deep enough, i.e. below the frost line, and the ground freezing over killing the cables.
Outdoor wiring is fun for everyone involved. If anyone here wants to deal with that crap, please read up on using the correct cable for the job, and FFS have a certified electrician sign off on the grounding of such cables and surge arrestor designs and installation.
This was not mission critical so I just "went for it" and it worked out. It was a great payoff since it only took 2 days to mount all the cameras and lay the cables. It would have taken much longer to dig trenches and put the cables in buried pipes. I treated it like a prototype and figured I would improve later based on actual problems that came up.
I did make sure all of the boxes with wire connections, power supplies, and PoE switches were in waterproof boxes and I used silicone sealer where cables entered the boxes. I opened up one box yesterday and not even a cobweb!
Let me guess: unifi. I love em but I have two dead cameras because I assumed outdoor meant outdoor.
For my own outbuilding office (above our detached garage), I ran fiber to avoid this issue.
I’m about to start construction on my own outbuilding office and want to not screw this up.
If someone is trying to sell you multi-mode fiber, they're 20 years behind the curve. (No, the transceivers are no longer notably cheaper.)
If someone is trying to sell you unarmored fiber, they want another sale after rodents chewed up your first fiber ;D
For waterproofing, note there's lateral and longitudinal waterproofing. You want longitudinal, otherwise the fiber can pull water like a hose straight into your patchpanel. (It's rare but it happens.)
Cheapest source I know is fs.com, for an outbuilding office order something that comes with connectors preattached (and add a good amount of slack). Splicing on connectors by any reasonable professional calls up mind-boggling hourly rates.
I think the total cost for fiber and transceivers was under $200.
I guess ability to power via same cable is an advantage here vs having to still have separate wire (or say local solar+battery for sensor).
It's not going to be much power, that's for sure.
You might be able to get a commercial system that delivers 1 watt at 24 volts. [2]
Given the optical power required, and the sensitivity of the human retina, I'd say this is a bad idea in all but the most demanding circumstances. If you've got to send power with extreme electrical isolation(i.e. lightning strike proof), consider something like compressed nitrogen powering a very small turbine, or a rotating fiberglass shaft between motor and generator.
[1] https://en.wikipedia.org/wiki/Power-over-fiber
[2] https://www.fiberopticlink.com/product/fiber-optic-isolation...
> In addition to the more computer-oriented two and four-pair variants, the 10BASE-T1,[20] 100BASE-T1[21] and 1000BASE-T1[22] single-pair Ethernet physical layers are intended for industrial and automotive applications[23] or as optional data channels in other interconnect applications.[24] The single pair operates at full duplex and has a maximum reach of 15 m or 49 ft (100BASE-T1, 1000BASE-T1 link segment type A) or up to 40 m or 130 ft (1000BASE-T1 link segment type B) with up to four in-line connectors. Both physical layers require a balanced twisted pair with an impedance of 100 Ω. The cable must be capable of transmitting 600 MHz for 1000BASE-T1 and 66 MHz for 100BASE-T1. 2.5 Gb/s, 5 Gb/s, and 10 Gb/s over a 15 m single pair is standardized in 802.3ch-2020.[25] In June 2023, 802.3cy added 25 Gb/s speeds at lengths up to 11 m.[26]
* https://en.wikipedia.org/wiki/Ethernet_over_twisted_pair#Sin...
802.3dg is going for 100M and 1000M over distances of 500m
Given that it's not even ratified yet… no.
Does it have problems on single unbroken cable like that or it just has few patch-panels along the way ? IIRC the standard was for 100m unbroken cable, not the usual of device -> cable -> patchpanel -> cable ->patchpanel -> cable -> patchpanel -> cable -> device
* https://www.youtube.com/watch?v=kNa_IdfivKs&t=11m48s
* https://www.truecable.com/blogs/cable-academy/maximum-ethern...
With the ISO standard the length is strictly informative, and the length of a cable/run doesn't matter as long as the signal characteristics are good:
Also, AIUI, having the electrical isolation between the 2 buildings is nice.
Get a cable tester and see what the cable type/qualtiy and signal characteristics are. Or if you're near some other equipment that is high-EM (where shielding may be needed).
There is nothing theoretical about the official numbers with a quality install:
* https://en.wikipedia.org/wiki/Ethernet_over_twisted_pair#Var...
In the ISO/IEC structural cabling standard the length is strictly informative, and the length of a cable/run doesn't matter as long as the signal characteristics are good: you can have a 130m run and a tester will not pass-fail based on the length, but on the signal quality:
Something to note is that it has a much lower bandwidth requirement than 10BASE-T, because 10BASE-T uses manchester encoding with two symbols per bit (either 01 or 10). So 3.75MHz of bandwidth versus 10MHz of bandwidth.
It's mindboggling how many different ways there are to communicate with microcontrollers, sensors, etc. So many different standards with different data rates, capabilities, features, etc.
It's cool to see something like ethernet be able to be used in rough situations like this. I'm sure this is done already with some technology, but I'd love to see a buoy with solar/wind and batteries for power, with a tether going down into the water to supply power and data for sensor arrays underwater. Trying to communicate through water is tough - I even looked at acoustic modems to try and transfer data but it looks like they haven't gotten down to consumer/tinkerer level of electronics yet.
Single Pair ethernet with power seems very complicated for a fairly ignorant but interested hobbyist haha
https://discourse.odriverobotics.com/t/can-bus-signal-noise/...
I understand there's even linux drivers for some hardware for the RPi.
As they say, motors and engines cause a lot of local noise....
And I can't tell if any of them are compatible. I think da is compatible with cg, but the others are all little islands, all serving very similar needs in mutually-frustrating ways.
Whyyyyyyyyyyyyyyyyyyy?
- 802.3bu specifies PoDL (power over data lines).
- 802.3bp specifies 1000Mb/s over SPE (single pair ethernet)
- 802.3bw specifies 100Mb/s over SPE
- 802.3cg specifies 10Mb/s over SPE
- 802.3da is an enhancement of 802.3cg.
Modern WiFi has a very long list of 802.11 standards attached to it... My WiFi access point supports all of these:
- 802.11a
- 802.11b
- 802.11g
- 802.11n
- 802.11ac
- 802.11ax
SPE is not intended for home users. The SPE standards are designed to make things easier for automotive and industrial applications, and they seem fine. Automotive needs are not the same as industrial needs, so flexibility in the standards allows them to meet the specific needs of each application better. It also allows them to remove unnecessary weight and complexity. Weight reduction is one of the main reasons automotive is interested in SPE.
SPE has no obvious advantages for home users over something like Monoprice's Micro SlimRun cables, which are extremely thin and flexible, for example. So, it makes sense that they haven't put effort into giving it cool branding like "WiFi 7".
PoDL does have real advantages over PoE. I agree that there's no home-user-ready products at this point, but I could see future exploration of this space for that reason alone.
I'm curious, what advantages are you thinking of? PoE++ can deliver more power than PoDL, last I checked.
I guess the option for lower voltage could be nice in some very specific applications? I think the minimum for PoDL in the spec is 12V, which would still require conversion for pretty much any use case.
It does, I already have a single twisted pair running in the walls of a building where it is hard to run new cables but I can't get more than 100Mb/s at the moment.
Using existing wiring is always a use case, a lot of people use MoCA or PLC because they can't run new cables for whatever reason.
But as you said, unfortunately SPE is strictly for industrial applications at the moment and there is no affordable product for consumers.
The 100mbit and gigabit variants of SPE require higher grade cabling than their multi-pair counterparts. 1000BaseT1 requires Cat6A, which would normally be needed for 10 gigabit. It is very unlikely that you have a single pair of Cat6A grade wiring available, or that anyone does anywhere.
They're not really for reusing existing wiring, they're for reducing wire count in new harnesses in automotive, aerospace, and other applications where size/lightness matters.
The 10 mbit SPE varieties on the other hand, those are more closely targeted at reusing existing wiring, but they mean the sort of wiring that might have previously carried CAN or other common control bus.
Seems plenty useful if you could actually buy that stuff for the home-user-tolerable pricing.
Connecting and powering 4 different devices over single ethernet cable is a very nice use case for various sensors.
Hell, even for IoT, ethernet/IP is pretty simple protocol compared to BT stack, wifi+ip, or zigbee, just plug in and power your sensor/switch/relay with 2 wires directly into local ethernet network, no bridges needed, and pretty safe too vs any radio.
If you have multiple clusters of devices, I can see that.
But in most cases I feel like a bunch of thin cables will be significantly less hassle than trying to split things.
Currently option is to get a PoE-powered switch and split it off that way which is extra device to manage.
I kind of want to run SPE over old coaxial cables that are quite commonly found in relatively recent houses. Add a cheap ESP with I2S, an I2S DAC and a speaker, and you get a smart multi-room speaker setup.
Because they're built for different roles with different requirements, but in all cases are expected to be used for specialized applications.
The 10 megabit SPE varieties are mostly intended to be able to be used on existing wiring in commercial/industrial applications where older hardware is being upgraded but replacing existing wiring might not be practical. The two varieties let you pick between long distances (10BaseT1L) or the ability to connect multiple devices to a single network segment like old school coax ethernet (10BaseT1S). There are also use cases for the short range variant internal to machines, where it can in many cases run over the same harness one might have run CAN over.
The 100 megabit and gigabit variants don't care about existing wiring, they're there to move a lot of data over as few wires as possible so harnesses can be light, thin, flexible, cheap, take your pick. Automotive infotainment and high bandwidth industrial sensors are the obvious target markets.
You aren't expected to ever need to mix and match between these variants. While more than one could plausibly be found in the same system it'd be rare for there to be any need to mix and match hardware between the different forms. If they need to talk to each other you stick a bridge/switch between them the same way you would have when transitioning from coax to twisted pair ethernet.