v5.23.0 - PS Vita link via T-Dongle bridge + node reliability fixes (node v42)

PS Vita companion link is here, running on a T-Dongle-C5 bridge so the core's work with the fleet is untouched. Core v5.23.0, node v42. Also brings the node reliability fixes from the last round to the whole fleet.

New: VITA LINK through a T-Dongle bridge

The WDGWARS Radar app on a PS Vita connects to a T-Dongle-C5 acting as a bridge, not to the Marauder itself. The dongle runs the Wi-Fi network and link server. The core only sends it your position and fleet counters, once a second over the existing cluster link. Running the access point on the core itself was tried first and abandoned: it hung the core and dropped the fleet.

• Setup: flash the T-Dongle with this node firmware. It switches into bridge mode automatically, because it is the only node with the larger flash and a screen. XIAO nodes with the same firmware stay regular collectors.
• Connect: the dongle screen and the Marauder's CLUSTER → VITA LINK screen both show the network name WDG-LINK-XXXX, the password wdgwars-link and a 6-digit PIN. Join that network once in the Vita's Wi-Fi settings, then connect from the Radar and enter the PIN.
• What the Vita gets: live position (marked as estimated when there is no fresh GPS fix), fleet counters, recording state, battery and node count. It also learns whether the dongle still hears the core.
• The fleet is not affected: the bridge is left out of the channel split, out of BLE duty and out of firmware rollouts. Bench test: the Vita paired and streamed, and the core logged 0 lost nodes, 0 restarts and no buffer drops.
• Dongle console: vita shows the bridge status. vita off / vita on switches it between bridge and regular collector (saved, then the dongle restarts).

Node fixes (v42, all nodes)

• No more firmware-update storms. While a core is running, only the core directs node-to-node updates: one at a time, skipping unreachable nodes. Before, every updated node independently kept offering the new image to the same out-of-range node. While doing so a node stopped collecting and dropped out of the core's view, so the core kept reshuffling channels.
• Nodes no longer drop out of the core's view while passing on an update. The keep-alive they send to the core was getting stuck behind the firmware data. It now goes out first.
• USB logging can no longer freeze a node. A node plugged into a computer that was not reading its serial port could stall for minutes.

Which file do I flash?

File	Chip	Offset	When
WDGWMarauderV8-marauder-merged.bin	Marauder V8 (ESP32-C5)	0x0	first install / clean flash — erases NVS + fleet key
WDGWMarauderV8-marauder-app.bin	Marauder V8 (ESP32-C5)	0x10000	in-place upgrade — keeps NVS + fleet key
WDGWMarauderV8-node-merged.bin	XIAO / T-Dongle C5 node	0x0	first install of a node — erases NVS
node_fw.bin	XIAO / T-Dongle C5 node	0x10000	node app only — cable update, or OTA/mesh from the core's SD card

For the Vita bridge: flash the T-Dongle with node_fw.bin at 0x10000 (keeps its fleet key) or with node-merged for a fresh dongle, then adopt it as usual. For the fleet: flash one XIAO by cable, or put node_fw.bin on the core's SD card and use NODE FW → UPDATE ALL. The core's auto mesh brings the rest up to v42.

WDGWMarauderV8-marauder-app.bin SHA-256: 6410f12e310b064ebad68fc6273958e9bc1f4fdf0f90a8f93b7fac7368a9a363

The three portal-served images are covered by SHA256SUMS.txt. Boot tags: core WDGWCOREFW:0005 … v5.23.0, node WDGNODEFW:0042.

v5.22.1 - fix: BLE-duty nodes going silent, no record loss on OTA (node v39)

A node fix release: node v39. The core is unchanged from v5.22.0; its version string is bumped to 5.22.1 so both match. If any of your nodes go silent after a while, update.

Fixed: nodes on BLE duty went silent

