Why am I seeing “Output Over Current Detected” even though the previewed amplitude is below the maximum Probe limit?
In some cases, the Probe may report “Output Over Current Detected” even though the previewed amplitude appears to be within the normal maximum range. the Probe may still need to output significantly more current than expected in order to achieve the requested response under real measurement conditions.
In some cases the Probe may report "Output Over Current Detected" even though the previewed amplitude appears to be within the normal maximum range. The preview is an estimate — under real measurement conditions the Probe may need to output significantly more current than the preview suggests in order to achieve the requested response.
General reference: V3 Probes typically preview below 15 A. V4 Probes typically preview below 20 A. A preview below these values does not guarantee the measurement will stay within those limits.
Agent triage — ask these first
Ask all three before troubleshooting:
-
"Which Probe model are you using — V3 or V4?"
- If unsure: A V4 has an EIS enable switch on the front panel. Alternatively, the model is printed on the label on the back of the Probe.
- If still unsure: Continue with troubleshooting — Probe model can be confirmed later.
-
"At what frequency range or band is the fault occurring, and what amplitude are you requesting?"
- If unsure of exact frequency: Ask — "Does the fault happen early in the sweep (low frequencies, slower part), later in the sweep, or partway through?"
- If unsure of amplitude: Ask — "What current amplitude is set in the experiment settings, in amps?"
-
"How are you running the measurement — through the Cloud Dashboard, a local dashboard, or Modbus/scripts?"
- If unsure: Ask — "Are you clicking buttons on a web page to run the measurement, or is it triggered automatically by a script or PLC?" They can also check by opening dashboard.pulsenics.com — if that's where they run measurements, it's the Cloud Dashboard.
Use the answers to route:
| Situation | Route |
|---|---|
| Fault only at low frequencies (below ~100 Hz) | → Most common case. Start with amplitude and simultaneous frequency reduction below. |
| Fault near ~700 Hz | → Likely near the power supply's resonant region. If V4, check whether frequency skipping is available in settings. If V3, manual range narrowing is the main mitigation. |
| Fault across multiple frequency bands | → Likely a systemic power environment issue. Collect DC conditions and escalate sooner. |
| Fault occurs even after reducing amplitude | → Client-side mitigations exhausted. Escalate to Pulsenics with the full checklist below. |
| Running via Modbus/scripts | → Amplitude and frequency settings may be hardcoded. Ask the client to confirm what values are being sent before suggesting changes. |
Why this happens
The preview estimates how much current the Probe needs based on the requested amplitude, but the actual current required during a real measurement can be higher. This gap can occur because:
- High current demand at low frequencies — more current is typically needed at lower frequencies to maintain the requested perturbation
- Power supply resonant region (typically around ~700 Hz) — at frequencies where the power supply presents lower impedance, it more actively opposes the Probe's perturbation, requiring significantly more output current. This is a characteristic of the power supply, not the Probe model. V4 Probes can detect and skip these problematic frequencies automatically; V3 Probes cannot and require manual range adjustment to avoid them.
- Too many simultaneous frequencies — increases total current demand
- Low DUT impedance — lower impedance systems require more output current for the same perturbation
- Rectifier or load noise / large ripple — noisy DC conditions make overcurrent behaviour more likely and worsen measurement stability
- Insufficient DC filtering — increases stress on the measurement
Recommended workarounds — try in this order
After each step, run one measurement attempt to confirm whether the fault is resolved before moving to the next step. A single clean run is not sufficient — confirm across at least 2–3 consecutive runs before considering it stable.
-
Reduce the requested amplitude
- Even a small reduction has resolved the fault in past cases, even when the preview already appeared acceptable
- Cloud Dashboard: adjust the amplitude field in the experiment settings before running
- Modbus/scripts: confirm with the client what parameter controls amplitude in their script before suggesting a change
- Confirm after: run 2–3 measurements and check that no overcurrent fault appears
-
Reduce the number of simultaneous frequencies
- Lowers total current demand across the sweep
- Confirm after: run 2–3 measurements and check that no overcurrent fault appears
-
Narrow the low-frequency range
- Removes the most demanding part of the sweep
- Confirm after: run 2–3 measurements and check that no overcurrent fault appears
-
Improve DC filtering
- Reduces ripple and noise that contribute to overcurrent conditions
- This typically requires changes to the client's external power setup — confirm with them what filtering is currently in place before recommending changes
-
Review the external power environment
- Check for large ripple, noisy DC, or load behaviour that may be opposing the Probe's perturbation
- Ask: "Is the DC power supply output stable, or does it fluctuate during the measurement?"
-
If none of the above resolve the issue → collect the full escalation checklist below and contact Pulsenics
Before escalating — collect this information
This speeds up Pulsenics review significantly. Ask the client for:
- Probe model (V3 or V4)
- Requested amplitude (A)
- Affected frequency band(s)
- Number of simultaneous frequencies
- DC current and voltage at the time of the fault
- DUT type
- Rectifier or load model
- Whether the issue is worse at low frequency
- Whether large ripple or noisy DC conditions are present
- Interface method (Cloud Dashboard / local / Modbus)
- What mitigations have already been tried and what effect they had
Prevention
- Avoid aggressive low-frequency and high-amplitude combinations
- Use fewer simultaneous frequencies in challenging setups
- Record DC current, DC voltage, and supply type when planning measurements
- Validate the setup on a narrower or less aggressive range first
- Consider whether the external power environment is likely to oppose or distort the perturbation
Escalate if
Flag for Pulsenics review if:
- The fault continues after reducing amplitude
- The fault continues after reducing simultaneous frequencies
- The measurement still faults after narrowing the low-frequency range
- Repeated runs continue to fail in the same frequency bands
- The fault is near ~700 Hz on a V3 Probe and manual range narrowing has not helped
- All available client-side adjustments have been exhausted
What recovery looks like
- Measurement completes successfully with no "Output Over Current Detected" faults across 2–3 consecutive runs
- Requested amplitude is achieved or tracked acceptably
- Low-frequency data quality is stable where relevant
Article status
This is a living troubleshooting note for the symptom Output Over Current Detected despite previewed amplitude appearing within range. Additional causes, checks, and confirmed resolutions may be added as more cases are identified.
Tags: overcurrent, Output Over Current Detected, amplitude, low frequency, simultaneous frequencies, DC filtering, ripple, resonant region, V3, V4