跳转到内容

20260928-2344-air-hub-first-build-rk3506j-cc1354p10 Lock the first Air Hub build on RK3506J with a CC1354P10 radio

  • status: rejected
  • createdAt: 2026-09-28 23:44
  • approvedAt: (pending)
  • relatedTask: 20260928-2344-air-hub-first-build-rk3506j-cc1354p10

Air Hub spec R0.8 defines three axes (platform H1–H14, CAN source, function radio R0–R8 / L1–L7) and 30 named combinations; no combination is chosen (AIR-O-03, AIR-O-11 open). The ESP32-C6 on the shared board is a Wi-Fi station uplink with BLE and 802.15.4 disabled, except in R0 and the C6-CAN combinations. CC1354P10 appears only in the Air design appendix §2.3 (BLE + sub-GHz overlay for Air) and in the wireless SoC catalogue; it is not on the Air Hub R axis.

The owner now wants to lock the first Air Hub: RK3506J, an ESP32-C6 as the configuration channel, and CC1354P10 as the extra radio, chosen over EFR32FG28 on 2.4 GHz grounds.

Datasheet findings (TI SWRS267B, Dec 2023; Silicon Labs EFR32FG28 Rev 1.1 via the LCSC mirror, the Silicon Labs site refused the download):

2.4 GHz item CC1354P10 EFR32FG28
Protocols BLE 5.3, Zigbee, Thread, Matter BLE only
BLE PHYs 1M, 2M, Coded 125k / 500k 1M, 2M; no Coded PHY
BLE 1M / 2M sensitivity −97 / −92 dBm −95.6 / −92.7 dBm
Coded 125k / 500k −104 / −100 dBm —
802.15.4 sensitivity −105 dBm —
Max TX +5 dBm standard PA; +20 dBm when the high-power PA output is matched to 2.4 GHz (101 mA) +10 dBm PA, 11.4 dBm typical (23.2 mA)
RX current 6.9 mA 5.2 mA
Temperature −40…+105 °C −40…+125 °C
Package VQFN48 7×7, VQFN64 8×8 QFN48 6×6, QFN68 8×8
LCSC RGZ $9.97 (stock 1), RSK $13.83 @100 B312 QFN68 $9.75 @100; B322 not listed

Constraints found:

  • CC1354P10 has one +20 dBm output (TX_20DBM_P/N), shared by sub-GHz and 2.4 GHz; board matching decides which band gets it. LP-EM-CC1354P10-6 puts it on 2.4 GHz (sub-GHz then uses the +14 dBm PA, up to +13 dBm at 433 MHz); LP-EM-CC1354P10-1 puts it on 868/915 MHz (2.4 GHz then +5 dBm).
  • Both chips have one transceiver; the two bands are time-shared (TI DMM), never received at the same time.
  • Zigbee host path on CC1354P10 (Z-Stack in the SimpleLink LOWPOWER F2 SDK), the BLE HCI path to BlueZ, and 32-pairing capacity are not yet proven.

Revised after the owner's decisions of 2026-09-28 (see Annotations).

