Forum - Recent Threads

[Part 5] Advanced Dashcam and Monitoring System – Single Pair Ethernet Integration, Battery Controller, Car Wiring

vmate — Thu, 02 Apr 2026 21:51:13 GMT

Overview

It’s finally time for Single Pair Ethernet, along with a custom battery management and charger control PCB.

The Single Pair Ethernet link will be used to connect the subjects of Part 2 and Part 3, aka. the glovebox mounted Compute Unit, and the battery and charging system in the trunk.

Charger Controller Board

This PCB will be housed in the big grey box mounted on top of the battery. Its responsibilities are the following:

Communicate over VE.Direct with the Orion XS (50A charger) and SmartShunt
Control the heating elements in the battery
Control and monitor fans based on temperature of various components
Communicate with the Compute Unit over Single Pair Ethernet
Communicate with the Bluetooth BMS inside the LiFePO4 battery

VE.Direct communication

This is Victron’s custom protocol for communicating with their devices, but electrically, it is just a simple UART, at either 3.3v or 5v. Hooking this up to a microcontroller is trivial, except for potential level shifting and isolation.

I decided to use ADUM1201 dual channel isolators, as they also provide level shifting, and prevent any dangerous oopsies related to ground paths.

Heating element control

As shown in Part 2, the battery contains two resistive heaters and DS18B20 temperature sensors, needed for preheating in cold weather.

Driving the heating elements is quite simple: just a low side FET per heating element. However, I didn’t want to waste a bunch of IO on my ESP32-S3, so I used an EMC2305 fan controller IC. This has 5 PWM outputs and 5 tach inputs, all controlled and monitored over I2C.

I hooked up a fifth low side FET to control a two wire fan, in case I need to use one of those.

I also added a few OneWire headers to hook up the DS18B20 temperature sensors.

Fan Control

The board supports two 12V, 4-pin fans, using an EMC2302 for control and monitoring. This chip is essentially identical to the EMC2305, except for channel count.

Interfaces

For debugging, I wanted to add USB, but to be safe, I made it isolated as well. My choice ended up being the ADUM3160, which is a USB1.1 isolator IC.

Having a CAN bus interface is always useful, so I added an isolated one for good measure. The choice for this was the ADM3053, which I also used on the Compute Unit, to later hook up to the car’s CAN network.

DC-DC Converters

I found a really nice looking buck converter IC some time ago from TI, which I wanted to try out.

The TPS543021 is a 4.5V to 28V input, 3A buck converter IC, which is very cheap (around 60 cents per piece in quantities of 25) and simple to use, and is reasonably easy to solder (although it is quite small with its SOT-563 package).

The BOM cost for a single buck converter, including the inductor and passives, ends up being around 1 USD, so if it works well, this will definitely become my go-to buck converter IC for general purpose applications.

Microcontroller

As mentioned earlier, I went with an ESP32-S3 here too. I needed Bluetooth capability, and it makes sense to use the same MCU as in the Compute Unit, to make code reuse easier, and be able to focus on mastering a single device.

The PCB

I sprinkled on a generous amount of TVS diodes, and designed this board.

The fan and heater control is in the bottom, power supplies in the middle, MCU at the top. The Single Pair Ethernet transceiver is not on this board, as I didn’t have enough space for it, so I just added an 8 pin JST-PH connector, and a separate PCB will have the ADIN1110 and various other SPE related components.

Single Pair Ethernet PCB

While the supplied kit includes an ADIN1110 development board, the ADI devkit is massive physically, and is full of features I do not need. Since I was ordering a custom PCB anyways, I tried my luck designing a minimal and tiny Single Pair Ethernet module, that I can use in future projects as well.

This is the schematic I ended up with:

And here’s the PCB design:

The finished module:

I hooked up my newly built module to the ADIN1100 devkit suppled for the challenge, and thankfully got the Link light lit up on both boards. This is a great sign, and almost guarantees that everything is working perfectly.

The size difference between the two boards is incredibly obvious (although this is the ADIN1100 dev board, and not the ADIN1110, but they have the same dimensions).

I had a Pi Pico on hand, so I used that for some quick testing.

Testing the boards

I hooked up the ADIN1110 module to the Charger Controller PCB, and connected the SPE jack to the ADIN1100 dev board.

The ADIN1100 board itself was connected to my PC through ‘regular’ ethernet, so I could use Wireshark to see what data was being sent over SPE.

I wrote some minimal testing code for the ESP32-S3, that sent a few frames of data through SPE. I forgot to save either the testing code, or images from Wireshark, I apologize for that, but I’ll have some cleaned up code in the next post.

Installing the PCBs in the Charger Box

This part was quite straight forward, I just had to make a few JST-PH and JST-XH cables to connect everything, and drill a hole in my box for the Single Pair Ethernet jack.

Adding SPE to the Compute Unit

I made a second ADIN1110 board, and printed a top half for the Compute Unit.

Wiring the car

The next step was wiring up everything in the car for the charger. This involved routing the Single Pair Ethernet cable from the trunk to the glovebox in the front, and also installing a robust, 40A capable 12V source for the charger.

To do this properly, I added another grey box, housing a relay, and some fuses. The purpose of the relay is to only supply 12V to the charger when the engine is running. Technically, this is not required, as the Orion XS and our Charging Controller board both implement a low voltage cutoff, but better safe than sorry. This also provides a simple way to hook up other loads later, like a high power laptop charger or cabin heater in the winter, if I ever decide to add one.

The thick blue cable exiting at the top is the 12V input to the Orion XS. It is not fused in this box, to prevent unnecessary voltage drop. This is safe, because the entire setup got a 40A fuse, right at the battery terminals.

The smaller blue cable exiting at the top is for my subwoofer, which got a second, 20A fuse.

