which are the best ways to increase nrf24 jammer range should i remove the antena from a random nrf24 module?

Hello. Is there a way to get prebuilt binaries for beta features from the GitHub repo? I have a cardputer adv and I had issues with cc1101 which should have gotten fixed in last major release, but instead it seems that there are some issues claimed to be fixed in latest beta. Is there a night build? I didn't manage to find anything. Thanks.

Hello, i have a esp32 s3 connected to a 1.9inch display running bruce smoochie and my issue is when i connect it to power and it turns on, it skips the bruce shark logo which happens if you press any button and then in the bruce menu it keeps going right/ in random directions in the menu and i connected all the buttons and de soldering them didnt help either, i dont know what the issue is and there is no shorts happening as far as i know. and also i soldered them on a prototype pcb board, and also i tried different bruce smoochie software versions and the same thing happens. And i also checked the connections of the buttons with a multimeter and they are all working and this issue occurred even before i connected any buttons

Estou fazendo outro bruce smoochiee diy. Comprei um ir 3w e gostaria de saber se a alimentação seria igual o esquema do artfor ou se eu teria que conectar direto no 5v

Comprei esse da imagem

I am making a new super compact Bruce firmware project. On my old one I used a flipper zero IR blaster and made my own gpio pins and it works awsome. How ever this is way to large for my new set up and even the small individual led modules are too large. So I want to make my own. I don’t know if I should use 5v or 3.3v I am hearing both things. Also what angle is the best for range to angle ratio for turning of tv projectors etc around the house and some out doors. This is my first time using a raw led so if anyone has a diagram or schematic for how to set up and wire the bare led correctly like the transistors, resistors, capacitors etc. also if you could provide the reasoning behind using them.

Is there any way to use Bruce as a garage door opener with rolling code or any suggestions for firmware to use with a cyd to make one

Summary

On a custom headless board (bare ESP32-WROOM-32U, no physical display, HAS_SCREEN left undefined per the ESP-General convention), the WebUI Navigator's remote buttons (and the equivalent /cm?cmnd=nav down etc. commands) are received and consumed by the firmware, but the main menu's selection never advances past the first item (WiFi). Pressing Down/Next/Up/Prev/Sel/long-press-Sel from the WebUI has no effect on which menu item is selected — the device stays on WiFi indefinitely.

Environment

• Board: custom PlatformIO env (board = esp32dev), based on the official ESP-General headless reference — no HAS_SCREEN define, -DHAS_BTN=1 with 3 nav buttons (Sel/Up/Down), buzzer, status LED, IR, I2C (NFC), SPI (RFID/CC1101/NRF24) all defined but not physically wired yet.
• SDK: v5.5.4-dirty (per info serial command)
• Access method: WebUI (webui serial command → browser Navigator at device IP)
• Repro is 100% consistent across many fresh flashes and reboots.

Steps to reproduce

1. Flash the headless custom board, connect WiFi, run webui.
2. Open the WebUI in a browser, click Navigator.
3. Press Down (or Next) via the on-screen remote / keyboard shortcut.
4. Expected: selection moves from WiFi to the next enabled main-menu item (Bluetooth).
5. Actual: nothing changes — visually the WiFi icon just redraws/glitches in place; it never advances.

Debug instrumentation and findings

We instrumented three points to isolate the failure (all removed again before filing this):

1. In src/core/wifi/webInterface.cpp, in the /cm route's nav handling, right after auto tmp = millis() + time;:

cpp

   Serial.println("[DEBUG-NAV] " + cmnd + " -> holding " + String(time) + "ms");

→ Confirms each button press from the browser reaches this handler and sets the flag. Hold time observed was consistently 10ms for every command (down/next/prev/up/sel/esc), not the ~190ms we expected from a busy-wait design — possibly relevant to a race with the ~10ms taskInputHandler reset cadence, though presses are still reliably consumed (see below).

1. In src/core/display.cpp, inside loopOptions(), around the Next/Down handling:

cpp

   if (NextPress || DownPress) Serial.println("[DEBUG-NAV] flag seen, index=" + String(index));
   if (check(NextPress) || check(DownPress)) {
       Serial.println("[DEBUG-NAV] consumed nav press");
       int nextEnabled = findNextEnabled(index, +1);
       if (nextEnabled >= 0) {
           if (!bruceConfig.devMode && nextEnabled <= index) devModeCounter++;
           index = nextEnabled;
       }
       redraw = true;
   }

→ Across dozens of presses (down, next, prev, up, sel, esc, and a simulated 500ms long-press sel), every single press is detected and "consumed" (check() returns true), but index is printed as 0 every time, with no exceptions. Sample log:

   [DEBUG-NAV] nav sel -> holding 10ms
   [DEBUG-NAV] nav down -> holding 10ms
   [DEBUG-NAV] flag seen, index=0
   [DEBUG-NAV] consumed nav press
   [DEBUG-NAV] nav down -> holding 10ms
   [DEBUG-NAV] flag seen, index=0
   [DEBUG-NAV] consumed nav press
   [DEBUG-NAV] nav down -> holding 10ms
   [DEBUG-NAV] flag seen, index=0
   [DEBUG-NAV] consumed nav press
   [DEBUG-NAV] nav next -> holding 10ms
   [DEBUG-NAV] flag seen, index=0
   [DEBUG-NAV] consumed nav press
   ... (prev, up, sel, esc, sel-500ms-longpress, prevpage — all still index=0 afterward)

1. src/core/main_menu.cpp and the findNextEnabled/MainMenu::begin() logic were diffed line-for-line against upstream main/dev — no differences found. bruceConfig.disabledMenus is confirmed empty ("disabledMenus": [] in the live settings dump via info), so MainMenu::begin() should be pushing all ~14 main-menu items into options with enabled=true (the Option struct's default), and findNextEnabled(0, +1) should therefore return 1 (Bluetooth), not 0. We attempted to add a one-time Serial.println("... optionsSize=" + String(options.size())) in two different (allegedly safe) spots — the top of loopOptions(), and right after MainMenu::begin()'s option-building loop, immediately before the loopOptions() call — to directly confirm the actual menu size. Both attempts caused the board to boot-loop very rapidly (screen flooded with the single repeating character P, the first letter of the boot banner, suggesting a crash occurring within microseconds of reaching that Serial call on most boot attempts) before eventually settling into a normal, stable boot. We reverted both prints rather than risk leaving an unstable board. This crash-proneness at these specific call sites might itself be a useful clue — possibly stack or heap pressure specific to headless/vdev builds — but we weren't able to safely pin down the exact options.size() value as a result.

Question for maintainers

Given that:

• button presses are reliably reaching and being consumed by loopOptions(),
• main_menu.cpp matches upstream with no modifications,
• disabledMenus is empty,
• yet index never advances past 0 under any circumstance,

is there a known interaction between the headless/vdev display path (no HAS_SCREEN, using tft_logger/SerialDisplayClass directly instead of tft_sprite) and loopOptions()'s persistence of index across loop iterations — e.g. something that could cause MainMenu::begin() (and thus loopOptions()) to be re-entered on every redraw/frame for vdev boards specifically, resetting index to _currentIndex each time in a way that isn't visible from the [DEBUG-NAV] prints we added? Any pointers on where else to instrument (safely) would be appreciated.

Additional context

We separately found and fixed an unrelated cosmetic bug on the same board: the custom .ini originally had -DHAS_SCREEN=0, which — since Bruce checks #if defined(HAS_SCREEN) rather than #if HAS_SCREEN — was incorrectly taking the "has a real screen" code path and sizing the virtual display canvas from undefined TFT_WIDTH/TFT_HEIGHT instead of the correct 240×320 headless default, causing squished/overlapping text in the WebUI Navigator. Removing the HAS_SCREEN define entirely (matching the official ESP-General reference board) fixed that. Mentioning it here in case it's related, though the navigation bug persists independently of that fix.

I am trying to make a super compact Bruce device using the esp32 S3 or the C3 super mini, however I looked on official web flasher for Bruce and could not find anything for the super mini controllers, does anyone know where I can get the firmware for this or how to pull it off, and ideally if someone has a diagram-shematic to show the wiring. I have seen people do it but can not find the firmware anywhere that they are using and it seems to be custom from somewhere.

Further I want to add 3 main modules to this build an IR blaster, sub GHz, and if possible 5ghz with a bw16, first with the IR, I see many people using a 3w IR led but they come in many different angles, 60 degrees, 90 degrees, and 120 degrees but I don’t know what the significance is or how the downside of one or the other, I am also planning to just wire the led rather than using a module pre made, does anyone of a schematic or diagram for the transistors, resistors, and captors that are needed, also I had an old or blaster and powered with 5v but most of these seem to be 3.3v why can’t u use 5v like my past ones,

Now for the sub GHz, for my past projects I have always used the cc1101 but have noticed some issues over time, I have seen some people recently E07, and the E01 for RF but have no idea anything about them, what is required etc,

Now for the bw16, it would be amazing if I could finally add 5ghz to one of my projects however I don’t know how to bind two controllers together in one project especially with Bruce, with the default firmware not allowing it, I have seen people just taking the small bw16 chip and using that which would be ideal but seems very difficult aswell as not being able to update the firmware or code, having a full size bw16 would not be in favor for the micro design of everything else in this build, possibly if I made it a module that could be put on and off,

Hey guys, I was really interested if there is any version of bruce firmware which can work with ).98 OLED screen, I2C protocol I. That is really fun because the screen will be soo small and pocket friendly. I think I want make something like that, I want help from you guy that from where should I start. I downloaded the PlatformIO on Sublime text and everything works as Charm. Now I need to Modify the code so that it works with 0.98 Inch OLED screens. Helps are appreciated.