Spec P05-air-hub.md (R0.9):

  1. §2.2 R axis: add R9 CC1354P10, high-power PA matched to 2.4 GHz, plus a populated 433.92 MHz receive path. Four signed firmware images, switched the same way as BLE / Zigbee / Thread (GW-07): BLE, Zigbee, Thread, and 433 OOK receive. One image is active at a time; GW-04 applies to the radio of the active image, as for R1–R8.
  2. §2.2 H12 row: first build uses a stamp-hole core board. Primary: Vanxoak (万象奥科) HD-RK3506J-256F256LI (RK3506J, 256 MB DDR3L, 256 MB SPI NAND, −40…+85 °C, 35×35 mm, 128 pins at 1 mm, single 5 V input with on-board regulators, on-board RJGT102 crypto chip; HD-RK3506J-512F8GLI for 512 MB + 8 GB eMMC; "-CN" domestic-BOM variants). Its RK3506G / B / J boards are pin-compatible. Alternates: Forlinx FET3506J-S (44×35 mm, 146 pins, 88 CNY, temperature not published) and MYiR MYC-YR3506J (37×39 mm, 140 pins, −40…+85 °C, $28). FET3506J-C (board-to-board) is not used for the first build. Vanxoak price not published.
  3. §2.3: add AH-19 = H12 stamp-hole core board (HD-RK3506J-256F256LI) + native CAN + R9, marked first-build combination; add AH-20 = H1 SSD202D + ESP32-C6 CAN + R9 as the named SoC fallback on the same radio. AH-19's board keeps the ESP32-C6 TWAI routed to the CAN transceiver as a population option so that the SSD202D fallback does not need a new CAN design; in AH-19 the C6 TWAI is not enabled and native CAN is the only controller.
  4. §1, §2.1, §2.4, §5: the ESP32-C6 in AH-19 / AH-20 is the configuration channel over both Wi-Fi and BLE (phone setup, diagnostics, updates) and keeps the Wi-Fi uplink; its BLE is not Air's radio. The Air Hub model gains 433 OOK receive when fitted with R9.
  5. §3: new requirement GW-13 for the C6 configuration channel: mutual authentication and encryption per device, no plaintext fallback, configuration commands carried to Linux and checked under maintenance permission, no path from the configuration channel to CAN frames or to Air control; GW-09 applies to the R9 433 OOK image as it does to Air Hub LR.
  6. §4, §6, §7: 433 OOK source for Air Hub with R9; compliance adds 433.92 MHz receive and the extra C6 BLE transmitter in the combined assessment.
  7. §8: AIR-O-03 and AIR-O-11 record the first-build selection (AH-19, stamp-hole core board, R9) and what stays open (FET3506J-S temperature and memory configuration in writing, Z-Stack host on CC1354P10, BLE HCI to BlueZ and GW-02 capacity, coexistence of CC1354P10 BLE, C6 Wi-Fi and C6 BLE); AIR-O-13 also covers AH-19.
  8. §9 change-log row.

Design appendix P05-air-hub-design.md (R0.7): §2.2 implementation table names the stamp-hole boards; §2.5 radio and Wi-Fi rows; §3 diagram and responsibility table (CC1354P10 images, C6 configuration channel, C6 TWAI population option); §5 interface note (FET3506J-S eMMC version has no SDIO, C6 then on SPI); §6 antennas (2.4 GHz internal, 433 MHz SMA); §7 image switching includes the 433 image; change-log row.

Evaluation evaluations/platform-combinations.md: §4 FET3506J-S row filled in; §7 R9 row and a new §7.2 CC1354P10 versus EFR32FG28 comparison; §8 BOM rows for AH-19 and AH-20; §9 risks.

Also: archive cc1354p10.pdf and efr32fg28.pdf in refs/datasheets/air-hub/ with manifest and checksum lines; docs/changelog.md entry; task and plan status.

  • Zigbee on CC1354P10 is less proven for Linux hosts than EFR32MG21 EZSP; the Rust host would implement ZNP/MT against Z-Stack. Mitigation: keep it an open item, verify on LP-EM-CC1354P10-6.
  • C1 puts two BLE radios in one enclosure (C6 BLE + CC1354P10 BLE) on top of Wi-Fi; coexistence test scope grows.
  • Only one LCSC price point with low stock; volume price unknown.

About 6 documentation files plus two archived PDFs: spec, design appendix, platform-combinations evaluation, datasheet manifest/checksums, changelog, task/plan indexes. No code.

  • EFR32MG21 (R1) as the dedicated 2.4 GHz radio: more mature Zigbee host, +20 dBm, no sub-GHz path at all.
  • EFR32FG28: rejected on 2.4 GHz grounds (BLE only, no Coded PHY, +10 dBm).
  • 2026-09-28: owner chose CC1354P10 over EFR32FG28 ("可以,按CC1354P10来选型").
  • 2026-09-28: decision B — sub-GHz enabled in the first build, switched in software like BLE / Zigbee ("首版启用,通过软件切换,可以考虑软件切换和ble zigbee切换一样").
  • 2026-09-28: decision C — C6 Wi-Fi and BLE are both configuration channels; C6 CAN is kept because the SoC may change to SSD202D ("c6的wifi和ble都是配置通道,can也保留,因为我们考虑可能更换mcu为ssd202d").
  • 2026-09-28: decision D — core board, stamp-hole ("d1,核心板邮票孔"). FET3506J-C is board-to-board, so the first build uses FET3506J-S (stamp hole) with MYC-YR3506J as second source.
  • 2026-09-28: owner supplied https://www.vanxoak.com/core-board/rk3506-stamphole.html; taken as the primary stamp-hole core board, FET3506J-S and MYC-YR3506J become alternates.
  • 2026-09-29: rejected. The owner set a retail target of 50-60 USD, which no RK3506J build meets, and dropped CC1354P10 ("放弃CC1354P10方案"). Superseded by 20260929-0011-air-hub-two-tier-ssd202d.