Hi,
One of my LC14_B devices (addr=DECA687912909D04) has stopped advertising over BLE after a configuration test, and I can’t get it visible to a central again. Details:
• Sequence: sent leaps_cfg_anchor_set with led_en=0 (payload [0x8a,0x02,0x02]) via tlv, followed by leaps_reset. Confirmed via tlv 8 0 that led_en correctly flipped to 0 (LED physically went dark) and back to 1 afterward. LED itself is now on and functioning correctly.
• Since that sequence, the device is no longer discoverable by any BLE central (confirmed: multiple other identical devices scan/connect fine from the same phone at the same time; only this one doesn’t appear).
• Behavioral difference noticed: on power-on, all my other devices buzz, flash red once, then the side button LED blinks green (presumably indicating “advertising/available”). This specific device buzzes and flashes red identically, but the side LED then goes to a solid green instead of blinking — possibly indicating it thinks it already has an active connection?
• Tried since: full power off/on cycle (Button A, 3s), and leaps_factory_reset (frst) followed by another power cycle. Neither changed the LED behavior or restored BLE visibility.
• si output post-reset shows ble=1 in the cfg line, and battery is confirmed not the issue (USB powered throughout).
Is there a known cause for a device to get stuck in this “connected-looking” LED state after a config change + reset, and is there a recovery step beyond factory reset + power cycle? Happy to provide more shell output if useful.
Thanks,
Trevor
Hi Trevordeanglass,
Can you please provide a log from the BLE communication when you are snding those TLV commands? Also the shell output from the commands “si” and “la” after the commands went sucessfull.
I tested with leapscom:
(.venv-leaps-zephyr)
┌📁 LEAPS-UWBS-Firmware-OpenOCD
└$ leapscom --ble DC:0A:80:73:09:3B -v --tlv 07038a0202
2026-09-08 13:37:13,008 Using configuration: {'tlv': [{'cmd': '07038a0202'}], 'timeout': 1.0, 'attempts': 5, 'repeat': 1}
2026-09-08 13:37:13,034 [dc:0a:80:73:09:3b] Connecting ...
2026-09-08 13:37:14,599 [dc:0a:80:73:09:3b] Disconnected!
2026-09-08 13:37:16,680 [dc:0a:80:73:09:3b] Connected
2026-09-08 13:37:17,469 [dc:0a:80:73:09:3b] BLE TX: 010100000000000000000000000000000000980007038a0202
2026-09-08 13:37:17,480 [dc:0a:80:73:09:3b] BLE RX: "0101000000000000000000000000000000004100400100"
2026-09-08 13:37:17,480 [dc:0a:80:73:09:3b] BLE HDR: 1/1, CRC: 4100 (sum=65)
2026-09-08 13:37:17,480 [dc:0a:80:73:09:3b] TLV: 1/1 "{'cmd': '07038a0202', 'status': 'OK'}".
2026-09-08 13:37:17,480 [dc:0a:80:73:09:3b] Finished. TLV: 1 commands (success: 1, failed: 0).
(.venv-leaps-zephyr)
┌📁 LEAPS-UWBS-Firmware-OpenOCD
└$ leapscom --ble DC:0A:80:73:09:3B -v --tlv 1400
2026-09-08 13:37:46,897 Using configuration: {'tlv': [{'cmd': '1400'}], 'timeout': 1.0, 'attempts': 5, 'repeat': 1}
2026-09-08 13:37:46,921 [dc:0a:80:73:09:3b] Connecting ...
2026-09-08 13:37:48,984 [dc:0a:80:73:09:3b] Connected
2026-09-08 13:37:49,353 [dc:0a:80:73:09:3b] BLE TX: 01010000000000000000000000000000000014001400
2026-09-08 13:37:49,364 [dc:0a:80:73:09:3b] BLE RX: "0101000000000000000000000000000000004100400100"
2026-09-08 13:37:49,365 [dc:0a:80:73:09:3b] BLE HDR: 1/1, CRC: 4100 (sum=65)
2026-09-08 13:37:49,365 [dc:0a:80:73:09:3b] TLV: 1/1 "{'cmd': '1400', 'status': 'OK'}".
2026-09-08 13:37:49,365 [dc:0a:80:73:09:3b] Finished. TLV: 1 commands (success: 1, failed: 0).
First configure anchor then reset to apply changes. The shell output after the configuration is as follows.
Copyright : 2016-2025 LEAPS
License : Please visit https://www.leapslabs.com/leaps-rtls-license
Compiled : Jun 16 2025 15:22:03 (v1.1.0-a25271)
Help : ? or help
leaps> si
[000004.726 INF] release: LEAPS RTLS v1.1.0-a25271
[000004.726 INF] sys: main main_ver=x02060001 cfg_ver=x01040000 batt=empty:0mV:NoCharger board=LC14_B pwr_cnt=0 rst_cnt=3
[000004.727 INF] uwb: ch9 prf64 plen128 pac8 txcode11 rxcode11 baud6800 phrmodeext phrratestd sfdtypeieee4a sfdto129 stsmodeoff stslen64 pdo0
[000004.727 INF] uwb: tx_pwr=x34/xC6C6C6C6 sts:shr:phr:data=22.6:22.6:22.6:22.6[dB] cpl=FCC/ETSI pgcnt=240 temp=25
[000004.728 INF] uwb: lna=1 pa=0 rf1=1 rf2=0 xtaltrim=35 tx_delay=16405 rx_delay=16405
[000004.731 INF] uwb: panid=x0000 panid_mask=xFFFF zone=255 addr=xDECA1D45C870C485
[000004.741 INF] mode: ani (act,real)
[000004.741 INF] uwbmac: connected prof=2 (manual)
[000004.774 INF] uwbmac: bh disconnected
[000004.774 INF] cfg: sync=0 fwup=0 ble=1 leds=0 init=1 uab=0 bh=auto bh_stat=off cr=0 upd_rate_stat=30 label=IDC485
[000004.774 INF] enc: off
[000004.774 INF] ble: addr=DC:0A:80:73:09:3B
I see LEDS being off correctly, also on the “si” output. The device is configured correctly as anchor initiator, profile==2, bh=auto, uwb mode 2. This correspond to your TLV payload ([0x8a 0x02 0x02])
Thanks,
Jan, Leaps.
Thanks for looking into this. A clarification first: the sequence that led to this device becoming unreachable over BLE was done entirely over UART/shell (not BLE) — we sent leaps_cfg_anchor_set with led_en=0 to test the LED bit, confirmed it visually (LED went dark) and via readback, then sent leaps_reset, then later re-sent leaps_cfg_anchor_set with led_en=1 and another leaps_reset to restore it. The LED did come back on, but this specific device has not been discoverable/connectable over BLE since, despite multiple leaps_factory_reset (frst) attempts and full power cycles.
Here is the requested si and la output, captured over UART just now (device is powered, LED is on, but not visible to any BLE central):
si output:
[000038.518 INF] release: LEAPS RTLS v1.1.0-a25271
[000038.519 INF] sys: main main_ver=x02060001 cfg_ver=x01040000 batt=empty:0mV:NoCharger board=LC14_B pwr_cnt=0 rst_cnt=0
[000038.519 INF] uwb: ch9 prf64 plen128 pac8 txcode11 rxcode11 baud6800 phrmodeext phrratestd sfdtypeieee4a sfdto129 stsmodeoff stslen64 pdoamodem0
[000038.520 INF] uwb: tx_pwr=x34/xCECECECE sts:shr:phr:data=23.4:23.4:23.4:23.4[dB] cpl=FCC/ETSI pgcnt=232 temp=25
[000038.521 INF] uwb: lna=1 pa=0 rf1=1 rf2=0 xtaltrim=32 tx_delay=16425 rx_delay=16425
[000038.524 INF] uwb: panid=x0000(sys_cfg=x0000) panid_mask=xFFFF addr=xDECA687912909D04
[000038.533 INF] mode: tn (pasv,twr,np,le)
[000038.534 INF] uwbmac: disconnected prof=0 (auto)
[000038.565 INF] uwbmac: bh disconnected
[000038.567 INF] cfg: sync=0 fwup=1 ble=1 leds=1 le=1 lp=0 uab=1 stat_det=1 (sens=2) mode=0 upd_rate_norm=1 upd_rate_stat=50 label=ID9D04
[000038.567 INF] enc: off
[000038.568 INF] ble: addr=68:79:12:90:9D:05
la output:
[000047.579 INF] AN: cnt=0 seq=xFF
One thing that stands out to us: si reports mode: tn (tag mode), but we never explicitly configured this device as a tag — only leaps_cfg_anchor_set (both led_en=0 and led_en=1 variants) and leaps_reset were sent to it. Is that mode value expected/normal here, or could it be related to why BLE isn’t working? cfg also shows ble=1, which suggests BLE should be enabled from the device’s own perspective.
Happy to provide anything else that would help — this device is currently set aside and not blocking our other testing, so no rush.
Thanks,
Trevor
- mode - You mentioned, you executed also factory_reset command. After factory reset, the default mode is passive tag. Also panid is set to 0, if you had UWB network with different panid before, this tag will not appear in that network.
- BLE - yes, from the si output I see that BLE should be enabled. Are you sure it is not advertising? I tested this and the passive tag should advertise normally as usual if ble=1. Can you share some logs please?
Jan
Thanks for the mode/panid explanation — that makes sense given the factory reset, not a bug on our end.
Regarding BLE: confirmed using nRF Connect (a generic BLE scanner app) that the device IS advertising and connectable over Bluetooth. So the device itself is working correctly — the issue is specific to our own app not finding/showing it, even though it’s genuinely there. We’ll investigate on our end why our app’s scan filter might be missing this specific device (possibly related to how its advertised name/label looks post-factory-reset, since si showed an empty label= field for this device). Will report back if we find something that might be useful for other developers, but this looks like it’s on our side, not a device or firmware issue. Thanks for your help narrowing this down.