Skip to content

Rev B1 ECN-16 — Move SK6812 LED supply from +5V0 to +3V3 (draft)

Draft — EverTag Station base PCB

Move the SK6812MINI LED VCC (LED1 system, and LED2 gateway on populated variants) and their per-LED bypass capacitors from the +5V0 rail to the battery-backed +3V3 rail. This (a) aligns the schematic with the 232200 §3.4 spec (which already states 3.3V supply), (b) makes the LEDs survive on battery (the +5V0 rail is dead on AC loss), and © removes a latent data-line logic-level marginality (3.3V GPIO into a 5V-powered SK6812). Not approved. Fix targets the B1 Altium release. Does not apply to Tag (230220).

Ships in the same B1 respin as Rev B1 ECN-01 — GPIO remap.

Background — schematic / spec / battery mismatch

Three independent observations point at the same net:

  • Schematic (A2 as built): the SK6812MINI VCC ties to +5V0, with a 100 nF bypass on +5V0 at the LED.
  • Spec: 232200 §3.4 states "Supply: 3.3V (SK6812MINI supports 3.5–5.5V, 3.3V tolerant)" — i.e. the documented intent is the 3V3 rail, not +5V0.
  • Bench finding (2026-06-15): on the 232201 battery test the LEDs die on AC loss because they are powered from +5V0 (not V_PP) — not a fault in itself, but it means the LEDs are dark on battery.

The system rail is already battery-backed: B1 (+5V0 → V_PP) OR B2 (V_BAT → V_PP) feeds TPS62160 VIN → +3V3. The LEDs are the one load left hanging on the un-backed +5V0 rail, so they are the only indicator that goes dark exactly when a power-loss indication is most useful.

Traceability — refdes

The A2 schematic shows LED1 (D2) VCC and bypass C14 on +5V0; cited here for traceability per the refdes rule. Final designators (incl. LED2 and its bypass) are confirmed in Altium at B1 lock — this ECN specifies the change by net and function.

What changes

Re-net the LED supply and its decoupling from +5V0 to +3V3. No component, footprint, daisy-chain, or LED_DATA (P0.01) change.

A2 (as built) B1 (proposed)
LED1 VCC (system, all variants) +5V0 +3V3
LED2 VCC (gateway, 232202/232203) +5V0 +3V3
Per-LED bypass cap 100 nF on +5V0 100 nF on +3V3 (rating unchanged; 16V part is fine)
LED_DATA / P0.01 unchanged unchanged
Behaviour on AC loss LEDs dark (+5V0 dead) LEDs live (V_PP → +3V3 holds up on battery)
Data-line level (VIH ≈ 0.7·VDD) 0.7·5 = 3.5V vs 3.3V GPIO → marginal / out of spec 0.7·3.3 = 2.31V vs 3.3V GPIO → comfortable margin

BOM / cost impact: none. No parts added or removed — this is a net-routing change only, zero unit-cost delta on every variant.

Rationale

Topic A2 problem B1 intent
Spec alignment Schematic on +5V0; spec says 3.3V Schematic matches spec
Battery backup LEDs dark on AC loss — no power-loss indication LEDs powered from battery-backed +3V3
Data logic level 3.3V GPIO into 5V SK6812 (VIH 3.5V) — out of spec on the first LED VIH 2.31V — valid with margin
Scope — LED VCC net + bypass only — no part/footprint/pin change

This is the hardware enabler for the firmware "on battery / AC lost" LED indicator (driven by DC_PRESENT); without it the indicator cannot exist because the LEDs lose power exactly when it is needed.

Risks of moving to +3V3 (and mitigations)

