Home / Notes / PEN Optical Module Diagnostics

NOTES · PEN OPTICAL MODULE DIAGNOSTICS

PEN Optical Module Diagnostics: Reading Rx/Tx Power Like a Pro

On a passive all-optical campus (PEN), there is no active equipment between the center switch and the classroom wall plate — which means every dB of loss along that path is either fiber, a connector, or the module itself, and nothing else. This is how to read a PEN module's Rx/Tx power correctly, what -40dBm actually means at each end, and the clean-then-replace order that isolates the fault instead of swapping parts at random.

By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026

Why PEN Optics Read Differently From an Active Network

A PEN interface's dBm reading only ever describes three things: the fiber, a connector, or the module itself — there is no switch, no repeater, no active box in between to blame instead.

PEN — Passive Ethernet, a passive all-optical campus design — connects a center switch to remote classroom or office access points through a passive convergence module and plain glass fiber, with nothing active in between. That is what makes the design cheap to run and reliable once it is right, but it also means an interface's Rx/Tx power reading carries the entire story of the physical path: a dirty connector, a bent or reversed fiber, or a genuinely dead module. Guessing which one it is by swapping parts costs a site visit every time; reading the power numbers first almost always tells you before you touch anything.

What follows is the light path this note is built around, the exact power thresholds for PEN's two module types — the center module and the remote module — what a -40dBm reading actually means at either end, and the clean-then-replace order that finds the fault with the fewest wasted trips.

Follow the Light Path Before You Touch a Module

Every PEN Rx/Tx problem sits on one of two fiber runs — and the center module and the remote module do not share the same warning thresholds.

Reading one module type's power against the other's threshold is the single most common way to misdiagnose a perfectly normal port on a PEN network.

Diagram labels are kept in English for engineering clarity.

-40dBm on either module means the receiver is seeing no light at all — not 'very weak', literally none. Everything above that is a question of degree: below the marginal-low band is a cleaning-then-replacement problem, above the high threshold is usually a run that is too short for the module's design distance.

Reading the Numbers Stage by Stage

Center and remote modules use different marginal-low bands, and a -40dBm reading means something slightly different depending on whether it is RX or TX.

Stage 1 — Center Module Thresholds

The center module's 8 logical ports share one marginal-low band; a single port at -40dBm is a different problem from all 8 together.

Run display interface transceiver brief on the PEN center module's port. An active low-power warning or alarm, or an RX reading between -12dBm and -10dBm, counts as marginal-low on this module type — even before any alarm has actually fired.
An RX of exactly -40dBm on a single port among a center module's 8 logical ports means that specific receiver is not seeing any light at all — treat it as a wiring or connector problem on that one port, not the module itself, until proven otherwise.
If every port on the same center module shows RX -40dBm together, that points at the shared fiber run between the convergence module and the center switch, or the convergence module itself — not eight simultaneously dead remote modules.
A TX reading of -40dBm is a different question entirely from RX — check whether the port is a dual-uplink backup member before assuming the port itself has failed (see the gotcha below).

<HUAWEI> display interface 10GE1/0/40 transceiver brief
10GE1/0/40 transceiver diagnostic information:
-------------------------------------------------------------------
   Temperature (Celsius)                  :48.96
   Voltage (V)                            :3.31
   Bias Current (mA)                      :0.00
   Current RX Power (dBm)                 :-40.00
   Current TX Power (dBm)                 :-7.07
-------------------------------------------------------------------
// -40.00 on RX -> this receiver sees no light at all, not just a weak signal

Stage 2 — Remote Module Thresholds

The remote module's marginal-low band sits about 2dB lower than the center module's — reading it against the wrong module's threshold is the most common false alarm on PEN.

Run the same transceiver command on the remote module's port. The marginal-low band here is -14.4dBm to -11.4dBm — lower than the center module's -12dBm to -10dBm band, because the remote module sits at the far end of a longer, more attenuated run.
RX -40dBm on a single remote port is most often a reversed TX/RX pair on that fiber, or the remote module's number not matching the convergence-module port it is plugged into — reverse the fiber ends first; if the reading is still -40dBm, move to cleaning the chain.
RX power above the module's high threshold on a remote port means the run is simply too short for the module's rated attenuation budget — add an inline optical attenuator rather than treating it as a fault.
When multiple remote ports on the same row show RX -40dBm together, check the module numbering (A1 through A8) for the whole row before cleaning anything — a wholesale numbering mismatch reads exactly like a wholesale dirty-fiber problem.

