The AGC interval is set in 4 s steps, matching MeshCore's
agc.reset.interval, so the old 30 s default could not be restored by a
host: setting 30 gives 28. Found on hardware. Use 32 s, the nearest
multiple of 4 above it.
A second SetFemState sent while the first was held for a TX got an
immediate TxBusy, which reached the host before the first request's
reply. With no request IDs, the host could not tell which Set failed.
FEM requests now go through a small ordered queue (Set, Get and their
error replies). Sets still wait for TxDone to be queued and apply
once. Each reply is kept until it can be queued. Capability checks
happen in order at processing time. Only an overflow (more than 4
waiting) replies TxBusy immediately.
Boards own their FEM control through handleCommand() ("get/set
radio.fem.rxgain|txgain"). Use that instead of a parallel set of FEM
virtuals on MainBoard, so any board that implements the commands works
in KISS with no extra code.
- Remove the six FEM virtuals from MainBoard and the board overrides.
- KissModem talks to the board in one adapter. A gain counts as
controllable only if "get" replies exactly "> on" or "> off". "set"
is checked by reading the state back, never by its reply wording.
- SetFemState always replies with the read-back state once the
requested bits pass the capability check.
- Guard the boards' prefs writes against a NULL store. KISS attaches
no prefs, so "set radio.fem.*" would dereference NULL.
- Wio Tracker L1 1W TX gain is exposed again, matching its CLI.
Add SetRxBoostedGain (0x20) / GetRxBoostedGain (0x21, reply 0xA1) and
capability bit 3, the KISS equivalent of the radio.rxgain CLI setting.
It is separate from FEM RX gain; a board may support either or both.
- Support is declared by the driver via a new
RadioLibWrapper::supportsRxBoostedGain() (SX1262, SX1268, LLCC68,
LR1110, LR1121, LR2021), so nothing is written to the radio at boot.
- The set is refused with TxBusy during TX or while host output is
backed up. Otherwise any completed RX packet is delivered first,
because some drivers (LR2021) drop to standby to apply the gain.
- The reply always carries the state read back from the radio.
Driver fixes found along the way, which also affect the radio.rxgain
CLI in regular firmware:
- CustomLR2021 never updated its cached gain state, so the getter
always reported off. It now tracks the applied level per RX path
and rolls RadioLib's cached level back if a write fails.
- CustomLR1110/LR1121 cached the requested state even when the write
failed.
- lr11x0ResetAGC only reapplied the gain when RX_BOOSTED_GAIN was
defined, so a runtime setting was lost on the next AGC reset.
- Wio Tracker L1 1W no longer advertises TX gain control: its setter
drives LORA_PWR_EN, the shared LDO for the SX1262 and the PA, so
"gain off" would power down the radio.
- A SetFemState that arrives mid-TX is now applied after TxDone is
queued, so its reply follows TxDone.
- SetFemState replies (immediate or deferred) are retained until they
fit in the host output queue instead of being dropped, so a change
that took effect is always acknowledged.
- GetFemState replies queue behind an outstanding SetFemState reply;
a further SetFemState returns TxBusy until it clears.
Add SetHardware sub-commands so a host can probe and configure
per-board RF front-end settings:
- GetCapabilities (0x1B): uint32 feature bits (AGC, FEM RX, FEM TX)
- Set/GetAgcResetInterval (0x1C/0x1D): 0-1020 s, 4 s resolution,
0 disables; default stays 30 s
- Set/GetFemState (0x1E/0x1F): apply/value masks for FEM RX (LNA)
and TX (PA) gain; all-or-nothing, Unsupported (0x08) if any
requested bit is not controllable on this board
The AGC scheduler moves from main.cpp into KissModem so it is
configurable and unit-tested. FEM changes that arrive mid-TX are
deferred until the packet ends, since board setters drive FEM pins
directly.
MainBoard gains virtual FEM hooks (canControl/set/is for LNA and PA
gain). Boards that already implemented these methods privately now
expose them as overrides: Heltec V4, V4 R8, T096, Tracker V2,
Station G3 and Wio Tracker L1 1W.
KISS_FIRMWARE_VERSION bumped to 2.
The project moved to meshcore-dev/meshcore, but two links still pointed at
ripplebiz/MeshCore: the GitHub Issues link in README and the git clone in the
FAQ build instructions.
Also fixes the FAQ build recipe:
- `pio run -e RAK_4631_Repeater` does not exist; the env is spelled
RAK_4631_repeater (variants/rak4631/platformio.ini:40).
- LORA_FREQ was given as 867.5; the default in [arduino_base] is 869.618
(platformio.ini:29). Reworded to point at the flag rather than a value that
drifts with the default preset.
- Renamed the venv so it no longer collides with the cloned directory name.
And one more env-name casing slip in the Raspberry Pi flashing instructions:
`Heltec_V3_companion_radio_ble` should be `Heltec_v3_...`. Release artifacts are
named directly from the env name (build.sh:147), and the two neighbouring
examples in the same block already use the lowercase spelling.
f6338430 added get/set dutycycle to CommonCLI and updated both CLI docs, but
Terminal Chat does not use CommonCLI -- simple_secure_chat/main.cpp:479-507 has
its own `set` handler supporting only af, name, lat, lon, tx and freq. Typing
`set dutycycle` there returns "ERROR: unknown config".
Restores `set af` as the documented command, points readers at cli_commands.md
for the roles that do have dutycycle, and documents `help`
(simple_secure_chat/main.cpp:510), which the client implements but the doc
never listed.
The doc claimed every pwrmgt command except `get pwrmgt.support` returns
"ERROR: Power management not supported" when NRF52_POWER_MANAGEMENT is not
defined. `get pwrmgt.bootreason` is not inside the #ifdef (CommonCLI.cpp:787)
and answers on all boards; only pwrmgt.source and pwrmgt.bootmv are gated.
Three factual errors in companion_protocol.md:
- The channel-datagram payload cap was given as 163 (MAX_FRAME_SIZE - 9 when
MAX_FRAME_SIZE was still 172). It went 172 -> 176 in 62f1b11d, but simply
updating the arithmetic to 167 would be worse than the stale value: 167 is
only the host-frame bound (MyMesh.cpp:1265). The radio-side bound is
MAX_GROUP_DATA_LENGTH = 184 - 16 - 3 = 165 (MeshCore.h:21, enforced at
BaseChatMesh.cpp:544). A 166- or 167-byte payload passes the frame check,
fails the radio check, and comes back as ERR_CODE_TABLE_FULL -- which this
same doc describes as "retry later", so a conforming client would retry a
permanently failing send forever. Documents 165 as the limit to enforce and
calls out the 166-167 band explicitly.
- Channel index was documented as 0-7 throughout. The bound is
MAX_GROUP_CHANNELS (BaseChatMesh.cpp:927,936), which is 40 on most current
variants, 8 on some and 1 on others. Clients should read max_channels from
byte 3 of PACKET_DEVICE_INFO instead. Index 0 is pre-populated with the
built-in Public channel but is not reserved.
- The secret field was documented as "all zeros" for public channels. The
firmware always hashes a real 16-byte key; the public channel ships with
izOH6cXN6mrJ5e26oRXNcg== (companion_radio/MyMesh.cpp:111,1040). An all-zero
secret is not a private channel and not an inert one: SHA256 over 16 zero
bytes is a fixed global constant, giving a well-known channel with an
all-zero AES key. searchChannelsByHash skips unnamed slots for exactly this
reason (BaseChatMesh.cpp:392-401), but a named slot with a zero secret is
not skipped and will absorb null-key group traffic from any node. Now
documented as something not to do.
Five "Default:" values in cli_commands.md no longer matched the firmware:
- radio / freq: the default preset moved to EU/UK (Narrow) in b777a7c6,
changing LORA_FREQ/BW/SF from 869.525/250/11 to 869.618/62.5/8
(platformio.ini:29-31). No variant overrides these, and LORA_CR is 5
on every path, so the full preset is 869.618,62.5,8,5.
- flood.advert.interval: raised to 47 hours in 40180b8f for both repeater
and room server; sensor leaves it disabled.
- advert.interval: prefs store minutes/2 and the getter doubles on read, so a
factory-fresh node reports 2, not 0. But savePrefs() zeroes any interval
below the 60 minute minimum (CommonCLI.cpp:162-165), and it is called from
every `set` handler -- so the value becomes 0 as soon as the node is
configured. Documented both states, since neither alone is the whole story.
- direct.txdelay: repeater defaults to 0.3, room server and sensor to 0.2.
Sources: platformio.ini:29-31, simple_repeater/MyMesh.cpp:893,903-904,
simple_room_server/MyMesh.cpp:650,661-662, simple_sensor/SensorMesh.cpp:716,
726-727, CommonCLI.cpp:162-165,680-681.
PA PL1 re-targets the PA's DC-DC supply rail rather than selecting a
logic-level gain, and the serial CLI is serviced on every main-loop pass
regardless of whether a transmit is in flight. A `set radio.fem.txgain`
write could therefore move the rail mid-transmit, while the SX1262 was
still driving the PA at full input power.
Record the requested level in setPAGainEnable() and drive the pin from
setTxModeEnable(), which runs from onBeforeTransmit() ahead of
startTransmit(). The level only matters while transmitting, so deferring
costs nothing.
Document that the pref is saved immediately but applied at the next
transmit, so `get radio.fem.txgain` can lead the hardware until then.
mkdocs will only consider the first H1 (if any) and subheaders under it for the table of contents
this increases the header levels of everything below "important concepts" by 1 so that the table of contents correctly resolves them
Switch ESP32-S3 KISS modem environments to HWCDC and move outbound KISS writes to a non-blocking queued frame path so loop() and TX completion keep progressing when the host reads slowly. Add native backpressure regression tests and correct the native_kiss_modem test filter so this suite runs directly with pio test.
Adds a small allocation for groupdata packets for the Meshcore firmware for the StreamSensor product. It was previously a LoRaWAN platform, and we've moved to Meshcore.
Let me know when and how to demonstrate.
Adds a small allocation for groupdata packets for the Meshcore firmware for the StreamSensor product. It was previously a LoRaWAN platform, and we've moved to Meshcore.
agessaman