# Risk Severity Mitigation
1 SK6812MINI rated supply. The part is specified 3.5–5.5V (VIH 0.7·VDD, i.e. 3.4–3.5V at 5V); 3.3V is at/below the datasheet minimum. The high-Vf blue/green dies (Vf ≈ 3.0–3.2V) lose headroom first → dimmer / colour-shifted. Med Bench-verify colour + brightness through the light guide at 3.3V. Note: the logic-level concern is fully resolved by this rail move alone — at VDD=3.3V even a 0.7·VDD part needs only VIH=2.31V, comfortably driven by the nRF54. A component swap is not required for the data level.
2 Rail sag on battery. On battery V_PP ≈ 3.2V and the TPS62160 is in near-100% duty (dropout); the +3V3 rail may sit below 3.3V (ECN-14 open item #2). SK6812 blue/green may not light at all on battery; red/amber is robust (red die Vf ≈ 1.8V). Med Use AMBER for the on-battery indication (warning class — uses the robust red die; see Firmware). Don't rely on full-colour (blue/green) fidelity on battery.
3 +3V3 current budget. Two LEDs at full white ≈ 72 mA add to the PAN611 (and ESP32-domain load on gateway) on the TPS62160 (1A, ~500 mA headroom). On battery the buck draws more input current from 3.2V. Low Confirm 3V3 headroom on the worst case (gateway + battery); LEDs are short blinks, not steady white. Covered by the battery hold-up retest.
4 LED switching noise on the MCU/RF rail. LED PWM currents now share the rail with PAN611 / NFC. Low Per-LED 100 nF decoupling already present (re-netted to +3V3); keep LED return short. No RF trace impact (LED data already routed away from RF).
5 Bypass cap. C14 (100 nF, 16V) on +5V0 re-netted to +3V3. None 16V rating covers 3.3V; reuse the same part.

Net assessment: the change is low-risk and net-positive — it fixes a real defect (LEDs dark on battery), aligns with the published spec, and improves the data-line margin. The only genuine watch-item is colour fidelity at 3.3V and especially on battery, which is mitigated by using an AMBER indication in battery mode and by a bench check of colours through the light guide.

Contingency — LED swap deliberately not bundled here

A 3.3V-rated drop-in (WS2812B-2020-V6, single-wire compatible, VDD 3.3–5.3V, VIH 0.55·VDD; LCSC C965555) exists, but is not recommended as part of this ECN:

  • The rail move already fixes the only hard electrical issue (logic level). V6's lower threshold is redundant once VDD = 3.3V.
  • Blue/green Vf (3.0–3.2V) is a physics limit shared by all these LEDs incl. V6 — battery-rail legibility is handled by the AMBER indication, not by the LED choice.
  • Sourcing fails the component rules: Worldsemi is single-source, no authorised DigiKey/Mouser stock (LCSC/JLCPCB/TME only), and the 3.3V rating is V6-revision-specific while distributors ship generic "WS2812B-2020" often rated 3.7–5.3V → the correct silicon is not procurement-guaranteed.
  • It is a footprint change (2020 vs 3535) — smaller, dimmer, light-guide rework.

If bench testing shows SK6812MINI colours at 3.3V are unacceptable, prefer raising the rail (feedback-divider tweak toward ~3.4V — its own small ECN) over swapping to a single-sourced LED.

Scope

Item B1 change
232200 Base Std LED1 VCC + bypass → +3V3 (shared base layout)
232201 Base Bat Same; LED1 now battery-backed (V_PP → +3V3)
232202 Base WiFi LED1 + LED2 VCC + bypass → +3V3
232203 Base Bat+WiFi Same; LED1 + LED2 battery-backed
232204 Base Bat+Radar Same shared layout
230220 Tag No change (separate product; single Red LED, own design)
LED_DATA (P0.01), SK6812 footprints, daisy-chain Unchanged

Altium implementation (after design approval)

  1. Re-net LED1 VCC (and LED2 VCC where present) from +5V0 to +3V3.
  2. Re-net the per-LED bypass caps to +3V3 (same 100 nF part).
  3. Verify no remaining SK6812 pin (VCC / bypass) references +5V0.
  4. BOM — no add/remove; net change only. Applies to all base variants.
  5. Gerber lock — confirm every SK6812 VCC + bypass net is +3V3, none on +5V0.

Firmware (after B1)

  • New LED state in UI behaviour: "On battery / AC lost", driven by DC_PRESENT (B1: P1.13, GPIOTE wake per ECN-01).
  • Colour: AMBER (warning class — mains lost but the anchor is still operational on battery; RED stays reserved for faults). AMBER uses the robust red die, so it stays legible even if the +3V3 rail sags on battery (see risk #2). Short blink.
  • Activates even in dormant mode (otherwise a deployed unit shows nothing on power loss).
  • Power budget: brief blink only; never steady white on battery.

Verification (assembly / QA)

  • Release BOM/net: every SK6812 VCC + bypass on +3V3, none on +5V0
  • Mains present: LED1 (and LED2 on gateway) show full colour set through the light guide at 3.3V — verify blue/green legibility
  • AC loss on a correct-polarity battery board (232201): LEDs stay lit (AMBER power-loss indication visible) — the original "LEDs die" symptom is gone
  • Measure +3V3 on battery (V_PP ≈ 3.2V): confirm rail level and that the AMBER indication is legible
  • LED_DATA (P0.01 / TP11) timing unaffected; no glitching at 3.3V VDD (VIH margin)
  • 3V3 headroom OK on worst case (gateway + battery) with LEDs driven
  • Non-LED behaviour unchanged on all variants

Open items

# Question Owner Status
1 Confirm the production SK6812MINI part is acceptable at 3.3V (and at battery V_PP ≈ 3.2V) for required colours. If inadequate, prefer nudging the rail (feedback-divider, separate ECN) over an LED swap — see contingency note HW + bench Pending
2 Fold the +3V3 LED load into the battery hold-up retest (buck headroom on V_PP) Bench Pending