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.

[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.

Deadline Looming

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

Hey everyone,

With the deadline coming up I've cleaned out posts from Projects 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!

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, kmikemoo 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?

[Part 2] Advanced Dashcam and Monitoring System – Battery and Charging System

vmate — Fri, 13 Mar 2026 16:32:46 GMT

Introduction

This part is about upgrading the current AGM battery bank and 4x parallel BQ25798 charger setup, to something more robust and powerful.

As discussed in the previous post, there are two main issues with the lead acid setup:

The overall battery capacity is too small
The recharge time (which happens during driving, from the vehicle’s generator) is way too long, and cannot keep the batteries charged enough to run in a ‘self-sufficient’ manner.

The conclusion I arrived at is that a roughly 1kWh battery is needed with a 20A+ charger.

For more details about how I got these numbers, check the previous part, I don’t want to pad out this post with repeat content.

Battery Candidates

My first step was to figure out what sort of battery would be ideal. I had a few constraints:

I did not want to use Li-ion or Li-Po batteries, as they have a tendency to go boom in very hot temperatures, or when stupidity is encountered. I do not trust myself. Not burning down my car would definitely be a useful feature.
Lead-acid, even very fancy AGM batteries suffer from two main problems: weight, and depth-of-discharge. This essentially rules them out completely.

These constraints narrow options down to two possible chemistries, that I can obtain and work with. I’m certain there’s some exotic battery type that costs more than my car that would be a great fit, but for obvious reasons, it’s not viable.

Candidate 1: NiMH

The tried and tested approach. Hybrid cars have used these for over 2 decades now, for basically the same exact reasons as mine. They do have some depth-of-discharge issues, but less severe than AGM. The energy density is way higher too, so they are less heavy and smaller for the same capacity.

Obtaining large NiMH batteries turns out to be a challenge though, it’s a niche market.

Candidate 2: LiFePO4

Looking at the name, it might look like this is another lithium battery that likes to violently express its dislike when rude things happen to it, but it turns out, that’s not the case. LiFePO4 batteries do not light on fire, do not explode, etc, even when punctured. They do obviously release some nasty chemicals and make a mess, but they are significantly safer in this aspect than even NiMH.

They are similar to Li-ion or Li-po in most ways, except have slightly lower energy densities, and run at a lower voltage: the nominal value is 3.2V, instead of 3.7V.

The energy density is still significantly higher than NiMH though, and they handle deep cycling insanely well. Limiting discharge depth by 10-20% easily gets us to 10000+ cycles, which translates to over 100 years in my use case. The AGM batteries lasted 6 months.

There’s one minor issue. These batteries cannot be charged below 0C at all, but more like 5C if we want to be safe. That will be a massive problem in the winter, but let’s just sweep this issue under the rug for a moment.

The only concern at this point was price and availability. Thankfully, LiFePO4 batteries got extremely popular for off-grid solar systems, and they are readily available. The prices are very compelling too.

The New Battery

After some research, I ended up buying a 1.28kWh, 100Ah LiFePO4 battery. The price was good, the reviews looked fine, so it seemed like the perfect option.

(yes, I really should’ve cleaned up a bit, but oh well)

Initially, everything seemed fine. Attached some loads, capacity was exactly as advertised.

However, a big problem surfaced: when charging, the BMS cut off at 13.7V, when the battery should be able to charge way higher. I did a few discharge cycles to see if things improved, but not really.

At this point, I decided to contact customer support, and get a replacement. Initially, they were relatively helpful, although they completely refused to cross ship a replacement for some reason, so I was stuck waiting weeks to get the new battery.

When the new one arrived, same issue. The BMS was cutting out way too early. I suspected that the issue was unbalanced cells internally, and one of them reaching a higher voltage than the others. Unfortunately, the battery is glued or ultrasonically welded in a way that it’s impossible to open up, and I wouldn’t want to lose my warranty on a dodgy battery anyways.

I reached out to customer support again, to explain what is happening. I even set up a system to log voltage and current to InfluxDB, and made a Grafana dashboard to have fancy plots of everything. After sending extremely detailed data to the manufacturer, they essentially told me that I have no idea what I’m doing and they don’t really want to deal with me anymore so just send the battery back, and they’ll refund me, no replacements, no upgrades, no nothing. So that’s 2 months wasted on unreliable batteries.

A massive disappointment honestly, according to everything I’ve read, these batteries should be quite good quality. I am 99% certain that the issue was unbalanced cells, which is a big fail on the part of the manufacturer. Getting two of these batteries in a row means that this is probably a widespread issue.

After some more research, I didn’t find any other good candidates for batteries, so I decided to buy another battery from this manufacturer, but this time, one with a “smart” BMS, that can connect to a mobile app. My hope was that I could sniff some useful data from Bluetooth, and possibly see cell voltage readings and BMS fault reasons.

The new battery had the same exact issue. The BMS cut off way too early. Looking into the “smart” BMS, I discovered that someone already reverse engineered the protocol, so I had no trouble writing some code to log the BMS data to InfluxDB. After looking at the numbers, my suspicions were confirmed. Cell 2 in my battery was resting at a significantly higher voltage than all the other cells.

The next 2 weeks were spent trying to get the cells balanced. I had relatively little success at this point, although a minor improvement did happen, and I was able to charge to 13.95V before the BMS intervening. The imbalance still persisted, but I just decided to not charge the battery to more than 13.9V to sidestep the problem somewhat. This would only result in a few percent of capacity loss, and maybe I could figure out a solution later.

The Cold Charging Problem

As mentioned earlier, LiFePO4 batteries cannot be charged in cold temperatures. Some more expensive battery models include a built-in heater, and in cold weather, the BMS disables charging, and uses the input energy to run the heaters instead.

This seems like a decent solution at first, but it’s another black box system. The BMS controls the heater somehow, with no explicit ability to turn it on, and the temperature sensor is almost certainly just glued to the outside of the cells. When the heater gets the outer shell of the batteries to a few degrees above freezing, I assume the BMS just enables charging immediately, and the battery gets damaged. The LiFePO4 cells are massive, and heating their outer shells to even 10+ degrees means nothing, if their centers are still below freezing. We will need some logic in our heater system to account for the heat having to reach the center of the cells, but we only have a temperature reading from the outer shell.

My solution was to add my own external heating. This is significantly worse in the sense that I am heating the outer plastic, which needs to heat the inside air, which needs to heat the cells, instead of just directly heating the cells. However, I get direct control over everything.

I got some heating films, big flexible sheets with glue on one side, and a long, snaking trace covering the surface, that acts as a heating element. I put two of these on the battery’s outer casing.

(one heating film is enough to cover one side completely, as visible in the picture, plus half of the bottom surface too)

I also added a bimetallic thermal fuse and a DS18B20 on both heating films, which I completely forgot to take a photo of, sorry.

The next step is insulation. Spending all that energy on heating the battery is useless, if the heat is not kept in.

A relative of mine made this lovely wooden box for me, that I padded out with multiple layers of XPS foam, typically used for insulating floors.

Added an XT60 and a GX12 connector temporarily, as this battery was essentially meant to be a drop-in replacement for the old AGM bank at this stage.

The heaters and temperature sensors were left unconnected for now, as it wasn’t yet cold outside, and hooking them up to the old system would’ve been a waste of time.

I hooked the new battery up for a short test period, and real-world battery life ended up being around 5 days. Perfect.

The Charger

The next issue to tackle is charging. As you might recall from earlier, four BQ25798 charger ICs were used, which means that a best-case maximum of 12A charging was possible. This is about half of what we need, and a terribly janky solution anyways.

I went searching for a sufficiently beefy charger IC, and I stumbled upon the BQ25756. This seemed like the perfect choice, it’s essentially the big brother of the BQ25798. It no longer integrates the FETs, but that’s fine. With a well-designed PCB and correctly chosen components, it should be capable of doing 20A.

Charger PCB v1

Emboldened by success with the very simple, integrated FET chargers from earlier, I thought this will be a cakewalk. In retrospect, I probably designed the worst PCB in the history of power electronics. I’ll do everyone a favor and not show it, let’s just forget it even existed.

The board barely ran, was unstable, had voltage spikes, OCP constantly triggered, etc.

Charger PCB v2

At this point, I probably had about 10% of the required knowledge to design such a charger. Obviously, I thought I knew everything at the time though. Same story as before really, just slightly less terrible.

This revision was significantly better, but still completely unsuitable for use. I followed the ‘add more caps’ methodology for solving stability issues, but with no success.

Charger PCB v3

After even more research and studying power electronics, I made a new revision of the board.

I did not actually get this made, for reasons that will become clear in a moment, but I believe this design should be okay-ish possibly (absolutely no reason to suspect that I might be overconfident here, this could never happen to me).

While designing this board and contemplating the meaning of life, and whether I’ll live long enough to produce enough revisions to end up with something that works, I went online to look for some power supplies for a different project. By complete accident, I stumbled upon something, that would make this project way simpler, and my wallet way lighter.

The Orion XS

The Victron Energy Orion XS is a DC/DC battery charger, that is EXACTLY what I need. If I could change something about it, I wouldn’t. It was made for the exact use case I need it for: charging a secondary battery in campers, from a car’s generator or main battery. It has a bunch of convenience features that will be extremely useful. But most importantly: it is a 50A, insanely efficient charger, that just works.

Power goes in, battery gets charged. Has Bluetooth and a fancy app, which is great for testing, but not that great for my project. However, there’s a “VE.Direct” port on there, which is electrically just UART, that lets me control it without Bluetooth. Absolute perfection.

I also picked up their SmartShunt 300A, which is just a big shunt resistor with an MCU and some analog stuff on there. The price was right, and it gives me hassle free battery state-of-charge numbers, and also uses the VE.Direct port that I’ll be using for the charger itself.

While this setup was significantly more expensive than doing my own charger, it took somewhere between 10 to infinite times less effort to build, and it also has the advantage of actually working. All that’s left is to put everything together.

The Charger Assembly

I got a big, waterproof(ish) box to put everything inside. It has almost the same width and height as the battery, so I can later mount it on top.

With a 50A charger, it made sense to wire everything for 50A. That brings some challenges though. 50A is no joke, especially in a car, where everything is constantly vibrating. That means it’s wire lug, bus bars, and big crimp tools time. And don’t forget fuses.

I couldn’t figure out any nice ways to mount everything inside, so I ended up designing and 3D printing a ‘baseplate’ that holds everything. This plate is then screwed into the big plastic box.

I put some brass threaded inserts into the box to help with mounting the baseplate, they are visible in the image above.

And here’s the baseplate with most of the components attached. There is no wiring yet, and the custom controller PCB is missing from the top right.

The 60A fuse in the bottom right is for the charger input, and the two smaller (40A and 30A) fuses are for the XT90 and XT60 outputs that will be on the box.

There’s a mounting pattern for a fan to add later, the charger will probably need some active cooling in the summer, but so far it has been running just fine with zero airflow. (The charger barely heats up, I measured ~98% efficiency, it’s very impressive)

The controller board I designed hasn’t arrived yet, but here’s the 3D render of it:

It contains an ESP32-S3 that runs all the logic, and also communicates with the LiFePO4 BMS over Bluetooth. There are two isolated UARTs to connect to the Victron VE.Direct ports (to avoid nasty ground loops, and also act as level shifters), an isolated USB port for programming and debugging, an isolated CAN bus port for future expansions, a bunch of fan headers, and heater power outputs.

This board will be hooked up to the ADIN1110 SPE transceiver and MAC, and the SPE link will connect the battery assembly to the SBC in the front.

As of early March, my package with the SPE hardware just arrived, but I had to prepare for the possibility of not receiving it in time, so I also designed and ordered a custom ADIN1110 breakout board:

But back to the charger box now.

I mounted the power connectors on the side of the box. An XT90 for the charger input, and an XT90 plus XT60 for power output. The XT90 will be unused for now, but I added it for future use cases, like heaters or even a jump start lead. (my car needs less than 40A to start, the 12V system is only used to engage the traction battery contactors and run the brake pump)

I spent about 3 days wiring up everything. Most of the wires are 10mm2, with big copper lugs on them. It should be able to handle 50A with no issues.

This entire box was screwed onto the top of the battery cover, which is also thermally insulated.

An 80A MEGA fuse was added right at the battery’s positive terminal, for maximum protection.

The connectors on the wooden box were removed, as everything will be on the top plastic box from now on.

Conclusion

With the controller PCB still in a factory somewhere, I don’t have all the fancy graphs and data to show for the new charging system, as I have no way to properly communicate with the charger and SmartShunt. However, I did already test the setup, using the Bluetooth app on my phone. Everything has been perfect so far, no overheating, no instability, and no need to take the battery out of the car ever again to charge it at home.

{gallery}Victron App Screenshots
Orion XS: Overview
Orion XS: Settings
Orion XS: Settings
Orion XS: Settings
Orion XS: Settings
Orion XS: Settings
SmartShunt: Overview
SmartShunt: Historical Data
SmartShunt: Historical Data
SmartShunt: Settings
SmartShunt: Detailed Statistics

{gallery}Victron App Screenshots

Orion XS: Overview

Orion XS: Settings

SmartShunt: Overview

SmartShunt: Historical Data

SmartShunt: Settings

SmartShunt: Detailed Statistics

waterproof when connected

JWx — Wed, 11 Mar 2026 16:04:47 GMT

"IP 67 in mated condition"

As we are progressing with the project, some additional experiments are becoming possible.

First - our IP67 connector assembly (consisting of socket and enclosure mount ) is - according to the documentation- only rated IP67 when connected. Let's see what will happen otherwise...

Test setup is as before: enclosure with paper towel inserted (to quickly identify water ingress), this time with the connector socket installed

is submerged in the water

community.element14.com/.../unconn_5F00_test_5F00_out.mp4

as we can see, water can enter through the connector, leaving enclosure after test in the state like below:

not good.

Fortunately, our mount is in the standard industrial M12 format, so we have proven remedies for situations like that.

M12 connector cap

Our Molex M12 connector mounts are of threaded variety, so we have inner thread and a gasket

so we can use standard M12 threaded connector caps. Connector filled with such a cap is shown on the photo below:

This time test result is quite different

community.element14.com/.../cap_5F00_test_5F00_out1.mp4

with no observable water ingress at the end

So we have an easy and cheap solution for not-always-connected sockets exposed to the elements.

"waterproof" enclosure

JWx — Mon, 09 Mar 2026 17:22:26 GMT

Enclosure selection

As an enclosure for Raspberry PI, Kradex Z74 with transparent lid was selected. As can be seen, Raspberry PI with CN-0575 SPE shield occupies about half of it, giving some space for additional components

Enclosure itself - rated for IP65 (so it is protected from dust ingress and from water jets from any direction, but not for water immersion), has foam-roll gasket between the main part and the lid that should be trimmed and self-installed from the provided length

Raspberry Pi itself was screwed into section of PCB cut-out to the shape of enclosure floor, boards connected using 2.5mm spacers and screws - RPI has mounting holes of 2.7mm diameter, so more common 3mm spacers cannot be used.

Immersion test

As this enclosure was a part of my research set from Extreme Environment challenges, let's test it Extreme Env way - never mind the formal rating, drop it into the water (with paper towel inserted to quickly identify water leaks)!

community.element14.com/.../enc_5F00_initial_5F00_2.mp4

And? No excessive bubbling, no water identifiable on the paper towel - success! This enclosure survived short-term water immersion - more tests will be executed as the project advances.

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.

[Part 1] Advanced Dashcam and Monitoring System – Introduction

vmate — Tue, 03 Mar 2026 12:37:30 GMT

Introduction

This project is essentially a continuation, or more precisely complete rework and re-imagining of my earlier project in the Eye on Intelligence Challenge. In this blog, I will recap the goals, systems, and ideas from that project, and plan the new system that will take its place.

The original idea was to make a DIY dashcam. The initial version used a Raspberry Pi 4 and a Raspberry Pi HQ camera to do this. I realized early on that adding a 4G modem and batteries to the system would make it way more versatile and useful.

The main goal is to stream the camera feed in real-time to a remote server, even when the car is parked. This immediately resolves two of the biggest problems with regular dashcams:

If an accident happens, a regular dashcam only stores video locally, and the storage media may get destroyed in the accident.
If the vehicle or dashcam gets stolen, the storage media gets stolen along with it.

Not relying on local storage at all fixes these two issues, but brings a mountain of challenges with it. To mention just a few:

Stream latency is critical: an accident can happen in less than a second in the worst cases. Imagine an oncoming car experiencing a tire blowout just meters in front, and colliding with our vehicle, destroying the dashcam. If the video stream was not encoded and transmitted within less than a second, zero footage of the accident will have been recorded.
Handling network connection dropouts: It is almost certain that the network connection’s quality will degrade or completely drop out at certain times. This makes the previous latency goal impossible to achieve in certain scenarios, and very difficult in others.
WWAN hardware consumes a lot of power. Running it for an extended period of time requires a massive battery.

Summary of my earlier project

The system was composed of the following major components:

Raspberry Pi 4
Raspberry Pi HQ Camera
Digilent Arty Z7 (Zynq 7020) FPGA for NN inference acceleration
Sierra Wireless EM7455 4G Modem
12V 40Ah (8x 12V 5Ah) AGM battery bank, 4x BQ25756 buck-boost chargers
MCP2515 CAN transceiver to interface with the vehicle's CAN network

The AGM battery bank had two ways of charging:

With the engine running, the vehicle’s generator provided power to the four chargers
When parked, solar panels could be connected, and the BQ25798 charger ICs would do MPPT to charge the battery bank.

The Raspberry Pi 4 used its hardware H264 encoder to create a constant bitrate, 6Mbps video stream, that was sent over an OpenVPN connection to my remote server.

All sorts of metrics, along with GPS data, was logged to an InfluxDB server running on the Pi, set up to replicate data to the remote server as well. A Grafana dashboard provided easy access and nice visualizations for this.

Issues and Improvements

There were two major issues present in this implementation, but almost all parts were suboptimal in some way.

Video Streaming

The image quality, encoder efficiency, and streaming setup in general was ill-suited to this project, due to the constant bitrate (CBR) output of the Pi 4’s hardware H264 block: the encoder is given a target bitrate (bitrate here essentially refers to the ‘video size’ produced) to precisely maintain, no matter what.

This is very obviously problematic: in low complexity scenarios, like when parked, close to zero movement is happening on the video. Very little bitrate is required to produce a sufficient quality video stream (about 2Mbps roughly, in my testing).

In complex, fast movement scenarios, like when driving fast in a dense city, almost everything is always changing, and a lot higher bitrate is required to maintain the same quality (10+ Mbps).

The solution to this problem is the variable bitrate (VBR) mode. Instead of specifying a bitrate to maintain, the encoder is told what ‘visual quality’ to maintain, and it dynamically adjusts its own bitrate to keep that video quality.

The Raspberry Pi 4’s hardware encoder does not support this mode (or at least not to the extent I need it), so my crude workaround in the previous project was to lower the CBR target bitrate to 1Mbps when the engine was not running.

Hardware encoders in general tend to struggle with VBR, so addressing this issue will be one of the biggest challenges in this project.

The overall goal is to minimize bitrate to the bare minimum at all times, while maintaining a decent video quality: this minimizes the video streaming latency and lets the system function well, even with a mediocre 4G connection.

The camera’s image quality was subpar too: the IMX477 in the Pi HQ Camera is not very good in low light scenarios, and also has relatively bad dynamic range. This meant that nighttime parked footage was close to useless, as the image was pretty much completely black, nighttime driving footage was horrible due to street lights and headlights blinding the camera, and direct sunlight into the sensor also destroyed image quality in the daytime.

The MIPI link from the camera to the Pi also interfered with GPS, the whole camera was massive, and the lens FOV was terrible.

Battery and Charging

The AGM battery bank’s capacity, around 40Ah on paper, turned out to be wildly undersized. It provided enough energy for roughly 2 days of parked time. Constant cycling and deep discharging are also horrible for these batteries, so the already low capacity just kept decreasing over time.

The charger system was also suboptimal: I used 4 separate “5A” charger ICs in parallel, but the absolute maximum input current they can do is 3.3A, translating to roughly around 10A maximum charging current for the entire charger setup. This was too little to keep the batteries charged purely by the engine, when driving.

The wiring and general ‘aesthetics’ of the system were horrible too:

The CAN bus controllers and transceivers, along with the 4G modem, were also located in separate, external 'boxes', with cables attaching them to the main unit. The FPGA was just thrown in there too, with an Ethernet link to the Raspberry Pi.

Post 'Eye on Intelligence Challenge' improvements

I ended up really liking the overall concept of having an always on, real-time streaming dashcam, and improving it has been on my mind for quite some time. This SPE challenge is the perfect opportunity to do so, but the original setup was way too messy for my liking, so I made some changes soon after the end of the previous challenge, to make it actually decent, and not a fire hazard in the meantime.

Tackling the H264 constant bitrate problem was first, I solved the issue by upgrading to a Raspberry Pi 5, and doing software H264 encoding, which fully supports variable bitrate.

To fix up the wiring mess, I decided to get rid of 2 of the charger modules, and the FPGA. Halving the number of chargers might seem odd, considering that 4 of them wasn’t sufficient in the first place. The rationale was that I had to carry a second battery almost every day to swap with and charge at home anyways, and only having 2 chargers significantly simplifies the circuit, so the net result would be an improvement.

I also changed the Pi Pico for an ESP32, added a few TPS566231 buck converters, and properly soldered together a PCB to hold everything.

The end result is a much nicer contraption:

The CAN bus hat is now used as an actual HAT, and not in a separate box (don't ask me why I didn't do it this way the first time, I have absolutely no idea). However, the 4G modem remains as a dongle on a USB cable.

Plans for the next version

The revision shown above has proven to be reliable and actually useful, so let’s see what could be improved during this challenge.

Battery and Charging

By far the biggest problem is battery life and charging power. AGM batteries are not fit for this purpose, and we need a way beefier charger.

The battery life target for the new version is 3-4 days, and the charger should be powerful enough to never have to manually swap/charge batteries.

Doing some quick math with rough approximations, we arrive at this:

The system is expected to use around 10W of power.
3-4 days of battery life would thus require a 720-960Wh battery (assuming 100% depth of discharge, which is not a great idea). To give us some headroom, 1kWh would be a reasonable target.
In the time period I counted, I found that I drive my car for roughly 30 hours a month. This comes out to exactly 1 hour per day on average.
To replenish one day worth of power in one hour of driving, we’d need to charge at 240W, or roughly 20A input current to the charger, from the vehicle.

Putting a 20A charger on the same PCB as sensitive, low power electronics, would be an unwise idea. Therefore, I made the decision to create a separate ‘power management’ PCB, that will contain the charger, power monitoring and fuel gauging, protection, etc. components, along with a microcontroller, and mount them on the battery.

This would make the battery a self-contained, ‘autonomous’ system, handling its own charging and monitoring.

The Linux system running the show still needs to have some level of control and detailed statistics about the battery though. This is where Single Pair Ethernet comes in.

For such applications, there are a few important features needed in the communication link:

Isolation – while the entire setup will be sharing a common ground, it is still a good idea to have an isolated interface. Stray currents in sensitive, low noise data connections can mess things up and cause headaches. Pulling significant amps would also result in a ground offset, potentially destroying the signal. Isolation is technically overkill, but it is cheap insurance to make sure everything works perfectly.
Resiliency – the cable run between the Linux system and the power management module could be as long as 4 meters depending on where I end up positioning things, and the cables will be running alongside super noisy, high current wires. It is crucial that the link is robust, tolerates noise, and supports (relatively) long cable runs.
Simplicity – running gigabit ethernet over a fiber link would certainly meet both of the requirements above, but it’s not exactly simple, cheap, or designed for this purpose.

There are 3 reasonable options in my opinion, that fit the bill:

RS485: a full-duplex RS485 link would need two twisted pairs, and could be hooked up to a regular UART interface on a microcontroller. This option can essentially be thought of as making a regular UART/Serial interface reliable for long ranges and high noise.
CAN bus: ubiquitous for exactly this sort of application. Requires only a single pair, fixes the downsides mentioned for RS485. The protocol itself is higher level, instead of sending individual bits, data is sent in messages, with a priority system, error detection, automatic retransmission, etc.
Single Pair Ethernet: even more advanced and faster than CAN bus. Still requires a single pair only, and can be used with an entire Ethernet stack. That means things like IP addressing, QoS, VLANs, flow control, etc.

Initially, I would have opted for CAN bus, if not for this Single Pair Ethernet challenge. I did not pay much attention to SPE, as CAN bus was familiar and good enough for my past projects. However, I looked into SPE, and found that it has essentially no downsides, but lots of upsides for my project:

Way more bandwidth available: 10x faster than classic CAN.
Competitive price: while a regular, non-isolated CAN PHY is cheaper, once isolation is required, a Single Pair Ethernet PHY and magnetics end up being roughly in the same price range as an isolated CAN transceiver and controller.
Much more features and options for high level protocols.

One disadvantage that could be a dealbreaker in some use cases: SPE (or, to be more precise, 10BASE-T1L, the version we will be using) is NOT a multi-drop bus. This means that a single physical bus can only connect two devices together, much like ‘regular’ Ethernet, and a switch is required to connect more than 2 devices together.

However, there is another SPE standard, 10BASE-T1S, which solves this exact problem, making SPE work just like CAN bus in this regard: multiple devices can be connected to a single, one pair bus, without any switches or other active devices.

This challenge is about 10BASE-T1L though, which is perfectly adequate for this project.

Application Processor

The Raspberry Pi 5 works fairly well, but it’s somewhat underpowered, and also lacks a hardware video encoder, which would significantly reduce power consumption and CPU usage.

Many modern SoCs integrate a proper H264, or even H265 encoder block, that would be incredibly useful here.

Some modern GPUs contain AV1 encoders too, which would be even better than H265, but these are usually large PCIe cards, meant for desktop computers.

Power consumption is by far the biggest constraint, the entire ‘processing system’, running Linux, encoding video, along with a dozen other services, has to stay under ideally 5W.

Choosing the best possible option for our constraints will be crucial for achieving the best possible battery life and video quality.

Cameras

As mentioned earlier, the Raspberry Pi HQ Camera is not well suited to this project. Its low light performance and dynamic range are simply not sufficient. The MIPI interface is also a pain to deal with in my case.

Another issue is that the Raspberry Pi 5, and most other single board computers, only support 2 or maybe 3 MIPI interfaces at most, and I have plans to use 4+ cameras.

By far the simplest and most common interface to use would be USB, which deals reasonably well with noise and interference, supports long enough cable runs, and is trivial to get enough ports on a single board computer or any other device.

Picking the perfect camera module is a challenging task, that I will go into more detail about in a future blog post.

Planned Posts

In the upcoming posts, I will go into detail about all of the identified improvement opportunities and issues present with the current setup, and talk about picking the best way forward, obtaining parts, and building the components of the new system.

The rough plan is the following:

Part 2: Battery and Charging System
Part 3: The new ‘Compute Unit’ – the box with the SoC, modem, etc.
Part 4: Cameras and Sensors
Part 5: Single Pair Ethernet hardware, software
Final Summary Blog – showcase of the finished system and its capabilities

You might notice that most of the blogs don’t actually contain much Single Pair Ethernet related work. This is due to some unfortunate mishandling of my package containing the SPE hardware, which I still have not received, but should be arriving next week.

Waiting with the project until the arrival of the package would have certainly made it impossible to finish within the timeframe of this challenge, so I had to work on most parts without having the Single Pair Ethernet hardware in hand.

To be specific, the ‘Battery and Charging System’ (Part 2), and ‘The new Compute Unit’ (Part 3) hardware were mostly completed before any of the SPE hardware arrived, with placeholder electronics and careful preplanning. Blog 5 will be about actually adding Single Pair Ethernet to these units.

Also, massive thanks to E14Alice for helping with getting the package situation sorted out.

SPE + Radar: Part 1

Ben5049 — Tue, 03 Mar 2026 00:56:06 GMT

Hi everyone! This is my first post here and since its March aready (somehow?!) I figured I should let people know where I'm at.

For my pitch to be a challenger I discussed integrating single pair ethernet (SPE) and power over datalines (PoDL) with some really advanced single chip radar solutions from TI, namely the IWR6843. The AoP (antenna on package) version of this chip means you don't have to be a RF wizard to use them, you can just put them on your PCBs and talk to them over UART or SPI. They have 4 transmitters and 3 receivers, so unlike other mmWave radar sensors they aren't made just for presence detection, but can actually output a point cloud like those commenly used for SLAM (simultaneous localisation and mapping) in robotics.

The devkit (shown above) is quite pricey and it turned out to be cheaper to just build my own. This meant I could also strip out any uncessary components, and I had some fun trying to make it as small as possible ;). It ended up measuring just 26mm * 18mm, not bad considering it needs four voltage rails to operate!