Next up, mounting the cameras. I had quite a lot of trouble with USB3 interference for the front camera, mainly regarding the GPS setup. The solution ended up being a very fancy, USB3.2 Gen2 cable, with USB-C connectors on both ends.

The rear and side cameras are only USB2, so I didn’t have any issues regarding those.

I added a 2J Antennas 2J4950PGF antenna to the windshield, which includes one 4G antenna, one 2.4/5GHz antenna, and an active GNSS antenna.

The cabling for the antennas and front camera were routed down the A pillar, to the glovebox.

With everything wired, this is what I got in the glovebox:

I temporarily added a USB connection to the Charger Control PCB, so I can debug the ESP32. This will be removed once the firmware is up and running, and all communication and firmware flashing will happen over SPE.

Conclusion

After confirming that everything was wired properly, and running some test code for the SPE link, the hardware is essentially finalized. All that’s left is to write a lot of code to make everything work, which will be shown in the next, final blog post, along with a summary of what happened so far.

The TPS543021 performed great in my testing, so it is definitely becoming my go-to buck converter for custom PCBs.

[Part 4] Advanced Dashcam and Monitoring System - Cameras

vmate — Sun, 29 Mar 2026 23:36:24 GMT

Overview

Next up is planning and selecting cameras. This is quite an interesting topic, but there’s relatively little to show, so this post will be a bit shorter, with less images.

Picking the sensor

The most straight forward starting point is to pick out the sensor we want, and then build around it, so let’s get into the important specs.

When talking about sensors, there are a few common specs everyone is familiar with. Namely, these are resolution and framerate. Interestingly, we don’t really care about either.

The dashcam setup will be severely video bandwidth limited, so we actually want the least number of pixels and framerate, to minimize how much the video encoder will chew up details.

In my quick experiments, roughly 1080p-ish resolution, at 15FPS would be a decent target to work with. That’s about 2MP. Pretty much every single modern sensor can do that, so this is not much to narrow our search by.

Now, let’s talk about the more interesting specifications. There are two that we care about a lot: low light performance, and dynamic range. Low light performance is straightforward, the car will be parked at night, the camera needs to be able to see in darkness. Dynamic range is more interesting.

Imagine trying to take a photo of a dark object with the sun in the background. This is close to impossible with a regular camera. The extreme brightness in the background requires the sensor to turn the exposure down, so that nothing is blown out. However, that also makes the dark object completely disappear. Manually exposing the dark object will result in the background being so incredibly bright, that it completely clips and just looks like a white blob.

The issue here is dynamic range. The camera cannot simultaneously capture the tiny differences in light on the dark object, while there’s a massive light source in the background.

To combat this issue, several methods exist. The sensor can be made just really really good, and have inherently great dynamic range, but that gets very challenging very quickly, so trickery is needed.

The most common method is multiple exposure HDR. The idea is to take a bunch of separate images with different exposure levels. One image will have the bright object perfectly exposed but the dark object too dark, one image will have the dark object perfectly exposed and the bright object overexposed, etc.

Then, a fancy algorithm can be used to merge all of these images into a single one, where all of the varying brightness objects are properly exposed.

This method works fairly well, and is very widespread. However, there’s one massive issue: as a single frame is constructed from multiple exposures, motion blur or ghosting can happen. If any movement happens between the individual exposures, the final image will be messed up. There are algorithms that try and correct for this, with varying results.

Ultimately, this is a no-go for my dashcam.

There are quite a few other methods to achieve high dynamic range, with various tradeoffs, but let’s jump to the one that fits my use case the best: subpixel HDR.

The idea is simple: instead of the sensor being made up of a bunch of equal pixels, let’s make multiple different sizes. The small pixels will be less sensitive to light, and the large pixels will be more sensitive. This means the sensor can take both an “underexposed” and “overexposed” image at the exact same time, preventing the motion artifacts.

There is a great article about this on e-con Systems’ website, with actual images and comparisons to multiple exposure HDR.

https://www.e-consystems.com/blog/camera/technology/everything-you-need-to-know-about-split-pixel-hdr-technology/

Going for subpixel HDR narrows down our sensor options from tens of thousands to a handful, mostly from Sony. My choice ended up being the Sony ISX031. This is a 1920x1536 30/60FPS sensor, but most importantly, it has a built-in ISP.

Image sensors don’t just magically output an image. The data needs to be processed in several ways, autoexposure and white balance need to be continuously adjusted, etc. This is an incredibly complex task, handled by an Image Signal Processor.

Developing and tuning an ISP is basically black magic, and it needs to be fine tuned to a specific sensor or use case. Typical camera modules also tend to have very bad ISPs that don’t just lack the magic, but are actively horrible.

The integrated ISP in the ISX031 solves this issue: it’s specifically made and tuned for the sensor it’s contained within. The sensor’s output is a preprocessed, beautiful, high dynamic range image, with no adjustments to worry about. It also has an LED Flicker Mitigation feature, which uses magic to make flickering LEDs not flicker on video.

The ISX031 also happens to have amazing low light performance, so it is the perfect choice for my dashcam.

The camera interface

Next up is picking what interface to use for connecting the sensor to the Compute Unit, which the previous blog post was about.

The native output interface of the sensor is MIPI. It works great, as long as you have short wires, which I don’t. Let’s see what options we have.

Stick with MIPI all the way through, and get some heavily shielded cable to make a 3 meter run work: this is the simplest solution in some ways, but the most painful in some others. MIPI-CSI requires at least 3 high speed twisted pairs for this setup, plus a handful of low speed communication signals. Signal integrity, and interference caused are a major issue with this setup.

Use a USB camera module: these modules use a MIPI to USB converter IC (or probably an entire cheapo ISP, that has most of its features turned off) to immediately convert MIPI to USB before any signal integrity issues can pop up. There are two big problems with this:

