20260911-1919-air-key-hub-sleep-and-key-scaling Apply the open key count, no-sleep receiver and Air-only sleep decisions

• status: completed
• createdAt: 2026-09-11 19:19
• approvedAt: 2026-09-11 19:40
• relatedTask: 20260911-1916-air-key-hub-sleep-and-key-scaling

Context

Current state of the three areas the decisions touch.

Key count. P06-key.md §2 fixes the lineup at Key 4 / Key 8 with 4 and 8 independent keys, KEY-02 requires independent per-key inputs with no ghosting, and P06-key-design.md §3 budgets five LED channels per key (RGB status + white and red legend), giving 20 and 40 channels served by one and two LP5024. KEY-05 caps both models at the same ≤60 mA@12 V full backlight. The recommended STM32G0B1CE is the 48-pin package under ST's part numbering, and the panel outlines are 77×77 mm and 77×150 mm. Nothing in X01 blocks more keys: the CMD originator field is u16 carrying the key index, with the node id in SRC.

Receiver sleep and naming. P05-air-hub.md §2 targets 深睡 ≤5 mA@12 V and GW-04 allows an explicitly configured deep sleep that stops receiving Air, with matching rows in the Air guide (GW-04, V-05, V-07), PRODUCT-PLAN P5, and X01 §9, which lets AIR-HUB enter sleep on a bus sleep signal. The family platform rule in PRODUCT-PLAN §1 states 休眠 ≤5 mA for modules generally.

Naming collision. P03-mate-hub.md already defines YBO Hub as the boat's central control unit — the Linux gateway and UI host on i.MX93, tier T0, MSRP $549 — and AIR-HUB is a node class code in X01 §2 and §4.9 as well as a nodes object in X02. Fifteen references in X02, thirteen in X01, nine in the Studio architecture and five in the Mate data model use the AIR-HUB token; roughly fifty documents mention the Gateway by name.

Key sleep. P06-key.md FR-10 / KEY-05 lets a Key sleep after 60 s of bus silence at ≤5 mA@12 V, woken by CAN or a local press, and X01 §9 lists the same entry rule. Decision 3 says only Air sleeps, which reaches this too.

Proposal

A. Key — open key count

Replace the fixed two-model lineup with a scalable platform whose key count is a configuration of one design, and state the ceilings the scale-up hits rather than assuming they hold:

• KEY-02 becomes "共用 MCU/驱动平台，按键位数可配置；独立键输入、无鬼键" with 4 / 8 as the first two build options and 32 as the platform target.
• KEY-05 changes from one absolute ceiling to a per-key budget — a base current plus a per-key increment, both measured at 12 V — because 32 keys at the design appendix's starting currents draw about 144 mA at the LED rail alone, well past today's ≤60 mA@12 V.
• P06-key-design.md §3 records what 32 keys requires: 160 LED channels, so seven LP5024 (or fewer larger drivers), and the I2C address budget of the chosen driver must be checked before the count is fixed.
• The 48-pin STM32G0B1CE cannot carry 32 independent wake-capable key GPIOs alongside I2C, FDCAN, USB and SWD; the appendix records the larger-pin-count option and the alternative of a scan or expander topology, noting that any expander must still satisfy KEY-02 no-ghosting and per-key wake.
• Mechanical: a single 32-key panel does not follow from the 77 mm width; the appendix states that the panel family, not one outline, carries the count, and the mounting and sealing work is per outline.

Each of these lands in KEY-O-03 (driver and MCU), KEY-O-05 (outlines and optics) and KEY-O-07 (power and thermal limits) rather than being closed here.

B. Receiver — never sleeps