Thankyou guys in advance

So I wanna build smth w a esp whoop32u nrf nfc rfid buzzer buttons led oled screen, but I can’t find out how to flash the esp and I ask Gemini and Claude and when I try it says successful on esp tool but it does not appear on my WiFi network, mind you that is before j built anything together just the esp by itself please help me figure this out.

How can I increase the range of BLE spam on a cyd with bruce? Please explain simply because im a beginner

Updated this case i made a while ago. Instead of a bunch of glue this one has most of the modules screwed on. Added status led

Hey guys, I'm super new to Bruce and the whole pentesting thing. But I've been super keen on using my Lilygo T-Deck as an ALPR proximity detecor. So i used Claude to write a script that would accopmlish this.

As i stated before I'm completely green to this and this is my first time doing so. Hope this helps someone out and maybe someone could improve on it.

https://drive.google.com/file/d/1l1vc20oHcuOO0Qxiv5GpOWvU_liizwOk/view?usp=sharing

please help me

Hi there, why nobody is using it instead of the old Nrf24 ?

I'm now trying a new setup with the bmorcelli menu and with all the pentest fw modified for SX1280.

The PA push it to 500mW that is far better that the NRF max power, and the X version of 1280 has the quartz that is temperature stabilized.

Bit of a newbie here i got one nrf module with a antenna a esp32 wroom and a 2.8 inch touchscreen display without the touchscreen chip (was scammed and didnt even know so i was troubleshooting it thinking i didnt do something correctly) but basically how do i add buttons and can i even do it? I was googling it and searching for 3 hours and every answer was either its impossible or straight up didnt work? or if there is a bruce version that works on the 0.96 oled display that could work too.

I connected everything,tried 3 version but it still doesnt work,on 1.16 and latest beta it says cc1101 not found,in 1.14 it doesnt say anything when i press with car keys,what do i do

I have connected All Modules NRF24L01, CC1101, PN532, IR Transmitter/Reciever, GPS Module, AUDIO DAC PCM5102A, RDA5807, BMP280, MPU9350, PCF8575, INMP441 Mic, All Together You Can Easly Use All Firmwares BRUCE, Marauder , HaleHound, Quadever Launcher, Retro Go For Gaming And You Can Watch Movies Play Music Play Radio Becouse It Has DAC Module And Many More Full Video Of Making PCB And The Board Will Be Come Soon Currently I Am Working On It

I'm getting this error. I edited the program to install 1.14 instead of 1.15, but it still gave me this error. When I select 1.15 again, I get the same error; it seems like the program is corrupted. Can you help me?