General Improvement

[wcd6]

Proposed Changes

This PR ports several UI/UX improvements from firmware-1.14 and adds major NRF24/RF jammer enhancements:

Ported from my changes in 1.14:

• IR Read Emulation: After capturing an IR signal, users can now emulate it directly without saving first. Added protocol auto-detection (not forcing raw), with OK to send again, NEXT for new signal, and PREV to save.
• App Store Menu: Added App Store as a dedicated main menu item with full category browsing, install, update, and delete functionality. Removed the old "Install App Store" option from the Config menu.
• Status Bar Icons Centered: Status bar icons (SD, GPS, WiFi, WebUI, BLE, WireGuard) are now centered horizontally with consistent 16x16 size and 6px gap between each icon.
• Battery "CHG" Indicator: Battery status now displays "CHG" text when the device is charging instead of a yellow fill.
• WireGuard Lock Color: WireGuard status icon now uses the theme's primary color (priColor) instead of hardcoded TFT_GREEN.
• WireGuard Setup UI: Improved WireGuard setup screen using drawMainBorderWithTitle, printSubtitle, padprintln, and printFootnote instead of raw TFT calls. Replaced fixed delay(7000) with AnyKeyPress wait.
• NRF24/RF Spectrum: Replaced spectrum analyzer modules with 1.14 versions.
• Better UI/UX on WebUI.

NRF24 Jammer Improvements (new):

• Three jamming strategies: CW (continuous wave), Flood (FIFO refill burst), and Turbo Flood (3-phase: XOR-varied payload + all-0xFF max energy + alternating 0x55/0xAA max transitions).
• Configurable burst count (1–20 packets per channel dwell).
• Random hop order via Fisher-Yates shuffle for unpredictable channel coverage.
• Expanded channel lists: USB 3→20 channels, Video 3→33 channels, RC 4→20 channels.
• All modes default to Turbo Flood strategy with max burst count and random hop enabled.
• Full config UI: PA Level, Data Rate, Dwell Time, Strategy, Burst Packets, Hop Order, Save & Back.
• Enhanced status display with sweep counter, color-coded strategy badge (CW/FLOOD/TURBO), and RND indicator.

RF Jammer Improvements (new):

• Four operating modes with dedicated selection menu: Full Power, Intermittent, Noise Storm, Frequency Sweep.
• Full Power: 3-phase rotation (micro-glitches 1µs/3µs, variable-width bursts 2–20µs, sustained carrier with hard cuts) cycling every 100ms for maximum spectral diversity.
• Intermittent: Forward+reverse chirp sweep (10–500µs) with random noise bursts (1–60µs pulses, 1–8µs gaps).
• Noise Storm (CC1101 only): PN9 hardware random TX at 800kbps, max deviation 47.6kHz, widest RX BW. Cycles modulation (ASK→2FSK→MSK) every 3s with live display of current scheme.
• Frequency Sweep (CC1101 only): ±5MHz around target in 50kHz steps, bidirectional sweep, 40 pulses per step with tight 30µs/5µs timing.
• Consolidated RFMenu to single "Jammer" entry with mode selection inside.

Others

• Merged "Connect" in Files section.
• Changed Apps icon.
• Added UI for wifi only text menus.
• Organizated Sections.

Types of Changes

• New Feature.
• Enhancement.

Verification

• Flash firmware to a lilygo-t-embed-cc1101 and verify:
• IR Read: capture a signal > confirm emulate option appears > press OK to resend, NEXT for new capture, PREV to save.
• App Store: visible in main menu, categories load, apps install/update/delete.
• Status bar: icons appear centered with equal spacing when SD/WiFi/BLE/WG are active.
• Battery: plug in USB > confirm "CHG" text appears.
• WireGuard: connect > lock icon matches theme color, setup screen shows formatted info with key-press dismiss.
• App Store icon: same visual size as other menu icons.
• NRF24 Jammer: open jammer > verify config UI shows all 7 options > test each strategy (CW/Flood/Turbo) > confirm random hop shuffles channels > status display shows badges.
• RF Jammer: open jammer > verify mode menu with 4 options > test Full Power (rapid pulse count) > test Noise Storm (PN9 modulation cycling on display) > test Freq Sweep (frequency updating on display).

