Firmware has two layers. The functions we've shared so far (below) are the App Layer. What we most want to align on is the layer beneath it — the Device Control Layer (the embedded software that drives each chip) — and how much of it UB BOX can develop.
Firmware · App LayerUB BOX · shown
Chargeable/Dischargeable Power Calc
Data Cleaning
Control Priority
Safety Alarm
Safety Strategy Exec
Smart Strategy Exec
Firmware · Device Control Layer★ the core question
The layer of embedded software that drives each communication / security chip. Because the implementation changes with the chip chosen, maker selection and a feasibility judgment must be made carefully.
likely OKWi-Fi / BLEMurata Type 1YNGeneric Wi-Fi5 + BLE5.0 combo module (SoC: SDIO / UART4). Standardised worldwide, so we understand this is not an issue.
keyWi-SUNROHM BP35C0-J11-T01Not generic — the driver is chip-specific. Our current choice is ROHM BP35C0-J11-T01 (driver = ROHM J11 protocol over UART2; 2nd source: Lapis ML7396C). We'd like to confirm whether UB BOX can implement this driver — or propose an alternative chip if preferable.
confirmLTEQuectel EG915Q-JPSelected chip: Quectel EG915Q-JP (Cat 1 bis, SoC: USB2.0 / AT; Giteki / JATE / TELEC done). Mainstream in Japan, though Europe tends to be wired-based. Can UB BOX obtain this module and implement its driver (USB / AT / PPP)?
securitySecurity SEInfineon OPTIGA Trust M V3Secure element driver (SoC: I2C 0x30, ECC256; 2nd source: NXP SE050).
Full firmware stack (from the HW spec): U-Boot (secure boot) → Linux 5.10/6.1 LTS (Yocto) → drivers for each chip → app layer (ECHONET Lite / Wi-SUN stacks). We'd like to align on how much of this whole stack — boot, kernel and drivers included — UB BOX can take on.
▶ We'd like to align on how much of this hardware-side Device Control Layer UB BOX can take on.