230 lines
21 KiB
Markdown
230 lines
21 KiB
Markdown
# HBOX V4 / V5 — pin-map audit against firmware 0.5.4 + bench log analysis
|
||
|
||
**Date:** 26-Sep-2026 · **Firmware:** `hbox_v5_bringup` 0.5.4 (`board_v4.h` / `board_v5.h`) ·
|
||
**Boards:** `hbox-watchdog-v4.kicad_pcb` (as fabbed, 01-Aug) · `hbox-watchdog-v5.kicad_pcb` (= fab IPC-356 netlist of 21-Aug, 768 pads compared, no net differences)
|
||
**Inputs:** `06-Testing-Validation/log1.txt` (13:12, stack OFF, vbat 3.14 V) and `STAT up=152s vbat=4.03 v5=0.00(no).txt` (13:14, battery duty cycle)
|
||
|
||
## 1. Verdict
|
||
|
||
1. **The pin map is correct on both boards.** Every `PIN_*` in `board_v4.h` and `board_v5.h`, plus the hard-coded `RELAY(PA10, PA9)` and USB, lands on the right net, and each net reaches the right load. This was checked at pad level and by a copper-connectivity check on the fabbed PCB files. V4 and V5 are netlist-identical outside the MCU. The only differences are the fan-tach parts (P6.4, Rtp1/Rts1, V4 only), Rig2 (V5 only), P1.4 and the W5500 exposed pad.
|
||
2. **`log1` shows no hardware fault. The firmware kept the stack OFF on purpose.** Three conditions each block it on their own: reset = **POR**, **0.00 V on P2** (PA4) and **vbat 3.14 V** (below the 3.40 V cut). Because of this the ArduSimple and the 4G are never powered, and a reset does not bring them back (§2).
|
||
3. **V4 has one real hardware problem, and it is not in the pin map.** The Blackpill 5V header pins are wired straight to its USB VBUS, and V4 ties those pins to `/SYS5V`. With a laptop on the Blackpill USB, the PC's USB port is hard-paralleled with the board's 5 V rail. On battery the PC (5.0 V) out-pulls the LTC4040 boost (4.79 V), so it is the PC that tries to feed the modem. **Battery tests on V4 with the USB console attached are not valid** (§4.1).
|
||
4. **The pack is flat and the firmware cannot recharge it.** Every 0.5.x build keeps `CHRG_EN` HIGH. Each battery test drains the pack permanently until it can no longer open a duty window. A pack at 3.14 V also needs attention to avoid over-discharge (§4.3).
|
||
5. The **V5 "4G dark after low-power mode"** problem is real and separate. The MCU side of the duty cycle works (log 2). The modem side has to be measured. See §5 for the three measurements that decide the fix.
|
||
|
||
## 2. What `log1` says
|
||
|
||
```
|
||
STAT up=80s vbat=3.14 v5=0.00(no) ign=OFF chrg=idle ... stack=OFF modo=AUTO ... bkp=0
|
||
$PHLG,0.5.4-fm,BENCH,SRCH,...,3.14,0.00,...,POR,...,80,BATT,0.00,3.13,0
|
||
```
|
||
|
||
| Firmware rule (0.5.4) | Value in log1 | Effect |
|
||
|---|---|---|
|
||
| AUTO powers the stack only when **PA4 ≥ 4.50 V for 3 s** (`V5_STACK`, `AUTO_SETTLE_MS`) | v5 = 0.00–0.01 V for the whole capture | Stack never switched on |
|
||
| Battery windows start only after a **warm** reset (IWDG/BOR/SOFT/LPWR). **POR and PIN (button) are excluded** | reset = POR | No duty window, and a button press would not start one either |
|
||
| Battery windows need **vbat ≥ 3.40 V** | vbat = 3.14 V (min 3.13) | Would be skipped even after a warm reset |
|
||
|
||
The I²C and analog paths are healthy: SHT40/TMP102 read, `i2cerr=0`, NTC 26.6 °C, MCU 31.9 °C, charger idle with no fault. **The one missing input is 5 V at P2.** One of these is true:
|
||
- the unit was on USB console only (no 24 V), which is normal but powers nothing;
|
||
- 24 V was on but the SD-15B output is not reaching P2 (the same symptom as RTK-005 on 18-Sep: harness / GX16 / SD-15B);
|
||
- 5 V reaches P2 but not PA4 (R7/R8 divider). This is unlikely, and the §6 measurement separates it.
|
||
|
||
## 3. Pin audit
|
||
|
||
`✔` = the MCU pin, the net and the load all agree with the header file. V4 socket pads were mapped with the WeAct header order (header 1 runs 5V…VB from the USB end, header 2 runs B12…3V3 from the USB end). **J1 is the `RevNum_EJ1` footprint: pad 20 (`/SYS5V`) and J2 pad 1 (`/ETH_CS`) sit at the same end (x = 107.2), which is the USB end.** The E-J1 mirror is fixed in V4, and the silkscreen labels (`5V`, `NRST`, `PCTL`…) match.
|
||
|
||
| Signal | FW pin | V5 U16 (LQFP64) | V4 socket pad → Blackpill pin | Load / other end | |
|
||
|---|---|---|---|---|---|
|
||
| BAT_SENSE | PA0 | 14 | J1.6 → A0 | R5/R6 10k/10k from `/BAT_PLUS`, C5 | ✔ |
|
||
| PWR_CTRL | PA1 | 15 | J1.7 → A1 | R1 1k → Q5 (B,E,C = 1,2,3) → `/GATE_LS` (R2 10k to SYS5V) → Q1 AO3401A (G,S,D = 1,2,3) → `/SW_5V` → MOD1.5 + U7 VIN/EN | ✔ |
|
||
| GNSS_TX / RX | PA2 / PA3 | 16 / 17 | J1.8 → A2 / J1.9 → A3 | MOD1.16 / MOD1.15 (simpleRTK2B UART1) | ✔ |
|
||
| 5V_SENSE | PA4 | 20 | J1.10 → A4 | R7/R8 10k/10k from `/VEH5V` (P2.1), C7 | ✔ |
|
||
| IGN_SENSE | PA5 | 21 | J1.11 → A5 | Rig1 22k from IGN_IN, Rigb1 3.3k (+Rig2 22k on V5), BAT54 clamp | ✔ |
|
||
| FAN_PWM | PA6 | 22 | J1.12 → A6 | fan low-side gate | ✔ |
|
||
| CHRG_EN | PA8 | 41 | J2.5 → A8 | U6 LTC4040 pin 4 (HIGH = charge off), R56 | ✔ |
|
||
| USART1 TX / RX | PA9 / PA10 | 42 / 43 | J2.6 → A9 / J2.7 → A10 | K1.10 (NO) / K1.1 (NC) + MOD1.23 (F9P TX2 tap); K1 COM → `/DIN_4G` → J7.3 | ✔ |
|
||
| USB D− / D+ | PA11 / PA12 | 44 / 45 | Blackpill USB-C (J2.8/9 left open) | V5: J11 + PESD | ✔ |
|
||
| ETH_RST | PA15 | 50 | J2.10 → A15 | W5500 pin 37 | ✔ |
|
||
| EXT_LED | PB0 | 26 | J1.14 → B0 | Q4 gate | ✔ |
|
||
| NTC | PB1 | 27 | J1.15 → B1 | R42 10k to 3V3 + P12 | ✔ |
|
||
| ETH_INT | PC0 (V5) / PB2 (V4) | 8 | J1.16 → B2 | W5500 pin 36 | ✔ |
|
||
| CHRG_STAT / FAULT | PB3 / PB4 | 55 / 56 | J2.11 / J2.12 | U6 pins 8 / 9, 100k pull-ups | ✔ |
|
||
| BYP_CTRL | PB5 | 57 | J2.13 → B5 | R40 → Q6 → K1 coil, D6 flyback | ✔ |
|
||
| I2C SCL / SDA | PB6 / PB7 | 58 / 59 | J2.14 / J2.15 | U3, U4, U10, U13, P5, 4.7k pull-ups | ✔ |
|
||
| SER_IRQ | PB8 | 61 | J2.16 → B8 | U10 pin 15, R81 | ✔ |
|
||
| ETH SPI | PB12–15 | 33–36 | J2.1–4 | W5500 | ✔ |
|
||
| LED_C13 | PC13 | 2 | Blackpill LED (J1.2 open) | V5: D17 + R102 to 3V3 (active low) | ✔ |
|
||
| NRST | — | 7 | J1.5 → R | **V5:** SW1 + C104 100 nF + P10 + TP5. **V4:** SW1 + P10 | ✔ |
|
||
| BOOT0 / BOOT1 | — | 60 / 28 | on Blackpill | V5: R98 10k↓ + SW2 to 3V3; R99 10k↓ | ✔ |
|
||
|
||
V5 support pins also check out: VCAP1 = C111 4.7 µF; VDDA through R104 10 Ω + C109/C112; HSE = Y3 25 MHz with 15 pF; LSE = Y4; VBAT tied to 3V3.
|
||
SW1 on both boards is the standard 6×6 THT footprint: NRST on the pad pair 6.5 mm apart, GND on the other pair (part C83205, K2-6639DP).
|
||
|
||
## 4. Hardware and firmware findings
|
||
|
||
### 4.1 V4: USB VBUS is hard-wired to `/SYS5V` (V4 only)
|
||
The WeAct 5V header pins are the USB VBUS, with no diode. V4 connects J1.20 and J2.18 to `/SYS5V`, and has no other 3V3 source apart from the Blackpill LDO. V5 does not have this problem: J11 VBUS reaches only the MCU LDO, through D13 in a diode-OR with D12.
|
||
- **USB only:** the laptop powers SYS5V, K1, U12/W5500 and back-feeds MAIN5V through P11. The stack stays off, because VEH5V = 0.
|
||
- **24 V + USB:** SD-15B (~5.2 V) and the laptop VBUS fight each other.
|
||
- **Battery + USB:** the laptop's 5.0 V is higher than the boost's 4.79 V, so the laptop port carries the stack. It cannot supply the LTE burst: **4G stays dark and the result says nothing about the battery path.**
|
||
- `board_v4.h` says "flash by DFU on USB only (W5500 unpowered)". **That is wrong on V4.** USB alone powers the W5500 through SYS5V → U12. If DFU ever fails to enter on V4, this is why (INTn on PB2 = BOOT1).
|
||
|
||
To confirm on your module revision: with the Blackpill out of the board, check continuity from the USB-C VBUS to the 5V header pin (expect ~0 Ω).
|
||
**Bench rule until reworked:** with the board powered, connect the console through a USB cable with VBUS cut (data only), or through a USB isolator. **Rework option:** lift the two Blackpill 5V pins out of the sockets and feed the Blackpill 5V from SYS5V through a Schottky diode (anode SYS5V, e.g. at D6 cathode). USB can then never reach SYS5V.
|
||
|
||
### 4.2 Reset behaviour
|
||
- **Hardware:** on both boards the MCU reset button is wired correctly (table above). The quick test is to press SW1 with the console open. The first line after the banner must read **`reset=PIN`**. If it does, the button works.
|
||
- **Firmware:** a button reset **never powers the stack without 5 V on P2**. POR and PIN are deliberately excluded from the "warm reset → battery mode" path in 0.5.2+. On battery, pressing reset therefore makes a unit go quiet until the vehicle 5 V returns. This matches "after reset the ArduSimple doesn't come back".
|
||
- **SW4G1** (the 4G reset) only pulls XBee pin 5 low. Whether the 4G NTRIP Master resets on that pin depends on the module. If pressing it with the modem running does nothing, the module does not use pin 5, and the only way to reset the modem is to remove its power (a stack cycle).
|
||
|
||
### 4.3 Charging is off in every 0.5.x build
|
||
`CHRG_EN` is held HIGH from boot ("paquete de un solo uso"). Consequences:
|
||
- after one or two battery tests the pack stays low for good;
|
||
- below 3.40 V every duty wake is skipped;
|
||
- at 3.14 V resting the cell is essentially empty. The LTC4040 boost keeps running the board until its own UVLO (2.45–2.6 V), which is deep over-discharge for Li-ion.
|
||
|
||
Disconnect or recharge that pack now, using an external charger. Battery tests cannot be repeated until the firmware can charge.
|
||
|
||
### 4.4 Minor
|
||
- The AUTO power-on also needs **v5 ≥ 4.50 V** (not only "present" ≥ 4.20 V). With 4.20–4.50 V at P2 the stack stays off, and no EVT line says why.
|
||
- The IGN divider reads 24 V correctly (V4 3.13 V, V5 2.77 V at the pin). A 12 V ignition, 1.4–1.6 V at the pin, sits in the undefined input band.
|
||
|
||
## 5. V5 battery problem ("4G does not turn on after the low-power mode")
|
||
|
||
The second log shows the **MCU side working exactly as designed**:
|
||
- windows #2 and #3 open 600 s apart;
|
||
- the F9P sends NMEA 0.9 s after `STACK ON` and has a GPS fix after ~12 s;
|
||
- Modo B engages at +10 s and 4 `$PHLG` go into the modem DIN per window;
|
||
- each window closes at 120 s;
|
||
- vbat is 4.08 V at rest and 4.00–4.06 V in the window (min 3.92 V).
|
||
|
||
The MCU cannot see whether the modem is alive. The first window works because the modem was already registered on vehicle power. The failure is a **cold modem start from the battery boost**: MAIN5V 4.79 V → P11 → F1 → Q1 (switched hard, no soft-start, into C3/C40 + the ArduSimple + U7) → 3V3_MODEM. The EMC audit already flagged the narrow `/SW_BAT` (0.3 mm) and `/BAT_PLUS` (0.3–0.5 mm) paths in exactly this current loop. Three measurements settle it:
|
||
|
||
| # | Test (during a battery wake) | If… | Then the fix is… |
|
||
|---|---|---|---|
|
||
| M1 | Min-hold DMM or scope on **3V3_MODEM (C43)**, **SW_5V (C3)** and **MAIN5V (C32)** for the first 60 s | 3V3_MODEM dips below ~3.1 V, or SW_5V below ~4.3 V | a supply problem: continue with M2 |
|
||
| M2 | Replace the pack with a **lab PSU 3.8 V / 5 A** on short leads into P4 | the modem starts on every wake | pack, wiring or trace impedance (EMC items 1–2); the pack side, not firmware |
|
||
| M3 | When the modem is dark inside a window, press **SW4G1** | the modem boots | a start-up latch: wire a spare GPIO to `/MODEM_RST` and pulse it from firmware |
|
||
|
||
Also check on the server whether `$PHEV DUTY_WAKE` and `$PHLG … BATT` arrived around 13:02 and 13:12 (windows #2/#3 of log 2). That confirms the modem side independently of the bench.
|
||
|
||
## 6. Bench sequence for the board in `log1` (≈15 min)
|
||
|
||
1. Remove the Blackpill USB (V4) or keep only J11 (V5). Charge or replace the pack to ≥ 3.8 V.
|
||
2. Apply 24 V. Measure **P2.1 to GND** (expect 5.1–5.3 V) and **R8 top / PA4** (expect half of that).
|
||
- 0 V at P2: fix the SD-15B / GX16 harness.
|
||
- 5 V at P2 but not at PA4: check R7/R8 and the socket contact at J1.10 (V4).
|
||
3. Reconnect the console (VBUS-cut cable on V4). Expect `V5 PRESENTE`, then `STACK ON reason=auto` 3 s later. `v` prints the checkpoints: PWR_CTRL 3.3 V → GATE_LS < 0.3 V → SW_5V ≈ 5 V.
|
||
4. Press SW1: the next boot must read `reset=PIN`, and the stack comes back 3 s later because 5 V is present.
|
||
5. Only then repeat the battery test (V5 first), with M1–M3.
|
||
|
||
## 7. Proposed 0.5.5 (for approval — nothing changed yet)
|
||
|
||
| Priority | Change | Size |
|
||
|---|---|---|
|
||
| 1 | Treat a **PIN reset like a warm reset**: with no 5 V and vbat ≥ 3.40 V, the first battery window opens at +60 s. The button then revives a unit on battery. | tiny |
|
||
| 1 | **Say why the stack is held:** `espera=5V(P2 0.00V)` / `vbat<3.40` / `v5<4.50` / `POR sin 5V` in STAT, plus a boot EVT. | tiny |
|
||
| 2 | **Charge enable** when 5 V is present and tbat/tntc < 40 °C, off at ≥ 45 °C, with the LTC4040 timer restart (the hostsim-validated v3.0 policy). Without it every battery test consumes a pack. | medium |
|
||
| 3 | **Modem start on battery**, picked by M1–M3: a PWM soft-start on PA1 (TIM2_CH2, ~100 ms ramp) if the fault is the inrush dip, or a modem-alive input plus a reset pulse (one bodge wire: V5 PC1–PC3 / V4 PA7 are free) if it is a start-up latch. | small–medium |
|
||
|
||
Same source for V4 and V5; the binaries stay `hbox-v5-bringup_0.5.5.bin` and `hbox-tarjetaV4_0.5.5.bin`.
|
||
|
||
---
|
||
|
||
## 8. Addendum (26-Sep, 15:00): what V4 still needs with firmware 0.5.5
|
||
|
||
**Binary checked.** `release/hbox-tarjetaV4_0.5.5.bin` has SHA-256 `39ea770b…2911`. That is the same as `out-v4`, built from commit `2e0bf24` with `board_v4.h`. Its strings read `0.5.5-fm`, `EinarBoard v4 (HBOX v4)` and `STM32F411CEU6 Blackpill`.
|
||
|
||
**The 0.5.5 change is correct on V4.** V4 declares `GNSS` as `Uart(PA3, PA2)`. `end()` followed by `pinMode(INPUT)`, and `begin()` again at stack-on, behaves the same as on V5. In `setStack(true)`, power goes on before the UART drives PA2, and at stack-off power goes off first.
|
||
|
||
### 8.1 One gap left in 0.5.5 (both boards): PA9/PA10 after Modo B
|
||
The STM32duino `HardwareSerial::end()` → `uart_deinit()` only resets and clock-gates the USART. **It never touches the GPIOs.** I checked this in `uart.c` on core 2.9 and on `main`. The pins keep the pin-map mode `AF_PP + GPIO_PULLUP`. 0.5.5 fixes this for the GNSS UART with explicit `pinMode(INPUT)`, but `relayDisengage()` still only calls `RELAY.end()`.
|
||
|
||
With K1 released, the node `USART1_RX` = PA10 + Rdfu1 (22 k to 3V3) + MOD1.23 (F9P TX2) + K1 NC is connected to `DIN_4G`, the modem's RX. So during the whole 8-minute rest, PA10's ~40 k pull-up in parallel with Rdfu1 pushes up to ~0.2 mA into the unpowered modem through its RX ESD diode.
|
||
|
||
This is a weaker version of the PA2 path, but it points the same way. The state that you saw revive the modem was an MCU reset, and in that state PA10 has no pull-up and only Rdfu1 remains. 0.5.5 does not reproduce that state after a Modo B window.
|
||
|
||
**Fix (1 line, both boards): done in 0.5.6** (commit `8d203df`, `relayDisengage()`). The standalone patch file was superseded and moved to `_to_delete/`.
|
||
|
||
If `DIN_4G` still reads > 0.3 V at rest after this fix, the remaining source is Rdfu1 itself. The next step would then be to drive PA10 LOW about 500 ms after stack-off, releasing it before `PWR_CTRL` goes HIGH, or to fit Rdfu1 as DNP.
|
||
|
||
### 8.2 V4-only: the console USB powers the board rail
|
||
On V4, the Blackpill USB (the "USB de consola del HBOX" in the battery procedure) is VBUS wired straight onto `/SYS5V` (§4.1). This has three effects:
|
||
- **In a battery run, the laptop (~5.0 V) beats the boost (4.79 V).** The laptop carries the MCU at rest and part or all of the stack in the window. The rails, `vbat`/`vbatmin` and the pass/fail result then describe the laptop, not the battery.
|
||
- **With 24 V on, SD-15B current (~5.2 V) flows back into the laptop's port.**
|
||
- On a USB-A port the stack's burst can trip the port, and the console disconnects mid-run.
|
||
|
||
**Until reworked, every V4 run with 24 V or a battery uses a console cable with VBUS blocked.** For example, a USB-A→C cable with Kapton over pin 1 of the A plug, or a cable with the red wire cut. It enumerates fine because the core does not use VBUS sensing.
|
||
- **Check:** with no 24 V and no pack, plug it in. The Blackpill must stay dark.
|
||
- **Flashing (DFU):** use a normal cable, with 24 V off.
|
||
- **Permanent rework:** take the Blackpill's two 5V pins out of the sockets, and feed its 5V pin from SYS5V (e.g. K1 pin 2) through a Schottky (SS14). USB can then never reach SYS5V.
|
||
|
||
### 8.3 Before any V4 battery run (the board from `log1`)
|
||
1. **Pack ≥ 3.8 V, charged externally.** 0.5.5 still keeps `CHRG_EN` high. At 3.14 V every wake is skipped (< 3.40 V), and the pack is being over-discharged.
|
||
2. **With 24 V on, P2 must read 5.1–5.3 V.** `log1` showed 0.00 V at PA4.
|
||
3. **simpleRTK2B switches: `IOREF=3.3V` OFF and `5V=OUTPUT` OFF.**
|
||
- IOREF (MOD1.2) is fed from the board's always-on 3V3. With `IOREF=3.3V` ON, that 3V3 would be tied into the simpleRTK2B rail and would keep the F9P alive at rest: a strong back-feed.
|
||
- **Diagnostic:** every wake must start with the F9P boot banner `$GNTXT,…u-blox AG…` (it does in the 13:14 log).
|
||
4. **Do not press RESET during a battery run.** POR and PIN resets never start battery mode (unchanged in 0.5.5), so the unit goes silent until 5 V returns.
|
||
|
||
### 8.4 Rest-state readings: what they mean
|
||
Take these with the stack OFF during a battery rest, ≥ 30 s after `DUTY reposo`, black probe on GND:
|
||
|
||
| Point (V4 = V5 refs) | Expected | If not |
|
||
|---|---|---|
|
||
| 3V3_MODEM (J7.1 / C43) | < 0.3 V | find the source with the next three rows |
|
||
| SW_5V (MOD1.5 / C3) | < 0.3 V | U7 body diode is back-feeding from 3V3_MODEM, or USB on the simpleRTK2B |
|
||
| DIN_4G (J7.3) | < 0.3 V | PA10 pull-up + Rdfu1: apply the §8.1 patch, then consider the PA10 clamp |
|
||
| DOUT_4G (J7.2) | < 0.3 V | IOREF-side pull-up inside the simpleRTK2B. Rework: feed MOD1.2 (IOREF) from 3V3_MODEM instead of 3V3 |
|
||
|
||
**Text to add to the battery procedure/acta (Material / Configuración)**, for the owner of `hbox-docs` to paste:
|
||
> **Tarjeta V4:** el USB del Blackpill está unido al riel de 5 V de la tarjeta. Para cualquier corrida con 24 V o con batería usar el **cable de consola con VBUS bloqueado** (cinta Kapton en el pin 1 del conector USB-A). Comprobación: sin 24 V y sin batería, al conectar ese cable el Blackpill queda apagado. Con cable normal la laptop alimenta la etapa y la prueba no vale. Para flashear sí se usa cable normal, con 24 V apagado.
|
||
|
||
---
|
||
|
||
## 9. Addendum (26-Sep, 16:00): firmware 0.5.6 on V4 — what is still open
|
||
|
||
**Binary checked.** `release/hbox-tarjetaV4_0.5.6.bin` has SHA-256 `1e604edd…ff95`, the same as `out-v4`, built from commit `8d203df`. Its strings read `0.5.6-fm`, `EinarBoard v4 (HBOX v4)` and `MODEM_RST`.
|
||
|
||
**Firmware review: no further change is needed for V4.**
|
||
- PA9 and PA10 are released after Modo B (§8.1).
|
||
- The `MODEM_RST` pulse behaves as intended. It fires 3 s after every `STACK ON` and lasts 500 ms, and stack-off cancels or releases it.
|
||
- P7 is forced in every PCF8574 write, so LED updates cannot clobber the pulse.
|
||
- The boot gauge walk writes bit 7 = 1, so P7 is released after any reset.
|
||
- With no bodge fitted, the pulse drives a pin that is not connected, so it is harmless.
|
||
|
||
Everything still open is hardware or bench work.
|
||
|
||
### 9.1 The bodge: diode type matters
|
||
**Position.** U13 pin 12 (P7) is unconnected on both boards (checked).
|
||
- **V4:** U13.12 at (157.9, 90.7) → diode → SW4G1 pad 1 (`/MODEM_RST`) at (181.1, 99.7), ≈ 25 mm.
|
||
- **V5:** ≈ 21 mm.
|
||
|
||
**Diode.** Use **BAT54**, the same part as D5 on the board, or another *small-signal* Schottky (BAT43, BAT85, 1N5711).
|
||
- **Avoid 1N5819.** At rest P7 is high on its ~100 µA pull-up, so the diode is reverse-biased for the whole 8 minutes. Its leakage flows P7 → MODEM_RST → into the modem.
|
||
- A large-area power Schottky leaks tens to hundreds of µA when hot, capped only by that pull-up.
|
||
- That is the same order as the back-feed 0.5.5/0.5.6 just removed.
|
||
- **1N4148** has no leakage problem, but drops 0.5–0.65 V. Keep it only if the `M` check reads < 0.4 V.
|
||
- The published instructions list "BAT54 / 1N5819 (1N4148 sirve)". I suggest "BAT54 (o Schottky de señal); no 1N5819".
|
||
|
||
**Optional firmware refinement.** Hold P7 LOW for the whole stack-off period and release it 3 s after `STACK ON`, instead of the 500 ms pulse. The diode is then never reverse-biased at rest, and the modem's own reset pull-up helps bleed its rail toward 0 V. Not required.
|
||
|
||
### 9.2 simpleRTK2B switch `IOREF=3.3V` must be OFF (also `5V=OUTPUT` OFF)
|
||
MOD1.2 (IOREF) is wired to the board's **always-on 3V3**. Per ArduSimple, the `IOREF=3.3V` switch ties IOREF to the simpleRTK2B's *own* 3.3 V rail. So with that switch ON, the board's 3V3 powers the **F9P during the whole rest**:
|
||
- its TX2 idles high → K1 NC → `DIN_4G` → the modem rail;
|
||
- roughly **0.3–0.4 W** comes out of the pack for the entire rest.
|
||
|
||
This is the only path that can keep the simpleRTK2B alive while `SW_5V` sits at ~0.6 V, apart from a USB cable on the simpleRTK2B. That fits candidate (1) in the 0.5.6 CHANGELOG.
|
||
|
||
**Checks:**
|
||
- At rest, the simpleRTK2B **POWER** LED is off. Its **IOREF** LED stays on, which is normal.
|
||
- Every wake starts with `$GNTXT,…u-blox AG…` on the console, meaning the F9P really rebooted.
|
||
|
||
The reset pulse revives the modem regardless of this switch. But if the F9P stays alive at rest, the duty-cycle battery budget is gone. This switch check is not in any procedure or checklist yet; it belongs in module integration.
|
||
|
||
### 9.3 Still pending from §8
|
||
- **V4 console cable with VBUS blocked** (§8.2). The published battery procedure (fw 0.5.6) still says "USB del HBOX" with no V4 caveat.
|
||
- **The `log1` pack (3.14 V) must be charged externally.** 0.5.6 is still `-fm` with the charger off.
|
||
- **With 24 V on, P2 must read 5.1–5.3 V** (`log1` read 0.00 V).
|