HaleHound · Volume 10
HaleHound Volume 10 — Updates, Upgrades & Ecosystem
The v4.0 release model, the OTA path, the hardware you can bolt on, and where HaleHound sits in the wider CYD-firmware family
10.1 About this Volume
Volume 10 covers everything that happens after a HaleHound is built and flashed: how new firmware reaches the board, which hardware modules extend it and what each one buys, where the firmware came from, and how it relates to the half-dozen other offensive ESP32 firmwares that run on the same Cheap Yellow Display (CYD) hardware. It is the “what next” volume — release cadence, upgrade paths, and ecosystem position — and it is deliberately forward-looking where the sources support it and silent where they do not.
Three threads run through it:
- The software is a single rolling target. There are no point releases to track module-by-module; the web flasher always writes the latest build, and the on-device updater pulls one
.bin. Section 2 and Section 3 explain the mechanics and the one real tradeoff between the two update routes. - The hardware is modular and the ceiling is raised by power amplifiers, not new radios. Sections 4–6 cover the three upgrades that matter — the sub-GHz PA, the 2.4 GHz PA plus the dual-NRF carrier, and the screen/battery options — each with its wiring and power consequences.
- HaleHound is one fork in a crowded family. Sections 7–8 place it against its parent (CiferTech’s ESP32-DIV) and its cousins (Bruce, Ghost ESP, ESP32 Marauder) at reference level, with the licensing contrast that matters: HaleHound is proprietary, almost everything around it is not.
Section 10 closes on the hard limit of the platform — the 2.4 GHz-only ESP32 radio — and names the only route to 5 GHz, which requires different silicon.
Note — Capabilities are referenced here at category level only. For the subsystem breakdown see Vol 8; for the radio wiring that every hardware upgrade in this volume plugs into, see Vol 3; for the two build paths (Classic vs Fire Weasel) see Vols 5 and 6.
10.2 The release model — one rolling build
10.2.1 Version, provenance, and cadence
The current firmware is HaleHound-CYD v4.0, published 2026-10-15. The public repository (github.com/JesseCHale/HaleHound-CYD) was created 2026-02-17 and had accumulated 1,800+ stars by the time v4.0 shipped — a fast-moving, single-author project by Jesse C. Hale (GitHub JesseCHale), sold and distributed through HaleHound.com.
The “v4.0” number is the CYD-edition line. The license text records that the CYD edition ports the earlier ESP32-DIV HaleHound v2.5.0 firmware onto the CYD’s 2.8″ touchscreen form factor and adds the external CC1101, NRF24 and GPS radios over the breakout pins (see Section 7 for the full lineage). The practical consequence for an operator is that the version a HaleHound carries is whatever the flasher wrote on the day it was flashed — there is no long-term support branch to pin to.
HaleHound-CYD release timeline (from repo + README/LICENSE)
═══════════════════════════════════════════════════════════
2023 ──── CiferTech ESP32-DIV (MIT) ............ parent project
│
▼
(pre-CYD) HaleHound for ESP32-DIV v2.5.0 ....... ESP32-DIV form factor
│ ported + radios added
▼
2026-02-17 HaleHound-CYD repo created
2026-10-15 HaleHound-CYD v4.0 ................. current, 1800+ stars10.2.2 What “rolling” means in practice
HaleHound does not ship the module menu as independently versioned plugins. The whole firmware is one image: bootloader, partition table, and application are flashed together, and the web flasher “always the latest build” by design (see Section 3). Capability additions — the modules credited in the README to community contributors, for example, IoT Recon, the Jam Detect suite, and the NRF Tuning panel — arrive folded into the next full build rather than as à-la-carte downloads.
Table 1 — 2.2 What "rolling" means in practice
| Attribute | HaleHound-CYD v4.0 |
|---|---|
| Distribution model | Single rolling binary (bootloader + partitions + app) |
| Where it lives | Official repo .bin + flash.halehound.com only |
| Source code | Proprietary — not published (see Vol 1, Vol 12 §legal) |
| Redistribution | Prohibited outside the repo / official flasher by license |
| Per-module versioning | None — modules ship inside the full build |
| Board targets built | esp32-cyd, esp32-e32r35t, esp32-e32r28t, esp32-cyd-hat |
Warning — The HaleHound proprietary license prohibits hosting mirrors or alternative download locations for the binaries, and prohibits reverse engineering, decompiling, or creating derivative works from them. The firmware is free to flash and run, but it is not open source and may not be redistributed. Do not stand up a private mirror “for convenience.”
10.2.3 What the community shaped
The release notes do not itemise a per-build changelog, but the README’s credits make the project’s development model explicit: features arrive from operators who “use it, break it, and tell me what to build next.” Several of the subsystems that distinguish v4.0 are credited to named contributors, which is the clearest available signal of how the rolling build grows.
Table 2 — 2.3 What the community shaped
| Subsystem in v4.0 | Credited origin | Category (Vol 8) |
|---|---|---|
| IoT Recon (LAN scan + credential brute) | @CircuitZ | SIGINT |
| Jam Detect suite (deauth / carrier / broadband) | @ValleytechSolutions | Defensive |
| NRF Tuning panel (live power/rate/dwell control) | BKBroiler | 2.4 GHz |
| OPSEC framing / Blue Team posture | @ValleytechSolutions, @TalkingSasquach, @Notorious-Squirrel, @Man-In-The-Mayhem, @hamspiced | Project-wide |
The takeaway for an operator tracking the project: new capability shows up folded into the next full flash, not as a module download, and the direction of travel has included more defensive and posture tooling (Jam Detect, Blue Team), not only offensive additions. A board reflashed from the web flasher months apart can gain whole subsystems between flashes.
10.3 The update path — web flasher vs OTA
There are two supported routes to move a board from one build to the next, and they are not interchangeable in the field.
10.3.1 Web Serial flasher (primary)
flash.halehound.com runs in Chrome or Edge on the desktop over the Web Serial API. It writes a complete image in one pass — bootloader, partition table, and application — so it is also the recovery path if a board is in an unknown state. Safari and mobile browsers cannot drive Web Serial and cannot flash. CYD boards use a CH340 USB-serial bridge, so the host must have the CH340 driver (built into Linux kernel 5.x+; a .EXE/.ZIP install on Windows and macOS). Full procedure and troubleshooting are in Vol 7.
10.3.2 OTA from SD (field update)
For a board already in service, Tools ▸ Update Firmware flashes a .bin placed in /firmware/ on the FAT32 microSD. This is the route that does not require a laptop, a cable, or a browser — useful once a unit is sealed in a case and carried. The tradeoff is that OTA applies the application image the operator deliberately staged on the card; the web flasher is what guarantees the latest build including any bootloader/partition changes.
Two update routes, one decision
═══════════════════════════════════════════════════════════════
┌───────────────────────────────┐
Latest everything? ──▶│ flash.halehound.com (Web Serial)│──▶ full image
(laptop + cable) │ bootloader + partitions + app │ recovery-safe
└───────────────────────────────┘
┌───────────────────────────────┐
In the field, no PC ─▶│ Tools ▸ Update Firmware (SD) │──▶ app .bin only
(/firmware/*.bin) │ from /firmware/ on microSD │ operator-staged
└───────────────────────────────┘Table 3 — 3.2 OTA from SD (field update)
| Route | Needs | Writes | Best for | Limitation |
|---|---|---|---|---|
| Web flasher | Desktop Chrome/Edge, data USB, CH340 | Bootloader + partitions + app | New builds, recovery, first flash | Desktop only, no Safari/phone |
| OTA from SD | FAT32 microSD with /firmware/*.bin | Application image | Field refresh on a sealed unit | Operator must stage the correct .bin |
Tip — Keep a known-good
.binon the card’s/firmware/folder before going out. If a field OTA leaves the UI in a bad state, the web flasher is the clean recovery — but that means a laptop. A spare good image on the SD is the lighter insurance.
10.3.3 Reading the installed build
Because there is no per-module versioning, the only authoritative statement of what a given board is running is on the board itself. Settings ▸ Device Info reports heap, CPU, flash, and board name; the About screen shows firmware info plus the armed-module list (which offensive modules are unlocked under the current VALHALLA/Blue Team state — see Vol 8). Before field work, the About screen doubles as a posture check: it confirms both the build and whether the device is in offensive or Blue Team mode.
Table 4 — 3.3 Reading the installed build
| Where | Reports | Use |
|---|---|---|
| Settings ▸ Device Info | Heap, CPU, flash size, board name | Confirm board/target and health |
| About | Firmware info + armed module list | Confirm build + current posture |
| Home-screen banner | VALHALLA / BLUE TEAM | At-a-glance mode |
Note — The board-name field matters when a mixed kit of 2.8″ and 3.5″ units is in play: it confirms the flasher wrote the right target (
esp32-cydvsesp32-e32r35tvsesp32-e32r28tvsesp32-cyd-hat), which in turn dictates the CC1101 CS pin (Vol 3).
10.4 Hardware upgrades — the sub-GHz PA
The single most consequential upgrade is swapping the stock CC1101 for an amplified sub-GHz front end. This is a range upgrade, not a new capability — the band coverage and the module menu are unchanged.
10.4.1 Stock CC1101 vs E07-433M20S
The stock radio is an HW-863 CC1101 breakout running at the firmware’s setPA(12) maximum — about +12 dBm. The optional E07-433M20S is a CC1101 with an integrated 20 dBm power amplifier; it lifts sub-GHz TX to roughly +20 dBm, an ~8 dB jump (a bit more than 6×) in radiated power at the antenna port. The E07 is enabled in firmware under Settings ▸ CC1101 Module (Standard HW-863 ↔ E07 PA).
Table 5 — 4.1 Stock CC1101 vs E07-433M20S
| Item | Stock CC1101 (HW-863) | E07-433M20S (PA) |
|---|---|---|
| TX power (firmware max) | +12 dBm | +20 dBm |
| Extra pins | — | TX_EN (GPIO 4), RX_EN (GPIO 0) |
| Power source | CYD 3.3 V rail OK | Independent 3.3 V buck required |
| Board support for PA mode | n/a | E32R28T / E32R35T only |
| Firmware setting | n/a | Settings ▸ CC1101 Module → E07 PA |
Band coverage does not change: HaleHound’s sub-GHz features are scoped by the firmware to 300–439 MHz regardless of the module. (Note the vendor store lists “300–928 MHz” for the CC1101 silicon’s capability; the firmware’s feature set targets 300–439 MHz. Treat 300–439 MHz as the operating range.)
10.4.2 The independent-buck requirement (non-negotiable)
The Ebyte PA modules draw more current than the CYD’s onboard 3.3 V regulator can supply. Powering an E07 from the CYD’s 3.3 V rail produces brownouts, random resets, and failed radio init. The fix is a separate 5 V→3.3 V buck: tap 5 V from USB VBUS before the CYD regulator, step it down independently, and feed only the module VCC from it. Every signal wire (SCK/MOSI/MISO/CS/GDO0/GDO2/TX_EN/RX_EN) still goes to the ESP32 GPIOs, and all grounds tie together.
E07-433M20S power + signal separation
═══════════════════════════════════════════════════════════════
USB VBUS 5V ──▶ [5V→3.3V BUCK] ──▶ E07 VCC (power: isolated)
(AMS1117-3.3 / MP2307, ≥500 mA) │
└── GND ──┐
ESP32 GPIO 18/23/19 (VSPI) ─────────▶ SCK/MOSI/MISO
ESP32 GPIO 27 or 21 (CS) ───────────▶ CS (signals: straight
ESP32 GPIO 22 / 35 ─────────────────▶ GDO0 / GDO2 to ESP32 GPIO)
ESP32 GPIO 4 / 0 ───────────────────▶ TX_EN / RX_EN
CYD GND ───────────────────────────── common ground ◀──────────┘Warning — “NOT CYD 3.3 V” is written on the wiring diagram in the README for a reason. Sharing the rail is the most common cause of a PA build that fails to initialise the radio. Use a buck rated 500 mA or better and keep a common ground.
See Vol 3 for the complete E07 pinout and the per-board CS-pin difference (GPIO 27 on the 2.8″ E32R28T, GPIO 21 on the 3.5″ E32R35T, because the other pin is the backlight on each).
10.5 Hardware upgrades — the 2.4 GHz PA and dual-NRF carrier
10.5.1 NRF24L01+PA+LNA and the E01-2G4M27SX
The required 2.4 GHz radio is already a NRF24L01+PA+LNA, running at RF24_PA_MAX — about +20 dBm with the PA module. The higher-power Ebyte option is the E01-2G4M27SX, which carries the same independent-buck requirement as the E07: its VCC must come from the separate 3.3 V supply, never the CYD rail, with a common ground. Regardless of module, a 10 µF capacitor across VCC/GND at the module suppresses the random resets that PA+LNA boards are prone to under TX load.
Table 6 — 5.1 NRF24L01+PA+LNA and the E01-2G4M27SX
| 2.4 GHz option | TX (firmware) | Power | Decoupling |
|---|---|---|---|
| NRF24L01+PA+LNA (standard) | +20 dBm (RF24_PA_MAX) | CYD 3.3 V tolerable; buck if unstable | 10 µF across VCC/GND |
| E01-2G4M27SX (Ebyte PA) | higher ceiling | Independent 3.3 V buck required | 10 µF across VCC/GND |
10.5.2 The Cinder Ferret dual-NRF carrier (V2.2)
The Cinder Ferret is the carrier board used in the Classic build path (Vol 5) that mounts the external radios onto an exposed-SPI CYD. It has shipped in three revisions; the current V2.2 adds a second NRF24 slot — the “DOUBLE NRF” configuration. A second 2.4 GHz radio is what makes genuinely concurrent 2.4 GHz operations practical: one NRF24 can hold a channel while the other sweeps, which is the hardware basis for the dual-radio detection work (the drone-detect suite already runs the ESP32 Wi-Fi radio and an NRF24 in parallel on separate cores — see Vol 8).
Table 7 — 5.2 The Cinder Ferret dual-NRF carrier (V2.2)
| Cinder Ferret rev | NRF24 slots | Price (as of 2026-10-16) | Note |
|---|---|---|---|
| V1 | 1 | $30 | Original carrier |
| V2 | 1 | $40 | Revised layout |
| V2.2 “DOUBLE NRF” | 2 | $40 | Second NRF24 slot |
Note — All external radios still share the single VSPI bus (GPIO 18/19/23) with the SD card no matter how many are mounted; the firmware’s SPI manager arbitrates so only one device talks at a time. A second NRF24 adds a second chip-select and antenna, not a second bus. See Vol 3 §VSPI arbitration.
10.6 Hardware upgrades — bigger screen and battery
10.6.1 The 3.5″ screen path
The display is a build-time board choice, not a field upgrade: moving from the 2.8″ ILI9341 (240×320) to the 3.5″ QDtech E32R35T (ST7796, 320×480) means a different board and a different build target (esp32-e32r35t). The firmware’s UI scales automatically between 240×320 and 320×480, so the same build drives either panel; the operator picks the board on the flasher. The 3.5″ gives more screen real estate for the spectrum and equalizer views at the cost of size, and shifts the CC1101 CS pin to GPIO 21 (the 3.5″ uses GPIO 27 as its backlight — the inverse of the 2.8″).
Table 8 — 6.1 The 3.5″ screen path
| Display option | Board / target | Panel | Resolution | CC1101 CS |
|---|---|---|---|---|
| 2.8″ | ESP32-2432S028 / esp32-cyd | ILI9341 | 240×320 | GPIO 27 |
| 2.8″ (QDtech) | E32R28T / esp32-e32r28t | ILI9341 | 240×320 | GPIO 27 |
| 3.5″ (QDtech) | E32R35T / esp32-e32r35t | ST7796 | 320×480 | GPIO 21 |
| 2.8″ Hat | NM-RF-Hat / esp32-cyd-hat | ILI9341 | 240×320 | GPIO 27 |
10.6.2 Battery and boost
Portable operation needs a 1S LiPo plus a boost/charger (a PowerBoost-1000C-class module) to lift the cell’s 3.7 V nominal to the 5 V the CYD expects, and to charge over USB. The complete units ship with no battery installed — a battery is soldered to the BAT+/BAT− pads by the operator. The vendor recommends a large 1S pack (a 3.7 V 5000 mAh 1S with a PH2.0 plug is the listed example) for long field sessions; smaller 1200 mAh packs suit a compact case.
Portable power chain
═══════════════════════════════════════════════════════
[1S LiPo 3.7V] ──▶ [Boost/charger 1000C] ──▶ 5V ──▶ CYD
▲ │
USB charge in └─(for PA builds)─▶
[5V→3.3V buck] ─▶ E07/E01 VCCTip — The PA buck (Sections 4–5) takes its 5 V from the same boosted/USB 5 V rail the CYD runs on, before the CYD’s 3.3 V regulator. Plan the power harness so the buck input and the CYD both see 5 V and everything shares one ground. See Vol 6 for the Fire Weasel power section.
10.7 Lineage — ESP32-DIV and the HaleHound family
10.7.1 The parent: CiferTech ESP32-DIV (MIT, 2023)
HaleHound-CYD is a fork of CiferTech’s ESP32-DIV, released under the MIT license in 2023. ESP32-DIV is an ESP32 “pocket RF multi-tool” with Wi-Fi/BLE/2.4 GHz/sub-GHz analysis on a small display. The HaleHound license preserves ESP32-DIV’s MIT copyright notice verbatim, as MIT requires, and states that the original code “has been extensively rewritten, expanded, and refactored.” The attribution notice also lists the clean-room nature of two HaleHound-authored components — nrf24_raw.h (its own NRF24 driver) and halehound_fft.h (its own FFT), written from public specifications — and notes the firmware contains zero GPL-licensed code.
10.7.2 The step from ESP32-DIV to CYD
The license records the exact move: HaleHound-CYD “ports the full ESP32-DIV HaleHound v2.5.0 firmware to the CYD’s 2.8″ touchscreen form factor, adding external CC1101 SubGHz, NRF24L01+PA+LNA 2.4GHz, and GPS radios via the CYD’s breakout pins.” In other words, the HaleHound application existed on the ESP32-DIV hardware first; the CYD edition re-homes it onto the cheaper, touchscreen CYD and wires the external radios to the CYD’s exposed SPI.
Lineage and license at each hop
═══════════════════════════════════════════════════════════════
CiferTech ESP32-DIV ── MIT (2023) ── open source
│ fork + heavy rewrite
▼
HaleHound (ESP32-DIV, v2.5.0) ── proprietary application layer
│ port to CYD + add CC1101 / NRF24 / GPS over breakout SPI
▼
HaleHound-CYD v4.0 ── proprietary (© 2026 Jesse C. Hale)
preserves ESP32-DIV MIT notice; 0 GPL code10.7.3 Third-party components carried in the binary
The compiled firmware incorporates permissive and LGPL libraries; the license offers LGPL source for three years by pointing to the unmodified upstreams. This matters for anyone auditing the licensing posture — the proprietary wrapper does not override the LGPL rights to those specific components.
Table 9 — 7.3 Third-party components carried in the binary
| Component | Author | License | Role |
|---|---|---|---|
| ESP32 Arduino Core | Espressif | LGPL-2.1 | SoC support |
| RCSwitch | sui77 | LGPL-2.1 | OOK/sub-GHz codes |
| TinyGPSPlus | mikalhart | LGPL-2.1 | NMEA parsing |
| EspSoftwareSerial | plerup | LGPL-2.1 | GPS UART |
| SmartRC-CC1101-Driver-Lib | LSatan | permissive | CC1101 |
| TFT_eSPI | Bodmer | FreeBSD | Display |
| ArduinoJson | bblanchon | MIT | Config/JSON |
| XPT2046_Touchscreen | Stoffregen | MIT | Touch |
| Adafruit PN532 | Adafruit | BSD | NFC |
| ESP-IDF components | Espressif | Apache 2.0 | SoC services |
10.8 The wider CYD-firmware landscape
HaleHound is one of several offensive/experimental firmwares that run on the same ESP32 + CYD hardware. The following is a reference-level map, not a feature-by-feature comparison (Vol 11 does the head-to-heads). The single most useful axis for an operator deciding what to flash is licensing posture and project model, so that is what the table fixes.
Table 10 — 8. The wider CYD-firmware landscape
| Firmware | Model | License | Character |
|---|---|---|---|
| ESP32-DIV (CiferTech) | Parent of HaleHound | MIT | The original ESP32 RF pocket tool HaleHound forked |
| HaleHound-CYD (JesseCHale) | This project | Proprietary | Offensive multi-radio, external CC1101/NRF24/PN532/GPS, touch UI |
| Bruce (pr3y) | Community firmware | Open source | Broad ESP32 offensive multi-tool; runs on many boards incl. CYD/M5Stack |
| Bruce-Smoochie | Bruce fork | Open source | A downstream Bruce variant in the same family |
| Ghost ESP | Community firmware | Open source | Wi-Fi/BLE/sub-GHz suite, originally a Flipper companion, standalone ESP32 builds |
| ESP32 Marauder (JustCallMeKoko) | Community firmware | Open source | The canonical Wi-Fi/BLE pentest firmware; its own hub deep dive |
| SquachWatch-CYD (skizzophrenic) | Same CYD platform | GPL-3.0 | Detector, not offensive — the posture opposite (Vol 11) |
Two points carry across the whole family:
- HaleHound is the odd one out on licensing. Its cousins are MIT/GPL/open; HaleHound’s application layer is closed. That is a deliberate project choice, not an oversight, and it shapes what can be audited, forked, or mirrored (nothing, by the license).
- The hardware is shared, the firmware is not interchangeable mid-session. A CYD is a CYD; what it is at any moment is whatever was last flashed. Switching between HaleHound and, say, Bruce or Marauder is a reflash, not a menu toggle.
Note — Bruce, Ghost ESP and Marauder are described here at a general-knowledge/reference level to position HaleHound. Version numbers and exact feature sets for those projects move independently and are not asserted here. For Marauder specifically, the hub’s ESP32 Marauder Firmware deep dive is the authority.
10.9 Companion-board and backend roadmap
The HaleHound “roadmap” is visible in two places: the hardware the vendor already sells (the carrier/board family) and the stubs the firmware already carries for backends not yet finished.
10.9.1 Hardware carriers (shipping)
HaleHound hardware ecosystem (shipping)
═══════════════════════════════════════════════════════
Classic path ──▶ exposed-SPI CYD + Cinder Ferret carrier + harness
└─ V1 → V2 → V2.2 (adds 2nd NRF24)
Fire Weasel path ▶ integrated radio board + "leash" (~45-min build)
└─ board+leash DIY / fully-assembled / PRO kit
Board target ───▶ NM-RF-Hat (esp32-cyd-hat) — hat-form 2.8″ CYDThe two build architectures (Vols 5–6) run identical firmware; the roadmap is about packaging and radio count, not capability. The Cinder Ferret line’s V2.2 dual-NRF (Section 5.2) is the clearest “next step” item already on the shelf.
10.9.2 Firmware backends (in progress)
The RFID menu is the one subsystem that openly advertises unfinished backends. It opens a backend picker, and three options sit behind it at different maturity:
Table 11 — The RFID menu is the one subsystem that openly advertises unfinished backends. It opens a backend picker, and three options sit behind it at different maturity
| RFID backend | State | What it adds |
|---|---|---|
| PN532 V3 (Elechouse, SPI) | Default, shipping | The full card suite (scan/read/clone/brute/emulate MIFARE) |
| Chameleon Ultra (over BLE) | Shipping | NTAG read/write and mfkey32 key recovery via a BLE-linked Chameleon Ultra |
| ST25R3916 | Stub | Menu wired; the RFAL driver is still in development |
The Chameleon-over-BLE path is notable because it is the clearest example of HaleHound acting as a controller for other hardware rather than doing the work on-board — the HaleHound drives a Chameleon Ultra over BLE for the NFC tasks the PN532 cannot do. Vol 11 treats this in the works-with map; Vol 8 covers it at category level.
Note — The ST25R3916 entry is explicitly a stub in the README (“the menu is wired up, but the RFAL driver is still in development”). It is a roadmap item, not a working backend; do not plan around it until a build lands with the driver.
10.10 The 5 GHz gap — where the platform can and cannot go
10.10.1 The hard limit
HaleHound runs on the classic ESP32 (the ESP32-2432S028 and its QDtech siblings). The classic ESP32’s Wi-Fi radio is 2.4 GHz only. No firmware change moves it to 5 GHz — the limitation is in the silicon’s radio, not the software. Every Wi-Fi capability in HaleHound (scan, deauth, evil-twin/portal, EAPOL/PMKID, beacon work) therefore lives entirely in the 2.4 GHz band. 5 GHz APs and clients are invisible to it.
Band reach by radio on a HaleHound
═══════════════════════════════════════════════════════
ESP32 Wi-Fi ....... 2.4 GHz only ........... [████████░░] no 5 GHz
ESP32 BLE ......... 2.4 GHz ................. [████████░░]
NRF24 (+PA+LNA) ... 2.400–2.525 GHz ........ [████████░░]
CC1101 (+E07 PA) .. 300–439 MHz (firmware) . [sub-GHz]
──────────────────────────────────────────────────────
5 GHz Wi-Fi ....... NOT REACHABLE ........... requires ESP32-C5 silicon10.10.2 The only route to 5 GHz: different silicon
The 5 GHz path on this hardware family is not HaleHound — it is a move to the ESP32-C5, the first dual-band (2.4 + 5 GHz) ESP32 part. In the broader CYD/ESP32 scene the 5 GHz work is appearing on C5-based hardware and firmware: ESP32 Marauder v8 targets the ESP32-C5, and the NM-CYD-C5 is a CYD-form C5 board. Those are the places 5 GHz scanning shows up. HaleHound v4.0 does not target the C5, so a 5 GHz requirement means reaching for C5 hardware and a C5-capable firmware, not a HaleHound setting.
Table 12 — 10.2 The only route to 5 GHz: different silicon
| Need | On HaleHound? | Where it lives instead |
|---|---|---|
| 2.4 GHz Wi-Fi / BLE | Yes (built-in ESP32) | — |
| 2.4 GHz NRF24 ops | Yes (external NRF24) | — |
| Sub-GHz 300–439 MHz | Yes (CC1101/E07) | — |
| 5 GHz Wi-Fi | No | ESP32-C5 boards (NM-CYD-C5) + C5 firmware (Marauder v8) |
Note — A CC1101 is a sub-GHz radio and an NRF24 is a 2.4 GHz radio; neither reaches 5 GHz. There is no external module in the HaleHound BOM that adds a 5 GHz Wi-Fi receiver. 5 GHz is a platform boundary, not a missing accessory.
10.11 Summary and cross-references
- Software is one rolling build. v4.0 (2026-10-15) is the current CYD-edition line; the web flasher always writes the latest full image, and OTA from
/firmware/on the SD is the field route. The firmware is proprietary and must not be mirrored (Vol 1, Vol 12). - Upgrades raise power, not band reach. The E07-433M20S lifts sub-GHz to +20 dBm and the E01-2G4M27SX/NRF24+PA+LNA holds 2.4 GHz at ~+20 dBm — both demanding an independent 3.3 V buck and a common ground (Vol 3). The Cinder Ferret V2.2 adds a second NRF24; the 3.5″ E32R35T is a board/target choice; battery is a 1S LiPo + boost the operator installs (Vol 6).
- Lineage is MIT-parent, proprietary-child. HaleHound-CYD forks CiferTech’s ESP32-DIV (MIT 2023), preserves its notice, and sits beside open cousins (Bruce, Ghost ESP, Marauder) and the GPL detector SquachWatch on the same CYD hardware (Vol 11).
- The ceiling is 2.4 GHz. The classic ESP32 radio cannot do 5 GHz; that path needs ESP32-C5 silicon and C5 firmware, outside HaleHound.
For the capability categories that these upgrades amplify, see Vol 8; for the comparison against SquachWatch, Nyan Box, Marauder, Flipper, Banshee and Chameleon Ultra, see Vol 11; for the field cards, legal envelope and glossary, see Vol 12.
Comments (0)