DiPho v2 Ethernet implementation

[gkasprow]

Existing Ethernet implementation (KSZ8851SNLI) lacks RUST support and MAC+PHY chip is unobtainable (2year lead time). It also requires external USB /Poe adapter when sb wants to use Ethernet. Piotr decided to not develop an Ethernet driver because at the time this chip was NRND.

Since typical use case requires several such sensors (@airwoodix ) in one setup, we need to adopt to such conditions. For the moment I see several possible solutions

1. Keep it as it is and buy chips paying 20x more.

Pros

• no need of new HW design
• we keep existing USB-C based architecture
• low cost

Cons

• need for SW development and maintainance of RUST driver
• not optimal architecture for multi-sensor Ethernet based network; we need several PoE-USBC adapters and Ethernet switch

2. Replace the SPI MAC+PHY with available and cheap DM9051.

Pros

• quick HW modification
• we keep existing USB-C based architecture
• low cost

Cons

• need for SW development and maintainance of RUST driver
• not optimal architecture for multi-sensor Ethernet based network; we need several PoE-USBC adapters and Ethernet switch

3. Other SPI Ethernet options are also available - Lan9250 - package much bigger,

Pros

• we keep existing USB-C based architecture
• lower cost

Cons

• serious HW modification, possibly additional PCB if we want to preserve the sensor package
• need for SW development and maintainance of RUST driver
• not optimal architecture for multi-sensor Ethernet based network; we need several PoE-USBC adapters and Ethernet switch

4. ENC424J600T - much bigger package, lack of Auto-MIDX

Pros

• no direction detection so we would have to use another connector, maybe RJ45 with embedded non-isolated PoE converter
• RUST driver support
• lower cost

Cons

• serious HW modification, possibly additional PCB if we want to preserve the sensor package
• not optimal architecture for multi-sensor Ethernet based network; requires PoE switch; we need several PoE-USBC adapters and Ethernet switch

5. Replace CPU with embedded MAC one + external PHY

Pros

• we keep existing USB-C based architecture
• RUST driver support

Cons

• serious HW modification, more layers to support BGA CPU package; possibly additional PCB if we want to preserve the sensor package
• much more expensive CPU (+8..10$) but we get rid of 1$ DAC

6. Replace CPU with embedded MAC one + external PHY supporting SPE

PHY supporting 10Base-T1L single pair ethernet is available from a few vendors. We already discussed with @jordens a year ago but chipset availability was poor. Now one can buy cheap USB adapters and RJ45-SPE adapters - a set of 2 below 80EUR However, if we consider multi-drop SPE version we have to use either CT25206, LAN8670 PHY or NCN26010 MAC+PHY

Pros

• serious redesign of PCB
• scalable architecture - just route a pair of wires from SPE adapter to all sensors in the setup. The same pair delivers power.
• existing RUST driver support

Cons

• serious HW modification, more layers to support BGA CPU package; possibly additional PCB if we want to preserve the package
• design a new adapter which provides power supply to al sensors (easy); there is even such design on github
• much more expensive CPU (+8..10$) but we save a lot on PoE adapters and get rid of 1$ DAC

7. Replace external KSZ8851SNL with NCN26010 supporting SPE

Pros

• quick HW modification
• scalable architecture - just route a pair of wires from SPE adapter to all sensors in the setup. The same pair delivers power.
• lowest cost but chip, hard to buy
• STM32 implementation (FREE RTOS)

Cons

• need for SW development and maintainance of RUST driver
• design a new adapter which provides power supply to al sensors (easy); there is even such design on github

[gkasprow]

if we decide to go for option 6 then: KSZ8851SNLI-TR -> LAN8671B1-E/U3B 6.2$ -> 3.2$ STM32F103T8U6 -> STM32F107VCH6 (the only available STM32 with MAC) 7.3$ -> 12,7$ DAC MCP47CMB02-E/MG - none 1.09$ USB connector 632722110112 -> pluggable twisted wire connector 691347000002B 3.6$ -> 0.9$ SMA 132291 -> MCX; we have to and can use lower connector 73415-1691 5.5$ -> 1.5$

total 23,69 -> 18,3

and we will fit.

we can also add optional mini-USB connector which is much smaller and cheaper than USB-C one

[pm-daniel]

To me, the 6. approach is the most appealing. It uses fairly recent technology so supply of the ICs should be quite good in near future. My two cents would be:

