Pump Controller Feedback Selection: Sensor, Sensorless, and System Trade-Offs

Prepared by the Sankey Engineering Team. Updated August 21, 2026.

Feedback choice affects pump-controller behaviour, harness design, firmware assumptions, protection coverage, and service diagnostics. There is no universal best approach. Sankey Engineering Team recommends choosing against the complete pump duty and the evidence the OEM needs to release the product.

Start with the required observability

Ask what the controller must know: rotor position, speed, flow-related state, fault condition, or simply an approved operating response. Map each requirement to a signal, an inference, or a controlled test condition.

This prevents adding a sensor that the product cannot use or omitting feedback needed for a reliable low-speed or protection decision.

Review startup and low-speed cases

Compare the expected start load, priming condition, minimum speed, restart frequency, and supply range. Sensorless assumptions may behave differently from a feedback-based design during low-speed or changing-load operation; validate the actual pump and motor.

Record transitions, not only steady state. A controller that reaches speed eventually may still fail the approved startup time or user experience.

Design the interface and harness

For a sensor connection, define voltage, polarity, connector keying, cable length, shielding or routing requirements, and diagnostic behaviour. For a sensorless approach, document the motor and algorithm assumptions that must remain stable.

Include manufacturing and service access in the decision. The signal path must be testable without creating an unsafe or confusing production procedure.

Tie feedback to protections

Define how the chosen feedback supports blocked-load, overspeed, dry-run, under-voltage, and thermal decisions where applicable. The controller response and reset path should be observable and recorded.

Never assume a feedback signal proves a hydraulic condition directly. Use the approved evidence and system tests to validate the protection claim.

Freeze the engineering decision

Capture the selected approach, rejected alternatives, motor configuration, firmware revision, test matrix, and known limitations in the design review. Revisit the decision if the pump, motor, fluid, or enclosure changes.

Visit pump controllers or send Sankey your pump and feedback requirements.

Make the review decision-ready

The design review should include the pump operating range, low-speed and start needs, signal interface, harness route, environmental conditions, service model, and protection goals. For every proposed feedback path, explain what it observes directly and what it only infers. This gives the OEM a defensible basis for comparing wiring complexity against control and diagnostic value.

Retain evidence that can be reviewed later

Document the motor and sensor configuration, controller hardware, firmware, signal checks, representative load tests, and any limitations discovered during the review. Tie the decision to controlled drawings and a change log so a later sensor, cable, or pump revision triggers the right validation discussion.

Use a cross-functional release gate

Before pilot production, review the current hardware and firmware identifiers, interface and wiring drawings, representative product setup, test matrix, results, unresolved risks, and any proposed changes with the OEM product owner, engineering, and production representatives. The release decision should state what was checked, what remains outside scope, and which change will require a repeat review. This is stronger evidence than a broad claim that the design has been “tested”.

Scope and responsible owners

This engineering resource describes a planning method. It does not replace product safety, EMC, wireless, regulatory, reliability, privacy, or market-access assessment. Those workstreams need their own applicable requirements, responsible parties, and evidence for the confirmed product and destination market.

Frequently asked questions

Is sensorless always lower cost?

It may reduce components, but total project cost also includes tuning, validation, robustness, and service requirements. Compare the full system.

Can feedback be added after firmware is complete?

It can require hardware, harness, firmware, fixture, and documentation changes. Treat it as a controlled design revision.