the terrible ISP scenario is still a pain, as we will lose even the small amount of control we have over the ISX031, because the cheapo ISPs don’t properly expose controls over USB.
USB is problematic in itself: the ISX031, in its full resolution output mode, generates over 350 megabytes per second of image data. That is around 8 times faster than what USB2.0 can do. USB3.0 can handle it just fine, but it brings its own signal integrity and noise issues, so we’re back to square one. (USB3.0 actually uses higher signaling speeds than MIPI, for this specific sensor)

Go the proper route: GMSL or FPDLink. These are the actual, reliable, proper solutions for my problem. Put a small GMSL/FPDLink serializer IC near the sensor, pipe MIPI into it, attach a coax or a single twisted pair cable, run that for as long as you need, and put a deserializer at the end to get back MIPI. The problem? Money. In single digit quantities, those two ICs cost well over 50usd. I’d also need custom PCBs, and probably spend a bunch of time debugging things. This would definitely be the proper solution, but it requires both time and money, neither of which I have at the moment.

I went searching for ISX031 camera modules, and I found the Arducam B0476. It’s a USB3.0 module with a 118 degree horizontal FOV lens. That settles our interface question, because I couldn’t find any other reasonably priced modules.

However, this camera was already quite expensive, and I needed 3 more. So, back to looking at sensors, to find a cheaper option for the rear and side cameras.

I settled on the IMX662 for this task. No fancy HDR, but good low light performance, and cheap. No need for USB3.0 either, as a lower framerate, or MJPEG encoded video output is fine from these cameras. The cheap modules, like the one I got, do suffer from a handful of cheapo ISP related issues though. The autoexposure algorithm is quite bad, there’s no denoising before MJPEG compression(which makes the video quality terrible), and the ISP only exposes a select few resolution/framerate combinations, which doesn’t include the ideal ones I’d want.

I bought 3 Arducam B0576 modules, which don’t come with an enclosure, so I designed and 3D printed some.

Conclusion

With that, all four of the cameras are ready to install. In the next post, I’ll talk about finally using Single Pair Ethernet, design and make the controller PCB for the charger box, and write some ADIN1110 code.

The final blog post will include the installation of all the cameras and other hardware, along with a demonstration of the system’s full functionality.

RE: [Part 4] Advanced Dashcam and Monitoring System - Cameras

DAB — Tue, 31 Mar 2026 18:49:40 GMT

Cool, I look forward to seeing how well it works.

[Part 3] Advanced Dashcam and Monitoring System - Compute Unit

vmate — Sun, 22 Mar 2026 00:11:12 GMT

Overview

This part is about the glovebox mounted compute unit, which is essentially the brain of the entire system.

Recap of the previous setup

A Raspberry Pi 4 and Raspberry Pi HQ camera were used in this initial version. As discussed in the first overview blog, this has several drawbacks, but the biggest ones are:

The Pi HQ Camera is bulky, has bad low light performance and dynamic range, and uses MIPI, which is a pain to wire up
The Pi 4’s hardware H264 encoder is not particularly great

The 4G modem is also bulky, since it’s an external box on a USB cable:

The rest of the old setup was related to battery charging and management, which we already redesigned and moved to the battery unit in the last blog, so a lot of the mess can be cut out.

Planning the new system

The plan is relatively straight forward:

Move to USB cameras
Use a SoC with a better hardware encoder, preferably H265
Design a custom PCB that integrates the 4G modem, power supplies, microcontroller, etc.

My first idea was making a carrier board for a Raspberry Pi CM5-style module. The CM5 itself is out due to lacking any hardware video encoders.

After some research, I came to the conclusion that the Rockchip RK3588 is the SoC I want:

It has 4x Cortex-A76 cores, and 4x Cortex-A55 cores
The hardware video encoder supports both H264 and H265
There is an NPU available for neural network acceleration

There are a few Compute Module style devices available with the RK3588, but I stumbled upon the Orange Pi 5 Plus:

This board has all the IO I need, 2.5Gb ethernet, an M.2 slot for WiFi and Bluetooth, and a 40 pin GPIO header. I decided to make a HAT-like PCB, instead of a CM carrier board, as this would be way simpler and faster to do. There’s only a single interface that is missing from the GPIO header for this, a USB2 link to the SBC. Not a major issue, but it’s not going to be the prettiest to fix.

The custom HAT

I started designing the PCB. The main responsibilities are the following:

Accept a 12-15V input source
Generate voltage rails to power the Orange Pi 5 Plus, 4G modem, and various electronics on the HAT itself
Include a microcontroller to manage power and handle low level communication
Integrate the 4G modem

I went with TPS566231 for generating the power rails, as I used these in earlier projects and had a few left. They are high-efficiency 6A buck converters.

I kept the EM7455 4G modem, as there are no reasonably priced better alternatives for the moment. The next meaningful step-up would be a 5G modem, but they are around 200USD, need PCIe, 4 antennas, and are a massive pain in general. The modem itself uses an M.2 B-key connector, but we also need a SIM card slot. The modem supports USB3, but USB2 will be plenty for us.

Since I need to attach both the ESP32 and modem to the Orange Pi through USB, I added an onboard USB hub, a USB2514B to be specific.

As it’s a 4 port hub, and we only need two, I decided to expose the two remaining ports for miscellaneous stuff I could need later.

An ESP32-S3 was chosen for the microcontroller, more specifically an ESP32-S3-WROOM-1U

I also added a fully isolated CAN transceiver, so I can later hook this up to my car’s CAN bus network, and a second, non-isolated CAN transceiver, along with full-duplex RS485 for future expansion.

An INA226 was included to monitor power consumption, added some fan headers and FETs to control them, and that’s about it.

I squeezed the design into a 100mm x 75mm form factor, the exact size of the Orange Pi 5 Plus.

The hole in the center is for a tiny 25mm x 25mm fan, to provide some airflow to the SoC, directly below, and also cool the modem.