<HUAWEI> display interface 10GE2/0/12 transceiver brief
10GE2/0/12 transceiver diagnostic information:
-------------------------------------------------------------------
   Current RX Power (dBm)                 :-40.00
   Current TX Power (dBm)                 :-6.82
-------------------------------------------------------------------
// reverse this port's fiber TX/RX first; if still -40.00, check module numbering A1-A8

Stage 3 — TX -40dBm: Is It Actually a Fault?

TX -40dBm is the reading most likely to send someone chasing a module that was never broken.

Check whether the port is a backup member of a PEN dual-uplink Eth-Trunk with display eth-trunk — a WorkingState of Inactive on that member is a normal standby state, and its TX reads -40dBm simply because it is not transmitting, not because it is damaged.
If it is not a backup member, run display interface and read current state. Administratively down means someone shut the port down; undo shutdown in interface view clears it.
If current state shows ERROR DOWN (down-cause), the down-cause field names the trigger, and each one calls for a different fix — see the table below rather than restarting blind.
Recover a genuine ERROR DOWN manually with shutdown then undo shutdown (or restart), or configure error-down auto-recovery cause <down-cause> interval <interval-value> so it clears itself the next time.
TX abnormal high or low that is not the -40dBm backup case is treated differently from RX — it almost always means the module itself is damaged, and the fix is a straightforward swap, not cleaning.

<HUAWEI> display current-configuration interface 10GE2/0/40
#
interface 10GE2/0/40
 eth-trunk 1
 device transceiver 10GBASE-FIBER
#
<HUAWEI> display eth-trunk 1
Eth-Trunk1's state information is:
WorkingMode: BACKUP
WorkingState: Master
--------------------------------------------------------------------------------
PortName                      Slave/Master       Status           WorkingState
10GE1/0/40                    M                  Up               Active
10GE2/0/40                    S                  Up               Inactive
// 10GE2/0/40 is the Inactive backup member -> its TX -40dBm reading is normal, not a fault

down-cause	What it means
auto-defend	Attack-source tracing shut the ingress port down as a punitive action after auto-defend action was configured, to stop the attack traffic at its entry point.
bpdu-protection	A forged BPDU arrived on an edge port protected against it in an STP network; the switch drops that port to Down to block all traffic on it.
link-flap	A faulty cable or a master/backup switchover caused rapid Up/Down cycling; once Link-flap protection is configured, the port shuts down after a set number of flaps within a set interval.
loopback-detect	The port received back its own loopback-detection frame, meaning a physical loop exists; shutting the port down is one of the configurable actions.
mac-address-flapping	The MAC address learned on the port keeps moving, and the port's physical state is set to Down as a result.
monitor-link	An uplink in a Monitor Link or Smart Link group went down (or all of them did), and the associated downlink port is brought Down in response.
portsec-reachedlimit	The number of MAC addresses learned on the port exceeded the configured limit, and the port's physical state is set to Down.
storm-control	Broadcast, multicast or unknown-unicast traffic exceeded the configured high threshold during the storm-control detection interval, with the action set to error-down.

Gotchas That Waste a Site Visit

Read these before you drive out with a bag of spare modules — most of what looks like a dead part is one of these five.

1. TX -40dBm on a Backup Member Is Not a Fault

SYMPTOMOne member of a dual-uplink Eth-Trunk pair permanently reads TX -40dBm, RX still looks reasonable, and someone opens a ticket to replace the module.

CAUSEThe port is the Inactive backup member of a manual-backup Eth-Trunk; a standby member does not transmit, so its TX reads exactly -40dBm by design — not because anything failed.

FIXBefore troubleshooting the module, run display eth-trunk on the bundle and check WorkingState; only chase TX -40dBm as a fault when the port is not a backup member, or when the Eth-Trunk's own state looks unexpected.

2. RX -40dBm Reads Like Dirty Fiber But Is Usually Reversed TX/RX

SYMPTOMA single port's RX sits at exactly -40dBm, with no warning ever building up gradually beforehand.

CAUSE-40dBm is the no-light floor, not a weak-signal reading — it almost always means the fiber's TX and RX are swapped at that connection, or the remote module's number does not match the convergence-module port it is plugged into, not that a connector is dirty.

