Hi,
We’ve found a reproducible discrepancy between leaps_reset sent over BLE vs over UART/USB, on LC14_B boards (v1.1.0-a25271).
Over UART (via the shell’s tlv command): sending leaps_reset (type 0x14, no payload) reliably causes the device to disconnect/reboot every time — confirmed repeatedly today, including immediately after a leaps_cfg_anchor_set / leaps_cfg_tag_set role change, with the config change confirmed to have taken effect afterward.
Over BLE (from our own app, using write-with-response to the API Request characteristic): the exact same command is ATT-acknowledged (the write itself succeeds, confirmed via write-with-response resolving normally) but the device does NOT disconnect or reboot afterward — it stays connected indefinitely, still running its pre-reset configuration. This happens consistently, reproduced across 4 different physical devices, both with a single device connected (no radio contention) and with multiple devices connected simultaneously.
Is there a known difference in how leaps_reset is handled depending on transport (BLE vs UART)? Is there an additional step required over BLE — e.g., does the central need to proactively disconnect after sending the reset, rather than waiting for the peripheral to do so? Any guidance would be very helpful, since we’re relying on this command to apply anchor/tag role changes from a mobile app.
Happy to share full byte-level logs if useful.
Thanks,
Trevor
Hi Trevordeanglass,
Can you share a log when trying to send leaps_reset TLV request via BLE?
You need to write the correct characcteristic e6bfa234- 6758-11e9- 979f-5b2 4c4603eb8 and follow the format of the TLV command over BLE. The BLE interface communication is described here: BLE Interface — LEAPS. See section BLE GATT model and messagee encoding. You can try to write the reset request using leapscom tool like this.
$ leapscom --ble DC:0A:80:73:09:3B -v --tlv 1400
2026-09-08 13:05:46,167 Using configuration: {'tlv': [{'cmd': '1400'}], 'timeout': 1.0, 'attempts': 5, 'repeat': 1}
2026-09-08 13:05:46,193 [dc:0a:80:73:09:3b] Connecting ...
2026-09-08 13:05:48,739 [dc:0a:80:73:09:3b] Connected
2026-09-08 13:05:49,325 [dc:0a:80:73:09:3b] BLE TX: 01010000000000000000000000000000000014001400
2026-09-08 13:05:49,336 [dc:0a:80:73:09:3b] BLE RX: "0101000000000000000000000000000000004100400100"
2026-09-08 13:05:49,336 [dc:0a:80:73:09:3b] BLE HDR: 1/1, CRC: 4100 (sum=65)
2026-09-08 13:05:49,337 [dc:0a:80:73:09:3b] TLV: 1/1 "{'cmd': '1400', 'status': 'OK'}".
2026-09-08 13:05:49,337 [dc:0a:80:73:09:3b] Finished. TLV: 1 commands (success: 1, failed: 0).
See BLE TX/BLE RX for expected request/response format. The actual TLV is encoded as the last two bytes. No CRC is needed via the BLE interface. The nonce is all zeros since the encryption disabled. MIC/MAC is a simple sum of the TLV bytes.
Regards,
Jan from Leaps.
Update: we tried the full wrapped format from your example and confirmed
via testing that it’s a well-formed, byte-correct frame (verified against
your reference bytes) — but a wrapped leaps_reset is 22 bytes, which
exceeds the default BLE ATT MTU’s safe ~20-byte write size. Our app has
never negotiated a larger MTU. Does the LEAPS BLE interface require or
expect the central to request a larger MTU before sending TLV commands,
particularly for anything over ~18-20 bytes? If so, we may have been
missing that step entirely, independent of the wrapping question.
Separately, going back to the original question: leaps_cfg_anchor_set
and leaps_cfg_tag_set (both short enough to fit in a single unwrapped
20-byte write) work completely reliably and are physically verified
(LED test). leaps_reset (also short, 2 bytes unwrapped) is ATT-acknowledged
but never causes an actual disconnect/reboot when sent the same way. Given
both are short single-fragment commands sent through the identical code
path, is there something specific about leaps_reset that requires
different handling over BLE versus UART?
Do we have a response to this yet?
Hi Trevordeanglass,
MTU) yes you need to request higher MTU after connection. See “BLE throughput” section here: BLE Interface — LEAPS.
leaps_reset) This command should return TLV response and then the device should terminate connection before actually resetting. No special handling required. If you see otherwise, please provide a log so we can analyze.
Jan