OpenSourceSDRLab PortaRF · Volume 2
OpenSourceSDRLab PortaRF Volume 2 — Hardware (HackRF Silicon + Integration Deltas)
Clifford Heath modified HackRF silicon + PortaPack-class UI board + integrated battery + single-box mechanical design
Contents
1. About this volume
Vol 2 walks the PortaRF hardware, with deliberate asymmetry of attention:
- The RF silicon is identical to the HackRF One — this volume cross-references
../../../HackRF One/03-outputs/HackRF_One_Complete.htmlVol 2 rather than re-authoring schematic-level walkthrough. - The PortaRF-specific content is everything around the SDR core — the PortaPack-class UI board, the integrated battery + charge subsystem, the single-box mechanical design, the OpenSourceSDRLab revision conventions. Those are this volume’s center of gravity.
This is the §1.2 sibling-project cross-reference pattern in action — the deep-dive protocol’s discipline for derivative tools. The reader is assumed to have already absorbed HackRF One Vols 2–3 before getting here; if not, stop and read HackRF One Vol 2 first, then come back.
The PortaRF specs in this volume are research-baseline as of 2026-05-13. Every hardware claim that isn’t inherited directly from the HackRF One silicon spec sheet is hypothesis pending vendor confirmation. The pre-purchase + on-arrival checklist in § 10 is the path from hypothesis to confirmed fact.
2. HackRF silicon — same as HackRF One
Cross-reference: ../../../HackRF One/03-outputs/HackRF_One_Complete.html Vol 2 covers the HackRF silicon in full schematic-grade detail. The PortaRF inherits all of it. Capsule recap:
| Component | Function | Notes |
|---|---|---|
| MAX2837 | RF transceiver (2.3-2.5 GHz native, mixed with RFFC5072 for 1 MHz - 6 GHz) | Same as HackRF One |
| RFFC5072 | Wideband synthesizer / mixer | Same as HackRF One |
| MAX5864 | 8-bit ADC/DAC pair (20 MS/s max) | Same as HackRF One |
| LPC4320 | ARM Cortex-M4 (Cortex-M0 + Cortex-M4 dual-core) — runs HackRF firmware | Same as HackRF One |
| Si5351 | Clock generator | Same as HackRF One |
| XC2C64A | Coolrunner-II CPLD (glue logic for the RF subsystem) | Same as HackRF One |
| MGA-81563-TR1G OR TRF37B73 | MMIC amplifiers (Heath modification replaces with TRF37B73) | See § 3 |
| SKY13350-385LF OR SKY13453-385LF | RF switches (Heath modification replaces with SKY13453-385LF) | See § 3 |
| (no protection chip) OR CLA4611-085LF | Antenna protection (Heath addition) | See § 3 |
The PortaRF runs all the same silicon as a HackRF One r4 / r5 / r6 / r8 / r10 / r10+ / H4M. The half-duplex limit, the 20 MS/s sample-rate ceiling, the +15 dBm TX power ceiling, the noise floor (-85 dBm typical), the 8-bit ADC quantization noise floor — all inherited unchanged.

