H2-1｜What is a Utility Metering Module (and what it is not)

The module is a metering sub-system that turns polyphase voltage/current into billable energy registers and tamper-grade evidence. It must keep measurement and time integrity close to the data source and expose only clean outputs to the rest of the product.

A practical definition is “module-level,” meaning responsibilities are split between the metering core (AFE/SoC), the host controller, and the communications block. The split must be engineered around determinism, traceability, and noise containment:

• Close to the analog domain: synchronous sampling, stable reference behavior, and raw measurement integrity signals belong to the metering AFE/SoC side to minimize uncontrolled noise and timing ambiguity.
• Close to the time source: time-stamped events and TOU buckets require a clear “time validity” concept (e.g., backup present, set-time events, drift flags) so disputes can be re-checked later.
• Close to evidence generation: anti-tamper should produce structured evidence (type, severity, duration, snapshots), not unbounded narratives, to keep logs compact and comparable across firmware revisions.
• Outside the module boundary: transport protocol stacks and cloud workflows can change frequently; the metering module should only publish a stable hardware/data contract.

H2-2｜System placement & signal/data flow (polyphase → compute → log → link)

A utility metering module must be described as a deterministic pipeline. Every downstream accuracy claim, tamper decision, and field debug step should map back to a specific stage: sensing → conditioning → synchronous sampling → compute outputs → timestamped events → logs → interface boundary.

To keep debugging fast and disputes resolvable, the module should publish a data contract rather than raw streams. The contract is best expressed in four layers, each with clear “evidence” and “validity” flags:

• Fast telemetry: Vrms/Irms, P/Q, PF, frequency, harmonic indicators (concept-level). Used to explain “why the register changed.”
• Billing registers: Wh/varh accumulators (per phase and total), optionally bucketed for TOU. Used for settlement and audit.
• Status & integrity flags: overrange/saturation, sensor fault hints, time-valid state, and tamper candidate bits (debounced).
• Event log entries: type + severity + duration + timestamp + snapshot pointer, enabling consistent forensics across firmware versions.

H2-3｜Front-end sensing choices: shunt vs CT vs Rogowski (what breaks first)

Current sensing is the first place metering accuracy can collapse. The best choice is the one whose failure mode is controllable: phase error under low power factor, temperature drift over long dwell, and saturation or nonlinearity during inrush or fault events. This section compares shunt, CT, and Rogowski with the matching front-end blocks and the fastest ways to validate what fails first.

Selection should be done as an engineering closure loop: error source → field symptom → evidence → quickest test. The “break-first” items below are the most common reasons a meter looks stable at nominal load but drifts, undercounts, or becomes PF-sensitive.

• CT: saturation and phase shift are the top risks; problems amplify at low PF and during high-current transients.
• Shunt: self-heating and common-mode/ground return noise dominate at long dwell and light-load conditions.
• Rogowski: integrator drift and low-frequency error dominate; behavior near DC/very low frequency is the weak point.

H2-4｜Polyphase metering AFE architecture (ΣΔ ADC, PGA, digital filters, accumulators)

A polyphase metering AFE is not “just an ADC.” It is a controlled chain that turns phase-coherent samples into stable billing registers. Architecture understanding enables correct AFE selection and faster root-cause isolation when low-current accuracy, PF sensitivity, or transient behavior looks wrong.

• Input range and PGA: keep signals inside the AFE’s linear window across both light-load and high-current conditions.
• ΣΔ + decimation (concept): digital filtering suppresses out-of-band noise but introduces group delay that must remain matched across phases.
• Phase-coherent sampling: consistent timing across channels is a prerequisite for stable power factor and accurate active/reactive separation.
• Accumulators: energy registers should be treated as deterministic outputs with explicit saturation/overrange and integrity flags.
• Diagnostics: temperature/overrange/status bits convert “mystery drift” into evidence that can be logged and correlated.
• Minimal host interface (concept): read telemetry/registers/status; write calibration coefficients; handle IRQ cause codes and pulse outputs.

H2-5｜Accuracy & error budget that actually closes (gain/phase/offset/drift/harmonics)

“Accuracy” must be treated as a closed budget, not a slogan. A metering chain can look stable in nominal conditions yet undercount or drift when power factor drops, harmonics rise, or the load enters the light-current region. This section converts the common error sources into a verifiable template: each item maps to a physical cause, a calibratability class, and a concrete validation method with evidence that should be logged.

Polyphase metering errors are coupled: a small phase mismatch across channels can become a billing error because real power depends on the V–I phase relationship. The practical lesson is simple: phase issues often hide at PF≈1 and appear suddenly when PF decreases or when waveform distortion increases.

• Looks right, bills wrong at low PF: channel-to-channel phase mismatch, filter/group-delay mismatch, CT phase behavior, or timing misalignment.
• Light-load instability: offset/noise floor dominates, PGA/range not optimized, reference drift, leakage/protection parasitics.
• Harmonic-rich loads: frequency/phase response of the sensing + anti-alias chain and the digital filter configuration becomes decisive.

H2-6｜Calibration & compensation workflow (factory, field, drift control)

Calibration must be a controlled workflow with acceptance criteria and record fields, not an ad-hoc knob turning exercise. The goal is to establish a stable baseline (factory), decide when field re-check is justified (evidence-based), and apply compensation only within validated boundaries—so repeated recalibration does not “improve yesterday and break tomorrow.”

