env:Generic_ESPNOW_room_svr was using 'Heltec Room' as ADVERT_NAME,
causing Generic ESPNow room server nodes to advertise with the wrong
device name on the mesh.
Repeater and Room Server environments in variants/thinknode_m5/platformio.ini
were using 'Thinknode M2' as the ADVERT_NAME, causing M5 nodes to advertise
with the wrong device name on the mesh.
- env:ThinkNode_M5_Repeater: 'Thinknode M2 Repeater' -> 'Thinknode M5 Repeater'
- env:ThinkNode_M5_room_server: 'Thinknode M2 Room Server' -> 'Thinknode M5 Room Server'
- Replace vTaskDelay(1) with YIELD_TASK() macro for platform compatibility
(FreeRTOS: vTaskDelay, others: delay)
- Make getCodingRate() and getFreqMHz() non-pure virtual with defaults
(default CR4/8, default freq 0.0f for unknown platforms)
- Add getCodingRate() and getFreqMHz() to CustomSTM32WLxWrapper
All environments now build successfully.
JP LBT mode now activates automatically based on operating frequency:
- CH25: 920.800MHz
- CH26: 921.000MHz
- CH27: 921.200MHz (ARIB STD-T108, 200kHz grid)
Changes:
- Add isJapanMode() to RadioLibWrapper using getFreqMHz()
- Add getFreqMHz() to CustomSX1262Wrapper and CustomLR1110Wrapper
- Remove #ifdef JP_STRICT throughout, replaced by isJapanMode()
- Remove -D JP_STRICT build flag from platformio.ini
- MAX_TEXT_LEN dynamically determined by CR at runtime via getMaxTextLen()
No build flags required: JP compliance activates automatically
when device is configured to Japan 3 frequencies.
LR1110 has codingRate as protected field in LR_common.h, so
getCodingRate() is implemented in CustomLR1110 class directly,
and exposed via CustomLR1110Wrapper override.
This enables dynamic MAX_TEXT_LEN calculation for T1000-E
under JP_STRICT mode.
Instead of compile-time LORA_CR define, MAX_TEXT_LEN is now determined
at runtime by reading the actual coding rate from the radio hardware.
Added getMaxTextLen() to RadioLibWrapper and Dispatcher:
- CR4/5: 48 bytes (~16 JP chars, TX ~3808ms)
- CR4/6: 32 bytes (~10 JP chars)
- CR4/7: 24 bytes (~8 JP chars)
- CR4/8: 16 bytes (~5 JP chars, default)
getCodingRate() added to CustomSX1262Wrapper to read codingRate
from RadioLib PhysicalLayer at runtime.
Tested: 48-byte limit with LORA_CR=5, 16-byte limit with LORA_CR=8.
MAX_TEXT_LEN is automatically selected based on the LORA_CR build flag
defined in platformio.ini (e.g. -D LORA_CR=5).
CR4/5: 48 bytes (~16 JP chars, TX ~3808ms)
CR4/6: 32 bytes (~10 JP chars)
CR4/7: 24 bytes (~8 JP chars)
CR4/8: 16 bytes (~5 JP chars, default)
To enable CR4/5 for Japan, add -D LORA_CR=5 to your board's
build_flags in platformio.ini. Set LORA_CR=5 for WioTrackerL1 and RAK WisMesh Tag.
Replace relative threshold (_noise_floor + _threshold) with absolute
-80dBm as specified by ARIB STD-T108 for carrier sense detection.
Previous relative threshold (~-99dBm) caused false busy detection
from environmental noise. -80dBm matches the legal requirement and
reduces spurious backoff.
Under JP_STRICT mode, add energy-based carrier sensing loop before CAD:
- Sample RSSI continuously for >= 5ms before each TX attempt
- If RSSI exceeds threshold at any point, trigger random backoff
- ARIB STD-T108 requires energy-based sensing; LoRa CAD alone is
insufficient as it only detects LoRa preambles
This satisfies the minimum 5ms continuous sensing requirement for
the 920.6-922.2 MHz zone (specified low power radio, LBT mode).
Test results (JP LoRa SF12/BW125/CR4-8, simultaneous DM):
- 16-char: 2/2 success, delivered within 1:03-1:50
- 1-char: 3/4 success, delivered within 0:46-2:11
(shorter airtime reduces RSSI detection window)
JP_STRICT limits MAX_TEXT_LEN to 1*CIPHER_BLOCK_SIZE (16 bytes) to keep
TX time under 4 seconds on SF12/BW125/CR4-8 (Japan LoRa settings).
SF12/BW125/CR4-8 airtime:
60 bytes total packet = ~3809ms (within 4s limit)
packet overhead ~44 bytes, leaving 16 bytes for text payload
Enabled only for WioTrackerL1 and RAK_WisMesh_Tag builds.
ESP-NOW radios (ie, Generic_ESPNOW_* variants) do not compile due to
missing methods
Changes in January 2026 (019bbf74) to add additional stats (receive errors)
to CMD_GET_STATS was not implemented in the ESPNOWRadio() class
Changes in March 2026 (9a95e25e) to add setRxBoostedGainMode to all devices
rather than just SX1262/SX1268 were not applied to the ESPNowRadio() driver
Specifically, this change adds the following to ESPNOWRadio()
* getPacketsRecvErrors() - always returns 0
* getRxBoostedGainMode() - always returns false
* setRxBoostedGainMode() - does nothing
