HARDWARE SURVEY

Citation policy: every concrete claim about a firmware/repo/chip has an inline link to a primary source pulled live on 2026-06-02 (release versions, dates, and star counts re-pulled 2026-07-20). Prices are intentionally absent — see §6 for the reasoning. A handful of cells are labeled “field-tested but not citable from public docs” — those are working knowledge from running the feeders, flagged so a future maintainer can re-verify if they doubt the claim.

2026-07-25 pass: §3e (the wider firmware catalog, covering everything that wardrives without a WDGWars uploader) and §10 (maturity signals for the long-running repos) are new. §4 gained a caveat because Ghost_ESP is now archived, §A gained the WDGWars rebrand note, and Biscuit’s app-mediated upload path is detailed in §3. Star counts and last-push dates in the new sections came from gh api repos/<owner>/<repo> on 2026-07-25.

Looking for the newcomer onramp? See Newcomer onramp for the leveled walkthrough from “just got an Android phone” → “lab-scale capture.” The companion canvas at Capture flow diagram visualizes the same paths as a flow diagram.

1. How a capture reaches wdgwars.pl

Two server-side upload paths exist. Picking firmware mostly reduces to which path it can use.

A /endpoint/* mirror exists for clients that want to dodge Cloudflare’s L7 rate limit on /api/* (returns 429 + code 1027 on cold-IP bursts). The shared transport handles this at the library layer — gungnir tag v0.1.2 flipped the default base URL; pin >= v0.1.2 to inherit. Hand-rolled HTTP clients (Bruce on-device, anything you write yourself) need the URL flip too if they want the bypass.

flowchart LR
    cap["Any capture<br/>Wi-Fi / BLE / ADS-B / MeshCore / Meshtastic"] --> route{"Which data type?"}
    route -->|"Wi-Fi + BLE (bulk)"| csv["WigleWifi-1.6 CSV<br/>multipart · X-API-Key"]
    route -->|"ADS-B + Mesh (MeshCore/Meshtastic)"| json["Signed JSON envelope<br/>HMAC via gungnir"]
    csv -->|"POST /api/upload-csv"| api(("wdgwars.pl<br/>/api/upload-csv"))
    json -->|"POST /api/upload/"| apij(("wdgwars.pl<br/>/api/upload/"))
    api -.->|"CF L7 429 on cold-IP bursts"| mirror["/endpoint/* mirror<br/>bypass · gungnir v0.1.2+ default"]
    apij -.-> mirror
    classDef dest fill:#3a2a05,stroke:#fbbf24,stroke-width:2px,color:#fbbf24
    classDef pcside fill:#053946,stroke:#00e5ff,color:#00e5ff
    class api,apij dest
    class csv,json pcside

1a. MeshCore vs Meshtastic: the mesh slot contract

MeshCore and Meshtastic are not the same thing, and mixing them up is common enough to be worth spelling out. Both are LoRa firmware for sub-GHz radios, and they often run on identical hardware: a T-Beam, a Heltec, a Wio Tracker can boot into either one. What differs is the firmware and the on-air protocol. A MeshCore node and a Meshtastic node on the same frequency do not talk to each other; picking one means re-flashing if you later want the other.

As of 2026-08-12, per LOCOSP, the WDGWars mesh slot (meshcore_nodes) accepts both networks, told apart rather than mixed:

• Records carry a network field, meshcore or meshtastic. If present, it’s authoritative.
• Omit it and the server infers from the role name: MeshCore roles are Title Case, Meshtastic roles are SCREAMING_SNAKE, and the two sets don’t overlap. Any other network value is rejected outright with its own reason, bad_network. Before today an unrecognized role was silently filed as MeshCore, which is how Meshtastic data had been arriving without anyone deciding it should.
• Node ids may carry a leading ! or not; the server strips it.
• Send the role exactly as captured. It’s stored verbatim and mapped onto the server’s own internal set feeder-side, no translation needed (ROUTER, CLIENT_MUTE, SENSOR, etc. all land sensibly).
• Ids no longer collide across networks. A MeshCore id is a key prefix; a Meshtastic id is a device number. The same string can legitimately be two different devices, and is now stored as two separate nodes.
• Prefix merging stays MeshCore-only. Resolving a short on-air id against a longer key seen elsewhere in the same capture means nothing in Meshtastic and isn’t applied there.
• Hops never reject a sighting. A sighting counts however it arrived. Send path_hops if the capture has it; omit it and the server assumes direct. A sighting can only move a node’s stored position if it’s at least as close as whatever set the current position, so a direct sighting always wins and a hopped one only fills in a position not already known. The practical guidance: send everything you captured, hopped or not, and tell the server the hop count if you have it.

For MeshCore specifically, the canonical node_id is the first 8 bytes of the node’s Ed25519 public key, lowercase hex, 16 characters; the server’s gate is [a-f0-9]{8,16}. The short 2-6 hex ids you see on-air are a local disambiguator, not an identity. Feeders may optionally send the full public_key (64 hex), with node_id verified as its prefix.

Today, Heimdall only parses MeshCore exports (MeshMapper CSV). A Meshtastic-native feeder is still unbuilt, tracked in §9. Buying Meshtastic gear no longer means the slot won’t take your data once something parses it into the envelope; it means the parser doesn’t exist yet.

2. Firmwares that upload to WDGWars directly (on-device, no PC needed)

Five projects verified to upload to WDGWars from the capture device itself (the first four as of 2026-06-02; ESP32 Dual Band Wardriver added 2026-07-20).

A sixth path needs no PC either, but uploads from your phone rather than the board. Biscuit (Pro, Ultra, and the free DIY firmware) pairs to an iOS or Android app that supplies GPS and performs the upload, so the board itself never touches Wi-Fi credentials or a GPS module. Field-verified working across all three variants on 2026-07-25. Hardware detail and citations are in the Biscuit row of §3; it stays there rather than moving here because its firmware is closed source, so unlike the five rows below you cannot read the upload path yourself.

Piglet was wrongly listed as “not found” in §A of v3 — that was a search-term issue (looked for wdgwars piglet instead of hamspiced piglet). Reinstated to §2 as the third confirmed on-device uploader after a Marauder-ecosystem deep-dive surfaced hamspiced/piglet. Raspyjack was similarly reinstated in v4 after the README-only dismissal turned out to miss the payload script.

In development — HellzGate C5. Hellz0wnzJ00/hellzgate is an ESP32-C5 multi-node passive survey array — one master coordinating up to nine scanner nodes over an I²C backplane, dual-band 2.4/5 GHz Wi-Fi + BLE, onboard GPS, microSD, OLED, USB-C — by Hellz (Sean Clossey), a WDGWars Discord mod. Per its README, WiGLE / WDGWars upload is firmware Phase 3 — planned, not yet shipped, and the firmware is proprietary/closed-source (the repo is product info + links only, no releases yet). Listed here so the family is visible; it graduates to the verified table above once on-device upload ships. Site: hellzgate.com.

3. Capture firmwares that need a PC-side feeder

These firmwares produce useful capture data but don’t upload to WDGWars directly. Convert via wigle-to-wdgwars (for WiGLE-compatible CSV) or the slot-typed feeders.

3a. HiroAlleyCat feeders + supporting tooling

The HiroAlleyCat WDGWars family — sibling repos to this one. All Python. The three feeders plus the shared transport library cover the common upload paths.

Active feeders (public)

Shared transport (public)

Observability

3b. Third-party community feeders

Tools authored by people outside LOCOSP and HiroAlleyCat that POST to wdgwars.pl. Every entry here has been verified by reading its README and/or its actual upload code. Vetting depth varies — see the rightmost column.

3c. Reference uploader implementation (the game itself)

The WatchDogsGo game source includes a plugin that is, in effect, the canonical reference for how a WDGWars uploader is supposed to work. Worth reading before writing your own client.

3d. LOCOSP companion firmware

3e. Wider firmware catalog (no native WDGWars upload)

Everything in this subsection wardrives. None of it ships a WDGWars uploader, and that does not keep it off the leaderboard. LOCOSP’s developer page states the general route plainly: POST /api/upload-csv takes a raw WigleWifi-1.6 file as multipart with an X-API-Key header, and “For firmware (Bruce, Kismet, Marauder): CSV method is recommended” (wdgwars.pl/press, read 2026-07-25).

So the rule for this whole subsection: if it writes a WigleWifi-format CSV, you are one upload away. Pull the SD card or the app export, then either run wigle-to-wdgwars or drop the file into the upload form on your wdgwars.pl profile. The 1.4-vs-1.6 column gap is the feeder’s problem, not yours. Where a project’s docs do not actually claim WiGLE-format output, the table says so rather than guessing, because “writes a CSV” and “writes a WigleWifi CSV” are not the same claim.

Star counts and last-push dates below are from gh api repos/<owner>/<repo> on 2026-07-25. They are maturity signals, not endorsements, and none of these projects were driven end-to-end for this pass unless the row says otherwise.

Three projects that would otherwise headline this section are already covered in §3 with fuller detail: HaleHound (CYD, browser flasher), wardriver.uk Rev3 (purpose-built dual-ESP32 rig), and Biscuit (app-mediated, phone supplies GPS and the upload). §3e picks up where that table stops.

Handheld and ESP32 firmware

Single-board computers and Linux rigs

Phone apps

Desktop and laptop capture stacks

Analysis, conversion, and destination databases

Not capture tools. These are what you reach for after the drive.

4. Chip-fit matrix (Marauder, Bruce, GhostESP)

Built from current-release asset binary names (not memory). Every cell traces to an asset in the linked release page. Re-derived 2026-07-25 against Marauder v1.14.0 (2026-07-22), Bruce 1.16 (2026-07-24), and GhostESP Revival v2.0 (2026-06-29). Marauder asset names below have the esp32_marauder_v1_14_0_20260721_ prefix stripped for readability.

The GhostESP column changed meaning in this pass. It used to describe Spooks4576/Ghost_ESP at VA1.4.8, which is now an archived repo (verified via API 2026-07-25, last push 2025-04-22). The column now describes GhostESP-Revival/GhostESP v2.0, which ships 47 board archives. Two cells flipped from “no asset” to yes as a result: ESP32-C5 and Cardputer ADV. If you are running a GhostESP build from before mid-2026 you are on the archived tree, and this column overstates what you have.

2026-08-11 addendum, scoped to two of the reading notes below. The C3 note and the T-Dongle C5 note were written after re-pulling Piglet’s README and LilyGO’s T-Dongle C5 board repo live on that date. The release-asset matrix itself was not re-derived in this pass and still carries its 2026-07-25 derivation, which is why the frontmatter last-verified date stays at 2026-07-25. Re-verify the asset cells before quoting them.

Reading the matrix:

• Want one wildcard board? Classic ESP32-WROOM. All three firmwares support it, and GhostESP Revival alone ships eleven variants of it.
• Best modern target? ESP32-S3. All three support it, PSRAM is common, and it is the chip the Cardputer builds sit on.
• C5 buyers: all three now have assets. This is the cell that moved in 2026, since GhostESP had none at VA1.4.8 and Revival v2.0 ships six. C5 also gets dual-band 2.4 + 5 GHz, but a binary existing is not the same as the 5 GHz radio being used for capture, so verify per firmware before assuming dual-band wardriving.
• C3 buyers: no longer GhostESP-or-nothing. Marauder and Bruce still lack a C3 binary in their current releases, and the GhostESP C3 output lacked BSSID on some commands in the archived tree, which is worth re-testing on Revival v2.0 before depending on it. The other option is Piglet, whose README lists a Seeed XIAO ESP32-C3 under Supported Hardware, selected with board=c3 in /wardriver.cfg or the XIAO C3 entry in the web UI, and auto-detected from the chip model on first boot. It is a purpose-built wardriver that writes WiGLE CSV and uploads to WDGWars itself, so it sidesteps the GhostESP BSSID question rather than solving it. Three caveats from the same README: the C3 is 2.4 GHz only, it has no built-in display (an SSD1306 OLED is optional on D4/D5), and it has no usable button because GPIO 9 collides with SPI MISO. The repo’s own one-line description still advertises only S3, C5, and C6, so treat C3 as a documented but secondary target. A C3 cannot see 5 GHz at all, so it remains the wrong buy for anyone chasing dual-band coverage.
• LilyGO T-Dongle C5 is a compact dual-band capture body with two independent firmware paths. GhostESP Revival v2.0 ships LilyGo-TDongleC5.zip (see the C5 row above), and Piglet ships a standalone port in TDongleC5_Piglet/ that its README describes as a self-contained sketch with its own display driver, LED control, and web UI, so no external OLED is needed. LilyGO’s board repo specs it as an ESP32-C5HR8 with Wi-Fi 6, BLE 5.0, a 0.96” ST7735 display, an SD slot, 16 MB flash, and 8 MB PSRAM.
  • The GPS connector is the load-bearing detail, and it is firmware-attested rather than vendor-confirmed. Piglet’s README says to wire a UART GPS module to the board’s Qwiic/JST connector at RX=GPIO12 / TX=GPIO11. LilyGO’s own pinout table does assign GPIO_11 to UART0_TX and GPIO_12 to UART0_RX, so the pin numbers agree. What neither LilyGO’s board repo nor its product page mentions anywhere is a Qwiic or JST connector, a battery connector, or onboard GPS. Confirm that connector is physically populated from the board photos before buying, and plan on a tethered capture node rather than a standalone rig.
  • Unattended operation is supported. Piglet’s documented config carries maxBootUploads, where -1 uploads all pending files every boot, 0 disables auto-upload so that uploading happens from the web UI instead, and 1+ caps it per boot. A car-mounted unit on switched USB power will boot, upload the previous run, and resume capture with nobody touching it.
  • Mint a device-specific API key for this build. The config lives at /wardriver.cfg on the SD card root, and wdgwarsApiKey= sits in it as plaintext. That is a removable card holding a live credential in an unattended vehicle. A per-device key makes a lost card a one-rig revocation instead of an account compromise.
  • It cannot host the PC-side feeders. It is a microcontroller with no Linux and no CPython, so wigle-to-wdgwars, Muninn, and Heimdall cannot run on it however light the workload looks. If you want one always-on box ingesting from several rigs, that box has to be a Linux machine, and a Pi Zero 2 W class board is the floor.
• C6 buyers: GhostESP has a generic C6 binary and Marauder has the M5 NanoC6. Bruce still has none.
• Bruce 1.16 adds a launcher flavor. Roughly a dozen assets are Bruce-LAUNCHER_* twins of the normal builds, meant for chaining from a firmware launcher instead of booting Bruce directly. Grab the plain build unless you are running bmorcelli/Launcher.

5. M5 Tab5 (purchased high-end option)

Verified specs from Hackster Tab5 Wardriver build:

• Chips: ESP32-P4 (main processor) + ESP32-C6 (WiFi/BT radio)
• Camera: built-in 2 MP SC2356
• GPS: external — M5Stack GPS/BDS Unit with SMA antenna (AT6668 chipset), GPS+BDS+GLONASS, Grove PORT.A
• Released: early 2026
• Caveat (from source): “at the project’s time had minimal documentation and undiscovered firmware bugs”

Price not stated in source. See §6.

6. Hardware tiers (without prices — see why below)

The previous draft cited price tiers (~$20 / ~$55 / ~$110 / ~$200) sourced from a single secondhand pass over ringmast4r’s homebrew page. On direct fetch on 2026-06-02 that page returned “No products found” — so the tier numbers were not actually grounded in a verifiable primary source. They are removed from this version. Pricing on these boards drifts on Aliexpress and Amazon, vendor by vendor, week by week; quote prices only after pulling them live for the specific store the reader will use.

Tiers reframed as form-factor + skill investment:

7. Decision tree for newcomers

flowchart TD
    q1{"Own an Android phone?"}
    q1 -->|Yes| a1["WiGLE app + wigle-to-wdgwars<br/>zero spend · validate the hobby first"]
    q1 -->|"No / want a dedicated device"| q2
    a1 --> q2{"Want zero PC steps<br/>after capture?"}
    q2 -->|"Yes · on-device upload"| a2["M5 Cardputer + GPS + LOCOSP Bruce v1.0-wdgwars<br/>— or — Hak5 Pineapple Pager + u-blox 7 GPS"]
    q2 -->|"No · OK pulling SD / running a feeder"| q3{"What matters most?"}
    q3 -->|"Best capture quality"| a3["Pi 4 + Kismet + monitor-mode USB Wi-Fi + GPS<br/>then wigle-to-wdgwars"]
    q3 -->|"Buying an ESP32 board"| q4{"Which ESP32?"}
    q4 -->|"Broadest firmware support"| e1["Classic ESP32-WROOM or ESP32-S3"]
    q4 -->|"Dual-band 2.4 + 5 GHz"| e2["ESP32-C5 — verify firmware uses the 5 GHz radio"]
    q4 -->|"Bare C3"| e3["Piglet (board=c3) uploads to WDGWars itself<br/>GhostESP is the other stock binary<br/>Marauder / Bruce have none · 2.4 GHz only"]
    q4 -->|"ESP32-H2"| e4["Wrong chip — no Wi-Fi"]
    classDef answer fill:#063312,stroke:#00e436,color:#00e436
    class a1,a2,a3,e1,e2,e3,e4 answer

8. WDGWars-specific gotchas

From WDGWars portal docs + field-tested integrations:

1. One API key = one driver. Putting the same key on two devices = one driver with two feeders, not two contesting drivers. Split-driver attribution needs two keys.
2. Cell grid is 0.02° lat × 0.03° lon. Cron-rebuilds every 5 minutes server-side. Map UI can lag actual state.
3. Read endpoints return caller-scope only. You see your own captures via /api/me/aps?since=; you don’t see who else is in a cell beyond dominant-owner/totals.
4. Cloudflare L7 shield trips on cold-IP bursts to /api/* — 429 + code 1027 BEFORE reaching origin. Use /endpoint/* aliases or pin gungnir >= v0.1.2.
5. Marauder needs GPS attached. Without GPS module, wardrive dumps are empty (memory-only, not re-verified in this pass — flag before recommending).
6. Phone app reporting “wrong password” may be CF 429 on a cold IP, not an auth failure. A single GET to /api/me from a never-seen IP can return 429 instantly with the CF rate-limit body. If the app can’t tell 429 from 401, it may surface CF rate-limiting as bad-credentials. Try again after a minute before assuming the password is wrong.

8.1 Server-side limits, caps, and dedupe behavior

LOCOSP’s documented numbers from the developer section of wdgwars.pl/press, read live 2026-07-25. These were previously undocumented here, which is the kind of omission that turns a working feeder into a 413 at 2 a.m.

Two behaviors worth designing around rather than fighting:

• Big batches should go async. Adding ?async=1 returns 202 plus a job_id immediately and processes server-side, which is how you avoid timeouts on large uploads. LOCOSP’s guidance in the same section is explicit about not hammering retries: stay inside the rate limit and send sequentially.
• Duplicates in a file are fine, and re-scans are not wasted. Multiple beacon captures of the same AP are merged (strongest RSSI wins, GPS averaged) and the response reports merged_samples. Scoring the same AP twice inside an hour does not stack more than once, but the later scan still refines that AP’s position. So there is no reason to dedupe client-side before uploading, and no reason to avoid re-driving your own turf.

The silent skip on the daily cap is the one that will bite hardest, because a 200 response carrying fewer new APs than you sent looks identical to a quiet day of driving. If you are running lab-scale capture (§6 Tier 5), log what you sent against what came back.

9. Known WDGWars feeder gaps

Gaps below are split between things nobody has built and things LOCOSP has said they intend to build. Rows added 2026-07-25 are marked with their source.

Anyone writing a new feeder should read gungnir (Python transport) and LOCOSP’s WatchDogsGo plugins/wardrive_upload.py side by side — those two cover the envelope, HMAC, retry/cooldown, and the slot-typed payload shape. For the read side and a one-place map of the whole surface, see the consolidated WDGWars API reference in wdgwars-discord-stats.

10. Maturity signals — the long-running repos

WDGWars is a 2026 game built on a hobby that is old enough to have reference implementations. This section separates the projects you can lean on from the ones that are simply popular right now. Everything was pulled via gh api repos/<owner>/<repo> on 2026-07-25.

How to read maturity here, in rough order of how much it should move your decision:

1. Last push, not stars. A 9k-star repo that has not been touched in a year is a worse bet than a 200-star repo shipping weekly. Archived is a hard stop.
2. Release cadence. Tagged releases with binaries mean somebody else already ate the build errors.
3. Breadth of hardware targets. Broad target lists mean the maintainer has to keep the build matrix honest, which correlates with the project surviving a chip generation.
4. Whether it is a reference for anything. Kismet, aircrack-ng, and WiGLE’s own app define formats other projects match. That is a different kind of durability from being liked.

Reference-grade (define formats or behavior other projects match)

Large and actively shipping (2026 wave)

Popular but frozen (check before you build on these)

Nothing in this section is a WDGWars uploader by itself. §2 is still the short list for that. This section exists so that when you pick a capture tool you can tell the difference between “old and load-bearing”, “new and moving fast”, and “popular in 2023”.

11. WiGLE — the parent hobby database

WiGLE.net is the long-running community wardriving database that WDGWars’s CSV upload format is derived from. Most of what someone learns capturing for WDGWars is directly portable to WiGLE, and vice versa. Worth understanding the relationship before deciding which platform to feed (or both).

11.1 Relationship to WDGWars

11.2 Practical implications

• Same capture can feed both. If you’re running WiGLE Wifi Wardriving on Android, the .wiglecsv.gz it produces is exactly what wigle-to-wdgwars ingests. One Android session can submit to both platforms.
• WiGLE has a much larger network database. Network ID claim (“first to see” credit) is WiGLE-side. WDGWars doesn’t change that.
• WiGLE has no aircraft / MeshCore slots. ADS-B (Muninn) and MeshCore (Heimdall) are WDGWars-only feeders — WiGLE doesn’t accept those data types.
• WiGLE API is read-heavy, WDGWars API is write-heavy. WiGLE rate-limits queries; WDGWars rate-limits the write path via CF L7 on /api/*.
• WiGLE’s CSV spec is the canonical source for WigleWifi-1.6. api.wigle.net/csvFormat.html — confirmed live 2026-06-02 to define the 14-column header MAC,SSID,AuthMode,FirstSeen,Channel,Frequency,RSSI,CurrentLatitude,CurrentLongitude,AltitudeMeters,AccuracyMeters,RCOIs,MfgrId,Type plus a pre-header device-info row.
• Marauder’s dump format is older. Marauder writes 11-column WigleWifi-1.4 dumps missing Frequency, RCOIs, and MfgrId — verified at WiFiScan.h:682. Any feeder padding Marauder dumps to WigleWifi-1.6 needs to know which columns to fill and with what defaults.

11.3 Submitting to WiGLE directly

If a user just wants to feed WiGLE (not WDGWars), the simplest paths:

1. Phone-only: Install WiGLE Wifi Wardriving from Google Play, sign up at wigle.net, the app uploads automatically when WiFi is available.
2. From a hardware capture rig: SD-pull the WigleWifi-1.6 CSV from your device (Bruce, etc.) and upload via wigle.net’s web upload form.
3. Programmatic: WiGLE has a documented HTTP API at api.wigle.net — see their FAQ for query/submission patterns.

For users feeding both: wigle-to-wdgwars handles the WDGWars side; the same source CSV goes to WiGLE via their own tooling.

11.4 Things WiGLE confirms about WigleWifi-1.6 (for spec verification)

Pulled live from api.wigle.net/csvFormat.html on 2026-06-02:

• Header row: MAC,SSID,AuthMode,FirstSeen,Channel,Frequency,RSSI,CurrentLatitude,CurrentLongitude,AltitudeMeters,AccuracyMeters,RCOIs,MfgrId,Type (14 fields)
• Pre-header device-info row: appRelease, model, device, brand, and planetary-coordinate fields
• Type field is always WIFI for Wi-Fi observations (WiGLE also tracks BT/BLE with different Type values)

A. Editorial notes — common misconceptions and why they’re wrong

Things that look like obvious facts about this ecosystem but turn out to be wrong (or trickier than they look) when you check the source. Kept visible so readers can apply the same scepticism to other claims in the same space.

B. Sources (all fetched live 2026-06-02 unless noted)

Primary:

• LOCOSP/bruce-firmware-wdgwars, tag v1.0-wdgwars
• LOCOSP/pineapple_pager_wdgwars README
• LOCOSP/WatchDogsGo
• LOCOSP/WDGWatch
• justcallmekoko/ESP32Marauder release v1.13.0 (fetched 2026-07-20)
• BruceDevices/firmware release 1.15
• Spooks4576/Ghost_ESP release VA1.4.8
• 7h30th3r0n3/Evil-M5Project README
• justcallmekoko/ESP32DualBandWardriver release v2.3.0 (fetched 2026-07-20)
• JosephHewitt/wardriver_rev3 README — wardriver.uk (fetched 2026-07-20)
• LOCOSP/projectZero README — start_wardrive (fetched 2026-07-20)
• Sil333033/flipperzero-wardriver README (fetched 2026-07-20)
• JesseCHale/HaleHound-CYD release v3.8.0 (fetched 2026-07-20)
• Hellz0wnzJ00/hellzgate README — HellzGate C5 (fetched 2026-07-20)
• Biscuit Shop + Biscuit Wiki — codehedge (fetched 2026-07-20)
• Yggdrasil-AI-labs/gungnir tag v0.1.2
• WiGLE CSV format spec (1.6)
• Hackster — Tab5 Wardriver build

Tertiary (background, not directly cited above):

• ringmast4r — Wonderful World of Wardriving (substack) — general hobby overview
• agucova/awesome-esp — broader ESP curation
• FusedStamen/antenna-database — empirical WiFi antenna SWR measurements (LiteVNA 64), fetched 2026-06-14

WDGWars portal: wdgwars.pl / API help

HiroAlleyCat feeders (this repo’s siblings):

• adsb-to-wdgwars (Muninn)
• meshcore-to-wdgwars (Heimdall)
• wigle-to-wdgwars
• gungnir
• wdgwars-api-tester

Added in the 2026-07-25 pass (all read live that day):

• wdgwars.pl/press — THE GEAR list, developer API section (/api/upload-csv, /api/upload, /api/me, rate limits and daily caps), branding rules, and the YouTube auto-feature mechanism
• biscuitshop.us — Biscuit Pro architecture page and DIY Biscuits board requirements
• JesseCHale/HaleHound-CYD README, flash.halehound.com, halehound.com, segfault.solutions/halehound
• cifertech/ESP32-DIV, 0ct0sec/M5PORKCHOP, GhostESP-Revival/GhostESP READMEs
• JosephHewitt/wardriver_rev3 + wardriver.uk, ElectronicCats/Minino, NSM-Barii/Dooku, NSM-Barii/flock-back
• mjaakko/NeoStumbler, acalcutt/Vistumbler, ghostop14/sparrow-wifi, lozaning/AtomGPS_wigler, cyberartemio/wardriver-pwnagotchi-plugin
• Star counts, last-push dates, and archive flags for every repo in §3e and §10 via gh api repos/<owner>/<repo>

Third-party community tools verified during this pass:

• phutur1st/intercept-wdgwars — intercept PostgreSQL → wdgwars
• DeflockJoplin/pack — Rust P.A.C.K. with Flock detection + wdgwars upload
• InfIux/Wardriving-Log-Aggregation — Marauder v8 log aggregator
• 7h30th3r0n3/Raspyjack payloads/exfiltration/wdgwars_upload.py
• LOCOSP/WatchDogsGo plugins/wardrive_upload.py — reference HMAC implementation