A node the core puts on BLE duty is meant to stay on the control channel. Instead, every time its buffer drained, it switched its radio to the first channel of its previous WiFi slice, often a 5 GHz channel, and stayed there. The core never heard it again. Other nodes passing through that channel still did, and its LED showed the "no core" blink. Power-cycling seemed to fix it, until the next time it got BLE duty. A BLE-duty node now stays on the control channel.

There was also no way out of BLE duty. If the core later gave the node a WiFi slice, the node stored the channels but kept doing BLE, and the core kept resending the assignment. A WiFi slice now ends BLE duty.

Bench test: all 8 nodes on v39 and the core hard-reset → all 8 back within 100 s, including the BLE-duty node, each sending its full buffer again.

Fixed: records lost when a node takes a firmware update

A node used to restart into a new image the moment it was written to flash. Its record buffer lives in RAM, so every record not yet delivered was lost (seen live: 47 records). A node now finishes delivering its buffer first, waiting at most 2 minutes, then restarts. If memory is too tight to hold the image alongside unsent records, it declines the update for now; the core or mesh offers it again later.

Mesh: no more re-trying a node that does not answer

A node that ignores a firmware offer, or goes quiet halfway through, is skipped for 10 minutes. Before, the serving node re-offered it every minute and waited on the control channel each time instead of collecting.

Which file do I flash?

File	Chip	Offset	When
WDGWMarauderV8-marauder-merged.bin	Marauder V8 (ESP32-C5)	0x0	first install / clean flash — erases NVS + fleet key
WDGWMarauderV8-marauder-app.bin	Marauder V8 (ESP32-C5)	0x10000	in-place upgrade — keeps NVS + fleet key
WDGWMarauderV8-node-merged.bin	XIAO / T-Dongle C5 node	0x0	first install of a node — erases NVS
node_fw.bin	XIAO / T-Dongle C5 node	0x10000	node app only — cable update, or OTA/mesh from the core's SD card