• Factory: offset → gain points → phase alignment → temperature points → repeatability check.
• Field check first: confirm whether the symptom follows load class (light-load/low PF/harmonics) or follows temperature/time/event history.
• Recal trigger (concept): systematic bias with repeatability; strong temperature correlation; stable measurement conditions but persistent deviation.
• Compensation boundary: LUT/model is valid only within the validated range; mechanical changes and sensor saturation behavior are not “fixed” by math.
• NVM write robustness (concept): versioned records, two-copy strategy, and write throttling to avoid endurance burn and power-loss corruption.

H2-7｜RTC, TOU, and time integrity (backup, drift, event timestamping)

In a utility metering module, time is not “nice to have.” Time is part of the auditable metering output: energy + when it happened + whether the timestamp is trustworthy. The RTC domain must survive power transitions, quantify drift, and label time quality so TOU windows and event logs remain reviewable.

RTC drift & timestamp error sources (what shifts first)

• Crystal initial tolerance: part-to-part frequency offset and load-capacitance sensitivity.
• Temperature behavior: short-term drift and slope changes during fast ambient transitions.
• Aging: slow monotonic drift over months/years (trend, not random noise).
• Power transitions: supply switchover glitches, backup-domain brownout, or unintended resets.

Backup strategy (keep “time” and the minimum audit trail)

Backup power is selected by holdover time, temperature, maintenance constraints, and transient robustness. The backup domain should preserve: RTC counter calibration/version ID event sequence last critical-event digest so logs remain ordered and reviewable after outages.

H2-8｜Anti-tamper: what to sense, how to decide, how to log

Anti-tamper becomes actionable only when it closes a loop: observable signals → decision policy → evidence log. The metering module should detect practical tamper classes (wiring tricks, phase anomalies, bypass behavior, magnetic/cover events, and sensor faults) while controlling false alarms using hysteresis, debounce, and multi-evidence voting.

Common tamper classes (module-level view)

The list below stays in the module boundary. It focuses on detectable contradictions and evidence capture, not on cryptographic signing or cloud forensics.

• Reverse / backflow: energy sign and phase relationship conflict with expected direction.
• Missing phase / missing neutral: phase presence mismatch and cross-phase inconsistencies.
• Phase sequence swap: abnormal phase ordering patterns and PF anomalies (concept).
• Bypass: voltage present while current path evidence is inconsistent or suddenly drops without physical cause.
• Strong magnetic field: magnetic sensor event + sensor behavior anomaly (e.g., CT response distortion) (concept).
• Cover open: cover switch triggers; log context around entry/exit.
• Sensor open/short/saturation: self-check flags, out-of-range, stuck readings, recovery artifacts.

H2-9｜Power, isolation, and survival on the mains (24/110/230/400V realities)

A utility metering module must do two things in real mains environments: survive (surge/EFT/ESD, miswiring, ground potential differences) and stay accurate (keep analog references and sampling stable while digital and comm domains switch hard). This chapter focuses on module-level power partitioning, isolation boundaries, protection placement, and “minimum pitfalls” in grounding/layout.

Power domains: what is noise-sensitive vs reset-sensitive

Domain separation is primarily about preventing high di/dt currents and comm bursts from contaminating the metering reference. Typical rails include: ANALOG DIGITAL COMM RTC BACKUP with explicit coupling control (filters, return-path control, and switchover integrity).

Isolation boundary: metering vs external comm/debug (principles)

• Break ground-loop paths: external cables and remote grounds must not inject common-mode currents into metering references.
• Contain surge energy: keep surge return paths on the “outside” of sensitive measurement areas.
• Preserve observability: isolate comm/debug while keeping module-level status pins and diagnostics consistent.

Protection placement logic (module-level)

Protection works when it controls where energy flows. Place devices so the high-energy current returns do not cross analog references or digital reset-critical rails. Use a layered strategy: ENTRY INTERFACE ISOLATION BARRIER SENSITIVE LOAD and verify return paths.

H2-10｜PLC / wireless links as a hardware interface (coupling, isolation, noise paths)

PLC and wireless are treated here as hardware interfaces, not protocol stacks. In a metering module they introduce coupling networks, burst currents, clock/EMI sources, and new return paths. The objective is simple: keep comm activity from corrupting measurements or creating false tamper events, while defining interface-level data integrity requirements (frame/CRC/timeout/retry).

PLC: coupling & protection roles (concept constraints)

• Impedance / bandwidth constraints: coupling network changes what the line “looks like” at the interface.
• Surge path definition: coupling is a physical entry path; protection must be placed to keep energy off sensitive returns.
• Common-mode control: keep PLC-related common-mode disturbances from shifting metering references.

Wireless: power and clock noise paths that hit metering

A typical field failure pattern is: TX BURST → COMM RAIL DROOP → GND BOUNCE → REF SHIFT → ERROR / FALSE TAMPER. Mitigation stays in hardware: local energy storage, rail filtering, and return-path confinement in the comm domain.

H2-11｜Validation & debug playbook (what to measure first, what evidence to keep)

This chapter defines an evidence-first debug order for a metering module: capture objective evidence, draw a bounded conclusion, apply a targeted fix, and retest under reproducible stress. The goal is to avoid “blind tweaks” that move the problem without closing it.

Example material list (part numbers) for validation & debug

The list below is a practical reference BOM for building a bench and enabling evidence capture. Equivalent parts are acceptable.

Output: 5-step debug loop (symptom → evidence → decision → fix → retest)