Open gkasprow opened 1 year ago
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
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'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.
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)
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. @jordens can you show them this issue? Maybe they will have some thoughts.
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. 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.
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. It has 0.8mm pitch so could fit on 4layer PCB
the NCN26010 chips are now available in Arrow So we can use them in the design simply replacing existing MAC+PHY with this one.
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
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. 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.
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.
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