• Delete the 深睡 ≤5 mA@12 V target row and rewrite GW-04 (and the Air guide's GW-04, V-05 and V-07 wording) to require permanent Air reception whenever the unit is powered; the only defined states become normal listening and control operation.
• Remove the AIR-HUB entry from X01 §9's sleep-entry rule, leaving Key and Core untouched by this edit (see D).
• Update PRODUCT-PLAN P5's Gateway target row and the corresponding open question.

C. Air — sleeps, stays present through intermittent communication

• State in P05-air-switch.md §3/§4 and the Air guide §5.2 that Air is the only sleeping device and maintains presence through scheduled intermittent contact rather than a maintained connection, which is what the always-on receiver makes possible.
• Resolve AIR-O-01's battery-versus-latency comparison accordingly: connect-on-press plus scheduled presence contact becomes the baseline, and a maintained low-duty connection becomes the alternative that must justify its current draw, instead of the two being equal options.
• AIR-05's 30-minute health report becomes the presence mechanism explicitly, with the interval a configurable target rather than a fixed constant.

D. Key sleep

Decision 3 says only Air sleeps, which removes P06-key.md FR-10 and the Key half of X01 §9's sleep entry. Proposed: Key no longer defines a sleep mode, but keeps ≤5 mA@12 V as a quiescent-current ceiling so the bus-load and supply budgets do not change. Core and Sense sleep behaviour is out of this task's scope and stays as PRODUCT-PLAN §1 has it.

E. Naming — resolved as Air Hub, separate from P03

Taken from the user's wording "air hub". The device stays separate from the P03 Hub; only the name changes. air-hub/ becomes air-hub/, P05-air-hub*.md becomes P05-air-hub*.md, and the AIR-HUB node class keeps its numeric value with only the token changing, across X01, X02, Studio, Mate, Tag and the research catalogue. P03's fail-safe doctrine is untouched.

Open point to confirm: with the F architecture below the Air Hub becomes a second Linux device on the boat, overlapping P03 (Linux, Wi-Fi, BLE, CAN). That is a duplicate OS update chain and a second CRA scope, which is the argument for folding the radio into P03 instead. Recorded, not decided.

F. Air Hub — Linux ARMv7 + dual ESP32-C6 as a compared option

Written as a dedicated evaluation document beside the specification, mirroring the ESP32-H2 precedent, so the current STM32G0B1CE + nRF54L15 recommendation stays in force until a gate decides otherwise. It must record:

• SoC facts. From the SSD202D preliminary product brief v0.1, 2020-03-04: ARM Cortex-A7 dual core up to 1.2 GHz with 32 KB L1 I/D, 256 KB L2, Neon, FPU and an MMU for Linux; one embedded DDR3 over a 16-bit interface; two USB 2.0 hosts; two Ethernet ports at 10/100 with one built-in PHY and one RMII; SPI NOR/NAND flash interface; SDIO 2.0; AES/DES/3DES/RSA/SHA-1/SHA-256 with secure boot; RTC with a sub-3 µA mode; H.264/H.265 decode, JPEG encode, 2D graphics and TTL/MIPI DSI display output; peripherals are GPIO, four PWM, three generic UART plus one fast UART with flow control, three timers and a watchdog, one SPI master, two I2C masters, one IR input and a three-channel SAR ADC; core 0.9 V, I/O 1.8–3.3 V, DRAM 1.8 V, power consumption stated as TBD; operating temperature −20 to 85 °C; 128-pin QFN 12.3 × 12.3 mm.
• No CAN controller. CAN appears nowhere in the brief's peripheral list. With both C6 assigned to radios, nothing in the stack provides CAN, so an external controller is required regardless of whether the bus is FD. Choosing an FD-capable part (MCP2518FD class) therefore costs the same as a Classical-CAN part and leaves X01 untouched; the alternative that does save the chip is giving CAN to one C6's TWAI, which forces the whole bus to Classical — see F2.
• One SPI master. The single SPI master has to serve the external CAN controller, leaving the two C6 host links on UARTs. Three generic plus one fast UART exist, but the framed inter-processor protocol already specified for the radio MCU has to fit that budget and its throughput; the boot flash uses the separate NOR/NAND interface. Record the allocation explicitly at D0.
• Temperature. −20 to 85 °C meets the Air Hub's own −20…+60 °C target but not the family platform rule of −25…+70 °C in PRODUCT-PLAN §1, which is a documented gap rather than a blocker for this product.
• Document status. The only obtainable document is a 2020 preliminary product brief marked "Security Level: Confidential B", retrieved from a community mirror rather than a vendor download page, and it lists power consumption as TBD. For a product that has to carry a compliance file and a long support window, the availability of vendor documentation, errata and lifecycle commitments is itself a risk to close at D0.
• Fit. The video decode, JPEG encode, 2D graphics and MIPI DSI blocks are unused in a headless receiver; what the part buys is integration — embedded DDR3 and a built-in Ethernet PHY in a 128-pin QFN — which is a real BOM and layout advantage. If the Air Hub is to carry a display, the video blocks stop being waste; that is worth settling before the comparison is scored.
• Standing power. Because the Air Hub no longer sleeps (decision B), a Linux SoC plus two radios runs permanently. The current listening target of ≤15 mA@12 V, about 180 mW, cannot survive that; an SSD202D-class platform with DDR, Ethernet and two C6 is of the order of 1.5–2.5 W, roughly 125–210 mA at 12 V. The target becomes a different number and belongs in the boat's quiescent budget.
• Role split. What each C6 does (Air BLE link versus Wi-Fi/802.15.4/Matter), the inter-processor interface, and which processor holds the binding and authorization decision, which today sits in the wired MCU.
• Doctrine. Local Air control currently must survive without Linux. An architecture where Linux is in the control path needs the same statement the P03 Hub carries, or the control path must terminate in a non-Linux processor.
• Cost of the platform. Two OS update chains, secure boot on ARMv7, CRA scope, boot time against the 5 s startup target, and the permanent listening current now that the unit never sleeps.

F2. Dropping CAN FD is a bus-wide decision

Classical-CAN controllers raise error frames when CAN FD frames appear on the same wire, so a bus segment is either FD or it is not; the Air Hub cannot be Classical while Core, Sense, Key, Hub and View stay FD. X01 §1 currently fixes "CAN FD 帧，29 位扩展标识符，载荷最大 64 字节" with 500 kbit/s arbitration, 2 Mbit/s data and BRS set on every YBO frame.

Five of the six message families exceed the Classical CAN eight-byte limit as defined today: CMD is 16 bytes including the CMAC auth tag at 12–15, STATE is 12, ALARM is 16, AUDIT is 32, and TELEM carries one to ten records after a three-byte header. Only ACK fits unchanged. Converting the bus therefore means redesigning or segmenting five message families, re-placing the authentication tag, recomputing the §6 bus-load budget (modelled today on 64-byte frames at 450 µs across 46 nodes), reworking the OTA block and retransmit scheme for eight-byte payloads, and rewriting the CT-01 conformance case, across every product in the family.

Three ways to satisfy the direction:

1. Keep the bus on CAN FD; give the Air Hub an external CAN FD controller. One SPI part on the SoC's single SPI master, no protocol change, no impact on other products. Recommended.
2. Convert the whole bus to Classical CAN and give CAN to one C6's TWAI. The only variant that saves the external chip, and the only one that delivers the stated direction literally. It costs the redesign above across six products, a slower OTA path, and a C6 that serves both a radio and the bus.
3. Put the Air Hub on its own Classical segment behind a bridge. Extra hardware plus a translation layer; carries the drawbacks of both.

G. Air — ESP32-C6 (superseded: the user moved Air to ESP32-H2, see H)

This conflicts with the battery requirements that are currently in force. The numbers, from the ESP32-C6-MINI-1/1U datasheet:

项目	数据手册值
供电	3.0 V min / 3.3 V typ / 3.6 V max
外部电源峰值能力	≥0.5 A
BLE 发射	0 dBm 131 mA；−16 dBm 94 mA；19 dBm 309 mA
BLE 接收	73 mA
Modem-sleep / Light-sleep / Deep-sleep	14–25 mA / 180 µA / 7 µA
其他	无 NFC；TWAI 为 Classical CAN；22 GPIO；−40…105 °C（H4/H8 档）

Against AIR-02's 3-year budget of 15.22 µA, i.e. 365 µAh/day: deep sleep alone is 168 µAh/day, 46 % of it. Adding the §5 duty cycle at an optimistic 100 ms of radio per interaction and 50 ms per health report, averaged at about 90 mA, gives roughly 75 and 60 µAh/day, so about 303 µAh/day or 83 % of the budget before the boost converter's quiescent current, LED, retries, upgrades and CPU-active time. Those radio-on times are my order-of-magnitude estimates, not measurements, but the direction is not in doubt. Separately, CR2450 sits below the 3.0 V floor for most of its discharge so a boost stage is mandatory, and 0.5 A cannot come from the cell — holding a 10 ms receive window at 73 mA within a 0.2 V droop needs roughly 3650 µF, against the 1250 µF the H2 evaluation computed under the same method.

So one of the following has to give, and the choice is yours:

1. Keep CR2450 and the 3-year target — then C6 cannot be the battery-Air platform; make it the recommendation for a powered or larger-cell Air variant and leave nRF54L15 as the battery-Air baseline.
2. Change the cell — a larger primary or rechargeable pack, which moves the 60×60 mm / ≤12 mm outline, the user-replaceable requirement and the EU battery-regulation position.
3. Change the maintenance target — state months rather than three years, and drop AIR-02 to match.
4. Make Air wired — the battery blockers disappear and C6 is a reasonable choice.

Recommendation: option 1, which also keeps the ESP32 family where its Wi-Fi/802.15.4/Matter value actually lands, which is the Air Hub. Whichever you pick, AIR-01, AIR-02, AIR-06, the §5 budget and AIR-O-01/AIR-O-05/AIR-O-07 all change together, and the ESP32-H2 evaluation's conclusion table needs revisiting since it rejected a lower-power sibling on the same grounds.

H. Air on ESP32-H2 — the cell, not the chip, is the binding constraint

The user chose ESP32-H2 over C6 for Air and asked what else could power it. H2's figures are already recorded in P05-air-switch-esp32h2-evaluation.md §2: 3.0 V minimum supply, 0.35 A peak supply capability, deep sleep 7 µA, BLE receive 25 mA, BLE transmit 55 mA at 7 dBm. Against CR2450 those produced three blockers — supply window, pulse current, average budget.

Estimated H2 consumption under the §5 duty cycle, as an order-of-magnitude figure and not a measurement: deep sleep alone is 61 mAh/year; 30 interactions/day at roughly 100 ms of radio averaging about 35 mA is roughly 11 mAh/year; 48 health reports/day at roughly 50 ms is roughly 9 mAh/year; a converter's 1–3 µA quiescent draw adds 9–26 mAh/year. Total on the order of 90–105 mAh/year. On the CR2450's 400 mAh budget that is about four years at best, with the pulse problem unsolved. On a cell of roughly 1200 mAh it is eight years or more, and the three-year target stops being the constraint.

Candidate cells, with the Energizer datasheets for the two lithium cylindrical options (L91 AA, L92 AAA):

方案	电气	与 H2 的匹配	外形代价
2× AAA Li-FeS2（L92）串联	1.5 V/节，Li/FeS2，IEC FR03；典型内阻 140–180 mΩ；最大 1.5 A 连续 / 2.0 A 脉冲；−40…60 °C；25 年货架寿命；容量以曲线给出，低放电率约 1200 mAh 量级	0.35 A 脉冲下内阻压降约 0.1 V，无需大储能电容；新电池 2×1.8 V 已达模组 3.6 V 上限，寿命末期 1.8 V，需 buck-boost 覆盖全程	AAA 直径 10.5 mm，含壳约 13–14 mm，超出 ≤12 mm 目标
3× AAA 串联	同上，4.5 V 标称	全程降压即可，效率优于升压	同上厚度；宽度约 31.5 mm，60×60 mm 内可容
2× CR2450 并联	每节约 620 mAh（已引用的 Energizer 数据），并联约 1240 mAh，内阻减半	仍低于 3.0 V 下限须升压；0.35 A 仍需约 1250 µF 储能电容，其漏电计入预算	保持 ≤12 mm
单节 CR2477	容量高于 CR2450，同为 3 V 化学体系	同上，问题不变只是能量更多	保持 ≤12 mm；须补该型号官方数据手册
2× AA Li-FeS2（L91）串联	典型内阻 120–240 mΩ；最大 2.5 A 连续 / 4.0 A 脉冲；−40…60 °C；容量低放电率约 3000 mAh 量级	电气裕量最大，脉冲完全不成问题	AA 直径 14.5 mm，含壳约 16 mm，明显超出目标
Li-SOCl2 ER14250 + HLC	3.6 V 标称、容量高、货架寿命长	开路电压高于模组 3.6 V 上限须降压；脉冲靠 HLC	非消费级可更换形式，与"用户可换"定位冲突

Recommendation: the AAA lithium pack, two cells with a buck-boost or three with a buck, and the thickness target moved from ≤12 mm to about 13–14 mm. It is the only group that solves the supply window and the pulse requirement together while keeping a user-replaceable consumer cell and covering −20…+60 °C. If ≤12 mm is non-negotiable, the coin-cell rows are the only choice and the storage-capacitor and boost-quiescent costs stay.

Riders on adopting H2, which must move together:

• AIR-01 loses "1×可更换 CR2450，一次电池，不充电" and the §2 form-factor row changes; AIR-02's 400 mAh budget and the §5.1 table are recomputed for the chosen cell, and AIR-06's outline follows.
• H2 has no NFC, so SEC-01's NFC OOB path is unavailable; the three candidate routes in the H2 evaluation §5 must be decided under AIR-O-02.
• The Air guide §4 recommendation row changes from nRF54L15 to ESP32-H2, with nRF54L15 moving to the alternate column, and the H2 evaluation's own conclusion table flips from "不推荐" to conditional once the cell changes — that document is owned by another session and must be coordinated.
• Battery transport, labelling and the EU battery-regulation position in AIR-O-06 are re-derived for a lithium cylindrical cell rather than a coin cell.

(superseded) Naming — the earlier blocking question

"Hub" is already taken by P03, the central control unit. Two readings, with materially different work:

1. Fold the Air radio into the existing P03 Hub. One fewer product, matching the lean-lineup direction. But the current fail-safe doctrine says Hub loss must not change any channel state and that configured Air control does not depend on Hub; if Hub becomes the Air receiver, Air control depends on it by construction. That doctrine, the Hub BOM, its tier and its compliance row would all have to change.
2. Keep it a separate device and rename it. No doctrine change, but "Air Hub" next to "Hub" invites confusion, and the AIR-HUB node class in X01/X02 plus roughly fifty documents carry the old name.

Recommendation: option 2 with a name that does not collide — for example Air Link or Air Base — unless you do intend the radio to live inside the P03 Hub. A rename is mechanical once chosen; the node class code can keep its numeric value with only the token changing.

Risks

• The per-key power budget replaces a number suppliers may already have quoted against; the change must be flagged in the guide's change record so responses are re-based.
• Removing the receiver's sleep state raises the boat's quiescent draw. The listening target is ≤15 mA@12 V, which now applies permanently; that belongs in the supply budget rather than being presented as a saving.
• Dropping Key sleep interacts with X01 §9 and the PRODUCT-PLAN §1 family rule. Limiting the edit to Key and the Air receiver keeps Core and Sense out of scope, but the family rule sentence will read as if it still covers them, so it needs a qualifier.
• A rename touching the AIR-HUB node class crosses into X01/X02, Studio, Mate and Tag. It is mechanical but wide, and a separate session is currently active in this repository.

Scope

Decisions A, B, C and D: about twelve files — the Key specification and design appendix, both supplier guides, the Air specification, the receiver specification and design appendix, X01, X02, PRODUCT-PLAN, OPEN-QUESTIONS, plus changelog and indexes. Decision E adds a repository-wide token rename across roughly fifty files if option 2 is chosen, or a rewrite of the Hub specification, its compliance row and the fail-safe doctrine if option 1 is chosen.

Alternatives

• Keep Key 4 / Key 8 as the only models and treat 32 keys as four panels on the bus. Cheaper and needs no MCU or driver change, but it does not deliver "开放式的不固定多少key" on one panel; worth confirming which the user means.
• Keep a receiver sleep state but forbid entering it while any Air is paired. Rejected: it keeps a mode that decision 2 removes outright and that the documents already spend paragraphs warning about.

Annotations

• 2026-09-11: Implemented. The user chose Classical CAN bus-wide with CAN provided through a C6, relaxed the Air thickness target, named the receiver Air Hub, moved Air to ESP32-H2, and asked for every current option to be written out. Three decisions received; A, B, C and D drafted. Naming answered as "air hub" (E). Two architecture directions added: Linux ARMv7 + dual ESP32-C6 as a compared Air Hub option (F), and ESP32-C6 as the Air first-version recommendation (G). G conflicts with the CR2450 three-year battery requirement and needs a choice before implementation.