New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DiPho v2 Ethernet implementation #18
Comments
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:
|
I don't think we need to implement entire PD classification and detection because that may cause issues with multi-drop network. |
I purchased following devkits so we will test various options: |
I added option 7 to the list |
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. |
|
Sure, I'd love to have choice, but it's hard to buy any STM32 these days. |
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? |
The multidrop SPE does not define the way PoDL is implemented. |
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. |
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. |
We can also go for STM32F777VIH6 in TFBGA100 which is somehow available and offers high performance. |
the NCN26010 chips are now available in Arrow |
so, the interoperability between Microchip and Onsemi chipsets exists :) |
I ordered both STM32 and NCN chips without problems. |
Which STM32 have you ordered finally? |
STM32F103T8U6TR |
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. |
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. |
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
Cons
2. Replace the SPI MAC+PHY with available and cheap DM9051.
Pros
Cons
3. Other SPI Ethernet options are also available - Lan9250 - package much bigger,
Pros
Cons
4. ENC424J600T - much bigger package, lack of Auto-MIDX
Pros
Cons
5. Replace CPU with embedded MAC one + external PHY
Pros
Cons
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
Cons
7. Replace external KSZ8851SNL with NCN26010 supporting SPE
Pros
Cons
The text was updated successfully, but these errors were encountered: