Project Overview and Improvements

This project is a small ESP8266 + OLED + 3-button UI build. The file/project name suggests “WiFi jamming,” but the actual schematic content (as currently captured) looks like a WiFi-capable microcontroller driving a simple menu/display, which is commonly used for things like WiFi scanning/monitoring, channel surveying, signal visualization, or general IoT UI. I can’t help with instructions to build or optimize a jammer, but I can explain what’s here and how to make it a robust, lawful WiFi/UI device.
Purpose (what it’s set up to do)
  • Provide a human interface (Up/Down/OK buttons) to control some firmware function on an ESP8266.
  • Show status/menus on an I2C OLED display.
  • Rely on the ESP8266’s WiFi capability for whatever the firmware implements (e.g., scanner, telemetry, configuration portal, etc.).
Core components Compute / WiFi
  • U1 (Nodemcu-12E ESP8266): the main controller module. It provides WiFi + GPIO + I2C lines for the display and button inputs.
User input
  • UP, DOWN, OK (push buttons): three momentary switches for navigating UI/menus.
Display
  • OLED (OLED 128 x 64 0.96 inch, I2C): 4 pins (SDA/SCL/5V/GND) suggesting a common SSD1306-style module.
Connectivity/organization
  • Green Jumper Wire (Net Portal): schematic-only connectivity label (excluded from BOM/PCB).
How they interact (current net-level view) Buttons to GPIOs + shared “ground”
  • UP connects to U1 via net “Blue Jumper Wire”: U1:D5 GPIO14 UP:P1.
  • DOWN connects to U1 via Net 5: U1:D6 GPIO12 DOWN:P1.
  • OK connects to U1 via Net 7: U1:D7 GPIO13 OK:P1.
  • The other side of all three buttons is tied together on Net 6, which also includes:
Implication: firmware likely uses GPIO internal pullups/pulldowns and reads button presses as logic transitions against the shared ground net.
OLED to ESP8266 (I2C + power)
  • OLED 5V connects to U1 3V3::25 via net “Black Jumper Wire”.
    Design choice / trade-off: This is labeled “5V” on the OLED module pin, but it’s being fed from a 3.3 V pin on the NodeMCU module. That can be OK for some OLED modules (many accept 3.3 V despite the “5V” label), but it’s a real integration risk unless verified for your exact module.
  • I2C nets in the schematic are currently inconsistent:
    • One net named “Blue Jumper Wire” connects OLED:SCL to U1:D2 GPIO4 SDA (note: D2 is typically used as SDA label-wise, but the symbol shows GPIO4 SDA).
    • Net “Green” only connects OLED:SDA and appears not connected to U1.
    Implication: As wired now, the display likely won’t work because SDA/SCL aren’t both connected to the ESP8266, and SCL is tied to a pin labeled as SDA.
Design & implementation status (what’s missing / what reviews say)
From the live checks:
  • ERC error: power input not connected
    • U1 VIN is unconnected.
    • This means there’s no defined input power source for the module in the schematic (even if you intend to power by USB in real life, the schematic still needs a power net strategy).
  • Project documentation missing (DRC/metadata review).
  • Project manufacturer name missing (metadata review).
These don’t prevent prototyping, but they do affect correctness and manufacturability readiness.
Key technologies & dependencies
  • ESP8266 (NodeMCU/ESP-12E ecosystem): WiFi + MCU + GPIO.
  • I2C display (SSD1306-type common pattern): depends on:
    • Correct SDA/SCL wiring
    • Proper pull-ups (sometimes on module, sometimes required externally)
    • Compatible logic levels (3.3 V on ESP8266)
  • GPIO button inputs: depends on:
    • Pull-up/pull-down strategy (internal vs external)
    • Debouncing (firmware and/or hardware)
Potential challenges & performance considerations
  • Display bus reliability
    • Miswired SDA/SCL is the main functional blocker.
    • If the OLED board expects 5 V on its “5V” pin (and you feed 3.3 V), you may get brownout-like symptoms: dim display, random resets, I2C instability.
  • Power integrity
    • ESP8266 WiFi activity is bursty and can be sensitive to supply droop; using a dev module helps, but your schematic currently doesn’t define the power source or rails cleanly (VIN floating).
  • Button robustness
    • Without explicit pull resistors and debouncing, button reads can be noisy or inconsistent (depends on firmware configuration and wiring).
Real-world applications (lawful)
Given the actual hardware blocks present, typical uses are:
  • WiFi site survey tool (RSSI/channel listing, environment monitor)
  • WiFi-connected status display (sensor dashboard, device status)
  • Configuration UI for an IoT node (local menu + display)
Areas for improvement / future enhancements
High-impact improvements based on what’s currently in the schematic:
  • Fix the I2C wiring so both OLED SDA and SCL connect to the intended I2C pins on U1 (and ensure they aren’t swapped).
  • Define a clear power strategy:
    • Are you powering via VIN, via 3V3, or via USB on the dev board? The schematic should reflect that with proper nets and connectors.
  • Confirm whether the OLED module “5V” pin is acceptable at 3.3 V for your exact display module; otherwise add proper 5 V supply and/or level considerations.
  • Add project documentation (requirements, intended power, intended firmware behavior) so the design intent is unambiguous.
If you tell me what the intended legal function is (scanner, monitor, UI controller, etc.), I can map the current wiring to that goal and recommend specific schematic-level corrections and hardening steps.
Show I2C wiring issues
Fix VIN power input
Check OLED supply compatibility
Run focused ERC checks
Review BOM sourcing
Line: 27:23: 'event' is declared but its value is never read.Line: 34:24: 'event' is declared but its value is never read.Line: 40:23: 'event' is declared but its value is never read.


No results...

Wifi Jammer

Properties

1.70

V

LED

CTL1206FYW1T

LED

Pricing & Availability

Distributor

Qty 1

Digi-Key

$4.53–$7.47

LCSC

$4.23

Mouser

$5.31

Controls