BLE Spam device data separation, more devices, refined config, better randomiser, & misc fixes

[Doominator1]

Proposed Changes

Fixed a bug where config sliders would be offset by 1 when over 20
Fixed a bug where config sliders would skip from 21->11
Fixed a bug where TX Power wouldn't apply until slider exited
Fixed a bug where selecting a specific Apple Action device did nothing, it always sent a random one
Made TX Power and Mac Rand config sliders not loop around

Made Gap ms go down to 0 (new default = 0)
made Adv ms floor at 5ms (because going any lower than 5ms would cause packet loss and therefore would result in lower spam speed)

Replaced Apple, Android, and Samsung device lists with real cross checked device data
Made every device fully selectable by name instead of random pools
Moved Random/All to the top of every list and made it pick each category equally
Fixed AirTag using the wrong prefix byte
Renamed and reordered some menu entries
Split device data out into its own files for better organisation & maintainability

Types of Changes

New Feature, Bugfix

Verification

Build, flash, check ble spam menus for changes mentioned above.

Testing

Tested on T-Embed cc1101

Linked Issues

User-Facing Change

Improved BLE Spam config, menu refinements, added live name stats, better randomiser, and way more devices

Further Comments

[Ninja-jr]

The slider fixes and the tx power apply-on-change fix look good, and I'd merge those as-is.

I'd want to keep the 5 ms gap default though. The observable difference at gap=0 is a slightly higher pkt/s counter — nothing a user can actually perceive. What the gap buys you is time for the NimBLE host task to apply the MAC change before advertising restarts. Since MAC rotation is what makes iOS fire a popup for every packet instead of only the first one, dropping the gap trades visible effectiveness for an invisible speed number. Users who want to experiment can still lower it manually.

The reason I'm cautious here specifically: NimBLE's own guidance flags the stop-then-start-from-the-same-task pattern as unreliable, and that's exactly what bleSpamRestartAdvertiserForMac() does. It calls stop(), issues the MAC change commands, and then bleSpamSendTick() immediately calls start() — all from the module's task, not the NimBLE host task. At gap=5 there's enough of a window for the host to drain the stop and apply the new address before the next start() lands. At gap=0 that window is gone, and any latency in the host task means the packet goes out with the old MAC — which is a missed popup, not just a slower counter.

[Doominator1]

The slider fixes and the tx power apply-on-change fix look good, and I'd merge those as-is.

I'd want to keep the 5 ms gap default though. The observable difference at gap=0 is a slightly higher pkt/s counter — nothing a user can actually perceive. What the gap buys you is time for the NimBLE host task to apply the MAC change before advertising restarts. Since MAC rotation is what makes iOS fire a popup for every packet instead of only the first one, dropping the gap trades visible effectiveness for an invisible speed number. Users who want to experiment can still lower it manually.

The reason I'm cautious here specifically: NimBLE's own guidance flags the stop-then-start-from-the-same-task pattern as unreliable, and that's exactly what bleSpamRestartAdvertiserForMac() does. It calls stop(), issues the MAC change commands, and then bleSpamSendTick() immediately calls start() — all from the module's task, not the NimBLE host task. At gap=5 there's enough of a window for the host to drain the stop and apply the new address before the next start() lands. At gap=0 that window is gone, and any latency in the host task means the packet goes out with the old MAC — which is a missed popup, not just a slower counter.

in this implementation, gap ms only adds extra idle time after the mac address has already been changed, the mac address has been changed before the gap ms timer even starts. (NimBLE blocks on the controller's ack before returning as a safety fallback)

so basically during the gap ms, absolutely nothing is happening except waiting

Apparently if we were using bluedroid, your concern would actaually be a problem, thats fair, but with NimBLE, it's already covered and safe as-is. (I checked: there is no board in this entire repo which uses bluedroid, so this is a non-issue anyway)

Also in my testing, it was extremely stable, didn't crash once, and resulted in slightly higher packet throughput due to the absence of the wait

if you'd like to check the related nimBLE code paths for confirmation having 0ms is safe, check ble_hs_hci_cmd_tx() in .pio/libdeps/lilygo-t-embed-cc1101/NimBLE-Arduino/src/nimble/nimble/host/src/ble_hs_hci.c:542-579

[Ninja-jr]

The slider fixes and the tx power apply-on-change fix look good, and I'd merge those as-is.

I'd want to keep the 5 ms gap default though. The observable difference at gap=0 is a slightly higher pkt/s counter — nothing a user can actually perceive. What the gap buys you is time for the NimBLE host task to apply the MAC change before advertising restarts. Since MAC rotation is what makes iOS fire a popup for every packet instead of only the first one, dropping the gap trades visible effectiveness for an invisible speed number. Users who want to experiment can still lower it manually.

The reason I'm cautious here specifically: NimBLE's own guidance flags the stop-then-start-from-the-same-task pattern as unreliable, and that's exactly what bleSpamRestartAdvertiserForMac() does. It calls stop(), issues the MAC change commands, and then bleSpamSendTick() immediately calls start() — all from the module's task, not the NimBLE host task. At gap=5 there's enough of a window for the host to drain the stop and apply the new address before the next start() lands. At gap=0 that window is gone, and any latency in the host task means the packet goes out with the old MAC — which is a missed popup, not just a slower counter.

in this implementation, gap ms only adds extra idle time after the mac address has already been changed, the mac address has been changed before the gap ms timer even starts. (NimBLE blocks on the controller's ack before returning as a safety fallback)

so basically during the gap ms, absolutely nothing is happening except waiting

Apparently if we were using bluedroid, your concern would actaually be a problem, thats fair, but with NimBLE, it's already covered and safe as-is. (I checked: there is no board in this entire repo which uses bluedroid, so this is a non-issue anyway)

Also in my testing, it was extremely stable, didn't crash once, and resulted in slightly higher packet throughput due to the absence of the wait

if you'd like to check the related nimBLE code paths for confirmation having 0ms is safe, check ble_hs_hci_cmd_tx() in .pio/libdeps/lilygo-t-embed-cc1101/NimBLE-Arduino/src/nimble/nimble/host/src/ble_hs_hci.c:542-579

Fair point and I meanwhile tested it and seems stable aswell on my side so I stand corrected. Plus for the users that had already the 5ms gap that doesn't set it back to 0, only on new installations.

[Doominator1]

drafted for now as im making some changes soon

[Doominator1]

Ready for review!

[Doominator1]

I just standardised the random modes on latest commit, ready for merge!