But how to connect it? I put an FPC connector on the board which exposes the UART, but this is a single pair ethernet challenge after all. I've had an idea for a while to create ethernet PHY 'modules' that allow a plug and play approach to SPE. The idea behind this is to put all the SPE and PoDL stuff on a PCB that can be plugged into any microcontroller board with an ethernet MAC in order to give it power and data transmission. The first of these modules I've designed is for 1000BASE-T1 shown below (shoutout to the Molex 2209570001 connector!):

The other part of this stackup is a microcontroller board with an STM32N6, which is a chip I've wanted to try out for a while. I'll only be using it as a bridge between UART and ethernet here, but I've put on a connector for a camera that I intend to use in a future project. The STM32N6 is a beefy chip with an Arm Cortex M55 running at 800MHz with an NPU and MIPI CSI! Putting it all together with a flexible PCB we get the following assembly:

This has all been assembled and is set to arrive soon and in the meantime I've started working on the software, more to follow in future updates! I'll be open sourcing everything after the competition too in case anyone is interested!

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.

Please enjoy and I am very open to suggestions or even better, to pointing out any blatant mistakes I have made. community.element14.com/.../P42_2D00_SPE10baseT1L_2D00_r1.pdf

SPE face-off

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

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.

community.element14.com/.../0245.P42_2D00_SPE10baseT1L_2D00_r1.pdf