I ordered all the parts, along with the 16GB RAM version of the Orange Pi 5 Plus (right before the RAM apocalypse, so I still have all my organs intact).

Assembly

I bought an Intel AX200 WiFi+Bluetooth card, and also got a Ublox Neo M8N GPS module. I whipped up an enclosure in Fusion for the entire thing:

The USB2 connection to the HAT was made with a custom cable that I plugged into one of the USB2 ports on the Orange Pi 5. It’s not the prettiest, but it works well.

You might ask yourself, where’s the SPE stuff? Well, at the time of making this, I didn’t have any of it yet, so I just made sure to add a bunch of extra IO and expansion ports to the PCB. The enclosure was made in a way to have another relatively large compartment screwed to the top, which will house the SPE transceiver and MAC.

Conclusion

I installed Armbian on the Orange Pi 5 Plus, wrote some minimal code for the ESP32 to enable all the buck converters, and set up a simple low battery voltage cutoff feature.

So far, everything has been working great, and I’m very happy with the Orange Pi 5 Plus,

With the Compute Unit ready, the next post will be a shorter one, about finding the perfect camera modules for our use case, and wiring them up.

RE: [Part 3] Advanced Dashcam and Monitoring System - Compute Unit

DAB — Tue, 24 Mar 2026 19:58:11 GMT

Nice build.

Deadline Looming

cstanton — Thu, 19 Mar 2026 09:50:35 GMT

Hey everyone,

With the deadline coming up I've cleaned out posts from [mention:a15d899f5f3b40efb1afbf8b37afcf7a:ca0e7c8086864d2fa5a863b9e212e922] that were either not related to the design challenge or should have been a forum post (which has been converted into one).

You will discover that you're not able to post a blog yet (including edit any drafts you may have), and this will change on the 23rd of March 2026 where you will then be able to post, edit, work on your final write-ups.

Looking forward to your posts!

RE: Deadline Looming

JoRatcliffe — Mon, 23 Mar 2026 16:57:52 GMT

Hi all, I am happy to extend the deadline by a week so the new deadline will be midnight (23:59 UK time) Sunday 5th April. I will update the dates and terms and conditions tomorrow.

You can now post and edit drafts in Projects so - when you are ready - you can submit your final, full project write-up.

RE: Deadline Looming

JWx — Mon, 23 Mar 2026 14:09:31 GMT

confirmed - draft edition possibility is restored

RE: Deadline Looming

cstanton — Mon, 23 Mar 2026 14:00:17 GMT

Challengers should now be able to post (and edit drafts).

RE: [Part 3] Advanced Dashcam and Monitoring System - Compute Unit

vmate — Mon, 23 Mar 2026 13:03:21 GMT

Thanks!

RE: [Part 3] Advanced Dashcam and Monitoring System - Compute Unit

veluv01 — Mon, 23 Mar 2026 04:54:46 GMT

Awesome build.

LTC9111 proof of concept

JWx — Thu, 19 Mar 2026 08:38:13 GMT

When several months ago, during a forum discussion what would be needed in the challenger's kit for SPE design challenge, [mention:e150bbdfa73b4f869b1c3bd03afb5272:e9ed411860ed4f2ba0265705b8793d05] suggested that LTC9111 Powered Device chip would be interesting.

In that time I have thought that it would be too time consuming to make use of it, but it the meantime, as a byproduct of some research, I have asked ADI for samples of both LTC9111 and LTC4296 (matching Power Sourcing Equipment controller) and they generously sent me them.

LTC9111 datasheet specifies typical schematics as below:

and the chip itself is operating according to the PD state machine like below:

which involves PSE-PD discovery process, allowing for proper PD classification and management.

During the discovery, PSE raises line voltage (with current limit enforced) to about 5V, then initiates communication.

When voltage is about 5V, classification can begin. It is done using one-wire SCCP protocol, which involves pulling down the power line at the transmitter side for predefined time.

LTC9111 is powered using Cstby capacitor during power down pulses and is using M2/M3 MOSFET pair to pull down power line by it's own (as the system is designed to be polarity-agnostic, symmetric design is used).

Communication is started by the PSE which sends reset pulse and PD answers with presence pulse. Then, PD transmits it's power class and, when accepted, PSE raises line voltage to the negotiated value. Then, PD opens M1 MOSFET and raises ENABLE signal, starting providing power to the load.

When voltage on the line drops, ENABLE signal is lowered and M1 closed.

Six power classes are defined (and can be configured using two three-state pins of LTC9111), three for supply voltage up to 30V and three for voltage up to 58V

Class	max power [W]	PD voltage [V]
10	1.23	14-30
11	3.2	14-30
12	8.4	14-30
13	7.7	35-58
14	20	35-58
15	52	35-58

As the solution is expected to work over long data lines, which may involve significant voltage drop - and, as we have previously discovered and confirmed in the requirements - signal polarity needs to be corrected if needed, low-loss rectifier is built using D1 and D2 Schottky diodes and M4 and M5 MOSFETs (from which one is activated when voltage polarity is sensed using SNS1 and SNS2 inputs to further reduce voltage drop). Before M4/M5 activation, current flows through their reverse parasitic diodes, effectively forming traditional Graetz bridge.

This solution is very advanced, but for the basic usage can be simplified: M4/M5 can be replaced with another set of Schottky diodes and some snubbing circuits can be (at least initially) omitted, leading to the circuit like below:

and PCB like below

as can be seen, chip installation is rather unusual, but it is caused by the fact that exposed pad at the bottom is the one and only GND contact (chip is housed in MSOP-12 package but has 13 active contacts), and MSOP-DIP adapter PCB (unlike - for example - QFN adapters) usually lack additional trace below the chip.

