Design & Materials
Application NotesSingle-pair Ethernet and power: approach selection, bench structure and evaluation preparation
If you are preparing to connect a sensor to single-pair Ethernet, first choose the evaluation platform. Building an application prototype with Raspberry Pi/Linux requires different hardware and software from connecting an analog front end to an AM2434 to develop an embedded node. This article compares two manufacturer reference designs, links to implementation materials, sets out a trial sequence from a short link to the target cable, and provides a bench plan you can edit directly.
Trial tools and field guidesPrepared by MTTJPublished: Updated:
Scroll tables horizontally to read every column.
Choose the approach that answers the current question
| Comparison | Analog Devices CN0575 | Texas Instruments TIDA-010261 |
|---|---|---|
| Main evaluation task | A 10BASE-T1L field-device prototype on Raspberry Pi/Linux | Connecting an analog front end to AM2434, processing data and uploading it over Ethernet |
| Data interface | ADIN1110 MAC-PHY connected to the host via SPI | AM2434 MCU with DP83TD510E PHY |
| Power path | LTC9111 powered-device side; the reference design supports SPoE Class 12/13 | PoDL Type E, Class 12, including SCCP; an auxiliary 24 V input is also provided |
| Implementation materials | Evaluation-board entry point, design package including schematic/BOM/layout, Circuit Note and user guide | Schematic, BOM, Gerber/layout, design guide and SDK instructions |
| Hardware availability | Officially listed EVAL-CN0575-RPIZ evaluation hardware; regional stock and lead times were not verified for this article | The manufacturer explicitly states that the complete validation board is not sold; assess in-house fabrication or another verified hardware option |
| Main software preparations | Raspberry Pi, ADI Kuiper Linux, corresponding device tree and examples | AM243x boot files and application; PoDL control also involves MSP430 firmware |
Sources: Official CN0575 materials, official TIDA-010261 materials. Both are reference designs for bench development. They are not one interchangeable set of finished products.
Selection guidance: if the immediate question is how an existing Linux application can obtain sensor data, start by examining CN0575 hardware and image preparation. If you need to evaluate how analog sampling, edge processing and reporting can be integrated into one embedded node, TIDA-010261 is closer to that task, provided board-fabrication and software-adaptation resources are confirmed first. If you only want to verify a particular cable, either development approach may exceed what is needed. Compatible endpoint devices that already work together are usually a more suitable comparison baseline. This is engineering guidance based on evaluation tasks, not a ranking of manufacturer performance.
Draw data and power as separate paths first
The following functional relationships are compiled from the reference designs. They help allocate bench-preparation work. They do not imply that the two designs can connect directly, or replace a wiring diagram for the specific board.
CN0575: the relationship between the Linux host and the single-pair link
- Raspberry Pi / Linux application
- SPI
- ADIN1110 MAC-PHY
- On-board coupling network and single-pair cable
- Compatible link partner
- Compatible power sourcing equipment (PSE)
- Single-pair cable and on-board power network
- LTC9111 powered-device (PD) control and downstream supplies
- On-board loads / Raspberry Pi
Carrying data and power on the same cable does not mean both functions will work automatically. The data link requires checking endpoint modes and the application. Power over the same pair also depends on PSE capability, the powered-device class and board settings. A media converter’s data interface does not establish that it supplies the required power. CN0575 function and power description
TIDA-010261: analog sampling, embedded processing and upload
- Analog front end / evaluation module
- AM2434 application processing
- DP83TD510E PHY
- On-board interface and single-pair cable
- Compatible link partner
- PoDL Type E, Class 12 powered-device path in the manufacturer's configuration
- Supported auxiliary-power configuration
Power selection: Use the PoDL Type E, Class 12 powered-device path in the manufacturer's configuration, or evaluate with its supported auxiliary-power configuration. See the design guide for specific settings and switching conditions.
Beyond Ethernet, this approach integrates the analog-front-end interface, application firmware and power control. The manufacturer’s materials provide entry points for design and debugging; the implementing team still needs to arrange board acquisition, startup and software adaptation. Diagram arrows show functional relationships and do not imply that two power supplies can be connected directly in parallel. TIDA-010261 overview
Turn approach selection into a preparation decision
Suppose a team already has a Raspberry Pi data application and wants to evaluate a single-pair link. CN0575 deserves examination first because it is close to the existing host and development environment. That judgment is not yet a purchase order. The team should obtain the complete user guide, check the image and device tree, link partner and power arrangement, then determine whether the boards and cable can form a complete bench setup.
If the actual goal changes to building an embedded node that connects an analog front end, and the team already has resources for board fabrication, startup debugging and firmware adaptation, TIDA-010261 materials are closer to the task. Procurement should then receive a versioned BOM and an engineering-preparation checklist. The fact that the complete validation board is not sold must be included in scheduling.
If the goal is simply to compare two cables, it is more suitable to establish a baseline with compatible endpoint devices that already work together. Changing the development platform, firmware and cable in the same comparison makes it difficult to identify which change caused an anomaly. These are engineering-selection recommendations for hypothetical scenarios; they provide neither measured results nor a cost ranking of the approaches.
List procurement and software preparations together
CN0575: check the complete bench, not just one board
The evaluation section of the official Circuit Note Rev. A lists the CN0575 board, Raspberry Pi 3B+ or later, host computer, single-pair cable, RJ45/USB connections and example scripts. The connection procedure uses EVAL-ADIN1100-EBZ as the link partner and requires power to match the board settings. The Raspberry Pi needs the corresponding Kuiper Linux and device tree. Evaluation section, page 6
Use this material to build your bench checklist, but do not infer that a media-converter board provides every PoDL/SPoE power function. Check the data partner, power injection method, powered-board jumpers and supply separately. Wire according to the board revision in hand and the manufacturer’s guide. Access to the linked detailed user guide was restricted during research for this article. Obtain it before procurement, especially to confirm the image, partner and jumper steps. Design files have download entry points; check the actual file versions, terms of use and component availability before ordering as well.
TIDA-010261: resolve board fabrication and startup before connecting the actual sensor
The TIDMBP8 schematic, TIDMBP9 BOM and TIDUF34A design guide are directly available. Section 4 of the guide covers debug interfaces, startup and software preparation. Without a compatible link partner that supplies power, its auxiliary supply path allows data evaluation using an external 24 V, 0.5 A supply with a media converter that does not supply power over the link. This power condition applies only to that reference board. Hardware requirements §4.1
| Work to complete | Specific entry point found | Engineering work still to arrange |
|---|---|---|
| Prepare the board | Schematic and BOM above; Gerber/layout on the project page | Check that design-file versions match; fabricate, procure, assemble and perform power-on checks |
| Start up and debug | UART and JTAG/SD interface descriptions in guide §4.1 | Prepare debug connections and record board ID, boot method and firmware version |
| Get the Ethernet application working | SDK and Ethernet example entry points in §4.2.2 | Adapt for DP83TD510E as instructed; the example is not precompiled firmware for any custom board |
| Evaluate PoDL power reception | MSP430 firmware instructions in §4.2.1 | Check SCCP, PSE capability and the actual firmware configuration |
| Reproduce the analog-data upload chain | TIDA-010249, signal source and PC DHCP/MQTT configuration in §4.3 | If substituting your own analog front end, recheck interface modes, voltages and sampling code |
Include the software sections, design files and hardware-debugging conditions in the preparation checklist. BOM pricing alone does not represent the cost of completing this approach. Comparable board lead times, integration hours and complete bench quotations were not obtained for this article, so it does not rank total cost.
Sequence bench trials so that results can be explained
The following is a proposed trial sequence. Before use, fill in both endpoint boards, firmware, cable drawings, connection arrangements, application-data criteria and permitted component conditions. Use only power paths explicitly supported by the manufacturer. Switch configurations with power off, following the relevant guide.
| Condition | Keep constant | Change in this trial | Evidence to obtain |
|---|---|---|---|
| B01: short-link baseline | Endpoint boards, firmware and application-data load | Establish the manufacturer-supported starting configuration | Actual negotiated mode, whether application data continues to arrive, and the log time window |
| B02: target cable | B01 endpoints, load and power arrangement | Substitute the target cable and recorded connector combination | Data counts, disconnections/reconnections, resets and power observations; compare with B01 over the same time window |
| B03: power over the same pair | B02 cable and data load | Switch to PoDL/SPoE when supported by the equipment and matched at both ends | Power-establishment sequence, PD state and data behavior; retain the PSE configuration |
| B04: startup or load changes | Confirmed circuit and cable | Change only one defined startup/load condition at a time | Startup count, application recovery time, resets and relevant waveforms/logs |
The 1,000 m distance in CN0575 materials is associated with 2.4 Vpp mode. Using 2.4 Vpp also requires both endpoints to advertise support and negotiate it. The target cable’s power capability, connectors and environment remain separate validation tasks. CN0575 physical-interface and negotiation description
Record “indicator lit/link established,” “valid data received by the application” and “stable operation under the target power arrangement” separately. These are three different observations. If the short-link baseline does not work, check endpoint configuration, image/firmware, partner and wiring first, rather than immediately blaming the long cable. If an anomaly occurs only with power over the same pair, preserve and inspect power establishment, PD input and reset timing next. The symptom alone does not prove that cable voltage drop is the cause. Stop that trial condition if temperature rise is abnormal, a component exceeds its permitted conditions or wiring is uncertain, and investigate using the component and board documentation.
What should be checked next when an anomaly appears?
The following checks follow the B01–B04 comparisons. Use them to choose the next evidence to collect; symptoms alone cannot assign fault to a component or cable.
| Current observation | Evidence to obtain or check first | Judgment this can support |
|---|---|---|
| Even the short-link baseline does not work | Endpoint and board versions, image/firmware, partner, wiring and application logs | Restore a valid baseline before interpreting long-cable behavior |
| The link is established, but expected application data is absent | Application configuration, application logs from the same time window and count definitions | Distinguish physical-link state from whether the application completes its task |
| An anomaly appears after substituting the target cable with the same configuration | Cable and connector combination, data from the same time window, reconnection/reset and power records | Associate the anomaly with this change and plan fault isolation; correlation alone still does not establish the root cause |
| An anomaly appears only after switching to power over the same pair | PSE configuration, PD state and timing relationships between reset and data events | Select the next power or timing measurement, rather than directly attributing the problem to cable voltage drop |
Handing these records and the untested scope to the next engineer supports a decision to continue, modify or add tests more effectively than a single “link connected” screenshot.
Plan and record files you can adapt directly
The bench-evaluation toolkit contains a bench plan and results sheet, a completed example plan and field instructions. The files place conditions, variables and result fields together, making it easier to retain failed conditions instead of capturing only one successful connection.
The example assumes a team with compatible endpoint devices comparing a 1 m baseline cable with a 20 m target cable and planning to check power over the same pair with power negotiation. These lengths are demonstration inputs, not recommended limits. Each example row specifies what changes, what stays constant and what to observe. Measured counts, voltages, reset counts and conclusions are all blank because no testing has been performed. Replace the devices and conditions, complete the documentation and criteria, and the plan can be handed to the person carrying out the trials.
You can define completion of this trial round as follows: every planned condition has a clear configuration and logs; failures lead to a next diagnostic check; power and data each have their own assessment; unverified environments, lengths and loads are listed separately. This result can support continuing the design, modifying it or stopping this approach. Production qualification, EMC, durability and final application acceptance require their own validation.
When preparing target-cable conditions, read the wire gauge and conductor selection guide. When organizing validation conclusions, read how to review a cable assembly test report.
Source versions: CN0575 Circuit Note Rev. A; TIDA-010261, design guide TIDUF34A (2025-08); manufacturer public materials accessed 2026-09-23. Confirm matching BOM, schematic and board versions for the actual setup. MTTJ used AI for research reading and editing. This article provides a document comparison and proposed trial tools; the two reference designs have not been physically reproduced for it.
Related resources and manufacturing scope
Trial tools and field guides
Single-pair Ethernet bench plan: fields and instructions
Single-pair Ethernet bench plan: fields and instructions
Version: 2026-09-23. Companion files: spe-bench-plan.csv and spe-bench-demo-plan.csv. Open the files as UTF-8, comma-delimited text using Excel’s “From Text/CSV” function or LibreOffice. English column names allow reuse across languages.
The plan already includes the trial purposes for B01 short-link baseline, B02 target cable, B03 power over the same pair, and B04 startup/load variation. This is a suggested sequence, not manufacturer wiring instructions or a completed test. Remove conditions that do not apply to the equipment’s capabilities. For repeated executions of one condition, duplicate the row and assign a unique test_id. Complete the documentation, actual boards, software and criteria before starting work.
| Field | Meaning and entry instructions |
|---|---|
| data_kind | unperformed_plan for the plan; illustrative_plan_not_measured for the example; use measured in a separate record after obtaining actual measurements |
| test_id | Unique ID for each execution, used to link logs |
| document_and_revision | Revisions of the actual board manuals, design files and software documents used |
| endpoint_a_hw_fw / endpoint_b_hw_fw | Hardware revisions and firmware/image/driver versions at both endpoints |
| cable_drawing_lot / planned_length_m | Cable drawing, connectors and lot / planned length in meters |
| power_route_and_class | Actual power path, PSE/PD configuration and power class; distinguish external power from power over the same pair |
| changed_factor / held_constant | Factor changed in this row / conditions kept constant |
| acceptance_criteria_ref | Reference to product criteria, component operating limits and stop conditions established before execution |
| planned_observation | Observations and logs planned for this condition |
| started_at_utc / ended_at_utc | Actual execution window, including date, time and UTC time zone |
| actual_tx_mode_vpp | Actual readback of transmit mode (Vpp); do not substitute a planned value |
| actual_tx_count / actual_rx_count | Transmitted/received counts at the same layer and within the same window; leave blank when counts are unavailable |
| counter_definition | Whether the counts represent Ethernet frames, application messages or another unit; how duplicates, filtering and resets are handled |
| link_down_count / reset_count | Link interruptions / endpoint resets actually observed in the window; leave blank if not observed |
| pd_input_min_v / pd_input_max_v | Minimum/maximum PD input voltage at the specified measurement point, in V; place instrument and measurement-point details in evidence_ref |
| power_setup_result / data_result | Separate conclusions for power establishment and application data, including the criteria used; do not enter a pass for an unperformed test |
| evidence_ref | Locations of logs, waveforms, measurement points, sampling settings and result files under the same ID |
| next_decision | Next action: continue, change a named item, stop this approach or perform a further test, with the basis for the decision |
How to use the completed example plan
The demonstration file assumes compatible endpoints already exist, with a 1 m starting link and a 20 m target cable. These lengths are illustrative only. Separate rows change the cable, power arrangement, and startup or load. Replace REPLACE fields with actual information. Also verify power classes, negotiation and connector support at both ends; an assumption of compatibility is not a completed check.
Every example field from started_at_utc through next_decision is blank. There are no actual times, counts, voltages, resets, logs or test conclusions. After preparation, copy the plan into a separate execution file and retain the original plan. Distinguish the files in both their filenames and data_kind values.
Summarizing and diagnosing results
First compare B01/B02 with the same window, load, endpoints and software. Note the change in power path when comparing B02/B03. An illuminated indicator alone is insufficient for data_result to be a pass; read the application data and apply the stated criteria. If count definitions differ or a counter resets, transmitted count minus received count cannot directly be treated as packet loss. Retain the logs and explain the difference first.
When faults appear only with power over the same pair, check the timing relationships among power establishment, PD state, resets and data events before choosing the next measurement. Do not infer cable voltage drop from that symptom alone. If the short link also fails, resolve the baseline configuration first. Leave unavailable records blank. Enter 0 only for an event that was actually absent during the observed window.
A bench conclusion is ready to hand over when each planned condition has configuration, criteria and result references, failures have an executable next diagnostic step, and untested scope is listed separately. The table does not automatically determine component compatibility or replace manufacturer wiring procedures, product qualification or EMC verification.
Original CSV values and their meanings
The original files retain stable English values. The following table explains their meaning; demonstration identifiers do not identify actual parts or tests.
| Original value | Meaning |
|---|---|
unperformed_plan |
A plan that has not been executed. |
illustrative_plan_not_measured |
An illustrative plan with no measured results. |
measured |
A separate record of actual measurements after execution. |
B01 |
Short-link baseline condition. |
B02 |
Target-cable condition. |
B03 |
Power-over-the-same-pair condition. |
B04 |
Startup or load variation condition. |
REPLACE: exact board manuals and matched revisions |
Enter the actual board manuals and verify that their revisions match. |
REPLACE: compatible endpoint A / firmware |
Enter the actual endpoint A and firmware, and verify compatibility. |
REPLACE: compatible endpoint B / firmware |
Enter the actual endpoint B and firmware, and verify compatibility. |
REPLACE: actual drawing and lot |
Enter the actual cable drawing and lot. |
REPLACE: product-specific criteria agreed before test |
Enter the product-specific criteria established before execution. |
original supported supply |
Use the original supply arrangement supported by the manufacturer. |
same as B01 |
Retain the power arrangement used for B01. |
compatible PoDL/SPoE only |
Use PoDL/SPoE only after verifying compatibility. |
validated route |
Use the power path already verified for the equipment. |
establish baseline |
Establish the initial comparison configuration. |
target cable and connector assembly |
Change to the target cable and connector assembly. |
power route |
Change the power arrangement. |
one declared startup or load condition |
Change one explicitly defined startup or load condition. |
endpoint firmware; application load |
Keep endpoint firmware and application load constant. |
endpoints; firmware; data load; supply |
Keep endpoints, firmware, data load and supply constant. |
B02 cable; endpoints; firmware; data load |
Keep the B02 cable, endpoints, firmware and data load constant. |
validated circuit and cable |
Keep the already verified circuit and cable constant. |
negotiation; application data; supply state |
Observe negotiation, application data and the supply state. |
same-window data counters; reconnect/reset; supply readings |
Observe data counters over the same window, reconnections/resets and supply readings. |
power classification/start; PD state; application data |
Observe power classification and startup, the powered-device state and application data. |
startup count; recovery duration; logs/waveform |
Record startup count, recovery duration and relevant logs or waveforms. |