1. the mentioned USB adapter does not support PoDL i.e. does not provide any power - so if one want to use an USB interface via an adapter there should be other way of powering the dipho or the custom adapter design supporting PoDL
2. from my experience I really dislike micro USB connectors. I find them to be really fragile and imho not suitable for lab instruments. I would use USB mini B connector preferably, as it's close in size and price but much more durable.
3. as there are no ICs for PoDL (or I couldn't find them quickly enough ;) ) I found a quite nice application note from TI on how to implement it

[gkasprow]

I don't think we need to implement entire PD classification and detection because that may cause issues with multi-drop network. I'd use simple 5V supply with short-circuit detector or even thermal fuse. Did you find PoDL example for 10BASE-T1S ? It's different standard than 10BASE-T1L. Most implementations provide a pair of cables for power delivery. So if we use fixed 5V PoDL we won't violate the 10BASE-T1S standard since the PHY outputs are AC coupled anyway.

[gkasprow]

I purchased following devkits so we will test various options: EVB-LAN8670-USB (10BASE-T1S) LAN+PoE ETH10-2wire-SET ATTE Power (probably 10BASE-T1L) DP83TD510E-EVM (10BASE-T1L) EV06P90A (10BASE-T1S) I plan to order NCN26010XMNEVK (10BASE-T1S)

[gkasprow]

I added option 7 to the list

[pm-daniel]

Good point - the mentioned PoDL implementation is not suitable for multidrop topology. I've looked for some reference implementation of PoDL for 10BASE-T1S but I only found such for point-to-point topology. This keynote digs into the topic and provides some nice calculations but mentions that PoDL for multidrop is not standardized yet.

Albeit the 7. option looks nice as hardware redesign would be fairly simple I'm a bit worried about the IC availability - it looks to be far worse compared to those from Microchip. Analog Devices also has such a chip in its portfolio - ADIN1110 and it looks to be priced slightly higher than NCN26010 but with better availability and shorter lead times.

[jordens]

• Take a chip from the stm32h7 line. There are a bunch of small packages, have a MAC, are energy efficient and we like them in Stabilizer/Thermostat-EEM.
• If you are interested I could talk to the folks at a neighbor company here about PHY/MAC T1S/T1L solutions. They do a lot of SPE for automotive and industrial systems and have wired up the entire kitchen with it.

[gkasprow]

Sure, I'd love to have choice, but it's hard to buy any STM32 these days. @jordens can you show them this issue? Maybe they will have some thoughts.

[airwoodix]

Given that multidrop SPE has no PoDL, I'm not sure it's very relevant. At least, we'd be happier with a star topology and a single cable per sensor module with limited stress-relief requirements. In particular, sensor modules are likelier to be far apart and inserted/removed dynamically, which makes chains annoying.

I would expect a significant number of free ports on PoE-compatible switchs in typical labs. At this stage, it therefore seems reasonable to me to use one such port per sensor head. If the RJ45/USB-C PoE adapters are quite small, they could either be bunched into a custom switch (would probably fit into a 1U unit) or distributed where there's space. This is surely not very scalable, but feels manageable for few tens of sensors and is practical, since it uses technology already deployed in physics labs.

Or did I miss some motivation for SPE?

[gkasprow]

The multidrop SPE does not define the way PoDL is implemented. Since we already use Ethernet in non-standard way (USB-C), I don't see a reason why we can't implement PoDL in simplest possible way. In order to discuss further we will verify if such PoDL and multidrop will work at all in dynamic conditions. I've purchased several devkits so first, we will give it a try. Another way is to implement PoE already in the sensor by adding a third PCB.

[pm-daniel]

What looks most appealing to me, in regards to multidrop SPE is the flexibility. If the multidrop SPE "switch" would be designed (ex. 4 or 8 SPE ports, using the standard ethernet switch as a base to build on) one can combine both star and bus topologies in one system - so we kinda get 2in1.

[gkasprow]

The SPI MAC+PHY from Onsemi supports up to 25 devices in one segment. Microchip ones supports up 8devices in network segment. Let's check interoperability and hot-plug performance od the network.

[gkasprow]

We can also go for STM32F777VIH6 in TFBGA100 which is somehow available and offers high performance. It has 0.8mm pitch so could fit on 4layer PCB

[gkasprow]

the NCN26010 chips are now available in Arrow So we can use them in the design simply replacing existing MAC+PHY with this one.

[pm-daniel]

Okay, so yesterday I tested 10BASE-T1S in a simple peer-to-peer configuration using NCN26010XMNEVK and EVB-LAN8670-USB and I can confirm that it works as expected

[gkasprow]

so, the interoperability between Microchip and Onsemi chipsets exists :)

[gkasprow]

I ordered both STM32 and NCN chips without problems.

[pm-daniel]

Which STM32 have you ordered finally?

[gkasprow]

STM32F103T8U6TR

[jordens]

The folks down the corridor pointed to their products and mentioned they would always prefer separate power (as there is little cabling/connector advantage with PoDL in practice but big price for the trafo/decoupling/SI management/consumption/robustness to be paid for PoDL). They just run two pairs. And multidrop appears to be problematic in practice for reasons of stub length, robustness and flexibility. They would also recommend 100BASE-T over 10BASE-T for SI and future proofing reasons. Maybe trying their modules wouldn't be all that stupid. Then one could focus on the frontend development. It would need to be a separate small stm32f1 or similar for adc/dac handling and signal processing hooked up via uart and gpio to the network module. Obviously there's a lock-in into their development environment and onto their code but to get started in some thesis project it would be fine as a first shot.

[gkasprow]

The version with Onsemi MAC+PHY and low-cost STM was already prototyped. We checked interoperability with Microchip chipset. The modules are nice but won't fit into the enclosure and would significantly increase the cost. We are currently producing a series of 5 devices to see how they work together. We can always supply our devices via USB.