FIXReverse the fiber pair at that port first and re-check before reaching for a cleaning pen; only move to cleaning the fiber, ODF and module chain if reversing the pair does not clear it.

3. All Ports on One Center Module at -40dBm Points Upstream, Not at 8 Remote Modules

SYMPTOMEvery one of a center module's 8 logical ports shows RX -40dBm at the same time.

CAUSEIt is vanishingly unlikely that eight independent remote modules failed at once — the point all eight ports have in common is the fiber and connectors between the convergence module and the center switch, or the convergence module's UPLINK port itself.

FIXReverse one fiber at the shared uplink first; if that single test clears -40dBm across the whole group, work down the shared segment — fiber, then convergence module, then module numbering — rather than opening eight separate tickets for eight separate remote modules.

4. High Optical Power Is Not a Module Defect — It Is a Run That Is Too Short

SYMPTOMRX power sits above the module's high threshold, consistently, on a run that otherwise looks fine.

CAUSEThe fiber run is simply shorter than the module's design distance calls for, so the signal never attenuates down into the range the receiver expects — a distance mismatch, not a failing part.

FIXAdd an inline optical attenuator, preferably on the uplink between the convergence module and the center module rather than at every single remote port, and re-check the reading.

5. Clean in Order — Do Not Replace Hardware First

SYMPTOMA module gets swapped for a marginal-low or -40dBm reading, the replacement shows the identical number, and the real cause turns out to be the fiber all along.

CAUSEFiber and ODF-connector contamination looks identical to a marginal or dead module on a power reading alone — jumping straight to a module swap skips the cheaper, faster fix and does not even confirm which segment is actually at fault.

FIXClean in a fixed order — fiber and ODF connectors first, then the convergence-module interface, then the remote module — re-checking the power reading after every single step, and only replace hardware once cleaning the whole chain has not cleared it.

Five Questions That Come Up Constantly

Pulled straight from the field — the ones worth having an answer ready for.

What actually is a PEN network, and why does it change how I read optical power?

PEN — Passive Ethernet — runs a center switch out to remote access points through a passive convergence module and glass fiber only, with zero active electronics in between. That absence of active equipment is exactly why the power reading at either end tells the complete story of the physical path — there is no intermediate box that could also be at fault.

Why do the center module and the remote module have different marginal-low thresholds?

The remote module sits at the far end of a longer, more attenuated run by design, so its normal operating range — and its marginal-low warning band, -14.4dBm to -11.4dBm — sits about 2dB lower than the center module's -12dBm to -10dBm band. Reading a remote module's number against the center module's threshold, or the reverse, makes a perfectly normal port look marginal.

I see RX -40dBm on one port but the rest of the row is fine — do I need to test every fiber before I start?

No — reverse just that one fiber's ends first. If the reading clears, it was a TX/RX swap. If it stays at -40dBm, check that the remote module's number actually matches the convergence-module port it is connected to before doing anything else; only move to cleaning once both of those are ruled out.

TX shows -40dBm — how do I know if that is the normal backup state or an actual fault?

Check whether the port is a member of a PEN dual-uplink Eth-Trunk first. An Inactive backup member reads TX -40dBm by design, every time, simply because it is not transmitting — that is normal. If the port is not a backup member, then -40dBm on TX is worth chasing as Administratively down, ERROR DOWN, or a damaged module.

Optical power on the module looks completely normal, but I am still seeing intermittent packet loss — what is next?

A clean power reading does not rule out a module putting out a degraded signal that still causes bit errors rather than an outright alarm. Reading CRC, Giants/Runts and discard counters is the next layer once optics look clean on the surface — see our Network Packet Loss note for the exact fields and thresholds to check next.

Honest Limits of This Note

Honest Limits of This Note

This note is built around the Huawei S-series PEN passive-all-optical-campus fault-classification model and its display interface transceiver / display eth-trunk commands, plus the field cases behind them. If your access design is a different vendor's passive-optical or media-converter system, the exact thresholds change, but the underlying logic — the no-light floor, the marginal-low band, the clean-then-replace order, backup-member TX behavior — carries over directly. It does not cover fiber-optic test-equipment procedures such as OTDR traces or power-meter calibration in depth, since that is a separate field-service skill rather than a switch-side diagnostic.

Staring at a PEN port that will not clear -40dBm?

Tell us whether it is one port or the whole row, center module or remote module, plus the display interface transceiver brief output — we will help you read it.

WhatsApp an engineer →