Hardware Architecture

Hardware Architecture — Component Selection & Rationale

MCU: Nordic nRF54L15

Current choice: Seeed XIAO nRF54L15 (confirmed in customer repo)

Why this chip:

ARM Cortex-M33 @ 128 MHz, new platform (2024)
BLE 5.4 excellent for local unlocking
No built-in LTE/GNSS (separate modules preferred for this application)
1.5 MB Flash, 256 KB RAM sufficient for Zephyr + I2C/PWM/ADC workloads
Successor to nRF52 — better power characteristics

Previous version: ESP32 + Python (legacy, being phased out)

Connectivity Strategy: Modular Approach

Instead of integrated SoC (like nRF9160), Cloudlock uses modular stack:

nRF54L15 (BLE only, application logic)
    ↓ I2C/UART
Blues Notecard (cellular + GPS + network stack)
    ↓ connector
Blues Starnote (satellite backup)

Advantages:

BLE handles local unlocking (no network dependency)
Notecard handles all cellular/satellite complexity (managed service, global eSIM)
Starnote adds satellite without redesign
Decoupled from network provider decisions

Tradeoff: More modules (higher BOM), but better flexibility and fault isolation.

Battery: 11-Cell Custom Pack

Unusual configuration: 11 cells (Francisco confirmed). Likely 3 parallel branches with different cell counts to manage voltage distribution.

Challenges:

Team lacks deep BMS expertise
Need proper balancing, cell matching, undervoltage protection
Custom pack increases NRE and risk

Recommendation for v2: Consider commercial LiFePO4 pack with integrated BMS module (e.g., Tadiran, ULTRALIFE) to reduce engineering burden.

Lock Mechanism: Single Servo via Mechanical Linkage

Confirmed: One servo (PWM20 channel 0, pin P1.06)

Pulse positions:

Closed: 1000 µs
Open: 1450 µs
Off: 0 µs (PWM disabled)

Hold time: 7 seconds open, then auto-return to closed

Mechanical design: One servo drives both bolts via mechanical linkage (rod/cam/worm). Correct engineering — minimizes BOM and synchronization complexity.

Power Rails (Recommended Separation)

For reliable operation in presence of servo current spikes and RF activity:

Battery (3.7V LiPo or LiFePO4)
    │
    ├── [BMS/protection IC]
    │       │
    │       └── [LDO 3.3V, 100mA] ──→ MCU + Notecard VIO + GPS V_BCKP
    │                                  (clean rail)
    │
    ├── [BATTERY_VMODEM] ──→ Blues Notecard VMODEM_P
    │   (direct, 750mA+ capable)    (no extra regulation!)
    │
    └── [MOSFET switch] ── [Buck 5V] ──→ Servo motor
        (MCU GPIO)         (1.5A)       (controllable power)

Why separate:

Servo spikes don’t degrade MCU/GPS rail
Notecard VMODEM_P requires direct battery connection (datasheet requirement)
RF section stays isolated from power/motor noise

Power Sequencing (Startup Order)

From main.c:

1. k_sleep(10 SEC)          — stabilize voltages
2. pwm_servo_init()         — init PWM, set servo to closed
3. ble_init()               — start BLE advertising
4. bat_adc_init()           — battery voltage measurement
5. notecard_configure()     — send hub.set, card.voltage, note.template
6. k_sleep(15 SEC)          — let Notecard connect to network
7. ds3231_get_datetime()    — check RTC time
8. threads_start()          — launch 4 working threads
9. main loop: k_sleep(10 SEC) forever

This sequence avoids “power shoot” brownout by giving network attach enough time and ensuring capacitors are charged first.