10BASE-T1L SPE using the Molex's T1 Industrial SPE

veluv01 — Tue, 24 Feb 2026 18:56:13 GMT

Introduction

In this post I'll be testing the Molex's Industrial SPE connector and cable assembly lineup, specifically the 220957 Series, rated IP67; especially for the industrial environments.

These are the specific part's I've used in my setup:

Wiring up the Molex's SPE PCB Jack

Mounting the PCB jack requires a specialized footprint and it's hard to mount on to the generic perfboard.

I began by connecting the wires, ( shorter ones, which are salvaged from a Cat6 cable) to the Molex's SPE PCB jack. I'm not entirely sure if this is the right way to connect wires to this vertical jack😅. One thing that stood out during soldering was how well the jack's plastic housing held up; despite direct heat from the soldering iron, there was no melting or deformation of the plastic support of the SPE jack.

I initially included the shielding wire attached to the connector, but after testing both configurations, the difference in performance was negligible. This was probably due to the minimal EMI noise in my testing environment and the cable length is only 1 meter, which is short when compared to the 10BASE T1L standard's maximum reach of 1 kilometer.

Molex's PCB jack spec's are interesting, supporting higher data rates but the ADIN1100 and ADIN1110 are only 10BASE-T1L compliant and the max data rate of the link is limited to 10Mbits / sec.

Attaching the Molex M12 Receptacle Shell Mount

So for my actual installation, I ended up mounting the shell mounts onto transparent acrylic sheets as they are provide a better view of everything inside the assembly and also part of the reason being I couldn't find proper enclosures😅 big enough and with the proper IP rating.

Now in terms of sealing and protection, the rubber washers protect against dust and moisture coming in from the outside.

The inner washer makes sure that the M12 cable assembly is cinching up tight and stays that way despite the vibrations.And just as JWx mentioned in his forum post, it provides IP67 rating only in mated condition along with the Molex's Plug Cable.

Here's the Front Mount dimensions and how the PCB mount fits into it.

Here's the Back Mount dimensions and how the PCB mount fits into it.

Here's some close up shots of the SPE mounts in my setup, the first one is the back mount

and the second one's the front mount attachment.