So, MSOP adapter was modified by placing adhesive copper tape at the center, then secured by two rivets in case when the glue didn't survive soldering and it worked - almost. When hot air soldered, tape glue expanded, raising the chip above the PCB, which required additional work to correct.

Next time I will try to remove adhesive from the tape and fix it using proper glue - but I am unsure what type of glue should be used? Maybe some cyanoacrylate glue would work? Or maybe something better is needed?

RE: LTC9111 proof of concept

kmikemoo — Fri, 20 Mar 2026 18:48:52 GMT

JWx NICE!!! That really opens up the world for long distance communication and SPoE (or PoDL). Excellent! 👍

RE: EVAL-ADIN1100 performance test

JWx — Fri, 20 Mar 2026 16:15:31 GMT

I have spool of CAT6 UTP which I could connect for > 1000m range but I don't know if I would have time before deadline

EVAL-ADIN1100 performance test

JWx — Tue, 03 Mar 2026 13:49:35 GMT

Packet loss diagnostics

In the previous post, transmission test using 192 meter UTP cable was presented. During the test data transmission was established but some packet loss was observed (which was an interesting case - problem was also present on very short cable distance).

To further pinpoint the problem, setup like in my Broadcom optical transceiver was established, consisting of two Dell servers running Debian GNU/Linux, each equipped with Intel 82576 1000Base-T adapter.

Initial tests

Ping test was successful:

PING 172.19.0.11 (172.19.0.11) 56(84) bytes of data.
64 bytes from 172.19.0.11: icmp_seq=1 ttl=64 time=0.561 ms
64 bytes from 172.19.0.11: icmp_seq=2 ttl=64 time=0.523 ms
64 bytes from 172.19.0.11: icmp_seq=3 ttl=64 time=0.533 ms
64 bytes from 172.19.0.11: icmp_seq=4 ttl=64 time=0.523 ms
64 bytes from 172.19.0.11: icmp_seq=5 ttl=64 time=0.545 ms
64 bytes from 172.19.0.11: icmp_seq=6 ttl=64 time=0.539 ms
64 bytes from 172.19.0.11: icmp_seq=7 ttl=64 time=0.544 ms
64 bytes from 172.19.0.11: icmp_seq=8 ttl=64 time=0.554 ms

Iperf3 TCP results were as below:

client side

iperf3 -c 172.19.0.11 -b 10M
Connecting to host 172.19.0.11, port 5201
[ 5] local 172.19.0.10 port 35668 connected to 172.19.0.11 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 1.30 MBytes 10.9 Mbits/sec 0 50.9 KBytes
[ 5] 1.00-2.00 sec 1.12 MBytes 9.44 Mbits/sec 0 50.9 KBytes
[ 5] 2.00-3.00 sec 1.22 MBytes 10.3 Mbits/sec 0 50.9 KBytes
[ 5] 3.00-4.00 sec 1.12 MBytes 9.38 Mbits/sec 0 50.9 KBytes
[ 5] 4.00-5.00 sec 1.12 MBytes 9.38 Mbits/sec 0 50.9 KBytes
[ 5] 5.00-6.00 sec 1.12 MBytes 9.38 Mbits/sec 0 50.9 KBytes
[ 5] 6.00-7.00 sec 1.12 MBytes 9.38 Mbits/sec 0 50.9 KBytes
[ 5] 7.00-8.00 sec 1.12 MBytes 9.38 Mbits/sec 0 50.9 KBytes
[ 5] 8.00-9.00 sec 1.12 MBytes 9.38 Mbits/sec 0 50.9 KBytes
[ 5] 9.00-10.00 sec 1.12 MBytes 9.38 Mbits/sec 0 50.9 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 11.5 MBytes 9.63 Mbits/sec 0 sender
[ 5] 0.00-10.08 sec 11.3 MBytes 9.37 Mbits/sec receiver

iperf Done.

server side:

iperf3 -s
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Accepted connection from 172.19.0.10, port 35656
[ 5] local 172.19.0.11 port 5201 connected to 172.19.0.10 port 35668
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 1.07 MBytes 9.01 Mbits/sec
[ 5] 1.00-2.00 sec 1.12 MBytes 9.42 Mbits/sec
[ 5] 2.00-3.00 sec 1.12 MBytes 9.41 Mbits/sec
[ 5] 3.00-4.00 sec 1.12 MBytes 9.42 Mbits/sec
[ 5] 4.00-5.00 sec 1.12 MBytes 9.42 Mbits/sec
[ 5] 5.00-6.00 sec 1.12 MBytes 9.42 Mbits/sec
[ 5] 6.00-7.00 sec 1.12 MBytes 9.42 Mbits/sec
[ 5] 7.00-8.00 sec 1.12 MBytes 9.41 Mbits/sec
[ 5] 8.00-9.00 sec 1.12 MBytes 9.42 Mbits/sec
[ 5] 9.00-10.00 sec 1.12 MBytes 9.42 Mbits/sec
[ 5] 10.00-10.08 sec 90.5 KBytes 9.32 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
[ 5] 0.00-10.08 sec 11.3 MBytes 9.37 Mbits/sec receiver

And iperf3 UDP

client

Connecting to host 172.19.0.11, port 5201
[ 5] local 172.19.0.10 port 42566 connected to 172.19.0.11 port 5201
[ ID] Interval Transfer Bitrate Total Datagrams
[ 5] 0.00-1.00 sec 1.19 MBytes 10.0 Mbits/sec 863
[ 5] 1.00-2.00 sec 1.19 MBytes 9.97 Mbits/sec 861
[ 5] 2.00-3.00 sec 1.14 MBytes 9.57 Mbits/sec 826
[ 5] 3.00-4.00 sec 1.14 MBytes 9.56 Mbits/sec 825
[ 5] 4.00-5.00 sec 1.14 MBytes 9.57 Mbits/sec 826
[ 5] 5.00-6.00 sec 1.14 MBytes 9.57 Mbits/sec 826
[ 5] 6.00-7.00 sec 1.14 MBytes 9.56 Mbits/sec 825
[ 5] 7.00-8.00 sec 1.14 MBytes 9.57 Mbits/sec 826
[ 5] 8.00-9.00 sec 1.14 MBytes 9.57 Mbits/sec 826
[ 5] 9.00-10.00 sec 1.14 MBytes 9.56 Mbits/sec 825
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-10.00 sec 11.5 MBytes 9.65 Mbits/sec 0.000 ms 0/8329 (0%) sender
[ 5] 0.00-10.08 sec 11.4 MBytes 9.52 Mbits/sec 0.014 ms 0/8285 (0%) receiver