On v5.22.0 you only need the node: flash one node by cable (or put node_fw.bin on the core's SD card and use NODE FW → UPDATE ALL). The core's auto mesh brings the rest of the fleet up to v39 by itself.

WDGWMarauderV8-marauder-app.bin SHA-256: 21cfd7d558cd417c1695fd2c304b4fd358abd8eb283d75b32e426a72a966f41d

The three portal-served images are covered by SHA256SUMS.txt. Boot tags: core WDGWCOREFW:0005 … v5.22.1, node WDGNODEFW:0039.

v5.22.0 - lossless node->core delivery + automatic mesh rollout (node v37)

A cluster reliability release — core v5.22.0, node v37. If you run a fleet, update both: the node now delivers every record to the core, and the core spreads new node firmware across the fleet by itself.

Fixed: nodes no longer lose records on the way to the core

• Delivery is confirmed, not assumed. A node used to drop a batch from its buffer as soon as ESP-NOW queued it. Any frame lost over the air was gone for good — one of the causes of "the cluster collects badly." Now a batch leaves the buffer only after the core's MAC-level ACK. A lost frame is simply sent again.
• Full resync after every core restart. The core picks a random session ID each time the cluster starts. When a node sees that ID change, it sends its whole retained buffer again. Before this, if the core restarted quickly (under 45 s), the node never noticed it had gone away. It kept sending only new records, so the core's fresh log file got a fraction of the data ("core 8, node 71"). Bench test: core hard-reset in 7 s → node core session … CHANGED -> full resync (31 records) → unsent 0.
• A full node buffer now drops its oldest record instead of refusing new ones.
• The core starts recording on its own as soon as the fleet delivers data.

New: automatic mesh rollout of node firmware

• When the core sees any node on a newer firmware than the rest, it treats that version as current. It then has that node pass the firmware to the most-behind node, one node at a time, with no clicking. A node that does not answer is skipped for 6 minutes, so it cannot block the rest. Console: mesh auto on|off; mesh still forces a round by hand.
• To roll out this release, flash one node by cable (or put node_fw.bin on the core's SD card and use NODE FW → UPDATE ALL). The rest of the fleet then catches up over mesh. v37 talks to v32/v33 nodes and older cores normally while the fleet is mixed.
• NODE FW screen: "current" now means the newest version known anywhere, in the fleet or on the card. An older node_fw.bin on the card no longer marks old nodes as current or suggests a downgrade. A new fleet line shows how many nodes are behind and what the mesh is doing.
• A node that is serving firmware stops after 30 s without progress, for example if the target rebooted or walked away. Before, it sat on the control channel for up to 10 minutes.

Fixed: overheated nodes went deaf (T-Dongle especially)

• In the hottest thermal state (MELT), a node left its radio on whatever channel it was on, often a 5 GHz capture channel. It never heard the core again and kept sending status messages flat out. It now waits on the control channel and stays linked to the core.
• A T-Dongle-C5 node idles around 56 °C plugged into a laptop and was stuck in MELT, collecting nothing. Its temperature limits are now 5 °C higher; XIAO limits are unchanged.
• Hot nodes do not start serving firmware. If a node overheats mid-transfer, it gets 20 s to finish and then hands off.

Which file do I flash?

File	Chip	Offset	When
WDGWMarauderV8-marauder-merged.bin	Marauder V8 (ESP32-C5)	0x0	first install / clean flash — erases NVS + fleet key
WDGWMarauderV8-marauder-app.bin	Marauder V8 (ESP32-C5)	0x10000	in-place upgrade — keeps NVS + fleet key
WDGWMarauderV8-node-merged.bin	XIAO / T-Dongle C5 node	0x0	first install of a node — erases NVS
node_fw.bin	XIAO / T-Dongle C5 node	0x10000	node app only — cable update, or OTA/mesh from the core's SD card

Paired rigs upgrade with app.bin (keeps the fleet key). Already-adopted nodes keep their key when updated with node_fw.bin at 0x10000 or over mesh.

WDGWMarauderV8-marauder-app.bin SHA-256: 781c71ac5515519233fefbb45af1eb0bba71026bb4aa1e7e1783e6a7d397943e

The three portal-served images are covered by SHA256SUMS.txt. Boot tags: core WDGWCOREFW:0005 … v5.22.0, node WDGNODEFW:0037.

v5.21.3 - fix: SCAN ALL now scans BLE (not just WiFi) + restart diagnostics

A core bugfix release. If you run SCAN ALL, update — v5.21.2's core collected only WiFi in ALL. The node firmware is unchanged (still v33, carried 1:1 from v5.21.2).

Fixed: SCAN ALL now actually scans BLE

In ALL mode the rig was collecting only WiFi. With the WiFi capture engine and the NimBLE host both up, free internal RAM fell to ~16 KB (largest contiguous block ~15 KB), and NimBLE's scan start() failed on every BLE slice — so BLE never ran, however long you waited.

The 48 KB TLS reserve (held for the upload handshake, and idle during a scan since SYNC tears BLE down first) is now lent to BLE on scan start and re-reserved on scan stop. Verified live: internal free back to ~65 KB, BLE back to hundreds of adverts per 10 s, zero deaf slices, zero start failures. WiFi capture is unaffected.

New: restart / crash diagnostics

The instability was also reported as "it shows something and restarts." To make that answerable:

• Boot prints the reset reason (POWERON / PANIC / INT_WDT / TASK_WDT / BROWNOUT …) and an RTC breadcrumb — the scan mode, phase, free heap and uptime at the moment of the last reset. On an abnormal reset it also shows a short banner on screen, so a field restart can be reported without a serial cable.
• A [health] line every 10 s while scanning (heap, BLE active/passive, adverts/10 s, WiFi frames/10 s, ALL-slice tallies).
• Per-BLE-slice deaf and start-fail counters.
• A diag serial command for an on-demand dump.

Which file do I flash?

File	Chip	Offset	When
WDGWMarauderV8-marauder-merged.bin	Marauder V8 (ESP32-C5)	0x0	first install / clean flash — erases NVS + fleet key
WDGWMarauderV8-marauder-app.bin	Marauder V8 (ESP32-C5)	0x10000	in-place upgrade — keeps NVS + fleet key
WDGWMarauderV8-node-merged.bin	XIAO / T-Dongle C5 node	0x0	first install of a node — erases NVS
node_fw.bin	XIAO / T-Dongle C5 node	0x10000	node app only — OTA/mesh update from the core's SD card

Paired rigs upgrade with app.bin (keeps the fleet key). The node is unchanged from v5.21.2 — no node re-flash needed if you are already on v33.

WDGWMarauderV8-marauder-app.bin SHA-256: 7b2461dcd68541142f4d4e33727b022d978b188a80de928a2c8bbcfcf659729a

The three portal-served images are covered by SHA256SUMS.txt. Boot tags: core WDGWCOREFW:0005 … v5.21.3, node WDGNODEFW:0033.

v5.21.2 - node v33: T-Dongle-C5 screen + status LED, drone/Lovense alerts, instant capture

A node-focused release. The Marauder core is functionally unchanged from v5.21.1 (its version string is bumped to 5.21.2 for parity); the work is in the node firmware, now v33.

What's new (node v33)

LilyGO T-Dongle-C5 is now a first-class node — with its own screen.
The same node image runs headless on a Seeed XIAO C5 and, on a T-Dongle-C5, lights up its 0.96" ST7735 as a live fleet monitor: die temperature, this node's WiFi/BLE counts, core link, channel slice and the peers it hears. Detection is automatic from the physical flash size, so a XIAO is never touched.

Status LED (T-Dongle APA102).

• No core link → white blink (searching).
• Linked to the core → steady dim white (calm, no blink).
• A nearby threat → steady colour for ~5 s: Flipper orange, camera glasses green, Lovense pink (BLE duty); deauth yellow, Pwnagotchi cyan, drone Remote ID/DJI red (WiFi duty).

On the T-Dongle's early hardware revision the APA102 sits on the screen's SPI bus with no chip-select, so it is driven over that shared bus and refreshed after each screen paint — no more stray colours from UI pixels.

Adopted nodes capture immediately.
A node that already holds the fleet key no longer waits to hear the core before it starts collecting: it fills its buffer right away and forwards everything the moment the core is reachable again, while still returning to the control channel to re-establish the link. A never-adopted node still holds the control channel so pairing stays reliable.

More reliable pairing (carried from earlier in this line): an unadopted node holds the control channel instead of hopping, so the core hears its join request on the first try.

Which file do I flash?

File	Chip	Offset	When
WDGWMarauderV8-marauder-merged.bin	Marauder V8 (ESP32-C5)	0x0	first install / clean flash — erases NVS + fleet key
WDGWMarauderV8-marauder-app.bin	Marauder V8 (ESP32-C5)	0x10000	in-place upgrade — keeps NVS + fleet key
WDGWMarauderV8-node-merged.bin	XIAO / T-Dongle C5 node	0x0	first install of a node — erases NVS
node_fw.bin	XIAO / T-Dongle C5 node	0x10000	node app only — OTA/mesh update from the core's SD card

Paired rigs upgrade with the app.bin (keeps the fleet key). Nodes update over the air: drop node_fw.bin on the core's card and the fleet pulls v33 by mesh.

WDGWMarauderV8-marauder-app.bin SHA-256: 6c81ef16f374e07f4a017a0d9d48724a6b373bac2bb0d7f4b7b37f3d3dbfc7d8

The three portal-served images are covered by SHA256SUMS.txt (shasum -a 256 -c SHA256SUMS.txt). Both images print their version on boot: core WDGWCOREFW:0005 … v5.21.2, node WDGNODEFW:0033.

v5.21.1 - hotfix: BLE scanning dead in v5.21.0

WDGoWars Marauder V8 (C5) — core v5.21.1 (hotfix)

Fixes a BLE regression in v5.21.0. If you flashed v5.21.0, update to this.

The bug

A memory seatbelt added in v5.21.0 tripped far too early (at 24 KB free). The rig
normally runs with ~25 KB free, so the guard latched on at boot and the Bluetooth
scanner dropped every advert before it reached the device list — BLE looked
completely dead (nothing in BT SCAN, no BLE rows while wardriving in ALL mode),
even though the radio was still receiving (170+ adverts/s). Now the guard only
engages near real exhaustion. Verified: BT SCAN lists devices again.

Everything else is identical to v5.21.0 (the ~365 KB flash reclaim, the dirty-row
blit, the HUB radar capped at 25 fps, the frame profiler, adaptive active/passive
BLE, and the v5.20.0 alert set).

Which file do I flash?

File	Flash to	Use when	NVS / fleet key
WDGWMarauderV8-marauder-merged.bin	0x0 (full image)	First install / recovery / web flasher	Erased
WDGWMarauderV8-marauder-app.bin	0x10000 (app only)	In-place update of an existing rig	Kept

Most people updating want -marauder-app.bin.

esptool --chip esp32c5 --baud 115200 write-flash 0x10000 WDGWMarauderV8-marauder-app.bin

Node firmware

Unchanged — carried over from v5.20.0.

Checksums

SHA256SUMS.txt covers the three portal-served images. -marauder-app.bin sha256:
479b1938c2eff363cd99be49ebc098ed5e47d2132d2bb4f02cd108e242dc97ce

v5.21.0 - leaner: 365 KB flash reclaimed, smoother draw, steadier BLE

WDGoWars Marauder V8 (C5) — core v5.21.0

Performance & stability pass — no new screens, the firmware just runs leaner.

Techniques adapted (reimplemented, not copied) from the open-source SquachWatch-CYD.

What's new

• ~365 KB of flash reclaimed (app image 93% → 81% full). The three full-screen
  backgrounds (FOX HUNT, POI NAV, POI ARRIVED) are now stored compressed and inflated at
  runtime — same look, far less flash, so there is finally headroom for new features.
• Smoother drawing under load. The blit now pushes only the screen rows that actually
  changed, so animated screens hand more radio/CPU time back to scanning on the single-core C5.
• Steadier in a BLE crowd. Two seatbelts stop a dense Bluetooth environment from
  exhausting memory: the scan drops adverts rather than allocate when RAM runs low, and it
  automatically switches to a lighter passive scan when the air gets very busy (and back when
  it quietens). Detection of Flipper, drones, camera glasses and Pwnagotchi keeps working in
  passive mode.
• New serial diagnostics for tuning: prof (per-10 s frame/loop timing), blemode auto|active|passive, blecount.

Everything from v5.20.0 (DEAUTH / EVIL TWIN / camera-glasses alerts, the ALL-scan fix,
the earlier nearby-device alerts) is included.

Which file do I flash?

File	Flash to	Use when	NVS / fleet key
WDGWMarauderV8-marauder-merged.bin	0x0 (full image)	First install / recovery / web flasher	Erased
WDGWMarauderV8-marauder-app.bin	0x10000 (app only)	In-place update of an existing rig	Kept

Most people updating an existing device want -marauder-app.bin.

esptool --chip esp32c5 --baud 115200 write-flash 0x10000 WDGWMarauderV8-marauder-app.bin

Node firmware

Unchanged — carried over from v5.20.0.

Checksums

SHA256SUMS.txt covers the three portal-served images (two -merged + node_fw).
WDGWMarauderV8-marauder-app.bin sha256:
44cca86b1a03c0524dd34dc2945554a7852c16e4e5ed1c11d4939250bca7c080

v5.20.0 - DEAUTH / EVIL TWIN / camera-glasses alerts + ALL-scan fix

WDGoWars Marauder V8 (C5) — core v5.20.0

Three new "something's near you" alerts, and ALL-mode scanning fixed.

What's new

• DEAUTH alert 🟡 — warns you when someone is flooding deauth/disassociation
  frames to knock a Wi-Fi network offline near you. One normal disconnect never fires
  it — only a real burst.
• EVIL TWIN alert 🟣 — warns you when one network name is being beaconed from two
  different access points that disagree about encryption (a classic rogue clone).
• CAMERA GLASSES alert 🟢 — warns you when recording smart glasses (Ray-Ban Meta,
  Snap Spectacles) are advertising nearby.
• All three behave like the existing nearby-device alerts: a colour flash, then a
  full-screen alert with its own gorilla art that waits until you tap GOT IT — and it
  survives the screen blanking, so an alert raised while the display is asleep shows up
  the moment you wake it.
• ALL scanning fixed. On the single C5 radio, Wi-Fi and BLE now take turns, so
  SCAN → ALL really collects both at once again. SCAN → WIFI and SCAN → BLE are each
  at full speed. (Earlier builds let BLE go nearly deaf during ALL — a Flipper beside the
  rig could go unseen on a whole drive.)

Alerts at a glance

Which scan hears what: Wi-Fi-borne alerts (DEAUTH, EVIL TWIN, Pwnagotchi, Wi-Fi drones)
need a scan that listens to Wi-Fi (WIFI or ALL); BLE-borne alerts (Flipper, camera
glasses, adult toy, BLE drones) work in any scan that uses BLE (BLE, BT SCAN, ALL).

Which file do I flash?

File	Flash to	Use when	NVS / fleet key
WDGWMarauderV8-marauder-merged.bin	0x0 (full image)	First install / recovery / web flasher	Erased
WDGWMarauderV8-marauder-app.bin	0x10000 (app only)	In-place update of an existing rig	Kept

Most people updating an existing device want -marauder-app.bin — it preserves the
fleet key and all settings.

esptool --chip esp32c5 --baud 115200 write-flash 0x10000 WDGWMarauderV8-marauder-app.bin

Gallery

Real screenshots from the device — DEAUTH, EVIL TWIN, CAMERA GLASSES:

Node firmware

Unchanged — carried over from v5.19.1.

Checksums

SHA256SUMS.txt covers the three portal-served images (two -merged + node_fw).
WDGWMarauderV8-marauder-app.bin sha256:
ebfb38a90eba55a97ccd4a405c6db8a1bb8773120ff4d17348ca980a2f36dd34

v5.19.1 - FIELD title fix, screenshots, alert demo

WDGoWars Marauder V8 (C5) — core v5.19.1

Small follow-up to v5.19.0.

What's new

• FIELD title fixed — the top bar shows the full "WDG // FIELD" again. The cluster
  indicator moved into the gap before the WiFi icon and is now a compact CL with a dot
  (cyan = recording, amber = waiting for START).
• Real screenshots over USB — the firmware keeps a copy of the screen, so the whole UI can
  be captured pixel-perfect from a computer (serial ui <screen> + screenshot).
• Alert demo — serial alertdemo plays all four nearby-device alerts in a row (GOT IT
  moves to the next), handy for showing the screens off.

Gallery

Photos of the alerts on a real Marauder V8 (the Flipper one is a live detection — its name and MAC are blurred; the others are the built-in demo).

Flipper Zero	Pwnagotchi	Drone	Adult toy

Known issue

In SCAN → ALL, BLE still hears far fewer devices than in BT SCAN, so BLE alerts (e.g.
Flipper) can be missed in ALL. Use BT SCAN or SCAN → BLE for them. Under investigation.

Which file do I flash?

File	Flash to	Use when	NVS / fleet key
WDGWMarauderV8-marauder-merged.bin	0x0 (full image)	First install / recovery / web flasher	Erased
WDGWMarauderV8-marauder-app.bin	0x10000 (app only)	In-place update of an existing rig	Kept

Most people updating an existing device want -marauder-app.bin — it preserves the
fleet key and all settings.

esptool --chip esp32c5 --baud 115200 write-flash 0x10000 WDGWMarauderV8-marauder-app.bin

Node firmware

Unchanged — WDGWMarauderV8-node-merged.bin and node_fw.bin are carried over from
v5.19.0 as-is.

Checksums

SHA256SUMS.txt covers the three portal-served images (two -merged + node_fw).
WDGWMarauderV8-marauder-app.bin sha256:
8429b96d474eb8fec176550bbed9f6e85955bfe1d6df97ce9ff0b4a1c65fb5fe

v5.19.0 - Nearby-device alerts + RING TAG screen

WDGoWars Marauder V8 (C5) — core v5.19.0

"Something's nearby" alerts with gorilla art, and a new RING TAG screen.

What's new

• Nearby-device alerts. When a new device of one of these kinds shows up, the screen
  flashes in its colour, then a full-screen alert with its own pixel-art gorilla stays up
  until you tap GOT IT. If the display is asleep, the alert waits and appears right
  after you wake it. Several alerts queue up; each device alerts once per session.
  • 🟠 Flipper Zero — recognised from its BLE advertising frame, not its name, so
    renamed Flippers are caught too. The alert shows the body colour (black / white / clear).
  • 🔵 Pwnagotchi — recognised from its WiFi beacon.
  • 🔴 Drone — Open Drone ID (WiFi beacon or BLE) and DJI drones.
  • 🩷 Adult toy — new art; the FIELD-screen AT counter matches its colour.
    BLE-based alerts work in every scan that uses BLE; Pwnagotchi and WiFi drone alerts need
    a scan that listens to WiFi (WIFI or ALL).
• RING TAG has its own banner (the gorilla listening in a neon alley), status text on
  the art, and sound-wave arcs pulsing out of the tracker when a ring is confirmed.
• Colours tidied up. RING TAG tile and the BLE signal dots now use the WDG palette
  (purple → magenta → cyan); orange/red are kept for alarms.
• SCAN → ALL splits the radio evenly: WiFi and BLE now take turns.
• Fixes: a crash that could happen when an alert was raised, and a memory-safety issue in
  the wardrive BLE path.

Gallery

Photos of the alerts on a real Marauder V8 (the Flipper one is a live detection — its name and MAC are blurred; the others are the built-in demo).

Flipper Zero	Pwnagotchi	Drone	Adult toy

Known issue

In SCAN → ALL, BLE currently hears far fewer devices than in BT SCAN, so BLE alerts
(e.g. Flipper) can be missed in ALL. Use BT SCAN or SCAN → BLE if you want them
reliably. Under investigation.

Which file do I flash?

File	Flash to	Use when	NVS / fleet key
WDGWMarauderV8-marauder-merged.bin	0x0 (full image)	First install / recovery / web flasher	Erased
WDGWMarauderV8-marauder-app.bin	0x10000 (app only)	In-place update of an existing rig	Kept

Most people updating an existing device want -marauder-app.bin — it preserves the
fleet key and all settings.

esptool --chip esp32c5 --baud 115200 write-flash 0x10000 WDGWMarauderV8-marauder-app.bin

Node firmware

Unchanged — WDGWMarauderV8-node-merged.bin and node_fw.bin are carried over from
v5.18.0 as-is.

Checksums

SHA256SUMS.txt covers the three portal-served images (two -merged + node_fw).
WDGWMarauderV8-marauder-app.bin sha256:
451e0521bf7e5efea6b8735658fcd28af0c78a251b220d35bf879fb72dd3a7d3