This change updates the jammer sketch to initialize each RF24 instance up front, immediately power them down, and then bring them online one at a time during setup. The revised sequence avoids relying on implicit startup behavior and makes radio configuration more deterministic across all three modules before channels and transmit settings are applied. In practice, startup should be more reliable and easier to reason about on real hardware.

This commit adapts the Arduino sketch to a Blue Pill-style STM32 pinout, changing the RF24 CE/CSN assignments and switching the status LED handling to PC13. It also adds a Fritzing project file so the hardware wiring is documented alongside the firmware, which makes the setup much easier to reproduce correctly. The practical effect is that building and flashing this on a Blue Pill should be more straightforward and less error-prone.

This change updates nrf_jammer.ino so the radios continuously send 255 instead of 0 in the main loop. It’s a tiny code change, but it alters the actual byte pattern emitted by all three writeFast calls and may be intended to produce a stronger or more consistent test/jamming signal depending on the receiver behavior. The practical effect is that the jammer now transmits an all-bits-set byte on every iteration.

This change replaces the loop payload in nrf_jammer.ino from a one-character string buffer to a single byte, while keeping the same writeFast calls across all radios. It simplifies the transmitted data and makes the payload type match the apparent intent of sending a minimal fixed value rather than a string. The practical effect is a small cleanup to payload handling, but not a major behavioral change.

This change adjusts the SPI chip-select wiring for two RF24 instances and moves channel selection out of the main loop into setup, so each radio is configured once before transmission starts. It also changes the D33 control pin sequencing to go HIGH before initialization and LOW after all three radios are ready, which likely stabilizes startup behavior. The practical effect is a cleaner initialization path with corrected hardware configuration and less repeated work during packet transmission.

This change configures pin D33 as an output during setup and drives it HIGH after all three RF24 radios have been initialized and the startup delay completes. It adds a simple hardware status signal that makes it easier to verify the board is fully ready without relying only on serial output or inference from runtime behavior. The practical effect is faster bring-up and easier debugging on device.

This change improves both usability and runtime stability of the project. The README now includes a spectrogram image and a short components list, which makes the three-channel jamming approach easier to understand and reproduce, while the Arduino sketch increases the delays between initializing the three nRF24 radios from 100 ms to 1 s. In practice, that should reduce flaky startup behavior when bringing up multiple transceivers and make the build easier for others to wire up and verify.

This commit adds the first substantial project documentation, expanding the README from a one-line description into a technical overview of how BLE advertising works and why targeting the three advertising channels matters for discoverability jamming. It also documents the nRF2401+ module’s capabilities and ties that hardware choice back to BLE’s narrowband channel design, which makes the implementation easier to understand for contributors. The practical effect is that the repo now has enough context for developers to quickly grasp the approach and hardware assumptions before diving into the code.

This commit introduces the first cut of the Arduino-side implementation in nrf_jammer.ino, wiring up three RF24 instances with auto-ack disabled, high PA level, and 2 Mbps mode before transmitting continuously. In the main loop, each radio is pinned to a different channel and repeatedly sends a small payload with writeFast, establishing the project's baseline behavior for concurrent RF noise generation. The practical effect is that the repository now has a working starting point for hardware bring-up and further experimentation on the jammer logic.