The HackRF revision OpenSourceSDRLab ships into PortaRF is most likely R10 / R10+ class (the current Heath-modified board lineage with USB-C and the modern RF front end). Verifying this on the actual product is § 7’s job; until then, treat “R10-class Heath silicon” as the working assumption.
What this means practically: every command, every workflow, every signal-decode recipe that works against porta’s HackRF One r4 + PortaPack H2+ stack works against a PortaRF unchanged. The hackrf_* tool catalog (Vol 7), the GNU Radio source blocks, the Mayhem app catalog — none of it changes. This is the load-bearing reason PortaRF is “duplicate capability of porta” rather than “new capability” — Vol 1 § 5’s verdict.
3. Clifford Heath modifications detail
The Heath modifications are the single hardware-level differentiator between OpenSourceSDRLab’s PortaRF and a stock-GSG HackRF One. They’re worth understanding in detail because the practical implication for PortaRF operators is non-trivial.
Cross-reference: ../../../HackRF One/02-inputs/volume_sources/vol1.md § 3 is the canonical reference for Heath’s modifications, their rationale, the testing controversy, and the part substitutions. PortaRF context recap:
3.1 The four modifications
| Original GSG part | Heath replacement | Function | Why it matters |
|---|---|---|---|
| (no antenna protection) | CLA4611-085LF | Clamps RF input transients; blocks reverse-power damage | The unambiguous practical win; the #1 LNA-blow vector is “TX into wrong antenna” — protection chip mitigates |
| MGA-81563-TR1G | TRF37B73 | MMIC amplifier (TX final stage + RX LNA) | Newer Texas Instruments part; community reports of slightly better noise floor and higher TX output, but no standardized testing |
| SKY13350-385LF | SKY13453-385LF | RF switches (TX/RX path multiplexing) | Newer Skyworks; same switches GSG eventually moved to in r6/r8/r10 — Heath got there first |
| Original Bias-T | Improved | Phantom-power for active antennas / external LNAs | Better high-frequency response; lower noise contribution when disabled |
The signal-path silicon downstream of these front-end parts — MAX2837, RFFC5072, MAX5864, LPC4320, Si5351, XC2C64A — is identical to a stock HackRF One. Heath’s mods are RF-front-end-only.
3.2 What the protection chip actually does
The CLA4611-085LF is a Skyworks PIN-diode limiter — it sits across the antenna feed between the SMA connector and the first RF stage. Under normal RF input the diode is high-impedance and the signal passes through with negligible loss. When input power exceeds ~+10 dBm (or there’s a high-voltage transient), the diode goes low-impedance and clamps the input to a safe level.
The practical scenarios it protects against:
- TX-into-mismatched-antenna — wrong-band antenna or open SMA reflects TX power back into the LNA path. Without protection, the LNA gate gets cooked. With CLA4611-085LF, the reflected energy gets clamped before reaching the LNA.
- Strong adjacent emitters — standing next to a high-power transmitter (Wi-Fi AP, FM broadcast tower, ham repeater on the same band) feeds RF directly into the LNA. The protection diode clamps before damage.
- Static-discharge transients — touching an antenna after walking across carpet can deliver enough ESD to damage the LNA. Protection diode dissipates the transient.
It does not protect against: hot-swapping the antenna while TX is active (the protection sees TX-side current, not RX-side), wire-cutter-grade damage (someone shorts the SMA pin to ground), or sustained high RF input (the diode is a transient-clamp, not a power-sink).
For PortaRF operators specifically: the integrated form factor means antennas get swapped less often than a bench HackRF setup, but field operation exposes the unit to more strong emitters (you’re near things — building Wi-Fi, transit RF infrastructure, ham radio QSOs). The protection chip is more practically valuable in handheld deployment than in lab use.
3.3 The sensitivity testing controversy
The Mayhem firmware wiki maintains a page on Heath’s design with mixed community sensitivity reports. Some users measure better RX sensitivity than stock GSG; others measure the same or worse. There is no standardized testing methodology that resolves this.
The honest position: Heath’s design is a robustness upgrade, not a performance upgrade. The protection chip is the load-bearing benefit. Treat any sensitivity claims (Heath or otherwise) as anecdotal until you’ve run a side-by-side calibrated A/B test on the same antenna, against the same signal, with the same firmware and PC setup.
For PortaRF, this means: do not expect the unit to outperform porta at narrowband reception. Do expect it to survive operator mistakes that would brick porta.
3.4 How to confirm Heath silicon visually
On the HackRF main board, the Heath modifications are small SMD parts in the antenna-SMA region:
- CLA4611-085LF: 3 × 1.5 mm SOT-323 package, just inside the SMA connector
- TRF37B73: SOT-89-3 or QFN package, near the RF switching block
- SKY13453-385LF: 16-pin QFN, the RF switch silicon itself
- Improved Bias-T: a slightly different component arrangement around the bias-injection point — visible only if comparing side-by-side against a stock GSG PCB
Realistically: on the PortaRF the HackRF board is inside the sealed enclosure and not visible without disassembly. The trustworthy confirmation paths are (1) vendor product page explicitly lists Heath silicon, (2) hackrf_info output (some Heath-modified firmware identifies itself), or (3) a teardown video / community confirmation. § 10 covers the on-arrival check.
4. PortaPack-class UI board
The PortaPack-class UI board is half of what makes PortaRF a PortaRF — the display + controls that turn a USB-tethered SDR into a standalone handheld. Understanding which PortaPack revision OpenSourceSDRLab integrated determines what Mayhem features are available, what the keyboard layout is, and whether tjscientist’s porta-tested workflows port directly.
4.1 PortaPack revision lineage
| Revision | Display | Input | Status | Notes |
|---|---|---|---|---|
| H1 | 240×320 TFT (ILI9341) | Buttons + encoder | Legacy | First-generation; small community |
| H1+ | 240×320 TFT (ILI9341) | Buttons + encoder | Common | Refinement; mostly retired |
| H2 | 240×320 TFT (ST7789) | Buttons + encoder | Common | Sharkrf community revision |
| H2+ | 240×320 TFT (ST7789) | Buttons + encoder | Most common in DIY stacks | What porta runs. Backlight brightness improved; Mayhem feature-complete here |
| H4M | 240×320 TFT (ST7789P3) | Buttons + encoder, optional QWERTY | Premium variant | ”Clifford Edition” adds Heath HackRF modifications to the carrier board itself |
PortaRF’s PortaPack revision is unconfirmed as of 2026-05-13. Vendor-page verification is § 10’s job. The two plausible candidates:
- H2+: the cost-optimized PortaRF would use this — same panel as the H2+ porta runs. All porta Mayhem firmware ports directly.
- H4M (or H4M Clifford Edition): the premium PortaRF would use this — newer display controller (ST7789P3), possibly with QWERTY keyboard, possibly with Heath modifications baked into the carrier PCB itself (rather than the HackRF board below it).
The “Clifford Edition” naming on H4M is worth understanding: it means the PortaPack carrier PCB itself has been modified to incorporate Heath’s RF front-end improvements directly, rather than relying on a Heath-modified HackRF below it. In that variant the HackRF board can be a stock GSG part — the Heath silicon sits on the PortaPack rather than the HackRF.
If PortaRF ships H4M Clifford Edition: Heath silicon location is the PortaPack PCB. If PortaRF ships H2+ with Heath HackRF: Heath silicon location is the HackRF PCB. Either way the operator gets the protection chip; the location just determines which board to inspect if a teardown is ever needed.
4.2 Display controller details
Most PortaPack revisions use one of these TFT controllers:
| Controller | Resolution | Bus | Notes |
|---|---|---|---|
| ILI9341 | 240×320 | SPI (4-wire) | Legacy H1 / H1+ |
| ST7789 | 240×320 | SPI (4-wire) | H2 / H2+ |
| ST7789P3 | 240×320 | SPI (4-wire) | H4M; same software-interface as ST7789 with minor command differences |
Mayhem firmware autodetects the controller in current revisions, so the display driver doesn’t usually need explicit configuration. The driver detection happens at boot — if a Mayhem build doesn’t paint the display correctly on PortaRF, the controller mismatch is the first thing to check.
Display backlight is PWM-controlled (likely via the PortaPack’s STM32 or a discrete MOSFET driver). Mayhem exposes brightness in the Settings menu; PortaRF should inherit the same control unchanged.
4.3 Input subsystem
Standard PortaPack input topology, almost certainly inherited unchanged by PortaRF:
- 5-way directional input — typically a 4-direction D-pad + center-press, or a 4-button cluster + dedicated center button
- Rotary encoder with push-button (used for frequency tuning, gain adjustment, parameter scrolling)
- Dedicated buttons: typically Back / Menu / Select (3 buttons), sometimes a “Dynamic” softkey
- Optional QWERTY keyboard (H4M only, if equipped): membrane keyboard for entering frequencies, file names, regex patterns in capture modes
For a typical Mayhem workflow on PortaRF: D-pad navigates menus, encoder adjusts the active parameter (frequency, gain, mode), select-button enters a sub-menu, back-button exits. The QWERTY (if present) speeds up frequency entry and file-naming significantly — meaningful for capture-heavy workflows.
4.4 What changes vs porta’s H2+
Practically, if PortaRF ships an H2+: nothing changes. Porta workflows port directly.
If PortaRF ships H4M Clifford Edition: the differences are:
- Display controller is ST7789P3 — Mayhem handles this transparently, but custom firmware development (Vol 10) may need updated init code.
- QWERTY keyboard (if equipped) — Mayhem firmware needs the H4M build variant, not the H2+ build. The pre-built Mayhem release for H4M is selected by the SD-card filename convention.
- Possible touch-screen overlay — some H4M variants have a resistive touch layer; verify on vendor page.
- Heath modifications on the PortaPack PCB — if the PortaPack itself is Heath-modified, see § 3.
Either way, the operator UI experience on PortaRF should be near-identical to porta. The Mayhem feature catalog is what tjscientist already knows.
5. Integrated battery + power management
The integrated battery is the other half of what makes PortaRF a PortaRF — the difference between “HackRF stack on a bench” and “HackRF in a pocket.” Understanding the battery subsystem matters for field deployment planning (Vol 5 covers the operational power profile; Vol 11 covers field-engagement posture).
5.1 Likely battery configuration
The PortaRF battery is almost certainly a single-cell LiPo in the 1500–3000 mAh range, with USB-C charging at ~1 A and a TP4056-class charge controller. This matches the vendor pattern for PortaPack handheld products from this lineage (AWOK, M5Stack, Clockwork all follow similar patterns at similar form factors).
| Aspect | Likely value | Confidence | Notes |
|---|---|---|---|
| Battery chemistry | LiPo (single cell, 3.7 V nominal / 4.2 V max) | High | Industry standard for handhelds |
| Capacity | 1500-3000 mAh | Medium | Vendor sizing decision; 2000 mAh typical for this form factor |
| Charge controller IC | TP4056-class (or MCP73831 variant) | High | Linear single-cell charger, ubiquitous |
| Charge rate | ~1 A USB-C input | High | TP4056 default; charges a 2000 mAh battery in ~2.5 hours |
| Discharge rate | ~2 A peak during TX bursts | High | TX final stage current draw |
| Battery management IC | TBD — likely just charge controller + protection IC, not a separate BMS | Medium | Cost-optimized handhelds rarely have dedicated BMS |
| Battery telemetry | Yes (Mayhem displays %) | High | Likely ADC-read of battery voltage, mapped to % via discharge curve |
| Replaceability | Internal (sealed enclosure) | Medium | Probably requires disassembly for battery swap |
Full power profile under each operating mode (RX continuous, TX burst, sweep, capture) is Vol 5’s center of gravity. The hardware-level points here are:
5.2 Charge-while-operating
USB-C input feeds the charge controller; the charge controller’s output feeds both the system load and the battery. This is standard handheld topology:
- When USB power is connected and the battery is full: system runs on USB power.
- When USB power is connected and the battery is charging: system runs on USB power, excess current charges the battery (charge rate is reduced when system draws current).
- When USB power is disconnected: system runs on battery only.
Practical implication: PortaRF should support continuous operation from a USB-C battery pack — connect a 10,000 mAh USB-C power bank, and the unit runs essentially indefinitely (limited by power bank capacity, not internal battery). This is the recommended pattern for any engagement >4 hours.
5.3 Battery health considerations
LiPo cells in handhelds degrade based on (1) deep-discharge cycles, (2) sustained high temperatures, (3) high charge currents at low voltage, (4) overall age. PortaRF-specific considerations:
- Sustained TX heats the case, which heats the battery — limit continuous TX duty cycle in hot ambient conditions
- Storage at full charge for months degrades capacity faster than storage at ~50% charge — if the unit will sit for >2 weeks unused, discharge to ~50% first
- USB-C charging current of 1 A on a 2000 mAh cell is 0.5C — reasonable, not aggressive; doesn’t accelerate degradation significantly
- No fast-charge mode is likely (TP4056-class controllers are linear, not switch-mode) — PortaRF charging stays at ~1 A regardless of input current capability
5.4 Brownout posture
When the battery voltage approaches the cutoff threshold (~3.0 V for a single-cell LiPo with a protection IC), the protection IC disconnects the cell from the load. From the system’s perspective: power simply drops out.
Mayhem firmware should include a low-battery warning at ~3.4–3.6 V (giving the operator time to switch to USB-C power), and a controlled shutdown at ~3.2 V (saving any open captures before the protection IC cuts). Whether PortaRF’s specific firmware build does this correctly is § 10 verification: at first low-battery scenario, observe whether Mayhem warns + shuts down gracefully or just dies.
6. Mechanical design — single-box monolithic
PortaRF’s single-box mechanical design is the integration choice that most strongly differentiates it from porta. Understanding the mechanical implications matters for field-deployment planning, durability assessment, and the buy-vs-skip decision.
6.1 Enclosure topology
The PortaRF enclosure is almost certainly a custom plastic injection-molded shell — vendor pattern for this form factor. Likely materials: ABS or polycarbonate (impact-resistant), possibly with TPU rubber accents for grip. Industrial-design references (the Wired Hatters Banshee, the M5Stack Cardputer ADV, the Flipper Zero) all use similar materials at similar price points.
Internal layout, hypothesized:
┌──────────────────────────────────────┐
│ Display TFT │
│ (PortaPack-class, 2.4") │
├──────────────────────────────────────┤
│ Buttons + Encoder │
├──────────────────────────────────────┤
│ │
│ PortaPack PCB │
│ (stacks onto HackRF GPIO header │
│ internally; not externally exposed)│
│ │
├──────────────────────────────────────┤
│ │
│ HackRF PCB │
│ (Heath modified, R10/R10+/H4M) │
│ │
├──────────────────────────────────────┤
│ LiPo battery │
│ (1500-3000 mAh, single cell) │
└──────────────────────────────────────┘
Outer connectors:
- RP-SMA antenna (top edge)
- USB-C (side or bottom edge)
- microSD slot (side edge)
- Audio jack (top edge, if present — verify)
- Power button (side)
This is architecturally identical to porta — same boards, same stack — just sealed into one enclosure rather than left exposed.
6.2 RF shielding inside a single box
Putting an HF/VHF/UHF transceiver in the same enclosure as a TFT display + button-matrix + battery has RF interference implications:
- Display backlight switching at PWM frequencies (typically 1–10 kHz) emits broadband noise that couples into the SDR’s lower bands
- CPU clock from the LPC4320 (204 MHz) and PortaPack STM32 (typically 168 MHz) emit harmonics into the VHF/UHF range
- Switching converters (in the charge controller, in the battery protection IC, in any boost converter for the LCD backlight) emit broadband EMI
Mitigation in the PortaRF design (hypothesized):
- HackRF PCB likely has a shield can over the RF section (standard in r6+ revisions)
- Display ribbon cable likely has a ferrite bead
- Battery charge path likely has bulk capacitance + a small LC filter
Practical impact: PortaRF’s noise floor should be slightly higher than a bench HackRF due to in-enclosure EMI. Vol 5 covers measurement; expect a few dB degradation on the most sensitive bands (~70 cm, ~2 m). For most use cases (replay, capture, decode of strong signals) this is invisible. For weak-signal work (low-power telemetry, marginal-coverage AIS, distant ADS-B) it may matter — porta on a bench would do better there.
6.3 Antenna placement
The RP-SMA antenna mount is almost certainly on the top edge (HackRF convention). This is good for handheld use — natural antenna-up orientation. Concerns:
- Sealed enclosure means no GPIO header exposure → can’t add external LNA or Operacake antenna switch without disassembly
- Single antenna mount → for direction-finding or multi-antenna techniques, PortaRF is not the right tool
- Mechanical stress on SMA connector during field handling — repeated antenna swap cycles wear the connector; this is a more aggressive duty cycle than a bench HackRF gets
6.4 Heat dissipation
Sustained TX at +15 dBm dissipates ~5–10 W in the RF final stage and adjacent circuits. In a sealed plastic enclosure with no active cooling, this heats the case significantly:
- Continuous TX for >10 minutes likely raises case temperature to 40–50 °C (warm to the touch but not painful)
- Continuous TX for >30 minutes in a hot ambient may reach 55–60 °C — uncomfortable to hold
- The HackRF silicon’s TX final stage has a thermal limit (~85 °C junction) — sustained TX in hot conditions may trigger thermal throttling
Vol 5 covers thermal in detail. Bench-HackRF users don’t usually hit this because (1) lab ambient is climate-controlled, (2) the open form factor radiates heat freely. PortaRF’s field deployment is the harder thermal environment.
6.5 Drop / impact resilience
The single-box form factor is mechanically more robust than porta’s stacked-board design. Porta’s two-PCB stack with a GPIO connector between them is a known mechanical weakness — drops can dislodge or break the inter-board connector. PortaRF’s single PCB-stack inside a molded enclosure has no such weak point.
For field deployment (briefcase carry, body-worn, vehicular), this matters. For bench / lab work, it doesn’t. This is one of the few PortaRF advantages over porta that doesn’t have a workaround.
6.6 Weight estimate
Single-box LiPo handhelds with 2.4” TFT in this category typically weigh 150–250 g. PortaRF likely sits in the upper end of that range — the SMA connector + battery + two PCBs add mass. For comparison: a Flipper Zero is ~100 g, an AWOK Dual Touch V3 is ~140 g, a Cardputer ADV is ~70 g. The PortaRF is noticeably heavier than a Flipper but lighter than a porta+battery-pack rig.
7. OpenSourceSDRLab revision identification
OpenSourceSDRLab may ship different PortaRF revisions over time. The Heath HackRF design has been iterating since ~2018, and the integrated PortaRF product is more recent (post-2022 likely). What revision a specific PortaRF unit is depends on when it was ordered — verify on receipt.
7.1 What to identify
| Aspect | What to determine | How |
|---|---|---|
| HackRF generation | R10 / R10+ / H4M-derived | Vendor page invoice; teardown photos; hackrf_info output |
| Heath silicon location | On HackRF PCB or on PortaPack PCB (Clifford Edition) | Teardown — visual inspection of the antenna-SMA region |
| PortaPack revision | H2+ / H4M / H4M Clifford Edition | Mayhem boot banner usually identifies; vendor page should specify |
| USB connector | USB-C (expected for current production) | Visual; mini-B would be an older legacy SKU |
| Display panel | Specific TFT controller (ST7789 vs ST7789P3) | Mayhem-level identification |
| Battery capacity | mAh rating | Vendor page; possibly printed on cell after teardown |
| Has QWERTY? | Yes or no | Visual on vendor product page |
| Pre-flashed Mayhem version | Mayhem release version | Boot screen; “Settings → About” menu |
| Pre-flashed HackRF firmware version | HackRF firmware version | hackrf_info output via USB-C tether |
7.2 OpenSourceSDRLab product-page conventions (hypothesized)
The vendor’s product pages typically list:
- “Clifford Heath modified HackRF” — confirms Heath silicon
- HackRF revision (R10 / R10+ / H4M) — pinpoints generation
- “with PortaPack H2+ / H4M” — pinpoints UI board
- USB connector type (USB-C confirmed for current production)
- Battery capacity (mAh value usually disclosed)
- Pre-flashed firmware (Mayhem version usually stated, e.g., “v1.x.x”)
- Included accessories (antenna whip, USB-C cable, SD card if any)
- Price + lead time
If any of these are missing from the product page when verifying, ask vendor before purchase. OSL has been responsive to customer questions per community reports.
7.3 Date code identification
Once a unit is in hand, the HackRF PCB’s date code (e.g., “1620” = May 2016, or “2310” = March 2023) identifies the manufacturing date and indirectly the silicon revision. The LPC4320 marking + Q-marking on the XC2C64A CPLD also indicate manufacturing date.
For porta’s HackRF, the LPC4320 date code was 1620 (May 2016) and silkscreen showed “30 October 2022” (manufacturing date of the JSTVRO-Heath revision). PortaRF would have a more recent date code — likely 2024 or 2025 production.
7.4 Provenance through community
OpenSourceSDRLab is a smaller vendor than GSG; community confirmation of PortaRF specs is mostly through Discord (Mayhem firmware Discord, RF tools subreddits) rather than mainstream review sites. Pre-purchase: cross-check the vendor page against at least one community teardown / review video to confirm specs match.
8. What isn’t on board (and where to find it)
Inherited from HackRF One (cross-ref ../../../HackRF One/02-inputs/volume_sources/vol1.md § 5):
| Missing | PortaRF-specific workaround | Cost / friction |
|---|---|---|
| HF below 1 MHz | HF upconverter (NooElec Ham It Up, SpyVerter, etc.) — external in-line accessory | $40-80; adds external box; lossy |
| Full-duplex (simultaneous TX + RX) | HackRF silicon is inherently half-duplex; no workaround | None — different SDR needed (USRP, BladeRF) |
| Sample rate > 20 MS/s | USB 2.0 limited; no workaround within HackRF silicon | None — different SDR needed |
| Built-in spectrum analyzer | Use hackrf_sweep (tethered CLI) or Mayhem’s sweep app (standalone) | Free (already on the unit) |
| LNA for very weak signals | External low-noise preamp inline before SMA (Mini-Circuits ZX60-V63+ or similar) | $50-150; adds external box; needs Bias-T to power |
| Expansion bus for daughter cards | PortaRF lacks this entirely (sealed enclosure); porta has it (GPIO header on PortaPack) | None — physical-design choice |
| CC1101 sub-GHz daughter | Cannot add to PortaRF; for sub-GHz work, use Flipper Zero or porta-stacked CC1101 module | Different tool needed |
| Direction-finding (multi-antenna) | KrakenSDR is the canonical answer; PortaRF doesn’t multi-RX | Different tool needed |
| Better noise floor (8-bit ADC limit) | RTL-SDR-Blog v3 has same 8-bit ADC; SDRplay RSPdx-R2 has 14-bit and ~10 dB better noise floor for RX-only work | $150-200 for SDRplay |
| 5 GHz Wi-Fi RX/TX | HackRF tops out at 6 GHz but performance above 4 GHz is poor; for serious 5 GHz work, ESP32-C5-based tools (AWOK C5, Banshee) are better | Different tool needed |
| Continuous TX above ~30 minutes in hot ambient | Thermal limit on sealed handheld; for long sustained TX, use porta on a bench with passive cooling | Either accept duty cycle, or use porta |
The strategic point: PortaRF’s “missing capabilities” are mostly shared with porta — same HackRF silicon, same limitations. The PortaRF-specific deficit vs porta is the expansion bus (sealed enclosure prevents adding daughter cards or external amps without disassembly). For tjscientist’s lineup, this is rarely a blocking issue (other tools cover the missing capabilities), but it’s the single hardware capability porta has that PortaRF doesn’t.
9. PortaRF-specific hardware risk profile
Aside from generic HackRF risks (TX-into-mismatch, LNA damage from strong adjacent emitters), PortaRF introduces some integration-specific failure modes worth understanding before purchase or deployment.
9.1 Battery-related risks
| Risk | Likelihood | Severity | Mitigation |
|---|---|---|---|
| LiPo swelling from age / heat | Medium (~3-5 year horizon) | High (case bulge, possible cell breach) | Storage at ~50% charge; avoid sustained heat; replace after 3-4 years |
| Charge controller failure | Low | Medium (USB-C charging stops; battery still works) | Vendor RMA; if out of warranty, board-level repair |
| Cell protection IC false-trip | Low | Low (unit shuts down unexpectedly) | Power-cycle; rare event |
| Battery thermal runaway | Very low (LiPo with protection IC) | Catastrophic | Never charge a swollen cell; replace at first sign of bulge |
9.2 Sealed-enclosure risks
| Risk | Likelihood | Severity | Mitigation |
|---|---|---|---|
| Failure inside enclosure requires teardown | Medium over unit lifetime | Medium (warranty repair preferred) | OpenSourceSDRLab vendor support; expect typical $50-100 repair cost out of warranty |
| Display panel failure | Low | Medium (panel-level repair) | Vendor RMA; H2+ panels are inexpensive to replace |
| Encoder wear | Medium over heavy use | Low | Encoder is a common consumable; replacement parts available |
| SMA connector wear from antenna swaps | Medium with heavy field use | Low | Use right-angle SMA-to-SMA adapter to reduce stress on integrated connector |
9.3 Firmware-related risks
| Risk | Likelihood | Severity | Mitigation |
|---|---|---|---|
| Mayhem self-flash corruption | Low | Medium (recoverable from SD; Vol 8) | Always have a known-good firmware .bin on SD; never interrupt flash |
HackRF firmware bricked via hackrf_spiflash | Low | Medium (DFU recovery; Vol 8) | Take factory backup before flashing; never flash without verifying file integrity |
| Vendor-specific firmware customizations lost on Mayhem upgrade | Medium | Low | Verify vendor firmware vs mainline before deciding to upgrade |
9.4 Carry / environmental risks
| Risk | Likelihood | Severity | Mitigation |
|---|---|---|---|
| Drop damage to enclosure | Low (robust molded plastic) | Low (cosmetic) | Cosmetic only; internal damage rare with single-box design |
| Moisture ingress through SMA / USB-C / SD slot | Low | Medium (corrosion risk) | Avoid rain; if wet, dry completely before charging |
| Heat damage in vehicle (hot dashboard) | Medium in summer | Medium-High (battery degradation, LCD damage) | Don’t leave in hot vehicles; >40 °C accelerates LiPo degradation |
| Loss / theft | Variable | High (capture data on SD; possibly engagement-sensitive) | Encrypted SD partition for any sensitive data; sanitize before disposal |
The overall risk profile is lower than porta’s for mechanical / drop scenarios, higher than porta’s for thermal scenarios (sealed enclosure), and comparable to porta’s for everything else.
10. Pre-purchase + on-arrival verification checklist
Before purchase:
- Vendor page lists Heath silicon (“Clifford Heath modified” or similar) — confirm
- HackRF revision specified (R10 / R10+ / H4M) — confirm
- PortaPack revision specified (H2+ / H4M) — confirm; choice affects firmware version selection
- USB connector is USB-C (mini-B would be an older SKU; pass)
- Battery capacity disclosed in mAh — note for Vol 5 sizing
- Pre-flashed Mayhem version specified — note for firmware-update planning (Vol 8)
- Antenna included? — verify
- microSD included? — most likely yes; verify class (need Class 10 / U1 minimum)
- Price in expected range ($400-600); compare against alternatives
- Lead time acceptable for use case
- Vendor RMA / warranty policy understood
On arrival:
- Visual inspection — no damage, no swelling, no loose parts
- Power-on test — boots to Mayhem; display + buttons + encoder all work
-
hackrf_infoover USB-C — confirms HackRF firmware version, serial number, revision details - Mayhem version matches what was advertised; note for upgrade tracking
- Battery percent at first boot — note (some vendors ship at 50%, some at 80%)
- First charge to full — observe charge time + thermal behavior; should reach 100% in ~2.5 hours
- Mayhem features working — receive a known signal (FM broadcast, ADS-B from a nearby flight) to confirm RX path is healthy
- TX into a dummy load (50 Ω SMA dummy load, +20 dBm capable) — confirm TX path; check signal on a separate receiver
-
hackrf_spiflash -r portarf_factory_backup.bin— capture factory HackRF firmware for safety - SD card image backup — copy entire SD contents to a host PC for safety
- Photograph unit, serial number, included accessories — for warranty / RMA records
- Update MY_GEAR/inventory.yaml — add PortaRF unit entry; bump last_updated
- Update HackRF One CLAUDE.md Progress Log — note PortaRF acquisition + its relationship to porta
This checklist closes the loop from “research-baseline scaffold” to “validated owned tool ready for field deployment”.
11. Resources
HackRF silicon (foundational, cross-ref)
- HackRF One canonical Vol 2 (schematic-grade silicon walkthrough):
../../../HackRF One/03-outputs/HackRF_One_Complete.html - HackRF One Vol 1 § 3 (Clifford Heath modification rationale + parts list):
../../../HackRF One/02-inputs/volume_sources/vol1.md - Clifford Heath’s HackRF fork: https://github.com/cjheath/hackrf
- Mayhem wiki entry on Heath’s design: https://github.com/portapack-mayhem/mayhem-firmware/wiki/Clifford%27s-version
Vendor
- OpenSourceSDRLab: https://opensourcesdrlab.com/
- PortaRF product page: search vendor site (URL TBD)
PortaPack revisions
- Mayhem firmware (canonical PortaPack fork): https://github.com/portapack-mayhem/mayhem-firmware
- Mayhem wiki revision history: https://github.com/portapack-mayhem/mayhem-firmware/wiki
- Sharkrf community (legacy PortaPack development): https://www.sharebrained.com/portapack/
Component datasheets (Heath modifications)
- CLA4611-085LF (Skyworks PIN-diode limiter): Skyworks product page
- TRF37B73 (Texas Instruments MMIC amplifier): TI product page
- SKY13453-385LF (Skyworks RF switch): Skyworks product page
Display controllers
- ST7789 datasheet (PortaPack H2 / H2+): Sitronix product page
- ST7789P3 datasheet (PortaPack H4M): Sitronix product page
- ILI9341 datasheet (legacy H1 / H1+): Ilitek product page
Battery + charging
- TP4056 datasheet (likely charge controller): NanJing TopPower or similar
- DW01 + FS8205A protection IC pair (typical LiPo protection): manufacturer-specific datasheets
Sibling / cross-tool references
- tjscientist’s owned porta unit:
../../../HackRF One/00-inventory/porta.md - Hack Tools comparison:
../../../_shared/comparison.md - Capability matrix:
../../../_shared/capability_matrix.html
End of Vol 2. Next: Vol 3 walks the external interfaces — USB-C, antenna mount, microSD, audio jack (if present), and the sealed-enclosure-vs-expansion tradeoff.