Testing

Manual testing (lilygo-t-embed-cc1101).

Linked Issues

NONE

User-Facing Change

- Added IR signal emulation directly after capture (no save required)
- Added App Store as a main menu item with category browsing
- Centered status bar icons with consistent 16x16 sizing
- Battery now shows "CHG" text while charging
- WireGuard lock icon uses theme color instead of green
- Improved WireGuard setup screen with proper UI and key-press dismiss
- Removed "Install App Store" from Config menu (now in main menu)
- Better UI/UX WebUI.
- Replaced NRF24/RF spectrum analyzers with improved versions.
- NRF24 Jammer: 3 strategies (CW/Flood/Turbo Flood), configurable burst, random hop, expanded channels, full config UI.
- RF Jammer: 4 modes (Full/Intermittent/Noise Storm/Freq Sweep), CC1101 PN9 noise with modulation cycling, ±5MHz sweep, aggressive timing.
- Merged "Connect" in Files section.
- Changed Apps icon.
- Added UI for wifi only text menus.
- Organizated Sections.

Further Comments

[emericklaw]

The App Store is a JS script since all its features can be implemented as a JS script without increasing firmware size.
This then leads to more Bruce pen test focussed features to be included.

[wcd6]

@emericklaw Hello, i think the same with the Apps section

[dabassman28]

You still going to add in the mouse jacker middle man stuff from the other pull?

[wcd6]

@dabassman28 Hello, mousejack already exist on this beta version, try flashing my version and u will see

[dabassman28]

@wcd6 Yeah I have seen the mouse jack function in the dev. I meant specifically the sniffer/ middleman function that I saw in your other pull from a few days ago. Wondered if you were still going to add that to the main dev branch via a pull. I didn't see it here.

[wcd6]

@dabassman28 I will gonna see it

[dabassman28]

Nice looking forward to it

[wcd6]

@bmorcelli @pr3y

Review this PR, thanks.

[emericklaw]

@wcd6 please remove the App Store changes from this PR. If it even gets implemeted on device then I already have a verion locally.
As mentioned earlier the original descision was to keep this as a .js script.

This also allows for much faster roll out of changes to the App Store without having to do a whole Bruce release.

[wcd6]

@emericklaw Was removed.

[ninja-jr-2]

Technical Review: NRF24 & RF Jammer Optimizations

First, thank you for the PR - I can see you've put significant work into expanding features and improving the UI. However, I have some concerns about the implementation approach that I'd like to discuss before this gets merged.

Overview

I previously worked on optimizing both jammers for efficiency and real-world effectiveness. While your PR adds valuable features (turbo flooding, expanded channel lists, better UI), I'm concerned that some changes may actually reduce effectiveness while increasing resource usage.

---

RF Jammer (rf_jammer.cpp) Issues

Current Implementation (my previous work) - Efficient Approach:

· Microsecond-precise timing with intelligent glitching patterns
· Efficient ESC checking (every 100ms, not in tight loops)
· Minimized digitalWrite calls
· Random patterns optimized for spectral diversity

PR Changes - Concerns:

1. Excessive CPU overhead - The new full jammer spins 100+ iterations in tight loops before checking state
2. Questionable new modes - "Noise Storm" (PN9) creates predictable patterns that modern receivers can filter; "Frequency Sweep" at 50kHz steps is too slow for frequency-agile systems
3. Display updates during jamming - Adding TFT operations while transmitting can cause timing inconsistencies
4. pulseCount++ overhead - Counting every micro-pulse adds unnecessary cycles

Recommendation for RF Jammer:

