fix(m5stack_unit_c6l): add USB CDC flags to repeater and room_server envs - #3156
Closed
jirogit wants to merge 74 commits into
Closed
fix(m5stack_unit_c6l): add USB CDC flags to repeater and room_server envs#3156jirogit wants to merge 74 commits into
jirogit wants to merge 74 commits into
Conversation
Add getCodingRate() and getFreqMHz() virtual methods to RadioLibWrapper base class, enabling subclasses to report their operating frequency. isJapanMode() detects JP 920MHz band (CH25-27) for ARIB STD-T108 compliance. getMaxTextLen() and getMaxGroupTextLen() enforce 4-second airtime limits per SF12/BW125 measurements.
In JP 920MHz band (CH25-27): 5ms continuous RSSI sensing at -80dBm absolute threshold, exponential backoff (2000-16000ms) on busy, jitter (0-500ms) on free, then falls through to CAD if enabled. Non-JP path: existing relative-RSSI threshold + CAD unchanged. Add YIELD_TASK() macro and _busy_count field for backoff tracking.
Add isJapanMode() virtual to mesh::Radio (default false) so Dispatcher can query frequency context without depending on RadioLibWrapper. Dispatcher::getCADFailMaxDuration() returns UINT32_MAX for JP nodes, eliminating the 4-second forced-TX that would violate ARIB STD-T108. Non-JP nodes retain the original 4-second safety timeout unchanged.
getCodingRate() returns codingRate+4 (RadioLib stores 1-4 internally, expose as CR4/5-8 matching the rest of the codebase). CustomLR1110Wrapper overrides both getCodingRate() and getFreqMHz() so isJapanMode() and getMaxTextLen() work correctly on T1000-E.
Enables isJapanMode() and getMaxTextLen() to work on SX1262-based targets (WisMesh Tag, T-Echo Lite, T114, XIAO nRF52, etc.). codingRate accessed as SX1262 base class member +4 (same pattern as LR1110).
Add getMaxTextLen() and getMaxGroupTextLen() virtual to mesh::Radio (default 160 bytes). BaseChatMesh uses these instead of the hardcoded MAX_TEXT_LEN macro for limit checks in composeMsgPacket(), sendCommandData(), and sendGroupMessage(). Stack buffers remain sized to MAX_TEXT_LEN as a safe upper bound.
docs: リピーター/ルームサーバー初期設定ガイドをREADME_JP.mdに復元
Adds comparison table for 実験試験局 (5-year experimental station license) vs 特例制度 (180-day notification-based exemption), notes that 920MHz is not covered by the simplified 特定実験試験局 gazette frequencies, and clarifies no MeshCore devices currently hold 技適 certification (some Meshtastic devices do).
docs: add experimental station / notification system license guide
Community feedback (だてさま) confirmed 特例制度's technical conformity condition includes conformance to ARIB-designated standards (令和元年 総務省告示第263号 五号3), which explicitly lists ARIB STD-T108. Since this firmware targets ARIB STD-T108 compliance, this is a more direct path than foreign certification or radio engineer confirmation. Also flags a concern with 実験試験局: 電波法施行規則第6条 restricts use to the license holder only, which fits poorly with mesh networking's arbitrary-peer communication model. Removed the radio spec table — it duplicated the existing '日本向け無線設定' section below, which already covers frequency/power/etc in more detail.
Wio-SX1262 module (Seeed Technology, 201-250230) holds standalone technical conformity certification (技適) in Japan with a certified output of 10dBm, independent of host firmware. Seeed confirmed in writing (2026-07-20) that custom/third-party host firmware and RadioLib usage do not affect the certification, provided hardware, antenna, and RF parameters stay within the certified scope. Devices affected (10dBm, was 13dBm): - XIAO nRF52840 + Wio-SX1262 - XIAO ESP32S3 + Wio-SX1262 - Wio Tracker L1 Pro All other JP devices remain at 13dBm (ARIB STD-T108 limit). Build verified: WioTrackerL1_companion_radio_ble compiles with LORA_TX_POWER=10.
Seeed confirmed in writing (2026-07-20) that Wio-SX1262's standalone technical conformity certification (201-250230) remains valid under custom host firmware, provided hardware/antenna/RF parameters stay within the certified scope. Certified output is 10dBm. Updates both TX power reference tables to reflect the 10dBm limit for Wio-SX1262 devices (XIAO nRF52840/ESP32S3+Wio-SX1262, Wio Tracker L1 Pro), matching the jp-release.yml change in #4.
feat: limit TX power to 10dBm for Wio-SX1262 devices
The T1000-E vs Wio-SX1262 comparison implied Seeed was asked about both devices under the same terms. Only Wio-SX1262 was formally inquired about; T1000-E's certification scope is inferred from the technical conformity database listing, not a direct Seeed response.
docs: remove T1000-E comparison in Wio-SX1262 README section
…-guide # Conflicts: # README_JP.md
docs: simplify license guide, add ARIB STD-T108 path for tokurei
The blanket statement contradicted the Wio-SX1262 certification section added earlier. Now scopes the statement to non-Wio-SX1262 devices.
Add QUICKSTART_JP.md: 対応4機種の最短導入ガイド
Fix typo in QUICKSTART_JP.md
…(SF10/CR6 migration)
- 送信文字数セクション: CR依存表を削除、本家準拠(160B)に統一 - リピーター初期設定: CR4/8前提のUSB推奨理由・CR4/5推奨を整理 - 無線設定表: SF12→10, CR4/8→4/6 - set txpower 10 手順削除（意図的） - CR4/7案内の廃止に伴う注記削除
SF10/CR4:6移行 (jp-v1.8.0, breaking change)
- SX126X_DIO3_TCXO_VOLTAGE 1.8 -> 3.0 - I2C pins (PIN_BOARD_SDA/SCL) 16/17 -> 10/8 - Add PI4IO OUT_H_IM register write to release Hi-Z on the LoRa control pins (P5/P6/P7), which upstream left unset - Remove P_LORA_TX_LED=15 (ESP32-C6 strapping pin conflict) The TCXO voltage, I2C pins, and PI4IO initialization sequence are adapted from TheRealHaoLiu/MeshCore (main-m5stack-unit-c6l branch), a working M5Burner distribution for this board. Upstream's PI4IO handling in particular never releases the Hi-Z state on these pins, so writes to OUT_SET had no effect on the physical pins. This combination of changes resolves a repeatable crash where the USB serial port cycled connect/disconnect continuously on boot. Fixes present/absent USB port cycling reported in meshcore-dev#2229.
C6L's present/absent USB crash loop (upstream meshcore-dev#2229) is fixed and hardware-verified as of the PI4IO/TCXO/I2C fix merged in dev. Move it out of the "CI build only, unverified" group in the release notes template; Wio Tracker L1 Pro and T-DECK remain unverified.
Board manifest for esp32-c6-devkitm-1 defaults build.flash_mode to qio, which this module's flash chip does not support -- causes a boot crash-loop (repeated USB-Serial-JTAG reconnects) on real hardware. Override with board_build.flash_mode = dio in the common M5Stack_Unit_C6L section so it applies to all envs (ble/usb/repeater/room_server).
Root cause was flash_mode=QIO (unsupported by this module's flash chip), not the PI4IO/TCXO/TX_LED items from the earlier fix -- update the release note to reflect the actual fix (flash_mode header changed to DIO).
…dalone feat(c6l): add companion_radio_wifi env
Same change as meshcore-dev#3103, applied directly to jirogit/dev for jp-release inclusion. base_ms: 2000 -> 500 ms max_backoff: 16000 -> 4000 ms Provisional values; to be refined with traffic statistics from deployed nodes.
- jp-release.yml: generate_release_notes: true (auto-lists merged PRs since last tag) - PENDING_NOTES_JP.md: manual log for direct pushes to dev (not covered by PR-based auto notes)
jp-release: restrict Off-Grid Repeat to 921.2MHz
…test report The Wio-SX1262 test report (BL-SZ2531376-601) only contains test data for the 128us/0.4s/360s duty-cycle route. No test data exists for the 5ms/4s/50ms route this firmware actually implements. Followed up with Seeed (2026-08-07) to confirm whether their 'RF parameters within scope' answer covers this. Section will be updated once they reply. Also softens the T1000-E section with a cross-reference note, since whether it has the same test-route gap is unconfirmed (no test report obtained yet).
…envs Same issue as PR meshcore-dev#3099 (kiss_modem): without ARDUINO_USB_CDC_ON_BOOT=1 and ARDUINO_USB_MODE=1, Serial routes to UART0, which has no physical connector on this board. USB admin console was unreachable on these envs as a result. Tested on real hardware: USB admin console now responds on both repeater and room_server envs, confirmed configurations via serial.
Contributor
Author
|
Closing - this was opened against the wrong base, pulling in the entire JP fork history instead of just the CDC flag fix. Will reopen with a clean branch based on upstream/dev. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Same root cause as #3099 (kiss_modem): without
ARDUINO_USB_CDC_ON_BOOT=1/ARDUINO_USB_MODE=1, Serial routes to UART0, which has no physical connector on this board — so the USB admin console was unreachable on the repeater and room_server envs.Tested on real hardware: USB admin console now responds on both envs, confirme configuration via serial.