The back mount cannot be adjusted easily (i.e removed or tightened) without opening the enclosure, a more secure option when used on the outdoor units.These SPE mounts are made from brass (handles mechanical stress well and doesn't corrode easily on its own) and plated with Nickel (extremely resistant to oxidation, moisture, and the kind of atmospheric corrosion in outdoor environments).

Connecting using the Molex's T1 SPE Plug Cable Assembly

I gotta admit that this is my favorite cable in the kit, there's many reasons apart from it's design. First, just like all the Molex parts provided in the kit, this cable also handles up to 60V AC and 4 amps, which is quite impressive for the SPE's PoDL applications. Second, it has wide operating temperature range enough to use it in freezing winters or hot summers without cracking or degrading. The connector is also rated for 1000 mating cycles which is plenty for a semi permanent industrial installation.

The top part i.e the M12 screw attachment (labelled as 2 in the drawing) is the only part that rotates to screw into the front/back mount

There's also an arrow provided on it to properly orient the connector during the connection of SPE cable and the mount.

The cable itself is PUR(Polyurethane), jacketed in green, which is the standard color coding for SPE industrial cables, making identification easy in a busy panel or installation.

The M12 nut, hex nut and body shell are all brass with nickel plating, which protects against rust and corrosion in outdoor and humid conditions.

Another interesting detail worth noting is that the copper contacts inside the cable assembly are gold plated which is a meaningful design choice since it'll have better corrosion resistance over time, and more reliable signal integrity compared to standard tin plated contacts.

ADIN1100 and ADIN1110 with Molex Connectors and Cables

I've followed connecting the EVAL-ADIN1110EBZ and EVAL-ADIN1100EBZ as per the instructions provided in the user guide,

and the host computer I used in my setup is RPI4-MODBP-4GB.

Then I connected the EVAL-ADIN1100EBZ to the RPI4-MODBP-4GB and observed the stats from the webpage hosted on the EVAL-ADIN1100EBZ. The IP address of the webpage is provided through the serial connection.

MSE stands for Mean Square Error and this is the link quality indicator, measured in decibels and the more negative the number the better.The link strength in my setup was consistent at -37.2 dB which seems pretty much stable.

I still have to investigate the reasons for the dropped frames, I did change the wires but still there's some dropped frames; probably it's related to processing not the connectors and wires.

ADIN1100 and CN0575 with Molex Cables and Connectors

I connected the EVAL-ADIN1100EBZ and EVAL-CN0575-RPIZ using the Molex's T1 SPE cables and assemblies as shown below

I've connected the RPI4-MODBP-4GB to the serial port of the EVAL-ADIN1100EBZ and ran some inbuilt tests (which are provided in the default firmware) to check the link quality.

The link strength (MSE) was consistent at -37.2 dB.

Here's the log with the frame generator mode of EVAL-ADIN1100EBZ's and the link quality was consistent at the similar level, the Rx indicates the count of frames received by the PHY and Err is the number of frames with errors, which is zero so there's nothing wrong with the cable, connectors or termination.

The local ping results were also pretty consistent with zero losses.

Arrival of Pi 4

Also got my other RPI4-MODBP-4GB yesterday. Thanks E14Alice and JoRatcliffe for prompt shipment, despite the memory-driven price variations.

ADIN1110 evaluation board and 192m of UTP-5

JWx — Tue, 24 Feb 2026 18:44:21 GMT

ADIN1110 evaluation board

As we have discovered previously, ADIN1110 differs from ADIN1100 PHYs we have used so far that it includes complete Ethernet adapter (both PHY and MAC functions). In this Challenge, we were provided with evaluation boards for both ADIN1100 and ADIN1110.

External box of ADIN1110 evaluation kit is very similar to that of ADIN1100

and inside there are two components: a board and USB cable

{gallery}ADIN1110

192 meter test

Our next test would be connecting ADIN1110 evaluation board (that has on-board MCU and can serve a web page) with Raspberry PI - but before using CN-0575 shield, another interface will be used: USB 10BASE-T1L adapter that is included in AD-SWIOT1L-SL : AD-T1LUSB2.0, that is basically USB Ethernet adapter with included ADIN1100 PHY. It's block diagram is below:

Our test setup consists of

Raspberry PI
10BASE-T1L USB adapter
short run of MODBUS cable (included in AD-SWIOT1L-SL evaluation platform), later replaced with 48 meters of CAT5E UTP
USB powered ADIN1110 evaluation board in a default configuration

and is (after configuring DHCP server on Raspberry PI, because default configuration of ADIN1110 evaluation board uses dynamic address) working, serving page as below:

From this page, some interesting data can be gathered:

As we can see, it has autonegotiated as slave/follower (which is consistent with default jumper setting of "prefer follower"), some quality metric is displayed and DHCP configuration is also present.

Then, 48 meters of UTP CAT5E cable was connected instead of MODBUS cable

and? everything still worked:

what is interesting - MSE metric is the same as using MODBUS cable...

Then - in line with wolfgangfriedrich suggestion - available UTP pairs were connected in series, giving effective distance of 192 meters (and additional crosstalk between pairs).

And? The system was still working:

What is interesting - MSE metric is still the same and autonegotiation resulted in Master role (despite configured preference for follower).

Unfortunately, on Raspberry PI side ever increasing counter of receive errors was observed:

No good - although TCP retransmission retrieves those lost packets, something is wrong:

but - ICMP echo from the host is not affected, not even a single ping is lost.

After some research initial setup (with 30 cm of MODBUS cable) was restored - and lost packets were also observed:

As a conclusion - ADIN1110 works on 192 meters of low quality cable. There is some packet loss but only in very specific situation: TCP data transmitted from ADIN1110, ICMP is not affected.

At this stage it seems that this problem is elsewhere: USB adapter or Raspberry PI or maybe ADIN1110 demo software?

Additional tests are needed

Testing 10BASE-T1L on Salvaged Cat6 UTP Cable [Part -1]

veluv01 — Wed, 18 Feb 2026 08:55:06 GMT

Introduction

Some of you might be wondering or interested to look at the performance of SPE over inexpensive or bare basic cabling. I was in the same boat, and before testing with the Molex's SPE shielded twisted pair cable, I decided to run a full set of performance tests using just a pair of unshielded wires salvaged from a regular Cat6 Ethernet cable lying around. No special SPE cable, no shielding, just bare twisted pair wire of 1 meter.

Here's the Setup

The current test setup(similar to the setup in my previous post but instead of the router I'm using the Pi 4 for a Offline SPE network) has a Raspberry Pi 4 (with the Argon One case, got it since it provides better cooling and also looks cool 😅 ) as the main compute of the test setup, connected via standard Ethernet cable to an ADIN1100 media converter, which translates the signal into 10BASE - T1L. That signal then travels over the salvaged twisted pair wires to a CN0575 HAT sitting on top of a Raspberry Pi Zero 2W, which is my edge device in the test setup.

Start with the Ping !

Before throwing any heavy traffic at the link, I just pinged the Pi Zero 2W to check basic latency and stability.

The results were not disappointing, there was zero packet loss. The average round trip time was 0.665 ms, the minimum was 0.632 ms, and the maximum never went above 0.771 ms (Finally got the sub-millisecond latency which I mentioned in my previous forum post 😁 ). The standard deviation was just 0.026 ms, meaning the latency was rock steady with almost no variation between packets.

--- 169.254.158.120 ping statistics ---
100 packets transmitted, 100 received, 0% packet loss, time 20185ms
rtt min/avg/max/mdev = 0.632/0.665/0.771/0.026 ms

For a bare twisted pair wire setup, this was a great start and gave me confidence to push further.

Here's the full log

epsilon@argonpi:~ $ ping -c 100 -i 0.2 169.254.158.120
PING 169.254.158.120 (169.254.158.120) 56(84) bytes of data.
64 bytes from 169.254.158.120: icmp_seq=1 ttl=64 time=0.761 ms
64 bytes from 169.254.158.120: icmp_seq=2 ttl=64 time=0.637 ms
64 bytes from 169.254.158.120: icmp_seq=3 ttl=64 time=0.643 ms
64 bytes from 169.254.158.120: icmp_seq=4 ttl=64 time=0.655 ms
64 bytes from 169.254.158.120: icmp_seq=5 ttl=64 time=0.646 ms
64 bytes from 169.254.158.120: icmp_seq=6 ttl=64 time=0.639 ms
64 bytes from 169.254.158.120: icmp_seq=7 ttl=64 time=0.650 ms
64 bytes from 169.254.158.120: icmp_seq=8 ttl=64 time=0.644 ms
64 bytes from 169.254.158.120: icmp_seq=9 ttl=64 time=0.694 ms
64 bytes from 169.254.158.120: icmp_seq=10 ttl=64 time=0.658 ms
64 bytes from 169.254.158.120: icmp_seq=11 ttl=64 time=0.639 ms
64 bytes from 169.254.158.120: icmp_seq=12 ttl=64 time=0.655 ms
64 bytes from 169.254.158.120: icmp_seq=13 ttl=64 time=0.714 ms
64 bytes from 169.254.158.120: icmp_seq=14 ttl=64 time=0.664 ms
64 bytes from 169.254.158.120: icmp_seq=15 ttl=64 time=0.673 ms
64 bytes from 169.254.158.120: icmp_seq=16 ttl=64 time=0.660 ms
64 bytes from 169.254.158.120: icmp_seq=17 ttl=64 time=0.644 ms
64 bytes from 169.254.158.120: icmp_seq=18 ttl=64 time=0.646 ms
64 bytes from 169.254.158.120: icmp_seq=19 ttl=64 time=0.643 ms
64 bytes from 169.254.158.120: icmp_seq=20 ttl=64 time=0.666 ms
64 bytes from 169.254.158.120: icmp_seq=21 ttl=64 time=0.693 ms
64 bytes from 169.254.158.120: icmp_seq=22 ttl=64 time=0.655 ms
64 bytes from 169.254.158.120: icmp_seq=23 ttl=64 time=0.661 ms
64 bytes from 169.254.158.120: icmp_seq=24 ttl=64 time=0.650 ms
64 bytes from 169.254.158.120: icmp_seq=25 ttl=64 time=0.664 ms
64 bytes from 169.254.158.120: icmp_seq=26 ttl=64 time=0.664 ms
64 bytes from 169.254.158.120: icmp_seq=27 ttl=64 time=0.644 ms
64 bytes from 169.254.158.120: icmp_seq=28 ttl=64 time=0.667 ms
64 bytes from 169.254.158.120: icmp_seq=29 ttl=64 time=0.639 ms
64 bytes from 169.254.158.120: icmp_seq=30 ttl=64 time=0.648 ms
64 bytes from 169.254.158.120: icmp_seq=31 ttl=64 time=0.656 ms
64 bytes from 169.254.158.120: icmp_seq=32 ttl=64 time=0.644 ms
64 bytes from 169.254.158.120: icmp_seq=33 ttl=64 time=0.633 ms
64 bytes from 169.254.158.120: icmp_seq=34 ttl=64 time=0.728 ms
64 bytes from 169.254.158.120: icmp_seq=35 ttl=64 time=0.675 ms
64 bytes from 169.254.158.120: icmp_seq=36 ttl=64 time=0.644 ms
64 bytes from 169.254.158.120: icmp_seq=37 ttl=64 time=0.653 ms
64 bytes from 169.254.158.120: icmp_seq=38 ttl=64 time=0.644 ms
64 bytes from 169.254.158.120: icmp_seq=39 ttl=64 time=0.674 ms
64 bytes from 169.254.158.120: icmp_seq=40 ttl=64 time=0.673 ms
64 bytes from 169.254.158.120: icmp_seq=41 ttl=64 time=0.653 ms
64 bytes from 169.254.158.120: icmp_seq=42 ttl=64 time=0.670 ms
64 bytes from 169.254.158.120: icmp_seq=43 ttl=64 time=0.707 ms
64 bytes from 169.254.158.120: icmp_seq=44 ttl=64 time=0.645 ms
64 bytes from 169.254.158.120: icmp_seq=45 ttl=64 time=0.648 ms
64 bytes from 169.254.158.120: icmp_seq=46 ttl=64 time=0.720 ms
64 bytes from 169.254.158.120: icmp_seq=47 ttl=64 time=0.653 ms
64 bytes from 169.254.158.120: icmp_seq=48 ttl=64 time=0.666 ms
64 bytes from 169.254.158.120: icmp_seq=49 ttl=64 time=0.662 ms
64 bytes from 169.254.158.120: icmp_seq=50 ttl=64 time=0.707 ms
64 bytes from 169.254.158.120: icmp_seq=51 ttl=64 time=0.665 ms
64 bytes from 169.254.158.120: icmp_seq=52 ttl=64 time=0.732 ms
64 bytes from 169.254.158.120: icmp_seq=53 ttl=64 time=0.649 ms
64 bytes from 169.254.158.120: icmp_seq=54 ttl=64 time=0.666 ms
64 bytes from 169.254.158.120: icmp_seq=55 ttl=64 time=0.659 ms
64 bytes from 169.254.158.120: icmp_seq=56 ttl=64 time=0.657 ms
64 bytes from 169.254.158.120: icmp_seq=57 ttl=64 time=0.660 ms
64 bytes from 169.254.158.120: icmp_seq=58 ttl=64 time=0.725 ms
64 bytes from 169.254.158.120: icmp_seq=59 ttl=64 time=0.680 ms
64 bytes from 169.254.158.120: icmp_seq=60 ttl=64 time=0.668 ms
64 bytes from 169.254.158.120: icmp_seq=61 ttl=64 time=0.662 ms
64 bytes from 169.254.158.120: icmp_seq=62 ttl=64 time=0.659 ms
64 bytes from 169.254.158.120: icmp_seq=63 ttl=64 time=0.652 ms
64 bytes from 169.254.158.120: icmp_seq=64 ttl=64 time=0.646 ms
64 bytes from 169.254.158.120: icmp_seq=65 ttl=64 time=0.665 ms
64 bytes from 169.254.158.120: icmp_seq=66 ttl=64 time=0.656 ms
64 bytes from 169.254.158.120: icmp_seq=67 ttl=64 time=0.666 ms
64 bytes from 169.254.158.120: icmp_seq=68 ttl=64 time=0.664 ms
64 bytes from 169.254.158.120: icmp_seq=69 ttl=64 time=0.660 ms
64 bytes from 169.254.158.120: icmp_seq=70 ttl=64 time=0.771 ms
64 bytes from 169.254.158.120: icmp_seq=71 ttl=64 time=0.673 ms
64 bytes from 169.254.158.120: icmp_seq=72 ttl=64 time=0.661 ms
64 bytes from 169.254.158.120: icmp_seq=73 ttl=64 time=0.677 ms
64 bytes from 169.254.158.120: icmp_seq=74 ttl=64 time=0.717 ms
64 bytes from 169.254.158.120: icmp_seq=75 ttl=64 time=0.669 ms
64 bytes from 169.254.158.120: icmp_seq=76 ttl=64 time=0.677 ms
64 bytes from 169.254.158.120: icmp_seq=77 ttl=64 time=0.654 ms
64 bytes from 169.254.158.120: icmp_seq=78 ttl=64 time=0.663 ms
64 bytes from 169.254.158.120: icmp_seq=79 ttl=64 time=0.664 ms
64 bytes from 169.254.158.120: icmp_seq=80 ttl=64 time=0.676 ms
64 bytes from 169.254.158.120: icmp_seq=81 ttl=64 time=0.655 ms
64 bytes from 169.254.158.120: icmp_seq=82 ttl=64 time=0.653 ms
64 bytes from 169.254.158.120: icmp_seq=83 ttl=64 time=0.703 ms
64 bytes from 169.254.158.120: icmp_seq=84 ttl=64 time=0.634 ms
64 bytes from 169.254.158.120: icmp_seq=85 ttl=64 time=0.678 ms
64 bytes from 169.254.158.120: icmp_seq=86 ttl=64 time=0.648 ms
64 bytes from 169.254.158.120: icmp_seq=87 ttl=64 time=0.665 ms
64 bytes from 169.254.158.120: icmp_seq=88 ttl=64 time=0.662 ms
64 bytes from 169.254.158.120: icmp_seq=89 ttl=64 time=0.654 ms
64 bytes from 169.254.158.120: icmp_seq=90 ttl=64 time=0.661 ms
64 bytes from 169.254.158.120: icmp_seq=91 ttl=64 time=0.644 ms
64 bytes from 169.254.158.120: icmp_seq=92 ttl=64 time=0.708 ms
64 bytes from 169.254.158.120: icmp_seq=93 ttl=64 time=0.656 ms
64 bytes from 169.254.158.120: icmp_seq=94 ttl=64 time=0.638 ms
64 bytes from 169.254.158.120: icmp_seq=95 ttl=64 time=0.724 ms
64 bytes from 169.254.158.120: icmp_seq=96 ttl=64 time=0.655 ms
64 bytes from 169.254.158.120: icmp_seq=97 ttl=64 time=0.633 ms
64 bytes from 169.254.158.120: icmp_seq=98 ttl=64 time=0.651 ms
64 bytes from 169.254.158.120: icmp_seq=99 ttl=64 time=0.632 ms
64 bytes from 169.254.158.120: icmp_seq=100 ttl=64 time=0.650 ms

--- 169.254.158.120 ping statistics ---
100 packets transmitted, 100 received, 0% packet loss, time 20185ms
rtt min/avg/max/mdev = 0.632/0.665/0.771/0.026 ms

UDP test for the 10BASE 1TL SPE

What's the UDP? and what does this test evaluate? UDP stands for User Datagram Protocol, but you can think of it like dropping a stack of letters into a street mailbox. You toss them in and walk away. You don't get a tracking number to confirm they arrived, there is no system to request a resend if a letter gets lost, and we certainly don't slow down just because the recipient is overwhelmed. UDP just fires packets out at whatever speed we choose and moves on. Because of this, UDP is the most honest way to test the capcity of a physical link.This makes it perfect for measuring two specific things. First, it shows if the connection is clear enough to carry data without losing or breaking packets because there is nothing hiding/masking those errors. Second, it reveals if the receiving end can actually keep up with the traffic because again there is no feedback mechanism to slow things down if the receiver is struggling to process it.

The iperf UDP test inferred some interesting observations. The Pi 4 transmitted at a steady 10 Mbps and had no way of knowing the Pi Zero 2W was struggling to keep up. Because UDP does not verify that data arrived, the Pi 4 just kept going and reported that it sent all of them with zero errors.

- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-100.00 sec   119 MBytes  10.0 Mbits/sec  0.000 ms  0/86327 (0%)  sender
[  5]   0.00-100.05 sec   114 MBytes  9.56 Mbits/sec  0.076 ms  0/86310 (0%)  receiver

Here's the Client side log

epsilon@argonpi:~ $ iperf3 -c 169.254.158.120 -u -b 10M -t 100
Connecting to host 169.254.158.120, port 5201
[  5] local 169.254.158.1 port 33705 connected to 169.254.158.120 port 5201
[ ID] Interval           Transfer     Bitrate         Total Datagrams
[  5]   0.00-1.00   sec  1.19 MBytes  10.0 Mbits/sec  865  
[  5]   1.00-2.00   sec  1.19 MBytes  10.0 Mbits/sec  863  
[  5]   2.00-3.00   sec  1.19 MBytes  10.0 Mbits/sec  863  
[  5]   3.00-4.00   sec  1.19 MBytes  10.0 Mbits/sec  863  
[  5]   4.00-5.00   sec  1.19 MBytes  10.0 Mbits/sec  864  
[  5]   5.00-6.00   sec  1.19 MBytes  10.0 Mbits/sec  863  
[  5]   6.00-7.00   sec  1.19 MBytes  9.99 Mbits/sec  863  
[  5]   7.00-8.00   sec  1.19 MBytes  10.0 Mbits/sec  863  
[  5]   8.00-9.00   sec  1.19 MBytes  10.0 Mbits/sec  864  
[  5]   9.00-10.00  sec  1.19 MBytes  10.0 Mbits/sec  863  
[  5]  10.00-11.00  sec  1.19 MBytes  10.0 Mbits/sec  863  
[  5]  11.00-12.00  sec  1.19 MBytes  9.99 Mbits/sec  863  
[  5]  12.00-13.00  sec  1.19 MBytes  10.0 Mbits/sec  864  
[  5]  13.00-14.00  sec  1.19 MBytes  10.0 Mbits/sec  863  
[  5]  14.00-15.00  sec  1.19 MBytes  10.0 Mbits/sec  863  
[  5]  15.00-16.00  sec  1.19 MBytes  9.99 Mbits/sec  863  
[  5]  16.00-17.00  sec  1.19 MBytes  10.0 Mbits/sec  864  
[  5]  17.00-18.00  sec  1.19 MBytes  10.0 Mbits/sec  863  
[  5]  18.00-19.00  sec  1.19 MBytes  10.0 Mbits/sec  863  
[  5]  19.00-20.00  sec  1.19 MBytes  10.0 Mbits/sec  864  
[  5]  20.00-21.00  sec  1.19 MBytes  10.0 Mbits/sec  863  
[  5]  21.00-22.00  sec  1.19 MBytes  9.99 Mbits/sec  863  
[  5]  22.00-23.00  sec  1.19 MBytes  10.0 Mbits/sec  863  
[  5]  23.00-24.00  sec  1.19 MBytes  10.0 Mbits/sec  864  
[  5]  24.00-25.00  sec  1.19 MBytes  10.0 Mbits/sec  863  
[  5]  25.00-26.00  sec  1.19 MBytes  10.0 Mbits/sec  863  
[  5]  26.00-27.00  sec  1.19 MBytes  9.99 Mbits/sec  863  
[  5]  27.00-28.00  sec  1.19 MBytes  10.0 Mbits/sec  864  
[  5]  28.00-29.00  sec  1.19 MBytes  10.0 Mbits/sec  863  
[  5]  29.00-30.00  sec  1.19 MBytes  10.0 Mbits/sec  863  
[  5]  30.00-31.00  sec  1.19 MBytes  10.0 Mbits/sec  863  
[  5]  31.00-32.00  sec  1.19 MBytes  10.0 Mbits/sec  864  
[  5]  32.00-33.00  sec  1.19 MBytes  10.0 Mbits/sec  863  
[  5]  33.00-34.00  sec  1.19 MBytes  10.0 Mbits/sec  863  
[  5]  34.00-35.00  sec  1.19 MBytes  10.0 Mbits/sec  863  
[  5]  35.00-36.00  sec  1.19 MBytes  10.0 Mbits/sec  864  
[  5]  36.00-37.00  sec  1.19 MBytes  10.0 Mbits/sec  863  
[  5]  37.00-38.00  sec  1.19 MBytes  10.0 Mbits/sec  863  
[  5]  38.00-39.00  sec  1.19 MBytes  10.0 Mbits/sec  863  
[  5]  39.00-40.00  sec  1.19 MBytes  10.0 Mbits/sec  864  
[  5]  40.00-41.00  sec  1.19 MBytes  10.0 Mbits/sec  863  
[  5]  41.00-42.00  sec  1.19 MBytes  10.0 Mbits/sec  863  
[  5]  42.00-43.00  sec  1.19 MBytes  10.0 Mbits/sec  863  
[  5]  43.00-44.00  sec  1.19 MBytes  10.0 Mbits/sec  864  
[  5]  44.00-45.00  sec  1.19 MBytes  10.0 Mbits/sec  863  
[  5]  45.00-46.00  sec  1.19 MBytes  10.0 Mbits/sec  863  
[  5]  46.00-47.00  sec  1.19 MBytes  10.0 Mbits/sec  864  
[  5]  47.00-48.00  sec  1.19 MBytes  10.0 Mbits/sec  863  
[  5]  48.00-49.00  sec  1.19 MBytes  10.0 Mbits/sec  863  
[  5]  49.00-50.00  sec  1.19 MBytes  10.0 Mbits/sec  863  
[  5]  50.00-51.00  sec  1.19 MBytes  10.0 Mbits/sec  864  
[  5]  51.00-52.00  sec  1.19 MBytes  10.0 Mbits/sec  863  
[  5]  52.00-53.00  sec  1.19 MBytes  10.0 Mbits/sec  863  
[  5]  53.00-54.00  sec  1.19 MBytes  10.0 Mbits/sec  863  
[  5]  54.00-55.00  sec  1.19 MBytes  10.0 Mbits/sec  864  
[  5]  55.00-56.00  sec  1.19 MBytes  10.0 Mbits/sec  863  
[  5]  56.00-57.00  sec  1.19 MBytes  9.99 Mbits/sec  863  
[  5]  57.00-58.00  sec  1.19 MBytes  10.0 Mbits/sec  863  
[  5]  58.00-59.00  sec  1.19 MBytes  10.0 Mbits/sec  864  
[  5]  59.00-60.00  sec  1.19 MBytes  10.0 Mbits/sec  863  
[  5]  60.00-61.00  sec  1.19 MBytes  10.0 Mbits/sec  863  
[  5]  61.00-62.00  sec  1.19 MBytes  9.99 Mbits/sec  863  
[  5]  62.00-63.00  sec  1.19 MBytes  10.0 Mbits/sec  864  
[  5]  63.00-64.00  sec  1.19 MBytes  9.99 Mbits/sec  863  
[  5]  64.00-65.00  sec  1.19 MBytes  10.0 Mbits/sec  863  
[  5]  65.00-66.00  sec  1.19 MBytes  10.0 Mbits/sec  863  
[  5]  66.00-67.00  sec  1.19 MBytes  10.0 Mbits/sec  864  
[  5]  67.00-68.00  sec  1.19 MBytes  10.0 Mbits/sec  863  
[  5]  68.00-69.00  sec  1.19 MBytes  10.0 Mbits/sec  863  
[  5]  69.00-70.00  sec  1.19 MBytes  10.0 Mbits/sec  864  
[  5]  70.00-71.00  sec  1.19 MBytes  10.0 Mbits/sec  863  
[  5]  71.00-72.00  sec  1.19 MBytes  10.0 Mbits/sec  863  
[  5]  72.00-73.00  sec  1.19 MBytes  10.0 Mbits/sec  863  
[  5]  73.00-74.00  sec  1.19 MBytes  10.0 Mbits/sec  864  
[  5]  74.00-75.00  sec  1.19 MBytes  10.0 Mbits/sec  863  
[  5]  75.00-76.00  sec  1.19 MBytes  10.0 Mbits/sec  863  
[  5]  76.00-77.00  sec  1.19 MBytes  10.0 Mbits/sec  863  
[  5]  77.00-78.00  sec  1.19 MBytes  10.0 Mbits/sec  864  
[  5]  78.00-79.00  sec  1.19 MBytes  10.0 Mbits/sec  863  
[  5]  79.00-80.00  sec  1.19 MBytes  10.0 Mbits/sec  863  
[  5]  80.00-81.00  sec  1.19 MBytes  10.0 Mbits/sec  863  
[  5]  81.00-82.00  sec  1.19 MBytes  10.0 Mbits/sec  864  
[  5]  82.00-83.00  sec  1.19 MBytes  10.0 Mbits/sec  863  
[  5]  83.00-84.00  sec  1.19 MBytes  10.0 Mbits/sec  863  
[  5]  84.00-85.00  sec  1.19 MBytes  10.0 Mbits/sec  863  
[  5]  85.00-86.00  sec  1.19 MBytes  10.0 Mbits/sec  864  
[  5]  86.00-87.00  sec  1.19 MBytes  10.0 Mbits/sec  863  
[  5]  87.00-88.00  sec  1.19 MBytes  9.99 Mbits/sec  863  
[  5]  88.00-89.00  sec  1.19 MBytes  10.0 Mbits/sec  863  
[  5]  89.00-90.00  sec  1.19 MBytes  10.0 Mbits/sec  864  
[  5]  90.00-91.00  sec  1.19 MBytes  10.0 Mbits/sec  863  
[  5]  91.00-92.00  sec  1.19 MBytes  9.99 Mbits/sec  863  
[  5]  92.00-93.00  sec  1.19 MBytes  10.0 Mbits/sec  864  
[  5]  93.00-94.00  sec  1.19 MBytes  10.0 Mbits/sec  863  
[  5]  94.00-95.00  sec  1.19 MBytes  10.0 Mbits/sec  863  
[  5]  95.00-96.00  sec  1.19 MBytes  10.0 Mbits/sec  863  
[  5]  96.00-97.00  sec  1.19 MBytes  9.99 Mbits/sec  863  
[  5]  97.00-98.00  sec  1.19 MBytes  10.0 Mbits/sec  864  
[  5]  98.00-99.00  sec  1.19 MBytes  10.0 Mbits/sec  863  
[  5]  99.00-100.00 sec  1.19 MBytes  9.99 Mbits/sec  863  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-100.00 sec   119 MBytes  10.0 Mbits/sec  0.000 ms  0/86327 (0%)  sender
[  5]   0.00-100.05 sec   114 MBytes  9.56 Mbits/sec  0.076 ms  0/86310 (0%)  receiver

iperf Done.

However, the server log on the Pi Zero 2W revealed the hidden loss of datagrams.

- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-100.05 sec   114 MBytes  9.56 Mbits/sec  0.076 ms  3746/86310 (4.3%)  receiver
-----------------------------------------------------------

The Pi Zero 2W was consistently dropping about 4.3% of the incoming packets. That is roughly 3,746 lost packets over 100 seconds. Since the jitter remained very low, probably the physical link was not the problem? Maybe the real bottleneck was with either the overhead (or the SPI ?) or the Pi Zero 2W.

Here's the server (Pi Zero 2W) side log

Accepted connection from 169.254.158.1, port 60302
[  5] local 169.254.158.120 port 5201 connected to 169.254.158.1 port 33705
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-1.00   sec  1.09 MBytes  9.15 Mbits/sec  0.135 ms  4/794 (0.5%)  
[  5]   1.00-2.00   sec  1.14 MBytes  9.57 Mbits/sec  0.095 ms  45/871 (5.2%)  
[  5]   2.00-3.00   sec  1.14 MBytes  9.57 Mbits/sec  0.140 ms  40/866 (4.6%)  
[  5]   3.00-4.00   sec  1.14 MBytes  9.56 Mbits/sec  0.061 ms  35/860 (4.1%)  
[  5]   4.00-5.00   sec  1.14 MBytes  9.57 Mbits/sec  0.074 ms  36/862 (4.2%)  
[  5]   5.00-6.00   sec  1.14 MBytes  9.56 Mbits/sec  0.140 ms  39/864 (4.5%)  
[  5]   6.00-7.00   sec  1.14 MBytes  9.57 Mbits/sec  0.142 ms  38/864 (4.4%)  
[  5]   7.00-8.00   sec  1.14 MBytes  9.56 Mbits/sec  0.123 ms  39/864 (4.5%)  
[  5]   8.00-9.00   sec  1.14 MBytes  9.57 Mbits/sec  0.108 ms  38/864 (4.4%)  
[  5]   9.00-10.00  sec  1.14 MBytes  9.57 Mbits/sec  0.054 ms  35/861 (4.1%)  
[  5]  10.00-11.00  sec  1.14 MBytes  9.56 Mbits/sec  0.081 ms  37/862 (4.3%)  
[  5]  11.00-12.00  sec  1.14 MBytes  9.57 Mbits/sec  0.090 ms  38/864 (4.4%)  
[  5]  12.00-13.00  sec  1.14 MBytes  9.56 Mbits/sec  0.150 ms  39/864 (4.5%)  
[  5]  13.00-14.00  sec  1.14 MBytes  9.57 Mbits/sec  0.115 ms  38/864 (4.4%)  
[  5]  14.00-15.00  sec  1.14 MBytes  9.56 Mbits/sec  0.103 ms  39/864 (4.5%)  
[  5]  15.00-16.00  sec  1.14 MBytes  9.57 Mbits/sec  0.057 ms  35/861 (4.1%)  
[  5]  16.00-17.00  sec  1.14 MBytes  9.57 Mbits/sec  0.106 ms  37/863 (4.3%)  
[  5]  17.00-18.00  sec  1.14 MBytes  9.56 Mbits/sec  0.128 ms  38/863 (4.4%)  
[  5]  18.00-19.00  sec  1.14 MBytes  9.57 Mbits/sec  0.142 ms  38/864 (4.4%)  
[  5]  19.00-20.00  sec  1.14 MBytes  9.56 Mbits/sec  0.129 ms  38/863 (4.4%)  
[  5]  20.00-21.00  sec  1.14 MBytes  9.57 Mbits/sec  0.128 ms  38/864 (4.4%)  
[  5]  21.00-22.00  sec  1.14 MBytes  9.56 Mbits/sec  0.179 ms  38/863 (4.4%)  
[  5]  22.00-23.00  sec  1.14 MBytes  9.57 Mbits/sec  0.095 ms  39/865 (4.5%)  
[  5]  23.00-24.00  sec  1.14 MBytes  9.57 Mbits/sec  0.054 ms  35/861 (4.1%)  
[  5]  24.00-25.00  sec  1.14 MBytes  9.56 Mbits/sec  0.115 ms  37/862 (4.3%)  
[  5]  25.00-26.00  sec  1.14 MBytes  9.57 Mbits/sec  0.114 ms  38/864 (4.4%)  
[  5]  26.00-27.00  sec  1.14 MBytes  9.56 Mbits/sec  0.138 ms  39/864 (4.5%)  
[  5]  27.00-28.00  sec  1.14 MBytes  9.57 Mbits/sec  0.195 ms  38/864 (4.4%)  
[  5]  28.00-29.00  sec  1.14 MBytes  9.56 Mbits/sec  0.056 ms  37/862 (4.3%)  
[  5]  29.00-30.00  sec  1.14 MBytes  9.57 Mbits/sec  0.083 ms  36/862 (4.2%)  
[  5]  30.00-31.00  sec  1.14 MBytes  9.57 Mbits/sec  0.103 ms  38/864 (4.4%)  
[  5]  31.00-32.00  sec  1.14 MBytes  9.56 Mbits/sec  0.096 ms  38/863 (4.4%)  
[  5]  32.00-33.00  sec  1.14 MBytes  9.57 Mbits/sec  0.139 ms  39/865 (4.5%)  
[  5]  33.00-34.00  sec  1.14 MBytes  9.56 Mbits/sec  0.200 ms  38/863 (4.4%)  
[  5]  34.00-35.00  sec  1.14 MBytes  9.55 Mbits/sec  0.104 ms  30/855 (3.5%)  
[  5]  35.00-36.00  sec  1.14 MBytes  9.56 Mbits/sec  0.170 ms  47/872 (5.4%)  
[  5]  36.00-37.00  sec  1.14 MBytes  9.57 Mbits/sec  0.087 ms  36/862 (4.2%)  
[  5]  37.00-38.00  sec  1.14 MBytes  9.56 Mbits/sec  0.142 ms  39/864 (4.5%)  
[  5]  38.00-39.00  sec  1.14 MBytes  9.57 Mbits/sec  0.068 ms  37/863 (4.3%)  
[  5]  39.00-40.00  sec  1.14 MBytes  9.57 Mbits/sec  0.267 ms  35/861 (4.1%)  
[  5]  40.00-41.00  sec  1.14 MBytes  9.56 Mbits/sec  0.119 ms  38/863 (4.4%)  
[  5]  41.00-42.00  sec  1.14 MBytes  9.57 Mbits/sec  0.133 ms  38/864 (4.4%)  
[  5]  42.00-43.00  sec  1.14 MBytes  9.56 Mbits/sec  0.268 ms  37/862 (4.3%)  
[  5]  43.00-44.00  sec  1.14 MBytes  9.57 Mbits/sec  0.123 ms  39/865 (4.5%)  
[  5]  44.00-45.00  sec  1.14 MBytes  9.56 Mbits/sec  0.110 ms  39/864 (4.5%)  
[  5]  45.00-46.00  sec  1.14 MBytes  9.57 Mbits/sec  0.058 ms  37/863 (4.3%)  
[  5]  46.00-47.00  sec  1.14 MBytes  9.57 Mbits/sec  0.053 ms  35/861 (4.1%)  
[  5]  47.00-48.00  sec  1.14 MBytes  9.56 Mbits/sec  0.137 ms  39/864 (4.5%)  
[  5]  48.00-49.00  sec  1.14 MBytes  9.57 Mbits/sec  0.120 ms  38/864 (4.4%)  
[  5]  49.00-50.00  sec  1.14 MBytes  9.56 Mbits/sec  0.100 ms  38/863 (4.4%)  
[  5]  50.00-51.00  sec  1.14 MBytes  9.57 Mbits/sec  0.112 ms  39/865 (4.5%)  
[  5]  51.00-52.00  sec  1.14 MBytes  9.56 Mbits/sec  0.061 ms  37/862 (4.3%)  
[  5]  52.00-53.00  sec  1.14 MBytes  9.57 Mbits/sec  0.052 ms  35/861 (4.1%)  
[  5]  53.00-54.00  sec  1.14 MBytes  9.57 Mbits/sec  0.098 ms  38/864 (4.4%)  
[  5]  54.00-55.00  sec  1.14 MBytes  9.56 Mbits/sec  0.110 ms  38/863 (4.4%)  
[  5]  55.00-56.00  sec  1.14 MBytes  9.57 Mbits/sec  0.122 ms  38/864 (4.4%)  
[  5]  56.00-57.00  sec  1.14 MBytes  9.56 Mbits/sec  0.167 ms  39/864 (4.5%)  
[  5]  57.00-58.00  sec  1.14 MBytes  9.57 Mbits/sec  0.085 ms  37/863 (4.3%)  
[  5]  58.00-59.00  sec  1.14 MBytes  9.56 Mbits/sec  0.133 ms  39/864 (4.5%)  
[  5]  59.00-60.00  sec  1.14 MBytes  9.57 Mbits/sec  0.072 ms  37/863 (4.3%)  
[  5]  60.00-61.00  sec  1.14 MBytes  9.56 Mbits/sec  0.101 ms  35/860 (4.1%)  
[  5]  61.00-62.00  sec  1.14 MBytes  9.57 Mbits/sec  0.091 ms  38/864 (4.4%)  
[  5]  62.00-63.00  sec  1.14 MBytes  9.57 Mbits/sec  0.166 ms  39/865 (4.5%)  
[  5]  63.00-64.00  sec  1.14 MBytes  9.56 Mbits/sec  0.130 ms  38/863 (4.4%)  
[  5]  64.00-65.00  sec  1.14 MBytes  9.57 Mbits/sec  0.150 ms  39/865 (4.5%)  
[  5]  65.00-66.00  sec  1.14 MBytes  9.56 Mbits/sec  0.058 ms  36/861 (4.2%)  
[  5]  66.00-67.00  sec  1.14 MBytes  9.57 Mbits/sec  0.097 ms  36/862 (4.2%)  
[  5]  67.00-68.00  sec  1.14 MBytes  9.56 Mbits/sec  0.132 ms  38/863 (4.4%)  
[  5]  68.00-69.00  sec  1.14 MBytes  9.57 Mbits/sec  0.082 ms  37/863 (4.3%)  
[  5]  69.00-70.00  sec  1.14 MBytes  9.57 Mbits/sec  0.093 ms  39/865 (4.5%)  
[  5]  70.00-71.00  sec  1.14 MBytes  9.56 Mbits/sec  0.107 ms  39/864 (4.5%)  
[  5]  71.00-72.00  sec  1.14 MBytes  9.56 Mbits/sec  0.088 ms  35/860 (4.1%)  
[  5]  72.00-73.00  sec  1.14 MBytes  9.56 Mbits/sec  0.135 ms  41/866 (4.7%)  
[  5]  73.00-74.00  sec  1.14 MBytes  9.57 Mbits/sec  0.153 ms  39/865 (4.5%)  
[  5]  74.00-75.00  sec  1.14 MBytes  9.56 Mbits/sec  0.072 ms  37/862 (4.3%)  
[  5]  75.00-76.00  sec  1.14 MBytes  9.57 Mbits/sec  0.057 ms  35/861 (4.1%)  
[  5]  76.00-77.00  sec  1.14 MBytes  9.56 Mbits/sec  0.136 ms  38/863 (4.4%)  
[  5]  77.00-78.00  sec  1.14 MBytes  9.57 Mbits/sec  0.108 ms  38/864 (4.4%)  
[  5]  78.00-79.00  sec  1.14 MBytes  9.57 Mbits/sec  0.135 ms  39/865 (4.5%)  
[  5]  79.00-80.00  sec  1.14 MBytes  9.56 Mbits/sec  0.161 ms  39/864 (4.5%)  
[  5]  80.00-81.00  sec  1.14 MBytes  9.57 Mbits/sec  0.123 ms  39/865 (4.5%)  
[  5]  81.00-82.00  sec  1.14 MBytes  9.56 Mbits/sec  0.054 ms  35/860 (4.1%)  
[  5]  82.00-83.00  sec  1.14 MBytes  9.57 Mbits/sec  0.136 ms  38/864 (4.4%)  
[  5]  83.00-84.00  sec  1.14 MBytes  9.56 Mbits/sec  0.110 ms  38/863 (4.4%)  
[  5]  84.00-85.00  sec  1.14 MBytes  9.57 Mbits/sec  0.100 ms  38/864 (4.4%)  
[  5]  85.00-86.00  sec  1.14 MBytes  9.57 Mbits/sec  0.170 ms  40/866 (4.6%)  
[  5]  86.00-87.00  sec  1.14 MBytes  9.56 Mbits/sec  0.159 ms  39/864 (4.5%)  
[  5]  87.00-88.00  sec  1.14 MBytes  9.57 Mbits/sec  0.053 ms  35/861 (4.1%)  
[  5]  88.00-89.00  sec  1.14 MBytes  9.56 Mbits/sec  0.097 ms  37/862 (4.3%)  
[  5]  89.00-90.00  sec  1.14 MBytes  9.57 Mbits/sec  0.083 ms  38/864 (4.4%)  
[  5]  90.00-91.00  sec  1.14 MBytes  9.56 Mbits/sec  0.094 ms  39/864 (4.5%)  
[  5]  91.00-92.00  sec  1.14 MBytes  9.57 Mbits/sec  0.151 ms  40/866 (4.6%)  
[  5]  92.00-93.00  sec  1.14 MBytes  9.57 Mbits/sec  0.091 ms  38/864 (4.4%)  
[  5]  93.00-94.00  sec  1.14 MBytes  9.56 Mbits/sec  0.054 ms  35/860 (4.1%)  
[  5]  94.00-95.00  sec  1.14 MBytes  9.57 Mbits/sec  0.099 ms  38/864 (4.4%)  
[  5]  95.00-96.00  sec  1.14 MBytes  9.56 Mbits/sec  0.085 ms  38/863 (4.4%)  
[  5]  96.00-97.00  sec  1.14 MBytes  9.57 Mbits/sec  0.132 ms  39/865 (4.5%)  
[  5]  97.00-98.00  sec  1.14 MBytes  9.56 Mbits/sec  0.118 ms  39/864 (4.5%)  
[  5]  98.00-99.00  sec  1.14 MBytes  9.57 Mbits/sec  0.095 ms  39/865 (4.5%)  
[  5]  99.00-100.00 sec  1.14 MBytes  9.57 Mbits/sec  0.053 ms  35/861 (4.1%)  
[  5] 100.00-100.05 sec  62.2 KBytes  9.32 Mbits/sec  0.076 ms  1/45 (2.2%)  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-100.05 sec   114 MBytes  9.56 Mbits/sec  0.076 ms  3746/86310 (4.3%)  receiver

I'll follow up with the TCP tests in the next forum post.

10BASE-T1L normative reference

JWx — Mon, 16 Feb 2026 23:07:34 GMT

As every datasheet of Single Pair Ethernet component that I have encountered states, 10BASE-T1L is specified by IEEE 802.3CG recommendation.

Unfortunately, according to the IEEE website, last version of that specification, 802.3cg-2019 is marked as superseded.

What makes things worse, there is no clear information by what it is superseded...

This situation is clearly different than for example RFC Internet standard stack, where every obsoleted standard is not only marked as such, but a successor standard is linked (example below)

So - by what is 802.3CG superseded?

IEEE website doesn't mention it neither as "active project" or "active standard", but current version of the main 802.3 specification includes "Historical participants" section with the following description:

The following individuals participated in the IEEE 802.3 working group during various stages of the
standard’s development. Since the initial publication, many IEEE standards have added functionality or
provided updates to material included in this standard. Included is a historical list of participants who have
dedicated their valuable time, energy, and knowledge to the creation of this material:

in which 802.3cg is listed

IEEE Std 802.3cg-2019 Physical Layers Specifications and Management Parameters for 10 Mb/s Operation and Associated Power Delivery over a Single Balanced Pair of Conductors

802.3-2018 doesn't include the above mention, which reinforces the conclusion that 802.3CG was merged into 802.3-2022 after the last version of 802.3CG-2019.

Another clue that 802.3cg is now a part of 802.3 can be found in only one public document in 802.3CG stack, an errata - which consists of one table that can be found in exactly the same form (and the same table identifier) on page 5921 of 802.3-2022

which - in my opinion - proves that Single Pair Ethernet specification is now included in the main 802.3 recommendation and manufacturers could update their datasheets 🙂

Single Pair Ethernet with Raspberry Pi

veluv01 — Sun, 15 Feb 2026 19:43:55 GMT

Introduction

After spending a good amount of time going through the hardware documentation, I finally got to do some real hardware testing! I'm pretty new to this Single Pair Ethernet stuff and was really excited to see how it actually works in practice. So I set up a simple test setup(as shown below) to experiment with it.

I've used the Molex's Shielded Twisted pair T1 Industrial Single-Pair Ethernet Cable ( 5 meters in length )

for for this test between the EVAL-CN0575-RPIZ

and the EVAL-ADIN1100EBZ (but I'm curious how the bare twisted pair would fair against it! I'll test both and post a comparison later.)

Setting up the Kuiper Linux Raspberry Pi Zero 2W

I used Kuiper Linux for this project. If you haven't heard of it, it's basically a Debian (the Bookworm variant as per the latest Kuiper image available) that Analog Devices put together specifically for their hardware. It comes with all the ADI libraries and tools already installed and configured, which saved me a ton of time.

Instead of hunting down and installing a bunch of different software components one by one, everything you need is already there and ready to go. I just flashed the image and was up and running.

It works great with the Raspberry Pi Zero 2W, even though it has less RAM compared to the other Pi variants which got ridiculously expensive due to the LPDDR4 memory shortages.

Here's the guide for the connecting and configuring the Pi for the CN0575 hardware. Just flashing the image and adding the "dtoverlay=rpi-cn0575" to the config.txt file and then rebooting the Pi makes it SPE ready, quite simple and quick! I've also increased the memory for the GPU since I'll be connecting Pi Zero 2W to a monitor and using the Desktop GUI for testing.

Another interesting feature is that the Kuiper Linux uses the network configuration as dhcpcd (pre-config'd for the analog devices hardware) instead of the Network manager. so you can't access the wireless networks without switching to the NetworkManager ( that might require some additional config when you want to use the AD's hardware over the network) which is enabled by default in the Raspberry Pi OS (BTW, Bluetooth works).

Then, I attached the CN0575 to the Pi Zero 2W's 40 Pin GPIO headers, just like any other RPi HATs and connected all the required cables to it.

Adapter for connecting the Molex's SPE STP Cable and Screw Terminals

I've used Molex's horizontal SPE jack i.e the 220957-0001

for making an adapter to connect the screw pin headers with the Molex's SPE STP cable

Oh, and I took some care to properly twist the wires I used as it'll be like a proper twisted pair, got them from a CAT6 cable I had sitting around (stripping the insulation was way harder than I expected!). I went with the green pair since it matched the Molex cables and the Perf-Board, so everything looked nice.

Testing the Single Pair Ethernet Network using the Molex STP SPE Cable

My test setup uses three main devices to evaluate the 10BASE-T1L performance. I have a Raspberry Pi 4 connected to my router over WiFi, which serves as my testing client.

The router also has an ADIN1100 board connected to it via standard Ethernet, this acts as one end of my Single Pair Ethernet link.

On the other end, I'm using a CN0575 evaluation board with a Raspberry Pi Zero 2W,

which connects to the ADIN1100 through the Molex's STP SPE cable.The CN0575 has the ADIN1110 on it,

which receives the 10BASE-T1L signals and passes the data to the Pi Zero 2W via SPI interface.

I've did a basic ping test to check the internet connection via the 10BASE T1L SPE ,

and I got zero packet loss and decent latency around 38 to 44 milliseconds. The only thing that might be adding a tiny bit of overhead is that my test client is going through WiFi instead of directly connected to the ADIN1100.

I also did a local ping test to the Pi Zero 2W, most of of my ping times are hovering around 7 to 8 milliseconds, as it's going through through my WiFi connection and then across the 10BASE-T1L link to reach the Pi Zero 2W. The latency isn't bad at all for that kind of path, it's just not the sub-millisecond response I may get from a direct wired connection (I'll try it the next time without the router).

Here's the log of the local ping

ping 192.168.29.231
PING 192.168.29.231 (192.168.29.231): 56 data bytes
64 bytes from 192.168.29.231: icmp_seq=0 ttl=64 time=11.430 ms
64 bytes from 192.168.29.231: icmp_seq=1 ttl=64 time=7.824 ms
64 bytes from 192.168.29.231: icmp_seq=2 ttl=64 time=8.065 ms
64 bytes from 192.168.29.231: icmp_seq=3 ttl=64 time=7.728 ms
64 bytes from 192.168.29.231: icmp_seq=4 ttl=64 time=7.962 ms
64 bytes from 192.168.29.231: icmp_seq=5 ttl=64 time=7.826 ms
64 bytes from 192.168.29.231: icmp_seq=6 ttl=64 time=7.548 ms
64 bytes from 192.168.29.231: icmp_seq=7 ttl=64 time=7.923 ms
64 bytes from 192.168.29.231: icmp_seq=8 ttl=64 time=7.999 ms
64 bytes from 192.168.29.231: icmp_seq=9 ttl=64 time=7.615 ms
64 bytes from 192.168.29.231: icmp_seq=10 ttl=64 time=7.783 ms
64 bytes from 192.168.29.231: icmp_seq=11 ttl=64 time=8.060 ms
64 bytes from 192.168.29.231: icmp_seq=12 ttl=64 time=7.501 ms
64 bytes from 192.168.29.231: icmp_seq=13 ttl=64 time=8.192 ms
64 bytes from 192.168.29.231: icmp_seq=14 ttl=64 time=8.176 ms
64 bytes from 192.168.29.231: icmp_seq=15 ttl=64 time=8.330 ms
64 bytes from 192.168.29.231: icmp_seq=16 ttl=64 time=8.601 ms
64 bytes from 192.168.29.231: icmp_seq=17 ttl=64 time=4.019 ms
64 bytes from 192.168.29.231: icmp_seq=18 ttl=64 time=4.046 ms
64 bytes from 192.168.29.231: icmp_seq=19 ttl=64 time=8.603 ms
64 bytes from 192.168.29.231: icmp_seq=20 ttl=64 time=8.464 ms
64 bytes from 192.168.29.231: icmp_seq=21 ttl=64 time=8.145 ms
64 bytes from 192.168.29.231: icmp_seq=22 ttl=64 time=7.839 ms
64 bytes from 192.168.29.231: icmp_seq=23 ttl=64 time=8.564 ms
64 bytes from 192.168.29.231: icmp_seq=24 ttl=64 time=4.146 ms
64 bytes from 192.168.29.231: icmp_seq=25 ttl=64 time=8.199 ms
64 bytes from 192.168.29.231: icmp_seq=26 ttl=64 time=8.503 ms
64 bytes from 192.168.29.231: icmp_seq=27 ttl=64 time=3.433 ms
64 bytes from 192.168.29.231: icmp_seq=28 ttl=64 time=8.475 ms
64 bytes from 192.168.29.231: icmp_seq=29 ttl=64 time=4.040 ms
64 bytes from 192.168.29.231: icmp_seq=30 ttl=64 time=8.612 ms
64 bytes from 192.168.29.231: icmp_seq=31 ttl=64 time=8.546 ms
64 bytes from 192.168.29.231: icmp_seq=32 ttl=64 time=8.992 ms
64 bytes from 192.168.29.231: icmp_seq=33 ttl=64 time=8.303 ms
64 bytes from 192.168.29.231: icmp_seq=34 ttl=64 time=8.085 ms
64 bytes from 192.168.29.231: icmp_seq=35 ttl=64 time=10.234 ms
64 bytes from 192.168.29.231: icmp_seq=36 ttl=64 time=4.510 ms
64 bytes from 192.168.29.231: icmp_seq=37 ttl=64 time=4.783 ms
64 bytes from 192.168.29.231: icmp_seq=38 ttl=64 time=3.944 ms
64 bytes from 192.168.29.231: icmp_seq=39 ttl=64 time=8.506 ms
64 bytes from 192.168.29.231: icmp_seq=40 ttl=64 time=8.707 ms
64 bytes from 192.168.29.231: icmp_seq=41 ttl=64 time=8.872 ms
64 bytes from 192.168.29.231: icmp_seq=42 ttl=64 time=8.675 ms
64 bytes from 192.168.29.231: icmp_seq=43 ttl=64 time=8.171 ms
64 bytes from 192.168.29.231: icmp_seq=44 ttl=64 time=8.546 ms
64 bytes from 192.168.29.231: icmp_seq=45 ttl=64 time=8.373 ms
64 bytes from 192.168.29.231: icmp_seq=46 ttl=64 time=8.739 ms
64 bytes from 192.168.29.231: icmp_seq=47 ttl=64 time=8.206 ms
64 bytes from 192.168.29.231: icmp_seq=48 ttl=64 time=8.496 ms
64 bytes from 192.168.29.231: icmp_seq=49 ttl=64 time=8.250 ms
64 bytes from 192.168.29.231: icmp_seq=50 ttl=64 time=8.540 ms
64 bytes from 192.168.29.231: icmp_seq=51 ttl=64 time=8.426 ms
64 bytes from 192.168.29.231: icmp_seq=52 ttl=64 time=8.567 ms
64 bytes from 192.168.29.231: icmp_seq=53 ttl=64 time=8.619 ms
64 bytes from 192.168.29.231: icmp_seq=54 ttl=64 time=4.280 ms
64 bytes from 192.168.29.231: icmp_seq=55 ttl=64 time=8.356 ms
64 bytes from 192.168.29.231: icmp_seq=56 ttl=64 time=8.590 ms
64 bytes from 192.168.29.231: icmp_seq=57 ttl=64 time=4.990 ms
64 bytes from 192.168.29.231: icmp_seq=58 ttl=64 time=4.965 ms
64 bytes from 192.168.29.231: icmp_seq=59 ttl=64 time=8.361 ms
64 bytes from 192.168.29.231: icmp_seq=60 ttl=64 time=8.280 ms
64 bytes from 192.168.29.231: icmp_seq=61 ttl=64 time=8.571 ms
64 bytes from 192.168.29.231: icmp_seq=62 ttl=64 time=8.494 ms
64 bytes from 192.168.29.231: icmp_seq=63 ttl=64 time=7.110 ms
64 bytes from 192.168.29.231: icmp_seq=64 ttl=64 time=8.707 ms
64 bytes from 192.168.29.231: icmp_seq=65 ttl=64 time=8.295 ms
64 bytes from 192.168.29.231: icmp_seq=66 ttl=64 time=8.895 ms
64 bytes from 192.168.29.231: icmp_seq=67 ttl=64 time=4.472 ms
^C
--- 192.168.29.231 ping statistics ---
68 packets transmitted, 68 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 3.433/7.663/11.430/1.663 ms

Also ran the apt update to check for the connection and it's having no issues.

For the LAN testing setup, the Pi 4 acts as an iperf3 client and requests the traffic from the the Pi Zero 2W (at IP address 192.168.29.231) running the iperf3 server.

Here's the results(from the iperf3 server i.e the Pi Zero 2W) of the iperf3 test for the throughput over my local network.

The 10BASE-T1L link is running at about 94% of its theoretical maximum, which seems okay.

What's next ?

Next I'll run some direct connection tests and compare the results. Then I'll try testing out the ADIN1110 ( Thanks✌ for E14Alice for shipping it promptly and resolving the issues with the FedEx 😅) and the ADIN1100.

ADIN1110 board arrival and ADIN1100 media converter medium range test

JWx — Wed, 11 Feb 2026 16:02:12 GMT

ADIN1110 Evaluation board

Last week my missing ADIN1110 evaluation board has finally arrived (thanks E14Alice for support). It is based on ADIN1110 chip, which - unlike ADIN1100 - integrates both MAC and PHY function, which can be mapped to first two layers of OSI stack (respectively link level and physical layer).

At the other side, ADIN1100 is a 10BASE-T1L PHY, so connecting it to the MCU requires builtin MAC - which may (in - for example - some variants of ESP32) or may not (in Broadcom SoC based Raspberry Pi boards) be present, which explains why our Raspberry Pi SPE shield is also ADIN1110 based.

ADIN1110 evaluation board looks like below:

{gallery}ADIN1110_eval

ADIN1110 evaluation kit can be described as kind of superset of CN0575 Raspberry PI SPE shield (save PoDL circuit), where SPE MAC connects to STM32L4S5 MCU, which can serve as independent network node with hardware encryption offload and even Arduino UNO compatible header:

IEC 63171-6 to terminal block adapter

As both types of ADIN evaluation boards terminate SPE link on terminal blocks, IEC63171-6 (didn't find more user-friendly name for this connector) to terminal block adapter was prepared. As veluv01 already shown, IP20 connectors can be easily installed on standard universal PCB, so adapter construction was very easy:

and with cable connected

Medium range loop test

Our first test will be if 48m of CAT5E CCE (copper clad aluminum - very inexpensive one) AWG 24 cable - shown below - can be used for reliable communication using two ADIN1100 evaluation boards in default configuration (working as media converter)

In the default configuration, ADIN1100 evaluation board works as media converter between 10BASE-1TL and 10BASE-T links, and can be powered either by USB or dedicated power supply with voltage in 5-32V range.

In such a setup, ADIN1100 and ADIN1200 PHY are connected back-to-back and provide media conversion:

As I now have two of them (E14 team generously decided to let me keep an additional one that was sent in my design kit), I can check if they can reliably operate on medium-length link of cheap and easily avaliable cable in office environment.

Test setup was prepared as in photo below:

One media converter is connected to the laptop PC, another one to the Ethernet uplink and between them is nearly 50m of (sub)standard Ethernet cable with one pair of four available used for transmission. Both converters are powered using powered USB hub (only power, no data link connected).

First - autonegotiation was successful and link speed of 10Mb/s correctly set:

Then, ICMP echo (aka ping 🙂 ) test was successful:

then - as quick verification, Internet based bandwidth metering page was tried, assuring us that all the available link bandwidth is present

Further tests are planned to more precisely measure link performance but first observations are promising.

Technical Support Thread | Experimenting With Single Pair Ethernet

JoRatcliffe — Wed, 11 Feb 2026 11:56:26 GMT

Hi Ben5049 , JWx , veluv01 , vmate , how are we doing with the challenge?

There has already been some great discussion on the kit but, as everyone progresses, I thought it might be helpful if I created a dedicated place for discussing any technical challenges you come across or solutions that you discover.

This is also a great place if you have any questions for Molex, the challenger sponsor and provider of much of the kit. You can also contact me directly if you prefer.

To help facilitate discussion, I am sharing below some reference points like the part numbers and order codes as well as documentation for all the kit parts. If you come across any useful documentation that you think everyone should be aware of then leave a comment or drop me a message and I will add it here.

Product	Manufacturer Part Number	Farnell Order Code	Documentation / Guides
	220957-0104	4328214	Datasheet Drawing
	220957-0108	4328215	Datasheet Drawing
	220957-0001	4328208	Datasheet Drawing
	220957-0008	4328211	Datasheet Drawing
	220957-0116	4328216	Datasheet Drawing
	220957-0011	4328212	Datasheet Drawing
	EVAL-ADIN1110EBZ	4032785	User Guide
	EVAL-ADIN1100EBZ	4032784	User Guide
	RPI4-MODBP-4GB	3051887	Datasheet Enhanced Product Overview
	EVAL-CN0575-RPIZ	4203675	Datasheet
	410-221	2290114	Datasheet

Update on kit

E14Alice — Tue, 27 Jan 2026 09:50:24 GMT

Hi all!

Just wanted to let you all know that the Raspberry Pi has been ordered; however, it's out of stock until the second week of February. Once they are back in stock, they will be sent straight out to you.

I will send you the tracking once they have been shipped.

If anyone has any questions, pop them below ☺

IP rating details of the connector and the cable assembly

JWx — Mon, 26 Jan 2026 13:02:47 GMT

In the post below I would like to summarize my findings regarding IP parameters of cable assembly and connector with enclosure mount .

IP rating specifies protection level against dust (first digit) and water ingress (second digit).

IP6x describe equipment that is "dust-tight", which means that even limited amounts of dust are prevented from entering,
IPx5 inform that equipment is protected against "water jets" - water projected in low-pressure jets from any direction will not have harmful effects (but limited ingress may happen),
IPx7 specifies that equipment is protected against temporary immersion in water (up to 1m for 30min),

First observation: 2209570116 1m cable assembly is specified as IP65/67 - which documentation further specifies as P65 / IP67 (IN MATED CONDITION).

This feature is even more evident when PCB connector is examined.It is rated as IP67, but - as we can see on the photos below - enclosure mount is circular and a connector has a flat bottom side:

which is confirmed by the connector drawing from the datasheet:

and under the light it can be seen that there are free areas between mount and the connector which could allow for water ingress:

I have asked Molex customer support and got an answer in very quick time that has confirmed my suspicion - it is IP67 only when mated, which is stated at the last page of datasheet of the enclosure mount:

I think those observations could be useful for proper employment of these components in the outdoors environment.

SPE kit unboxing

JWx — Sat, 24 Jan 2026 23:33:24 GMT

Yesterday I have finally (after long stop at customs office) got my SPE Challenge design kit - this time without usual round of ignoring Delivery Duties Paid information (thanks E14Alice for educating my local branch of FedEX 🙂 ), in the box showing signs of customs inspection but with content in good condition

The kit consist of three cables: IP20 1m and 5m and IP65/67 1m

{gallery}cables

Three Analog Devices evaluation kits:

but both ADIN boards of the same type: ADIN1100, instead of expected one ADIN1100 and one ADIN1110

Temperature sensor module, connectors and one Raspberry Pi

and many E14 branded stickers:

After opening connector bags we can see four IP20 connectors, four IP67 and two enclosure connector mounts

I have identified two differences between the official kit listing and a provided one:

- the official kit contains two Raspberry Pi SBC's, while only one was provided,

- two different ADIN boards were expected, while only one type has arrived,

I have contacted E14 team about this and they have offered help with resolving theses differences

SPE Kit has arrived !!

veluv01 — Sat, 24 Jan 2026 07:11:54 GMT

Guess what just showed up at my doorstep? The Single Pair Ethernet kit is finally here! I've been checking the tracking info obsessively for days, and now that it's actually in my hands, I'm excited to get started with this challenge!

A Big Thank You

First things first; I want to extend my heartfelt thanks to element14 community team for selecting me as one of the participants in this amazing challenge. It's truly an honor to be chosen among so many talented community members.
I also want to give a special shout-out to E14Alice for her incredible support in resolving the shipping and customs issues so promptly. International shipments can be tricky, and there were a few hurdles along the way, but everything was sort out quickly. Thank you so much for making this possible!

Unboxing the Kit

When the package arrived, I have to admit I was like a kid on Christmas morning! The contents of the package were well and secure, everything arrived in perfect condition despite its long journey.

I also got a ton of stickers, which was such a pleasant surprise!

Here's a close-up of the Molex connectors, which I've relocated them to the compartment box.

The horizontal SPE jack mounts easily onto the perfboard without requiring any modifications. However, the vertical connector needs a custom footprint to properly solder onto the PCB.

Interestingly, I noticed only after transferring the the circular mount connectors to the compartment box them that the circular mount connectors are actually different models. But they work perfectly! They fit the vertical SPE jacks just right(with a slight variation on how long the threading is for the connector to screw on) and make it easy to mount them on an enclosure

In the next post, I'll cover about the Molex SPE cables that came with the kit. Once I get a proper outdoor-rated enclosure (which I'm still on the search for), I'll be mounting and connecting these Molex components.

How to apply?

Ben5049 — Mon, 10 Nov 2025 23:30:23 GMT

Hi All,

I found this design challenge today and I'd really love to join it. I'm before the deadline, but there doesn't seem to be an enroll button anywhere for me to submit an application? By the time the organisers see this message it will probably be past the enrollment deadline, but I'd be very grateful if they could reach out and help me submit a (slightly late) application?

Many Thanks!