In the TECMP Status Messages “Status bus” of the device you can find the link quality of each port, next to other information

In a multidrop bus, the “stub” is any short connection branching off the main bus. Stub lines are local wires to each device.

• Cable Type: Use twisted pair cables specified for 10BASE-T1S, ensuring they meet the necessary electrical and mechanical specifications.
• Cable Length: The maximum total length for a 10BASE-T1S multidrop segment is 25 meters. Ensure the sum of all segment lengths does not exceed this limit. Stubs are allowed but they should not exceed 10 cm each.
• Bus Topology: In a multidrop configuration, all nodes are connected along a single continuous cable, forming a bus topology (daisy chain). Each node taps into this bus at its respective connection point.
• Node Spacing: Distribute nodes evenly along the bus to avoid signal reflections and ensure balanced loading. Maintain a minimum distance of 1 meter between nodes to minimize interference and signal degradation.
• Bus Termination: Proper termination at both ends of the bus is crucial. Use the appropriate termination resistors as specified in the 10BASE-T1S standard (differential 100 ohms) to prevent signal reflections and ensure reliable communication.

• Ensure that all 10BASE-T1S connections in MQS connector are connected as described in User Manuals for specific Technica product (Network Interfacer 10BASE-T1S or Capture Module 10BASE-T1S)
• The device includes two pins for adding the 100-ohm differential termination. This termination can also be enabled or disabled internally through the webserver interface.
• To facilitate cabling, all 10BASE-T1S pins are duplicated. This allows you to create a bus with a daisy chain topology without needing to make any T-connections between wire pairs.
• Follow guideline from How to set up a 10BASE-T1S Multidrop Network (link to previous question) or User Manual

• It is the same as the standard for Ethernet II.
• The supported maximum frame size is 1514 bytes (mtu). Jumbo frames are not supported by our product.

When a port is used as an injector, the “PLCA Enabled” flag is set to 1, else it is 0.

The PHYs are working in a passive mode and doesn’t take part in the PLCA cycle.

The current Symbol count is only counting BEACONs. Also, in future releases only the BEACONs will be counted.

It is guaranteed that it works always with stub lines lower than 10cm, longer stub lines can still be fine, setup dependent, but not guaranteed.

Proper operation is guaranteed for stub lines below 10 cm. Longer stub lines may work, depending on the setup, but are not guaranteed.?

This is expected behavior. Once a port is configured for traffic injection, it is dedicated to transmit and cannot support logging or packet capture functions simultaneously. The port is an active part of the 10BASE-T1S BUS.

• The fallback to CSMA/CD mode requires indirect observation and deeper analysis of logged data.
• 1-second TECMP Bus Status message provides some info about the BUS.
• But Event Logging license provides the possibility of a more precise detection mechanism. The Capture Module can generate Control Messages with precise timestamps whenever significant change in PLCA behavior is detected.
• The following PLCA-related events are particularly relevant:
• PLCA Symbols Detected: PLCA symbols (e.g., beacons) were absent for a period, and their reception has resumed.
• PLCA Symbols Missing: PLCA symbols were being received regularly but are now missing at the expected timing.
• PLCA Empty Cycle: Beacons are still present, but no Ethernet traffic is detected between them—this may indicate silent or idle operation.

while there is no direct or specific error message or LED indicator that explicitly signals malformed PLCA topologies (such as duplicate Node IDs or multiple Coordinators), these misconfigurations can cause side effects—like collisions or decoding errors—that may trigger the general error LED on the device. However, these conditions often lead to side effects like:

• Packet collisions
• Frame CRC errors
• Symbol-level decoding issues

The Capture Module, in combination with Event Logging feature, becomes a powerful tool to identify such issues:

• PLCA-related events like PLCA Symbols Missing or PLCA Empty Cycle may indicate invalid or broken timing due to misconfigured nodes.
• Also End of Stream Delimiter (ESD) Errors, or 5B Decode Errors events might be helpful.
• CRC validation failures, are directly shown in TECMP traces and point to physical or MAC-layer corruption.
• A beacon with doubled periodicity could be a symptom of two Coordinators active on the bus—something observable via timestamp analysis in Control Messages.

In short, while there’s no single TECMP field stating “malformed topology”, you can infer such problems with high confidence by combining:

• Event Logging Control Messages
• CRC and ESD error fields in TECMP
• Timing pattern analysis (beacon periodicity, jitter, etc.)
• This avoids the need for an oscilloscope or physical-layer tools in most cases.

Yes, with following conditions:

• Needed HW: v3.1 or higher
• Needed SW: R.006.002 or higher
• License: no advanced license needed

Please check following:

• Is the port mode correctly configured (SGMII or 1000BASE-X)? Some SFPs are not supporting both
• Did you check with recommended SFP modules? (specific list link)
• Did you check which SFP modules are supported? (1G or less)
• Did you test with replacement of Network Interfacer with same SFP module?

• 88Q5151 – FIR Switch B0 from Infineon for HW v2.1 and higher
• 88Q5151 – FIR Switch D0 from Infineon for HW 3.1 and higher
• The PHYs are integrated

When the PLCA coordinator (Node ID = 0) is not present in the network, the devices cannot execute PLCA arbitration.

Fall Back: Instead, they fall back to a basic CSMA/CD-like (Carrier Sense Multiple Access with Collision Detection) mechanism, often referred to internally as CSDM:

• Devices attempt transmission after sending if the line is idle.
• There’s no guaranteed collision avoidance or deterministic time-slot scheduling.
• It is useful for simple or minimal test setups (e.g. 1–2 nodes) but not recommended for production environments or multi-node scenarios.

A rising “Collisions Tx” value often indicates an issue with the physical setup, rather than actual protocol-level collisions.

In a properly configured PLCA (Physical Layer Collision Avoidance) network, physical collisions should never occur, as only one node is allowed to transmit at a time. This is managed by PLCA’s in-band signaling and timing coordination.

If the bus is not correctly terminated or if the impedance of the network is not within specification, the device may interpret the resulting signal reflections or disturbances on the line as a collision. This is because the physical characteristics of the signal in such cases can resemble the condition of two nodes transmitting simultaneously. Since the device cannot reliably differentiate between an actual simultaneous transmission and a poor bus condition, it increases the “Collisions Tx” counter accordingly.

Below is the list of theoretical PLCA cycle times for node Counts from 1 to 8 following assumptions:

• transmit-opportunity is set to 3.2us:
• only 64bytes long frames are sent
• only node 0 is sending 1 frame per cycle

This is because the MAC requires a minimum inter-packet gap (IPG) of 9.6 μs, which cannot be achieved when using 64-byte packets with Node Count = 1 or 2.

In the specific case with only two active nodes (Node Count = 1 effectively means two devices in the network), the performance with or without PLCA should be quite similar—assuming there are no collisions. In such a scenario, the communication can operate close to the line rate even in CSMA/CD mode.

Main difference is that each node gets a unique MAC address. Further information can be found in the User Manual.

Yes. For more details, please check the UM.