====================================================================
  B-L-A-C-K-W-I-R-E
  A Handheld RF Site Survey Tool for the Arduino UNO R4 WiFi
====================================================================

Hardware:
    Arduino UNO R4 WiFi
    DFRobot LCD Keypad Shield

Features:
    * WiFi Scanner
    * BLE Scanner
    * Signal Tracker
    * Channel Advisor
    * EEPROM Database
    * Embedded Web Dashboard

Repository:
    https://github.com/Lovejoy-Zero/BlackWire-Arduino

====================================================================
[ 0x00 ] WHY?
====================================================================

This started because I had an UNO R4 WiFi and a DFRobot LCD Keypad
Shield sitting unused in a parts drawer from an old school project. I wanted to see how far I
could push the hardware without bolting on another ESP32, an
external display, or a second processor to help out.

The original idea was nothing more than showing nearby WiFi networks
on a 16x2 LCD.

One feature became two. Two became five. Eventually the thing turned
into a portable RF survey tool that scans WiFi, sniffs out Bluetooth
Low Energy devices, tracks signal strength, recommends less crowded
channels, keeps a database of known networks in EEPROM, and serves
its own browser-based dashboard straight from the microcontroller.

Honestly it evolved more out of "a network scanner" because i was really bored and decided to push myself T_T

====================================================================
[ 0x01 ] THE HARD PART
====================================================================

Scanning WiFi was never really the hard part. WiFiS3 already gives
you network scans out of the box, and ArduinoBLE makes BLE discovery
pretty easy.

The real challenge was getting all of it to run at once on a chip
with only 32 KB of SRAM.

At any given moment BlackWire might be doing several things at once:

    - Running RF scans
    - Maintaining EEPROM records
    - Updating the LCD
    - Handling keypad input
    - Running an HTTP server
    - Generating HTML responses
    - Accepting browser requests

Every one of those is fighting over the same tiny pool of memory.

Early versions leaned on Arduino String objects almost everywhere
because they're quick to write. That was fine for short tests, but
during long Auto Scan sessions the heap would slowly fragment. After
an hour or two, allocations started failing, and eventually either
the web server would hang or the board would just lock up.

The fix was ripping dynamic allocation out of every hot path. Every
String involved in scanning or HTTP processing got swapped for
fixed-length character buffers. HTTP requests now get parsed into a
128-byte buffer instead of a String that keeps growing. HTML goes
out in small chunks instead of getting built as one big page in RAM
first. EEPROM records use fixed-size structures so offsets are
always known without any extra allocation.

The payoff was that memory usage stays basically flat no matter how long the
thing runs. I'll check the System Info page after several hours and
free RAM has barely budged. That's about when the firmware/code started
feeling pretty good for actual field use, not just at a small scale.

====================================================================
[ 0x02 ] WHAT I LEARNED
====================================================================

Desktop software gets to hide memory management behind gigabytes of
RAM. Microcontrollers don't give you that luxury.

Building BlackWire meant thinking about allocation very carefully.

And the biggest win wasn't completing it even though it was great lol. It was the fact that I

Manged to create something at such a small budget.

====================================================================
EOF 
====================================================================

- Piper Lovejoy :)