Consider keeping the core jamming algorithms from the existing implementation and only merging:

· The improved UI structure
· Mode selection menu (but without the CC1101-only modes unless tested)

---

NRF24 Jammer (nrf_jammer.cpp) - Critical Hardware Constraints

This is where I have the most significant concerns. The NRF24L01+ has hardware limitations that your implementation doesn't account for:

1. TX FIFO Buffer Saturation

The NRF24L01+ has a 3-packet TX FIFO (96 bytes max). Your turbo flooding attempts:

for (int i = 0; i < burstCount; i++) {  // burstCount = 20
    NRFradio.writeFast(data, 32, true);
}

With burstCount=20, you're trying to push 20 packets through a 3-packet FIFO. This causes:

· Constant SPI bus saturation
· CPU spinning while waiting for FIFO space
· More overhead than actual RF transmission

2. SPI Bus Limits

Each writeFast() involves multiple SPI transactions. With burstCount=20 across 125 channels, you're doing 2,500 writeFast() calls per sweep - this will likely saturate the SPI bus and cause the module to become unresponsive.

3. Existing Implementation's Efficiency

The current code respects FIFO limits:

// Fills FIFO exactly once per channel
NRFradio.writeFast(JAM_FLOOD_DATA, 32, true);
NRFradio.writeFast(JAM_FLOOD_DATA, 32, true);
NRFradio.writeFast(JAM_FLOOD_DATA, 32, true);
delayMicroseconds(500);  // Let hardware work

4. Channel Lists

While expanded channel lists are good (USB: 3→20, Video: 3→33, RC: 4→20), they need to be paired with realistic timing. More channels ≠ better jamming if you can't cover them effectively.

5. Real-time Display Updates

Adding TFT updates every 200ms during jamming will cause timing jitter and may interrupt critical TX timing.

---

Specific Recommendations

For NRF24 Jammer:

1. Reduce default burstCount to 3-6 (FIFO-appropriate):

// Change from 20 to 3
static NrfJamConfig jamConfigs[NRF_JAM_MODE_COUNT] = {
    /* FULL */ {3, 1, 0, 2, 3, 1, 0},  // burstCount=3
    // ...
};

1. Respect FIFO limits in turbo flooding:

static void turboFloodChannel(uint8_t ch, uint8_t burstCount) {
    // Fill FIFO with MAX 3 varied packets
    // Don't loop beyond hardware capacity
    uint8_t packets[3][32];
    // Prepare 3 varied payloads (XOR, all-ones, alternating)
    for(int i = 0; i < min(3, burstCount); i++) {
        NRFradio.writeFast(packets[i], 32, true);
    }
    delayMicroseconds(500);  // Let TX complete
}

1. Add configurable aggression level to let users trade off between battery life and aggression:

struct NrfJamConfig {
    // ... existing fields
    uint8_t aggression;  // 0=power save, 1=balanced, 2=max
};

1. Make display updates optional or less frequent during jamming (every 500-1000ms instead of 200ms)

For RF Jammer:

1. Keep the efficient ESC checking pattern from existing code
2. Test CC1101-only modes extensively before merging - PN9 and frequency sweep may not be as effective as claimed
3. Remove pulse counting overhead or make it optional

---

Bottom Line

Your PR adds great features (turbo flooding concept, expanded channel lists, better UI), but the implementation needs to respect hardware limitations.

The existing code was simpler but hardware-appropriate. Your code is more feature-rich but risks:

· Saturating the SPI bus
· Overwhelming module FIFOs
· Burning battery without improving effectiveness
· Causing timing issues that reduce actual jamming performance

I'd be happy to help test if you adjust the implementation to respect these hardware constraints. The features are valuable - they just need to be paired with hardware-aware execution.

---

Note: I'm not a maintainer, but since I previously worked on optimizing these modules, I wanted to share my findings to help ensure this PR improves rather than degrades performance.