server

Accepted connection from 172.19.0.10, port 48540
[ 5] local 172.19.0.11 port 5201 connected to 172.19.0.10 port 42566
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-1.00 sec 1.09 MBytes 9.13 Mbits/sec 0.299 ms 0/788 (0%)
[ 5] 1.00-2.00 sec 1.14 MBytes 9.57 Mbits/sec 0.307 ms 0/826 (0%)
[ 5] 2.00-3.00 sec 1.14 MBytes 9.57 Mbits/sec 0.021 ms 0/826 (0%)
[ 5] 3.00-4.00 sec 1.14 MBytes 9.56 Mbits/sec 0.019 ms 0/825 (0%)
[ 5] 4.00-5.00 sec 1.14 MBytes 9.57 Mbits/sec 0.024 ms 0/826 (0%)
[ 5] 5.00-6.00 sec 1.14 MBytes 9.56 Mbits/sec 0.024 ms 0/825 (0%)
[ 5] 6.00-7.00 sec 1.14 MBytes 9.57 Mbits/sec 0.018 ms 0/826 (0%)
[ 5] 7.00-8.00 sec 1.14 MBytes 9.57 Mbits/sec 0.019 ms 0/826 (0%)
[ 5] 8.00-9.00 sec 1.14 MBytes 9.56 Mbits/sec 0.015 ms 0/825 (0%)
[ 5] 9.00-10.00 sec 1.14 MBytes 9.57 Mbits/sec 0.022 ms 0/826 (0%)
[ 5] 10.00-10.08 sec 93.3 KBytes 9.64 Mbits/sec 0.014 ms 0/66 (0%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-10.08 sec 11.4 MBytes 9.52 Mbits/sec 0.014 ms 0/8285 (0%) receiver

As can be seen, no data loss so far.

This observation was also verified by looking at net adapter's error counters:

inet 172.19.0.11 netmask 255.255.0.0 broadcast 172.19.255.255
inet6 fe80::225:90ff:fe3a:1730 prefixlen 64 scopeid 0x20<link>
ether 00:25:90:3a:17:30 txqueuelen 1000 (Ethernet)
RX packets 4010912 bytes 5725615220 (5.3 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1865313 bytes 565506418 (539.3 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device memory 0xc15a0000-c15bffff

inet 172.19.0.10 netmask 255.255.0.0 broadcast 172.19.255.255
inet6 fe80::225:90ff:fe39:8fb0 prefixlen 64 scopeid 0x20<link>
ether 00:25:90:39:8f:b0 txqueuelen 1000 (Ethernet)
RX packets 1865234 bytes 565502452 (539.3 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 4011112 bytes 5725623976 (5.3 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device memory 0xc15a0000-c15bffff

no errors after transferring 5GB and 500MB back (after bulk file transfer test)

Netpipe test shows transfer curve as below, very good, no packet loss symptoms - observed slight drop of transfer near 1kB frame size was identified before as a behavior of the Intel network card used.

Reverse pair connection

As 10Base-T1 interface has defined polarity ('DATA+' and 'DATA-''), next test performed was polarity reversal test

After reversing wires in the pair nothing spectacular occured.

Link still goes up, ping works:

64 bytes from 172.19.0.11: icmp_seq=1 ttl=64 time=0.543 ms
64 bytes from 172.19.0.11: icmp_seq=2 ttl=64 time=0.551 ms
64 bytes from 172.19.0.11: icmp_seq=3 ttl=64 time=0.570 ms
64 bytes from 172.19.0.11: icmp_seq=4 ttl=64 time=0.522 ms

Iperf3 performance is unaffected:

client:

Connecting to host 172.19.0.11, port 5201
[ 5] local 172.19.0.10 port 38580 connected to 172.19.0.11 port 5201
[ ID] Interval Transfer Bitrate Total Datagrams
[ 5] 0.00-1.00 sec 1.19 MBytes 10.0 Mbits/sec 863
[ 5] 1.00-2.00 sec 1.19 MBytes 9.97 Mbits/sec 861
[ 5] 2.00-3.00 sec 1.14 MBytes 9.57 Mbits/sec 826
[ 5] 3.00-4.00 sec 1.14 MBytes 9.56 Mbits/sec 825
[ 5] 4.00-5.00 sec 1.14 MBytes 9.57 Mbits/sec 826
[ 5] 5.00-6.00 sec 1.14 MBytes 9.57 Mbits/sec 826
[ 5] 6.00-7.00 sec 1.14 MBytes 9.56 Mbits/sec 825
[ 5] 7.00-8.00 sec 1.14 MBytes 9.57 Mbits/sec 826
[ 5] 8.00-9.00 sec 1.14 MBytes 9.57 Mbits/sec 826
[ 5] 9.00-10.00 sec 1.14 MBytes 9.56 Mbits/sec 825
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-10.00 sec 11.5 MBytes 9.65 Mbits/sec 0.000 ms 0/8329 (0%) sender
[ 5] 0.00-10.08 sec 11.4 MBytes 9.52 Mbits/sec 0.022 ms 0/8284 (0%) receiver

server:

Accepted connection from 172.19.0.10, port 39240
[ 5] local 172.19.0.11 port 5201 connected to 172.19.0.10 port 38580
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-1.00 sec 1.09 MBytes 9.13 Mbits/sec 0.303 ms 0/788 (0%)
[ 5] 1.00-2.00 sec 1.14 MBytes 9.57 Mbits/sec 0.306 ms 0/826 (0%)
[ 5] 2.00-3.00 sec 1.14 MBytes 9.57 Mbits/sec 0.028 ms 0/826 (0%)
[ 5] 3.00-4.00 sec 1.14 MBytes 9.56 Mbits/sec 0.019 ms 0/825 (0%)
[ 5] 4.00-5.00 sec 1.14 MBytes 9.57 Mbits/sec 0.010 ms 0/826 (0%)
[ 5] 5.00-6.00 sec 1.14 MBytes 9.57 Mbits/sec 0.020 ms 0/826 (0%)
[ 5] 6.00-7.00 sec 1.14 MBytes 9.56 Mbits/sec 0.021 ms 0/825 (0%)
[ 5] 7.00-8.00 sec 1.14 MBytes 9.57 Mbits/sec 0.020 ms 0/826 (0%)
[ 5] 8.00-9.00 sec 1.14 MBytes 9.57 Mbits/sec 0.020 ms 0/826 (0%)
[ 5] 9.00-10.00 sec 1.14 MBytes 9.56 Mbits/sec 0.014 ms 0/825 (0%)
[ 5] 10.00-10.08 sec 91.9 KBytes 9.50 Mbits/sec 0.022 ms 0/65 (0%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-10.08 sec 11.4 MBytes 9.52 Mbits/sec 0.022 ms 0/8284 (0%) receiver

And Netpipe graph is as below (comparing direct and reversed connection)

As can be seen, when using ADIN1100 PHY, connector reversal in the pair is not affecting transfer rate.

Packet loss evaluation

After series of tests Ethernet frame counters are still zero:

inet 172.19.0.10 netmask 255.255.0.0 broadcast 172.19.255.255
inet6 fe80::225:90ff:fe39:8fb0 prefixlen 64 scopeid 0x20<link>
ether 00:25:90:39:8f:b0 txqueuelen 1000 (Ethernet)
RX packets 2219550 bytes 883187824 (842.2 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 4373812 bytes 6055720865 (5.6 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device memory 0xc15a0000-c15bffff

inet 172.19.0.11 netmask 255.255.0.0 broadcast 172.19.255.255
inet6 fe80::225:90ff:fe3a:1730 prefixlen 64 scopeid 0x20<link>
ether 00:25:90:3a:17:30 txqueuelen 1000 (Ethernet)
RX packets 4373611 bytes 6055712233 (5.6 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 2219630 bytes 883191660 (842.2 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device memory 0xc15a0000-c15bffff

PHY monitoring also doesn't detect any errors:

MSE -37.2 dB Rx 3178421, Err 0
MSE -37.2 dB Rx 3178421, Err 0
MSE -37.2 dB Rx 3178421, Err 0
MSE -37.2 dB Rx 3178421, Err 0
MSE -37.2 dB Rx 3178421, Err 0
MSE -37.2 dB Rx 3178421, Err 0
MSE -37.2 dB Rx 3178421, Err 0
MSE -37.2 dB Rx 3178421, Err 0
MSE -37.2 dB Rx 3178421, Err 0

MSE -37.2 dB Rx 48231, Err 0
MSE -37.2 dB Rx 48231, Err 0
MSE -37.2 dB Rx 48231, Err 0
MSE -37.2 dB Rx 48231, Err 0
MSE -37.2 dB Rx 48231, Err 0

So frame loss that was observed during previous tests was definitely not connected to the cable used.

RE: EVAL-ADIN1100 performance test

JWx — Fri, 20 Mar 2026 15:56:55 GMT

yes - this is strange, never have seen anything other than -37,2dB

RE: EVAL-ADIN1100 performance test

veluv01 — Fri, 20 Mar 2026 15:55:20 GMT

Well...the -38dB in their datasheet is too evil.

-37.2 dB was all I could get, maybe it increases if we could go over a KM?

RE: Deadline Looming

cstanton — Fri, 20 Mar 2026 14:24:37 GMT

Hey veluv01 ,

That's definitely a JoRatcliffe question 🙂

RE: EVAL-ADIN1100 performance test

JWx — Fri, 20 Mar 2026 12:37:49 GMT

and MSE is still the same:

MSE -37.2 dB Rx 4693234, Err 0
MSE -37.2 dB Rx 4693235, Err 0
MSE -37.2 dB Rx 4693236, Err 0
MSE -37.2 dB Rx 4693237, Err 0
MSE -37.2 dB Rx 4693238, Err 0
MSE -37.2 dB Rx 4693238, Err 0
MSE -37.2 dB Rx 4693239, Err 0
MSE -37.2 dB Rx 4693241, Err 0
MSE -37.2 dB Rx 4693242, Err 0
MSE -37.2 dB Rx 4693243, Err 0
MSE -37.2 dB Rx 4693244, Err 0
MSE -37.2 dB Rx 4693245, Err 0
MSE -37.2 dB Rx 4693246, Err 0
MSE -37.2 dB Rx 4693247, Err 0
MSE -37.2 dB Rx 4693248, Err 0
MSE -37.2 dB Rx 4693249, Err 0
MSE -37.2 dB Rx 4693250, Err 0
MSE -37.2 dB Rx 4693251, Err 0
MSE -37.2 dB Rx 4693252, Err 0
MSE -37.2 dB Rx 4693253, Err 0
MSE -37.2 dB Rx 4693254, Err 0
MSE -37.2 dB Rx 4693255, Err 0

MSE -37.2 dB Rx 1563071, Err 0
MSE -37.2 dB Rx 1563072, Err 0
MSE -37.2 dB Rx 1563073, Err 0
MSE -37.2 dB Rx 1563075, Err 0
MSE -37.2 dB Rx 1563076, Err 0
MSE -37.2 dB Rx 1563077, Err 0
MSE -37.2 dB Rx 1563078, Err 0
MSE -37.2 dB Rx 1563078, Err 0
MSE -37.2 dB Rx 1563079, Err 0
MSE -37.2 dB Rx 1563080, Err 0
MSE -37.2 dB Rx 1563082, Err 0
MSE -37.2 dB Rx 1563083, Err 0
MSE -37.2 dB Rx 1563084, Err 0
MSE -37.2 dB Rx 1563085, Err 0

BTW - ADI support suggested that during laboratory testing noise level is so low that MSE couldn't drop even using long/worse quality cabling

RE: EVAL-ADIN1100 performance test

JWx — Fri, 20 Mar 2026 12:34:24 GMT

update after more than two weeks of testing using 192m twisted pair:

ping still works:

64 bytes from 172.19.0.11: icmp_seq=53436 ttl=64 time=0.526 ms
64 bytes from 172.19.0.11: icmp_seq=53437 ttl=64 time=0.517 ms
64 bytes from 172.19.0.11: icmp_seq=53438 ttl=64 time=0.548 ms
64 bytes from 172.19.0.11: icmp_seq=53439 ttl=64 time=0.509 ms
64 bytes from 172.19.0.11: icmp_seq=53440 ttl=64 time=0.513 ms
64 bytes from 172.19.0.11: icmp_seq=53441 ttl=64 time=0.528 ms

no errors on the interfaces

 inet 172.19.0.11 netmask 255.255.0.0 broadcast 172.19.255.255
 inet6 fe80::225:90ff:fe3a:1730 prefixlen 64 scopeid 0x20<link>
 ether 00:25:90:3a:17:30 txqueuelen 1000 (Ethernet)
 RX packets 5887813 bytes 6200897855 (5.7 GiB)
 RX errors 0 dropped 0 overruns 0 frame 0
 TX packets 3734229 bytes 1026886358 (979.3 MiB)
 TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
 device memory 0xc15a0000-c15bffff

 inet 172.19.0.10 netmask 255.255.0.0 broadcast 172.19.255.255
 inet6 fe80::225:90ff:fe39:8fb0 prefixlen 64 scopeid 0x20<link>
 ether 00:25:90:39:8f:b0 txqueuelen 1000 (Ethernet)
 RX packets 3733803 bytes 1028378330 (980.7 MiB)
 RX errors 0 dropped 0 overruns 0 frame 0
 TX packets 5888467 bytes 6199420743 (5.7 GiB)
 TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
 device memory 0xc15a0000-c15bffff

RE: Deadline Looming

veluv01 — Fri, 20 Mar 2026 03:15:43 GMT

cstanton would it be possible to extend the deadline by a week😅?

RE: SPE face-off

wolfgangfriedrich — Thu, 19 Mar 2026 12:10:08 GMT

Got me pretty confused too. And now there are 2 Forum posts. One from today and another one from the date I originally posted the blog (this one is missing today's comments).
Doesn't really matter as long as the content is still there.

SPE face-off

wolfgangfriedrich — Fri, 27 Feb 2026 06:05:12 GMT

Even before the Single Pair Ethernet design challenge started, I was pondering about making a SPE solution available for whoever is interested. Looking at the feature list, the cable length of 10baseT1L stood out more than e.g. 1Gbit over 40 meter on a single pair. So I started researching chip sets and landed on the TI solutions instead of ADI. And the chip of choice is the TI DP83TD510E.

This is not a competitive entry into the design challenge, I just want to share my work in progress. My idea is to build a simple board that works as an Ethernet extension: plug it into a network hub on one end and have 10Mb of Ethernet data rate at the other end which can be really far away. This is plenty for sensor data or even streaming audio, not so much for a NAS or other high speed data connections.
The first step is going to be a one-board design that can be used on both ends as a media converter from regular Ethernet to SPE. As a compliant interface it would also be possible to replace the far end with a ADI or Microchip device. Low power is a design goal but there will be lower power options available, I am thinking of the SPE to SPI chip ADIN1110. Also the selected microcontroller is not famous for its low power, but something I am comfortable working with, the RP2040.

The board is equipped with an expansion connector breaking out a set of signals that might be sufficient for a Power over Dataline (PoDL) add on board, but this is just a concept for now without a design yet. Another thought I had during a shower recently, power input for the PoDL section could be done as a USB-C PD sink device. Or even better, in the meantime there are chips available that can act as a sink or source, so I could extend the single board for both ends to a PD source to power the SPE far end device and provide additional power output. But that is step 42, I am at step 3 right now.

The schematic is finished enough to share and I have started putting components on a board. Layout progress will be shared when I have something to show for.

Edit: I had to remove the schematic as it was still full of errors. It should not be out in the wild in this form and I will update when I am confident in a better version.

Edit2: Added new schematic, which is much more complete. Added config resistors and changedMII to RMII connect.

Please enjoy and I am very open to suggestions or even better, to pointing out any blatant mistakes I have made.

[View:/cfs-file/__key/communityserver-discussions-components-files/448/0245.P42_2D00_SPE10baseT1L_2D00_r1.pdf:640:360]

RE: SPE face-off

JWx — Thu, 19 Mar 2026 11:04:39 GMT

no problem - I am simply trying to monitor new events in the challenge so unexpected change was somewhat surprising, maybe indicating some system misbehavior (especially loss of likes/votes)

RE: Deadline Looming

JWx — Thu, 19 Mar 2026 10:00:08 GMT

ok - will need to write offline until then. This time I have planned to start writing earlier than at the last moment for the change 🙂