Scanners & Radios

Scanners & Radios · Volume 19

DIY WPSD HotSpot

Pi-Star/WPSD/MMDVM DMR hotspot with Nextion display — Jeff's hand-built setup

Contents

SectionTopic
1About this volume
2Hardware tour
3Operating modes
4Hotspot configuration workflow
5Network config backups
6Network use
7Tips and tricks
8Resources

1. About this volume

The DIY WPSD HotSpot is Jeff’s hand-built DMR hotspot — a Raspberry Pi + duplex MMDVM hat + Nextion HMI display + 3D-printed (or off-the-shelf) enclosure that he assembled in April and May of 2022 from individually sourced parts, flashed to Pi-Star, and has since migrated forward to W0CHP-PiStar-Dash (WPSD). It is the tinker half of the two-hotspot duality that runs through this volume and its sibling Vol 18 (SkyBridge Plus): the SkyBridge is the BridgeCom-built turnkey appliance that sits on a shelf and gets reflashed when BridgeCom validates a new image, and this hotspot is the bench-side build that Jeff assembled himself, picked his own enclosure for, soldered the Nextion adapter for, mounted a duplex-capable MMDVM hat onto, and currently runs as the always-on companion to the SkyBridge.

It earns the bench slot as the DIY hotspot in the lineup for several distinct reasons that the SkyBridge can’t satisfy and a third turnkey unit wouldn’t add. Customisability is the headline — the Nextion 3.5” HMI display alone makes the on-shelf experience qualitatively different from the SkyBridge’s 0.96” OLED (TX/RX state, last-heard callsign, talkgroup, RSSI, network status, BER, all visible at desk distance in a single glance, with screen layout selectable from a community library), and the underlying Raspberry Pi can be SSH’d into for any configuration the WPSD dashboard doesn’t expose. Cost is the second — the total BOM for the build came in around USD 50-80 in early 2022 (the Pi was the biggest line item, with the MMDVM hat at $30-40, the Nextion display at $25-35, the enclosure under $20), compared against the SkyBridge Plus’s USD 230 retail at BridgeCom. Learning is the third — building the stack from a flashed SD card up, picking which MMDVM hat to source, wiring the Nextion’s four-wire UART, finding the right HMI layout for the screen size, and walking through the Pi-Star configuration end-to-end gave Jeff a working understanding of the MMDVM software stack that the turnkey appliance doesn’t impart. Update cadence is the fourth — the DIY hotspot runs upstream WPSD nightlies (the W0CHP-PiStar-Dash community fork of mainline Pi-Star that took over active maintenance after mainline slowed in ~2023), so any feature that lands in the upstream WPSD repo is available on the DIY hotspot within hours of the commit, whereas the SkyBridge runs whatever BridgeCom has validated and signed off on for their product image, which typically lags upstream by weeks to months.

Why someone picks the DIY hotspot instead of a turnkey commercial unit: every reason above. Why someone picks the turnkey commercial unit instead of building one: assembly time (a few hours of bench work that has to happen before the appliance is usable), occasional firmware troubleshooting (rare, but the WPSD nightlies do occasionally regress in a way that requires either a downgrade or an SSH session to investigate), the absence of any vendor support apparatus (the WPSD community is responsive and competent but it isn’t BridgeCom’s escalation queue), and the need to source MMDVM hats from a market full of clones with varying-quality TCXOs and unmarked QC. The split that Jeff lands on — own both, run both, partition the network coverage so each hotspot handles its own set of talkgroups — is the right one when you want the experimentation surface of the DIY plus the reliability floor of the appliance.

The hostname tjs-duplex in the current backup filename and the prior pi-star-duplex in the April 2022 legacy backup tell the operational story: the hotspot is configured as a duplex MMDVM (separate TX and RX frequencies with an offset, the classic DMR Tier II repeater split that simulates two-timeslot operation properly), and it has been the duplex unit since first assembly. The SkyBridge Plus is typically run as a simplex hotspot; this DIY unit running duplex is the other axis along which the two hotspots are partitioned. See §3 (Operating modes) for the duplex-vs-simplex deep treatment.

This volume reflects what Jeff actually built. Where the canonical write-up applies — Pi-Star history, MMDVM stack, BrandMeister and TGIF and W0CHP, talkgroup numbering, etiquette — the deep treatment lives in Vol 18 (SkyBridge Plus) and load-bearingly in Vol 20 (DMR Network Architecture); this volume cross-links rather than duplicates. Where the build differs from the SkyBridge — duplex operation, Nextion display, Pi-Star → WPSD migration history, the legacy configuration archive — this volume covers it in depth. Cross-link to Vol 5 (AnyTone AT-D878UVII PLUS) for the radio side; the D878 talks to both of Jeff’s hotspots, and its codeplug carries one zone per hotspot.

TBD — verify with Jeff. Several configuration items are inferable from the archive but Jeff is the authoritative source on the bench unit’s specific build. Specifically: (1) the exact Raspberry Pi model (the STEP file in the Nextion design archive is Raspberry Pi 4 Model B.STEP, which strongly suggests Pi 4B is the host SBC — but the file could also be reference geometry for a Pi-shaped MMDVM hat that the build actually mounts on a Pi Zero 2 W or Pi 3B+; verify by reading the WPSD dashboard’s “Hardware” panel or by looking at the unit). (2) The exact MMDVM hat model (duplex is confirmed by the tjs-duplex hostname and the MMDVM-Nextion-Screen-Layouts-master/HMI Files/.../Duplex_* layout files in the archive, but the specific clone — “Jumbo-Spot Duplex,” ZUM Radio MMDVM_HS_DUAL_HAT, BI7JTA dual-port, etc. — should be confirmed against the silkscreen on the installed board). (3) The Nextion display size (the archive contains HMI files for 24-, 32-, and 35-prefix sizes corresponding to 2.4”, 3.2”, and 3.5” Nextion variants; the build photo timestamps suggest the larger 3.2” or 3.5” was the practical choice for an at-desk hotspot, but the specific size is verifiable by reading the part number off the Nextion board’s back). (4) Antenna configuration for duplex operation — duplex MMDVM hats typically expose two SMA jacks (one TX, one RX) requiring two antennas, OR a single SMA via a duplexer/diplexer; Jeff’s build photos would confirm which configuration he chose. The volume text below assumes Pi 4B + duplex MMDVM hat + 3.5” Nextion + two-antenna duplex configuration as the working hypothesis, with each assumption flagged where it materially affects the discussion.

2. Hardware tour

The DIY WPSD hotspot is the assembled stack of four mostly-independent hardware pieces: the Raspberry Pi single-board computer as the host, the MMDVM hat as the radio, the Nextion HMI display as the operator interface, and the enclosure that holds them together physically. Each of those four pieces was sourced separately, and each was a decision Jeff made at build time in early 2022.

Raspberry Pi (compute host)

The reference STEP file in Jeff’s Nextion design archive is Raspberry Pi 4 Model B.STEP, which is the strongest signal that the host SBC is a Pi 4 Model B. Pi 4B is a sensible choice for a DIY hotspot in the 2022 build window: quad-core Cortex-A72 at 1.5-1.8 GHz, 2-8 GB LPDDR4, dual-band 802.11ac Wi-Fi, BLE 5.0, gigabit Ethernet, USB-C power input. Compared to the Pi Zero W in the SkyBridge (Vol 18 §2), the Pi 4B is overkill for the WPSD workload — MMDVMHost, DMRGateway, and the few WPSD daemons together consume well under 5% of even a single Pi 4 core — but the headroom is welcome for the Nextion serial-driver work, for any future plugin loading, and for running web-UI plus an SSH session plus a tail of MMDVMHost.log simultaneously without any latency. The Ethernet port on the Pi 4B is a significant operational advantage over the SkyBridge’s Wi-Fi-only posture: wired Ethernet eliminates the entire class of “the Wi-Fi flaked out and the hotspot dropped offline” failures that the SkyBridge intermittently suffers (Vol 18 §7), and the bandwidth headroom for MMDVM streaming on the wired side is irrelevant (DMR is <10 kbit/s per slot) but the reliability headroom is real.

TBD — verify Pi model. Possible alternatives that would have been period-appropriate in early 2022: Pi 3B+ (quad-core Cortex-A53 at 1.4 GHz, 1 GB, dual-band Wi-Fi, gigabit Ethernet, micro-USB power) — also reasonable and slightly cheaper, identical form factor and HAT compatibility; Pi Zero 2 W (quad-core Cortex-A53 at 1 GHz, 512 MB, single-band 2.4 GHz Wi-Fi, no Ethernet) — would be the smallest-footprint choice, would fit a much smaller enclosure, would also be Wi-Fi-only like the SkyBridge. The STEP file is design-time reference geometry; the actual installed Pi may differ. Read the WPSD dashboard’s hardware-detect panel or pull up the unit’s /proc/cpuinfo over SSH to settle this definitively.

The microSD card is the boot device and the entire filesystem. A high-endurance card is strongly recommended for any Pi that runs 24/7 — Samsung PRO Endurance is the canonical choice in the Pi community (rated for ~140,000 hours of continuous video recording, which translates to years of WPSD-grade logging and minor writes), and SanDisk High Endurance is the second-tier alternative. A consumer-grade microSD will eventually fail under the constant write workload of /var/log/MMDVMHost.log and similar; the failure mode is silent corruption that takes weeks to manifest, which is precisely the wrong failure mode for an always-on appliance.

MMDVM hat (radio subsystem)

The MMDVM hat is the daughter-board that sits on the Pi’s 40-pin GPIO header, exposes the SMA antenna jack(s), and handles the actual RF TX/RX. The duplex MMDVM hat that Jeff installed (confirmed by the tjs-duplex hostname and the abundant _Duplex_* HMI layouts in the Nextion archive) is a distinct hardware class from the simplex hat that ships in the SkyBridge — it has two separate radio modules (one TX, one RX), each with its own TCXO-disciplined synthesizer, each with its own SMA jack on the outside of the hat, and the firmware that runs on the hat’s MCU (typically an STM32F103-class part) coordinates the two so that the hat can transmit on one frequency and receive on another simultaneously. The simplex hat (Vol 18 §2) is the single-radio-module version that handles one transmission at a time and time-multiplexes between TX and RX on the same channel.

The functional payoff for the duplex hat: it can act as a true DMR Tier II repeater, with the two DMR timeslots properly interleaved on the TX side while the RX side simultaneously decodes anything coming back on the input frequency. From the radio’s perspective the duplex hotspot looks exactly like a real DMR repeater on the air — the radio can subscribe to talkgroups on both slots, and traffic on each slot is independently routed. The simplex hat, by contrast, can only handle one transmission at a time and effectively pretends to be a single-slot device. For an operator with one radio, the practical difference is small (a single HT only keys one transmission at a time anyway), but for an operator with two radios in the same household — or for the case where the hotspot is bridging two network talkgroups simultaneously and the operator wants both slots active in parallel — duplex is meaningfully more capable.

TBD — verify exact MMDVM hat model. The community-standard duplex options Jeff would have picked from in early 2022: ZUM Radio MMDVM_HS_DUAL_HAT (the canonical reference duplex hat, by KI6ZUM and KE0FHS; well-documented, generally well-built TCXOs, ~$80-100); Jumbo-Spot Duplex (the popular clone family — visually similar to the ZUM, varying-quality TCXOs and QC, ~$30-50, the higher-risk lower-cost choice); BI7JTA dual-band duplex (Chinese manufacturer with active firmware support, ~$50-70). The specific model is verifiable by reading the silkscreen on the installed board. Practical implication: the lower-end clones occasionally need a frequency-offset calibration through the WPSD dashboard’s “Modem” panel because their TCXOs aren’t on-frequency out of the box; the ZUM and BI7JTA generally are.

The hat’s two SMA jacks (typical for duplex; single-jack-with-internal-duplexer designs do exist but are less common at amateur prices) imply a two-antenna configuration: one antenna on the TX jack, one on the RX jack, with enough physical separation between them to prevent the TX side from desensing the RX side. The community convention for low-power hotspots is to put the two antennas a few inches apart (sometimes literally on opposite sides of the enclosure), and to use directional whips or rubber ducks pointed in slightly different directions if the receive sensitivity ends up degraded. At the 10-20 mW TX power level common for hotspot operation, the desense problem is manageable; at higher TX power (which would itself be a misconfiguration for a hotspot — see Vol 18 §6 (Antenna placement and RF posture)) the two-antenna isolation becomes the limiting factor.

TBD — verify antenna count. If the bench unit is actually a single-jack duplex hat with an internal duplexer, the operational and physical-deployment picture is different (one antenna, but the duplexer adds a ~1 dB insertion loss on both sides). Read the back of the MMDVM hat or count the SMA holes in the enclosure to settle this.

Nextion display (operator HMI)

The Nextion display is the largest visible difference between the DIY hotspot and the SkyBridge. It is a smart serial display — Nextion is a brand of HMI display by Itead Studio that integrates a TFT colour LCD, a touch overlay (resistive on most models, capacitive on a few), and an onboard microcontroller that runs the display logic (graphics rendering, touch handling, page transitions) internally. From the Raspberry Pi’s side, the connection is a single 4-wire UART — power (5 V), ground, RX from the display’s perspective (TX from the Pi’s), and TX from the display’s perspective (RX to the Pi). All the display logic runs on the Nextion’s MCU; the Pi just sends command strings (“show last-heard callsign N0SWN on the DMR page”, “increment the slot-1-active flag”) over the UART, and the display interprets them and updates its graphics.

The community-standard layouts that Jeff has archived under programs/wpsd-hotspot/Nextion Display/MMDVM-Nextion-Screen-Layouts-master/ are by WA6HXG (Ryan), maintained on GitHub and widely adopted across the MMDVM hotspot community. The archive contains HMI source files (the editable Nextion-Editor project format) and TFT files (the compiled binary format that uploads directly to the display) for three screen sizes — 2.4” (320×240, the smallest practical size; the size prefix in filenames is 24in), 3.2” (400×240, the most popular hotspot size; filename prefix 32in), and 3.5” (480×320, the largest practical size; filename prefix 35in). Each size has Blue and Green colour-scheme variants, each in Simplex and Duplex flavour, each at several version numbers tracking incremental layout improvements (2.0, 2.1, etc. — see the README for the version history).

The duplex layouts at the 3.2” and 3.5” sizes are the ones Jeff’s duplex hotspot can use; the simplex layouts work too but waste the slot-2 display real estate. The screen typically shows: the current TX/RX state with a TG-colour-coded indicator, the last-heard callsign and DMR ID (the headline information the operator wants when QSO-checking), the talkgroup number and name for both slots in the duplex layouts, the RSSI in dBm and BER (bit error rate) for QSO quality assessment, the network status (connected to BrandMeister / TGIF / W0CHP), and timing/duration counters for the in-progress call. The dwell-on-information density is what the SkyBridge’s 0.96” OLED cannot match — the OLED has space for four lines of text and has to cycle through them; the Nextion 3.5” has space for all of it at once.

TBD — verify Nextion size. The build’s actual display is one of 2.4”, 3.2”, or 3.5” — likely 3.2” or 3.5” given Jeff has all three sets of HMI files but the larger sizes are the practical at-desk choice. Read the part number off the back of the display (Nextion model numbers follow the pattern NX4024T032_011R where 032 is the screen size in tenths of an inch and R indicates resistive touch).

The Nextion connects to the Pi via the GPIO header’s UART pins (/dev/ttyAMA0 or /dev/serial0 after the boot-loader and console are reassigned away from the UART — the Pi’s standard configuration requires this), at the baud rate the Nextion firmware is configured for (typically 9600 baud for the older WA6HXG 2.x layouts, 115200 for the 3.x layouts that use the ON7LDS-derived Nextion Driver). The wiring is a four-wire ribbon: 5 V from the Pi’s 5 V pin (the Nextion has its own onboard regulator), GND to the Pi’s ground, Nextion-TX to Pi-RX (GPIO 15), Nextion-RX to Pi-TX (GPIO 14). The Pi’s /boot/config.txt needs enable_uart=1 and dtoverlay=disable-bt (to free the primary UART from the BLE controller it normally drives on Pi 3B+ / 4 / Zero 2 W), and /boot/cmdline.txt needs the console=serial0 boot console removed. WPSD’s setup tooling handles this automatically when the Nextion display type is selected in the dashboard.

The Nextion also has a microSD slot on the back — this is not the Pi’s microSD; it’s the Nextion’s own slot used for uploading TFT firmware files. You drop the compiled .tft file from the WA6HXG repository onto a freshly FAT32-formatted microSD, insert it into the Nextion, power-cycle the display (which auto-detects the SD and flashes itself), then remove the SD and the new layout is live. This is the easiest way to swap layouts; the alternative is over-UART flashing via the Nextion Editor on a Windows PC, which is more work but allows interactive layout debugging.

Enclosure and physical assembly

The enclosure is the most personalised piece of the build — community options range from 3D-printed cases (Thingiverse and Printables have dozens of designs specifically sized for MMDVM hat + Nextion display combos), to commercial enclosures from BridgeCom and DealExtreme that wrap the same Pi-plus-hat-plus-Nextion stack, to laser-cut acrylic frame designs, to bare “exposed-board” mounts on a bookshelf. The Nextion’s resistive touchscreen wants a flat front face with a cutout for the display, the MMDVM hat wants its SMA jack(s) accessible from a side panel, and the Pi wants its USB-C power input and Ethernet jack accessible from a back panel. The seven build photos in programs/wpsd-hotspot/Pix - My HotSpot Build/ from April and late April 2022 document Jeff’s specific build sequence; those photos are the authoritative record of which enclosure Jeff used and how he routed the Nextion ribbon and the antenna cabling.

Build photos (programs/wpsd-hotspot/Pix - My HotSpot Build/): 20220420_104751.jpg, 20220420_104831.jpg, 20220426_141411.jpg, 20220426_141424.jpg, 20220426_141436.jpg, 20220426_142804.jpg, 20220426_142815.jpg. The two April-20 photos document the initial assembly state; the five April-26 photos document either the completed build or a major reassembly. Useful reference for any future re-build or for the question “how did I route the Nextion ribbon last time.”

The STEP CAD files in programs/wpsd-hotspot/Nextion Display/STEP Files/ (Raspberry Pi 4 Model B.STEP and likely sibling files for the MMDVM hat and the Nextion display) are the 3D reference geometry for a custom enclosure — if Jeff (or a future operator) wants to redesign the case or print a replacement, the STEP files are the input to FreeCAD / Fusion 360 / SolidWorks for the enclosure CAD work.

Power and physical specs

Power is 5 V via USB-C for a Pi 4B host (or micro-USB for a Pi 3B+ / Zero 2 W). The Pi 4B is sensitive to under-voltage — the official 5.1 V 3 A USB-C power supply is the canonical choice; a generic phone charger may trigger the under-voltage warning and lead to intermittent throttling. Power consumption: Pi 4B alone at idle ~600 mA, plus the MMDVM hat at ~100 mA idle and ~200 mA TX, plus the Nextion 3.5” at ~120 mA (display + backlight) = ~800-900 mA total at idle, ~900-1000 mA at TX. A 5 V 2.5 A supply is the minimum; the 3 A official Pi supply is the right answer.

Dimensions depend on the enclosure: a typical 3D-printed case sized for Pi 4B + duplex hat + 3.5” Nextion lands around 130 × 85 × 60 mm, weight ~250-350 g depending on case material (PETG vs PLA) and whether antennas are counted. Smaller for a Pi Zero 2 W build; larger for a built-in-fan enclosure.

3. Operating modes

The MMDVM stack that runs on the DIY hotspot is the same stack that runs on the SkyBridge — the same MMDVMHost daemon, the same DMRGateway / YSFGateway / D-STARGateway / NXDNGateway / P25Gateway / M17Gateway family of network bridges, the same WPSD dashboard frontend. The modal capability table is identical to the SkyBridge’s, and the comprehensive treatment lives in Vol 18 §3; reading both volumes back to back gets you no new modal information. What is different on this hotspot is the duplex vs simplex axis.

Duplex vs simplex — the load-bearing difference

A duplex MMDVM hat operates with two separate frequencies — a TX frequency and an RX frequency, typically split by 600 kHz on 2 m or 5 MHz on 70 cm (the standard amateur repeater offsets) — and two simultaneous radio paths, each with its own TCXO-disciplined synthesizer and its own SMA jack. The hat can transmit on one frequency while simultaneously receiving on another, which is what a real DMR repeater does: the input frequency is what radios transmit on, the output frequency is what the repeater transmits on, and the repeater listens-and-rebroadcasts continuously.

A simplex MMDVM hat operates on a single frequency — TX and RX use the same channel, and the hat time-multiplexes between transmitting and receiving rather than doing both at once. From the radio’s perspective the simplex hotspot looks like a “single-frequency repeater” or, more accurately, like another radio on the same frequency: the radio transmits, the simplex hat hears it, the simplex hat finishes its own receive and then transmits the network-routed response on the same frequency. This works fine for a single radio talking to a single talkgroup, but it cannot handle the case where two radios in range are both trying to use the hotspot, and it cannot properly serve both DMR Tier II timeslots simultaneously.

The duplex hotspot simulates a real DMR Tier II repeater much more faithfully. DMR Tier II uses two timeslots on a single 12.5 kHz channel, with the two slots interleaved on a 30 ms cycle (TDMA: slot 1 talks for 30 ms, slot 2 talks for 30 ms, slot 1 again, etc.). A duplex MMDVM hat can independently route traffic on slot 1 and slot 2 to two different network talkgroups, so a single hotspot transmission carries (for example) BrandMeister TG 3162 on slot 1 and TGIF TG 31 on slot 2 simultaneously, and the radio can hear both by listening on the right slot. A simplex hat doesn’t truly serve two slots — it transmits one slot at a time, so only one of the two network talkgroups is heard at any moment.

For Jeff’s bench use case — DMR with the AnyTone D878 (Vol 5) as the only radio, occasionally bridging two networks at once across the two slots, sometimes using DMR Tier II’s slot 2 for a regional talkgroup while slot 1 carries a worldwide TG — the duplex hat is the right choice. The SkyBridge’s simplex hat is fine for the always-on home-base “one talkgroup at a time” use case; the DIY’s duplex hat is the better experimentation platform when slot routing matters.

The trade-off is two antennas and frequency coordination. Duplex operation needs a TX frequency and an RX frequency that are separated by enough offset to allow the antennas to isolate (5 MHz on 70 cm is the standard amateur repeater offset and is sufficient), and it needs two antennas physically separated enough not to desense each other. Simplex operation needs one frequency and one antenna. The duplex setup is more capable; the simplex setup is mechanically simpler.

Operating modes (the rest)

Every other modal capability is shared with the SkyBridge: DMR (Tier I direct, Tier II via the hotspot, all four major networks — BrandMeister, TGIF, W0CHP, and the FCS/XLX reflector ecosystem); D-STAR, YSF, P25, NXDN, M17 (all five other digital amateur modes supported in MMDVMHost firmware, each requiring the corresponding gateway daemon to be enabled and pointed at the right reflector); cross-mode bridges (DMR2YSF, DMR2NXDN, etc. — these let a DMR-only radio talk to a YSF reflector by keying a DMR talkgroup that DMRGateway cross-routes to a YSF gateway, a useful feature for Jeff’s D878-only configuration). The deep treatment of every one of these modes is in Vol 18 §3 — reading the SkyBridge volume’s mode discussion applies here directly with the single substitution that this hotspot can run any of them in duplex when the mode supports duplex operation.

Bands: the MMDVM modem supports amateur 2 m (144-148 MHz) and amateur 70 cm (430-450 MHz), software-selectable per channel. 70 cm is the conventional choice for the same reasons covered in the SkyBridge volume (Vol 18 §3). For duplex operation, the standard amateur 70 cm repeater offset is 5 MHz (input at 442-445 MHz, output 5 MHz lower at 447-450 MHz, or vice versa); some regional repeater coordinators publish different splits in their “low-power simplex / hotspot allocation” plans, and Jeff’s frequency selection should be coordinated against the regional repeater plan before committing (see Vol 22 (Frequency Planning)).

For the bridging-two-hotspots-in-the-same-house case (Vol 18 §6 Bridging), the partitioning Jeff has landed on is that the SkyBridge handles one set of network talkgroups (typically BrandMeister) on one simplex 70 cm frequency, and the duplex DIY hotspot handles a different set (typically TGIF, or the cross-mode bridges, or both DMR slots) on its own TX/RX frequency pair that’s separated from the SkyBridge’s by at least 1-3 MHz to avoid desense. The radio’s codeplug carries one zone per hotspot.

4. Hotspot configuration workflow

The DIY hotspot’s configuration is end-to-end web-managed once the WPSD image is on the SD card and the Pi is on the network, exactly as the SkyBridge is. The difference is that the configuration starts earlier — you have to flash the SD card, do the initial Wi-Fi/Nextion setup, and pick the MMDVM hat type yourself, all before the first dashboard interaction. The SkyBridge ships pre-flashed; this hotspot ships as a stack of parts.

Step 1 — Flash WPSD to the SD card

The canonical starting point is downloading the current WPSD image from the W0CHP project website (https://w0chp.radio — the download page hosts versioned releases plus the nightly), unzipping it to a ~3 GB .img file, and writing that image to a microSD card with Raspberry Pi Imager (Imager is the easiest tool; Balena Etcher and dd are equivalent). The image is a complete Debian-based Linux system with WPSD pre-installed, configured for the typical Pi GPIO and UART layout, and ready to boot once Wi-Fi credentials are provided.

For comparison: the SkyBridge ships with this step already done at the factory, and you’d only redo it on RMA-replacement or if the SD card fails (Vol 18 §5). On the DIY hotspot, this is the first task at first-build and the recovery task whenever an upstream WPSD upgrade goes sideways or the SD card fails. The Samsung PRO Endurance / SanDisk High Endurance microSD recommendation from §2 (Hardware tour) is load-bearing here; a consumer microSD eventually corrupts under WPSD’s logging workload, and the recovery is “re-flash and re-upload the most recent WPSD_Config_*.zip backup.”

Step 2 — First boot and Wi-Fi onboarding

On first power-up, WPSD does the same Wi-Fi-AP-mode captive-portal trick that the SkyBridge does (Vol 18 §4): the Pi advertises an open SSID like “WPSD-Setup” or “Pi-Star-Setup,” a phone or laptop joins that SSID, the captive portal prompts for the home Wi-Fi SSID and PSK, and the Pi writes wpa_supplicant.conf to the boot partition and rejoins as a client. The DIY-hotspot variant: if the Pi has Ethernet (the Pi 4B / 3B+ both do; the Zero 2 W doesn’t), you can skip the Wi-Fi onboarding entirely and just plug an Ethernet cable into the home network — the Pi will DHCP up and be reachable immediately at its assigned IP or at pi-star.local / wpsd.local via mDNS.

Jeff’s archived Wi-Fi credentials are in programs/wpsd-hotspot/wpa_supplicant.conf.docx (the .docx is just a Word-wrapping container; the actual content is the standard wpa_supplicant.conf format with the network={…} block specifying the home SSID and PSK), and the NetworkManager-style profile programs/wpsd-hotspot/FBI_Surveillance_Van__3.nmconnection carries the same credentials in the modern NetworkManager format (UUID c116fac3-8a64-45dd-9d54-008399e8b4a0, SSID FBI Surveillance Van #3, PSK redacted-in-public-discussion-but-stored-in-the-file; the same home Wi-Fi the SkyBridge connects to per Vol 18 §5). Either flavour can rebuild the Wi-Fi connection if it has to be reconstructed from scratch.

Step 3 — WPSD dashboard onboarding

Once the Pi is on the network, point a browser at http://pi-star.local/ or the assigned IP — the WPSD dashboard appears. Default login is pi-star / raspberry (the upstream WPSD default, inherited from mainline Pi-Star; change immediately on first login from the dashboard’s Security panel). The dashboard’s Configuration page is the same as the SkyBridge’s, with the same fields:

  • Callsign — Jeff’s amateur callsign (the same N0SWN used in the AnyTone D878’s codeplug per Vol 5 §6 and the SkyBridge per Vol 18 §4).
  • DMR ID — Jeff’s 6- or 7-digit RadioID.net-issued DMR ID; same as in the D878 codeplug.
  • Hostname — tjs-duplex (current; the latest backup file is named after this hostname). The earlier hostname was pi-star-duplex (per the programs/wpsd-hotspot/pi-star-legacy/Duplex/Pi-Star_Config_pi-star-duplex_2022-Apr-20.zip archive); Jeff renamed at some point during the Pi-Star → WPSD migration.
  • Frequency (TX and RX) — separate values for the duplex setup. The standard amateur 70 cm repeater offset is 5 MHz, so for example TX at 442.700 MHz and RX at 447.700 MHz; verify against the local repeater coordinator’s published low-power simplex/hotspot allocation before committing.
  • Colour code — CC 1 by community convention; this matches the AnyTone D878 default and the SkyBridge’s CC.
  • Modem type — pick the duplex modem variant matching the installed hat. For a ZUM Radio MMDVM_HS_DUAL_HAT, the WPSD dropdown entry is “MMDVM_HS_Dual_Hat” (or similar — exact text varies by WPSD version); the Jumbo-Spot Duplex and BI7JTA equivalents appear in the same dropdown. Pick wrong and the hat may not initialize or may run at the wrong frequencies.
  • TX power / TX Level — the MMDVM hat’s “TX Level” parameter (0-255 numeric). 60-80 corresponds to roughly 10-20 mW EIRP — same low-power-is-good-on-a-hotspot argument as the SkyBridge (Vol 18 §4). Resist the temptation to crank this up; the antenna proximity argument from Vol 18 §6 applies equally.
  • Network selection — pick BrandMeister, TGIF, W0CHP, and/or the FCS/XLX reflector ecosystem; per-network API keys go in the corresponding sub-panels. For the partitioning Jeff has set up (SkyBridge on BrandMeister, DIY on TGIF and/or cross-mode and/or DMR slot 2), the DIY hotspot’s network configuration mirrors the partition.
  • Static and dynamic talkgroups — per-slot in the duplex configuration, which is the other major difference from the SkyBridge’s simplex setup. Slot 1 typically gets the always-on talkgroups for the slot-1-active networks; slot 2 gets the static set for the slot-2-active networks. See Vol 20 §6 (Talkgroup hygiene) for the deep discussion.

The dashboard’s Save button writes everything under /etc/pi-star/, restarts MMDVMHost, DMRGateway, and the per-mode gateway daemons, and shows the new state in the live panels within ~10 seconds. No reboot needed except for network-mode toggles.

Step 4 — Nextion display configuration

This is the step that’s unique to the DIY hotspot — the SkyBridge has no Nextion equivalent, just the small OLED. Two pieces of configuration are required.

MMDVMHost.ini Display setting. The Pi’s MMDVM configuration (under /etc/mmdvmhost/MMDVMHost.ini or the equivalent path in the current WPSD layout — the dashboard’s Configuration > Display panel exposes this) must specify Display=Nextion plus the serial port (Port=/dev/ttyAMA0 or /dev/serial0) and the baud rate (Baud=9600 for the WA6HXG v2.x layouts; Baud=115200 for the v3.x layouts that use the ON7LDS Nextion Driver). The WPSD dashboard sets these automatically when “Nextion” is selected as the display type and the right layout family is picked from the dropdown.

Nextion layout upload. The actual graphical layout the Nextion shows is a .tft file that has to be flashed to the Nextion’s own microSD slot (not the Pi’s), or alternatively uploaded over UART using the Nextion Editor running on a Windows PC. The microSD-slot method is the standard:

  1. Pick the matching HMI layout from programs/wpsd-hotspot/Nextion Display/MMDVM-Nextion-Screen-Layouts-master/TFT Files/{24,32,35}/. For a 3.5” duplex Nextion the file is Blue1_Duplex_35in_LHnLHT_2.0.tft (or the Green1 variant); for a 3.2” duplex the file is Blue1_Duplex_32in_LHnLHT_GB_2.1.tft (the 2.1 version added the dual-last-heard feature and requires the “G4KLX Layout” setting in WPSD per the WA6HXG README, not the default Nextion layout — easy gotcha).
  2. Copy the .tft to a FAT32-formatted microSD card (single .tft file in the root of the card; the Nextion’s bootloader looks for it).
  3. Power off the Nextion, insert the SD card, power on. The Nextion’s bootloader detects the SD, begins flashing the new layout, displays a progress bar, finishes in 30-60 seconds.
  4. Power off, remove SD, power on. The new layout is live.

The alternative upload path is the Nextion Editor (Windows-only; the programs/wpsd-hotspot/Nextion Display/nextion-setup-vLTS/NextionEditor.exe is the version Jeff archived, presumably the vLTS — long-term-support — release that was current at the time of his build). The Editor lets you edit the HMI source file directly (graphical layout, text-box positioning, font choices, button actions) and upload over UART when the Nextion is connected to the PC via a USB-to-serial adapter. This is the path for customising the layout — changing background colours, repositioning fields, adding pages — rather than just installing a stock one. The Editor’s manual is at programs/wpsd-hotspot/Nextion Display/MMDVM-Nextion-Screen-Layouts-master/Info Sheets/EDITOR NEXTION.pdf; the tutorial is NEXTION_Tutorial_v2.03.pdf in the same folder.

For ongoing operation, the Nextion just works — once the layout is loaded and the MMDVMHost is sending it data, the display updates in real time without further intervention. The maintenance task is updating the layout when the WA6HXG repo releases a new version (a few times a year), which is the same procedure as step 1-4 above with the newer .tft file.

Step 5 — WPSD updates

WPSD pushes updates frequently — the W0CHP project is actively maintained, with nightly builds and periodic stable releases. The dashboard’s Configuration > Update panel checks the upstream WPSD update server and applies updates in-place; configuration is preserved across updates. Cadence: the recommendation is to check the dashboard’s Update panel at least monthly, apply stable releases when they appear, and skip nightlies unless chasing a specific feature.

The contrast with the SkyBridge (Vol 18 §7) is that BridgeCom validates and signs off on releases before pushing them to SkyBridge units, so the SkyBridge is typically several weeks behind upstream. The DIY hotspot is on upstream timing; if an upstream regression lands in a nightly that the maintainers haven’t caught yet, the DIY hotspot may see it before the SkyBridge does. The mitigation is to back up the configuration before applying updates — see §5 (Network config backups) — so the rollback path is clean.

Step 6 — SSH and command-line access

Unlike the SkyBridge’s “officially unsupported” SSH posture (Vol 18 §4), SSH on the DIY WPSD hotspot is expected. The default user (pi-star, password raspberry, change on first login) has full sudo access; the filesystem layout follows the upstream Pi-Star convention with /etc/pi-star/ for daemon configuration and /var/log/pi-star/ for logs. Common SSH tasks:

  • Tailing MMDVMHost.log for debugging — the real-time per-transmission log that shows every keyup, talkgroup, and BER value the modem decodes.
  • Editing MMDVMHost.ini or DMRGateway.ini directly when the dashboard’s UI exposes only part of the configuration — for example, fine-tuning RxLevel and TxLevel separately, adding custom DMRGateway rewrite rules, or experimenting with non-standard modem parameters.
  • Running pistar-watchdog and similar Pi-Star utility scripts that the WPSD dashboard wraps but doesn’t expose for direct invocation.
  • Backing up the configuration tree via tar or rsync for off-Pi storage, as a belt-and-suspenders complement to the dashboard’s Backup/Restore ZIP export.

The SSH access is a core differentiator vs the SkyBridge for the experimentation use case. Most operators most of the time don’t need it; for Jeff specifically, it’s the reason the DIY hotspot is the “test new things” platform.

5. Network config backups

The configuration backup hierarchy in programs/wpsd-hotspot/ is several years deep and documents the migration path from original Pi-Star through WPSD, plus the supplementary Nextion-side files:

programs/wpsd-hotspot/
├── FBI_Surveillance_Van__3.nmconnection           ← current NetworkManager Wi-Fi profile
├── wpa_supplicant.conf.docx                        ← Wi-Fi credentials (wrapped in .docx — do NOT publish)
├── W0CHP - DMR config and notes.xlsx              ← per-hotspot config notes (talkgroups, API keys)
├── WPSD_Config_tjs-duplex_2025-Dec-29.zip         ← latest WPSD export (hostname tjs-duplex)
├── Pix - My HotSpot Build/                         ← 7 build photos from April 2022
│   ├── 20220420_104751.jpg
│   ├── 20220420_104831.jpg
│   ├── 20220426_141411.jpg
│   ├── 20220426_141424.jpg
│   ├── 20220426_141436.jpg
│   ├── 20220426_142804.jpg
│   └── 20220426_142815.jpg
├── Nextion Display/                                ← Nextion HMI source + layouts + tooling
│   ├── EDITOR NEXTION.pdf                          ← Nextion Editor manual
│   ├── NEXTION_Tutorial_v2.03.pdf                  ← display tutorial
│   ├── Status Codes and Fields.txt                 ← MMDVM-Nextion command reference (GitHub snapshot)
│   ├── STEP Files/                                 ← 3D reference geometry
│   │   └── Raspberry Pi 4 Model B.STEP             ← Pi 4B model — design-time reference
│   ├── MMDVM-Nextion-Screen-Layouts-master/        ← WA6HXG layout repo snapshot
│   │   ├── HMI Files/{24,32,35}/                   ← editable Nextion Editor projects
│   │   ├── TFT Files/{24,32,35}/                   ← compiled binaries for direct upload
│   │   ├── Info Sheets/                            ← Editor manual + tutorial + status codes
│   │   ├── Instructions.md                         ← README
│   │   └── README.md                               ← WA6HXG version history
│   └── nextion-setup-vLTS/                         ← Nextion Editor vLTS (Windows .exe + DLLs)
│       └── NextionEditor.exe                       ← the layout editor itself
└── pi-star-legacy/                                  ← pre-WPSD archive (March-April 2022)
    ├── Pi-Star_Config_2022-Mar-24.zip               ← first WPSD-precursor backup (24 March 2022)
    ├── BridgeCom_Pi-Star_Config_2022-Mar-26.zip    ← BridgeCom-skinned Pi-Star backup (26 March 2022)
    ├── Pi-Star_RPi_V4.1.5_30-Oct-2021.zip          ← original Pi-Star v4.1.5 image (October 2021)
    ├── Pi-Star_RPi_V4.1.5_30-Oct-2021/             ← unzipped form of the same
    ├── Saved Config Files/                          ← intermediate per-config snapshots
    ├── Duplex/
    │   └── Pi-Star_Config_pi-star-duplex_2022-Apr-20.zip  ← duplex config at hostname pi-star-duplex
    ├── Simplex/                                     ← (currently empty in archive)
    ├── NEXTION_Tutorial_v2.03.pdf                   ← duplicate of the tutorial PDF
    ├── js_composer.zip                              ← unrelated WordPress plugin (left in archive)
    └── themeforest-...wordpress-theme.zip          ← unrelated WordPress theme (left in archive)

A few observations about the archive structure that reflect the build’s history.

The presence of both Pi-Star_Config_2022-Mar-24.zip (vanilla Pi-Star) and BridgeCom_Pi-Star_Config_2022-Mar-26.zip (BridgeCom’s customised Pi-Star variant) two days apart suggests Jeff initially tried the BridgeCom dashboard skin on the DIY hotspot (presumably as a cross-reference against the SkyBridge’s customisations) and then reverted to vanilla Pi-Star within the same week. The legacy Pi-Star_RPi_V4.1.5_30-Oct-2021.zip is the actual upstream Pi-Star image from October 2021 — the starting point of the build, before any customisation.

The Pi-Star_Config_pi-star-duplex_2022-Apr-20.zip in pi-star-legacy/Duplex/ is the earliest dated configuration that explicitly references duplex operation; the build photo timestamps (April 20 and April 26) align with this date, suggesting the duplex MMDVM hat was installed and configured during the same April 20-26 window that the case was assembled.

The current backup WPSD_Config_tjs-duplex_2025-Dec-29.zip (December 29, 2025) is the WPSD-era equivalent — by this point the migration from Pi-Star → WPSD has happened, the hostname has been changed from pi-star-duplex to tjs-duplex, and the configuration is in the WPSD-specific format with the W0CHP dashboard customisations. The gap between Pi-Star April 2022 and WPSD December 2025 reflects an “if it’s working, leave it alone” stance — Jeff didn’t proactively migrate, he migrated when the WPSD upstream had matured enough to be worth the move.

Backup cadence

The recommended cadence for the DIY hotspot is:

  • Before every WPSD update. Always. The update is in-place and usually preserves config, but if it doesn’t (the rare case where a major schema change happens), having the immediately-pre-update ZIP is the rollback path.
  • After every meaningful configuration change. A new talkgroup added to the static set, a network added or removed, a frequency changed, an API key rotated, a Nextion layout swapped. Anything that would be painful to reconstruct from memory if the SD card failed tomorrow.
  • Quarterly. A defensive belt-and-suspenders backup that catches any incremental drift that the “after every change” rule missed.
  • After any major build change. New MMDVM hat, replacement Pi, enclosure swap — anything that touches hardware that the configuration depends on.

Each backup is the WPSD dashboard’s Configuration > Backup/Restore > Download a ZIP. The convention is to name them WPSD_Config_<hostname>_YYYY-MMM-DD.zip to match WPSD’s own filename timestamping; Jeff’s current backup WPSD_Config_tjs-duplex_2025-Dec-29.zip follows this convention.

Restore workflow

The recovery path if the SD card fails or the WPSD installation corrupts:

  1. Flash a fresh WPSD image to a replacement microSD card per §4 step 1.
  2. First-power-up onboarding — Wi-Fi captive portal or Ethernet, configure home Wi-Fi credentials, get the Pi on the network.
  3. Log into the dashboard, change the default password.
  4. Configuration > Backup/Restore > Upload WPSD_Config_tjs-duplex_<latest-date>.zip → click Restore. WPSD unpacks the saved config tree, writes back the daemon configurations, the modem parameters, the network credentials, the talkgroup subscriptions, and restarts the daemons.
  5. Reconfigure the Nextion if the SD-card replacement also wiped the Nextion’s flash — flash the .tft from the Nextion HMI archive per §4 step 4.
  6. Verify the dashboard shows the expected callsign, DMR ID, frequencies, talkgroups, network connections; key the D878 on the configured frequency and confirm the hotspot’s TX LED and the dashboard’s Last Heard show the transmission.

End-to-end recovery: 30-60 minutes given a fresh SD card, the most recent WPSD_Config ZIP, and the Nextion .tft. Without the backup, the recovery is from-scratch (re-entering all the configuration items by hand) which is longer and risks missing edge-case settings. The W0CHP - DMR config and notes.xlsx spreadsheet is the cross-check that’s not in the ZIP — it carries the talkgroup map, the frequency plan, and the cross-reference notes that the dashboard doesn’t surface.

What to NOT publish

Two files in the archive contain semi-sensitive content and should never be committed to a public repo or shared in a public-website handoff:

  • wpa_supplicant.conf.docx — carries the home Wi-Fi PSK in cleartext.
  • FBI_Surveillance_Van__3.nmconnection — same PSK in NetworkManager format. The .gitignore should exclude both, or they should be flagged for redaction before any public-website sync. See Hack Tools/CLAUDE.md for the analogous handling of MY_GEAR/inventory.yaml.

The WPSD_Config_tjs-duplex_*.zip may also contain BrandMeister and TGIF API keys (the per-network authentication tokens that the dashboard configures); these should be treated as semi-sensitive too. Rotating the API keys on the network’s website is cheap and easy if a backup leaks.

6. Network use

The on-air experience of the DIY hotspot is functionally the same as the SkyBridge’s — same MMDVM stack, same network bridges, same talkgroup numbering, same etiquette. The deep treatment of talkgroup choice, talkgroup hygiene, and network selection is in Vol 18 §6 (Network use) and the load-bearing reference is Vol 20 (DMR Network Architecture). What’s specific to this hotspot is the duplex routing.

Duplex talkgroup routing

The duplex setup lets the two DMR slots route to different networks or different talkgroups within the same network independently. The configuration is in the WPSD dashboard’s DMR Configuration panel, which has separate static-talkgroup lists for Slot 1 and Slot 2. The two common partitionings:

  • Slot 1 = one network, Slot 2 = another network. For example, Slot 1 carries BrandMeister statics (TG 3100, TG 3162, etc.) and Slot 2 carries TGIF statics (TGIF 31, TGIF 2, etc.). The radio’s codeplug carries one channel per (slot, talkgroup) tuple; switching between BrandMeister and TGIF is then a channel-knob action rather than a network-change action.
  • Slot 1 = ragchew / general-traffic, Slot 2 = special-interest / event-specific. For example, Slot 1 carries the always-on TG 91 (Worldwide English) and TG 3162 (Michigan state), Slot 2 is dynamic-only and reserved for the per-event talkgroup the operator is following. This is the “high signal, separated by purpose” partitioning.

The duplex hotspot can serve both slots simultaneously, which is the qualitative difference from the simplex SkyBridge. If both slots have inbound traffic at the same moment, both slots transmit (on the same TX frequency, interleaved on the 30 ms TDMA cycle), and the radio decodes whichever slot its current channel is tuned to. This is how a real DMR Tier II repeater behaves.

Antenna pairing

For duplex operation, two antennas with enough physical separation to avoid desensing each other. The community convention:

  • Two 70 cm rubber-duck whips or two short telescoping antennas, mounted on opposite sides of the enclosure (or front and back), with at least 6-12 inches of physical separation between them.
  • At 10-20 mW TX power, the desense problem is manageable even with closely-spaced antennas; at higher TX power the isolation requirement gets stricter (and again, raising hotspot TX power is the wrong fix — see Vol 18 §6 (Antenna placement and RF posture)).
  • A 70 cm J-pole or Slim Jim on the TX side and a small rubber duck on the RX side is a workable asymmetric configuration for the case where the operator wants slightly better TX coverage; both directions limited by the same low TX power.

The cross-link for the deep treatment is [Antennas Vol 29 (Use-case Matrix)](../../../Hack Tools/Antennas/02-inputs/volume_sources/vol29.md), which has per-radio antenna recommendations including the hotspot case (the “low-gain wins” argument applies here too — duplex doesn’t change the proximity-only RF posture, just the slot-routing capability).

If Jeff’s bench unit turned out to be a single-jack duplex hat with internal duplexer (the alternative configuration flagged in §2), the antenna picture is simpler — one antenna, with the duplexer’s ~1 dB insertion loss on both TX and RX paths. Mechanically tidier; slightly worse RF performance.

Frequency coordination

Same frequency-coordination discipline as the SkyBridge (Vol 18 §7) plus an extra constraint for duplex operation. The TX and RX frequencies must both fall within the local repeater coordinator’s published low-power simplex / hotspot allocation, and they must be separated by a standard amateur repeater offset (5 MHz on 70 cm in the US is the convention). Picking a frequency pair that conflicts with a local repeater’s input or output on either of your two frequencies will desense the hotspot’s RX path in particular. The deep regulatory framing is in Vol 22 (Frequency Planning) and [Antennas Vol 31 (Regulatory & RF Safety)](../../../Hack Tools/Antennas/02-inputs/volume_sources/vol31.md).

For two-hotspot operation (this hotspot plus the SkyBridge on the same shelf), the partitioning is the same as Vol 18 §6 (Bridging two hotspots): different RF frequencies, same colour code, the radio’s codeplug carries two zones (“HS-WPSD-Duplex” and “HS-SkyBridge”), and zone-knob switching moves between them. The duplex hotspot’s two frequencies need to clear the SkyBridge’s single frequency by at least 1-3 MHz to avoid desense; coordinate against the local repeater plan to find a triple-clear set of frequencies.

Radio-side configuration

The AnyTone D878 codeplug zone for this hotspot is structured the same way as the SkyBridge zone (Vol 5 §6, Vol 18 §6), with the duplex-specific addition that channels for slot-2 talkgroups go on slot 2 in the codeplug instead of slot 1. So the zone has, e.g., one channel for “BrandMeister TG 3100 on Slot 1,” one channel for “TGIF 31 on Slot 2,” each pointing at the same TX/RX frequency pair, each on colour code 1, each with the slot field set to the matching slot. The 878’s zone-knob switching plus channel-knob switching lets the operator pick (hotspot, talkgroup, slot) in two button presses.

The duplex routing can be tested with the D878’s promiscuous mode (Vol 5 §7) — set the radio to monitor both slots, key any talkgroup-bearing transmission, and watch the radio’s display report which talkgroup decoded on which slot. This is the diagnostic for verifying the dashboard’s slot-routing configuration matches the actual on-air routing.

Posture

The DIY hotspot is the experimentation platform. It runs alongside the SkyBridge on the same shelf, on the home Wi-Fi (or Ethernet, depending on Pi model), with whatever the current talkgroup partitioning is. Reboots happen more often than the SkyBridge — once a month or so for WPSD updates, occasionally for Nextion layout updates, sometimes after Jeff’s been SSH’d in experimenting with DMRGateway rules. Cycle time from cold boot to ready-to-bridge: ~90 seconds for a Pi 4B (faster than Pi Zero W’s ~3 minutes), similar to the SkyBridge.

The use cases that the DIY hotspot specifically serves:

  • Try new talkgroups — subscribe dynamically, see what the traffic is like, decide whether to make it static.
  • Test cross-mode bridges — set up DMR-to-YSF cross-mode and try keying a YSF reflector from the DMR-only D878.
  • Customise Nextion screens — try a new HMI layout from WA6HXG’s repo, or edit the layout in the Editor and load a custom version.
  • Run WPSD nightlies — chase upstream features (the W0CHP project ships new dashboard widgets and modem features regularly).
  • Slot-2-routing experiments — try a different network on each slot, see what the operational experience is like, decide whether to keep it.

The contrast is that the SkyBridge is the always-on home-base hotspot that doesn’t get touched between firmware updates — same configuration for months at a stretch. The DIY hotspot is the one that gets reconfigured, tinkered with, occasionally rebooted, and kept current with upstream. Together they provide both the experimentation surface and the reliability floor.

7. Tips and tricks

The non-obvious things worth knowing about running a DIY WPSD hotspot for any length of time:

WPSD vs Pi-Star — the fork story

Mainline Pi-Star (by MW0MWZ) slowed in development around 2022-2023; the upstream pace of MMDVM features had moved past what mainline was tracking. W0CHP-PiStar-Dash (WPSD) is the community fork that took over active development — same Pi-Star foundation, refreshed dashboard, modernised internals, current-with-upstream MMDVM features. By the time of writing (mid-2026), WPSD is effectively the de facto Pi-Star: the W0CHP project ships nightly and stable builds, has an active support community, and is what almost all new hotspot deployments default to. Mainline Pi-Star still exists and still works for older deployments, but new builds should start from WPSD. Jeff’s migration from Pi-Star (2022) → WPSD (sometime between 2022 and December 2025, per the backup-file naming progression) reflects this transition. The W0CHP project home is https://w0chp.radio; the legacy mainline Pi-Star is at https://www.pistar.uk.

Nextion screen-burn — dim or sleep

The Nextion’s TFT will exhibit faint persistent-image artefacts if it shows a static layout for years (the same fate as any LCD). The mitigation is the dashboard’s Display panel “screen dim after N minutes idle” setting — set it to 10-15 minutes, and the Nextion backlight drops to a low level when there’s no activity for that interval. A full screen-off after a longer interval (30-60 minutes) is even better; the layout returns instantly when any RF activity wakes the hotspot. The WA6HXG layouts include the screen-saver / dim hooks in the layout’s MMDVMHost integration; the WPSD dashboard exposes the timeout values.

Nextion screen sizes — the layout-file mismatch trap

The WA6HXG layouts come in three matched size families — 2.4” / 3.2” / 3.5” — and each .tft file is sized for exactly one Nextion variant. Uploading a 3.5”-sized layout to a 2.4” Nextion produces a layout that’s cropped, off-position, or completely blank; uploading a 2.4” layout to a 3.5” Nextion produces a layout occupying the upper-left corner with empty space everywhere else. The naming convention in the archive (Blue1_Duplex_24in_LHnLHTG_GB_2.0.tft for 2.4” duplex, Blue1_Duplex_32in_LHnLHT_GB_2.1.tft for 3.2” duplex, Blue1_Duplex_35in_LHnLHT_2.0.tft for 3.5” duplex) lets you pick the right one if you know the Nextion’s actual size. Verify the size by reading the part number off the Nextion’s back before flashing; the size is encoded in the Nextion model number (e.g., NX4827T035 for a 3.5” model).

Duplex hat — both timeslots actually serve

For the operator coming from a simplex hotspot (or from a simplex understanding of how DMR works), the duplex hat’s both-slots-active behaviour is sometimes surprising. The dashboard’s Slot 1 and Slot 2 panels are independent — talkgroup statics for Slot 1 don’t affect Slot 2, and inbound traffic on a Slot 1 talkgroup does not block Slot 2. If both slots have inbound at the same moment, the hat actually transmits both, interleaved on the TDMA cycle, and the radio decodes whichever slot its current channel is tuned to. This is real, and it’s the right behaviour for a duplex hotspot pretending to be a Tier II repeater.

microSD card health — pick the high-endurance line

WPSD logs to /var/log/pi-star/ continuously; over years of always-on operation, a consumer-grade microSD will eventually wear out. The Samsung PRO Endurance line is the canonical choice (rated for 140k+ hours of continuous video recording, so basically forever for the WPSD write workload); SanDisk High Endurance is the second-tier option. A 32 GB or 64 GB card is plenty; bigger doesn’t help because WPSD’s actual disk footprint is well under 10 GB. Replace the card every 2-3 years as preventive maintenance even if it’s still working — the cost of a fresh card is $15-20, the cost of a card failure at the wrong moment (an unreachable hotspot during a fire drill, a corrupted config that you had to remember everything to rebuild) is much higher. The WPSD_Config_*.zip backups make replacement painless.

Frequency coordination — avoid local repeater pairs

For duplex operation specifically, you need to clear both the TX frequency and the RX frequency against the local repeater plan within a ~5 mile radius. A local repeater on a frequency you’d otherwise want for the hotspot’s RX side will desense the hotspot’s receiver into uselessness; a local repeater on the hotspot’s TX side is a different category of problem (the hotspot’s tiny TX power doesn’t disrupt the local repeater, but the local repeater’s traffic appears on the hotspot’s TX frequency as background noise the dashboard reports). Use the published low-power simplex / hotspot allocation in your regional repeater plan; in Michigan that’s coordinated by the Michigan Amateur Radio Council. The deep regulatory framing is in Vol 22 (Frequency Planning) and [Antennas Vol 31 (Regulatory & RF Safety)](../../../Hack Tools/Antennas/02-inputs/volume_sources/vol31.md).

External antenna — but lower TX power is better

The temptation when running a DIY hotspot is to upgrade the stock rubber-duck antenna to something bigger (a J-pole, a Slim Jim, a small Yagi) and then crank the TX power up. Resist both. The hotspot’s purpose is local-room bridging, not wide-area coverage. A bigger antenna mostly increases the local-RFI footprint and makes the hotspot a more conspicuous RF spur in the room; cranking TX power buys you nothing on the receive side and risks splashing into the neighbour’s electronics. Keep the stock antennas (or upgrade to slightly more efficient short whips), keep TX power at 10-20 mW, and put the hotspot in the same room as the radio. This is the same argument as Vol 18 §6 (Antenna placement and RF posture); duplex operation doesn’t change it.

MMDVMHost.ini is canonical — back up before SSH-editing

The dashboard exposes most of the configuration but not all of it. When you SSH in and hand-edit MMDVMHost.ini or DMRGateway.ini or one of the gateway INIs, the changes persist across daemon restarts but may be overwritten by the next dashboard Save (since the dashboard regenerates the INI from its own state). The discipline: SSH-edit only when you know the change is something the dashboard wouldn’t touch (rare configuration items, log-level adjustments), and back up the entire /etc/pi-star/ tree before any SSH-side editing. The dashboard’s Backup/Restore ZIP captures the tree; a tar -czf /tmp/pre-edit-backup.tgz /etc/pi-star/ over SSH is the same thing with a different filename.

Active development — check the W0CHP project monthly

The W0CHP project ships updates frequently — new dashboard widgets, new modem firmware revisions, new gateway features. The dashboard’s Update panel checks for them; visit the panel monthly, apply stable releases when they appear. The DIY hotspot’s whole point is to track upstream faster than the SkyBridge does; tracking means occasionally checking what landed, which is a 30-second task once a month.

Build photo reference — Pix - My HotSpot Build/

The seven photos from April 2022 in programs/wpsd-hotspot/Pix - My HotSpot Build/ document the original build sequence — which enclosure, how the Nextion ribbon was routed, where the antennas were mounted, what the assembled stack looked like. If a future rebuild is needed (case crack, Pi replacement, Nextion swap), the photos are the reference for “how it was assembled the first time” and “what the working layout looks like.” They are also the only photographic record of which specific MMDVM hat and Nextion display Jeff installed — the silkscreens and model numbers should be visible in at least one of the photos.

DMR roaming — configure the D878 to prefer the DIY hotspot when in-range

The AnyTone D878 supports roaming zones (Vol 5) — a list of channels the radio scans through and picks based on signal strength. Configure a roaming zone that contains both the SkyBridge channel and the DIY hotspot channel(s), and the radio will automatically prefer whichever has the stronger signal. For the same-room two-hotspot deployment, this means the radio picks the closer hotspot without manual zone switching. For the case where you walk out of range of both (out the front door, into the car), the roaming zone falls through to a local repeater channel if one is configured, then loses contact gracefully. The roaming-zone CPS workflow is in Vol 5 §4 (Programming workflow).

The Pi-Star → WPSD migration was painless

For anyone considering the same migration from a working Pi-Star setup: the WPSD migration is in-place from a recent Pi-Star image. Download the WPSD upgrade tool from the W0CHP project, SSH in, run the upgrade, the system reboots into WPSD with all of the Pi-Star configuration preserved. The dashboard skin changes, a few menu items move, but every callsign / DMR ID / frequency / talkgroup / network connection stays where it was. Jeff’s archive shows the discrete jump from Pi-Star_Config_* (2022) to WPSD_Config_* (2025) — same hotspot, same configuration, different dashboard.

8. Resources

Local manuals and configuration backups (../../programs/wpsd-hotspot/):

  • WPSD_Config_tjs-duplex_2025-Dec-29.zip — most recent dashboard export (entire /etc/pi-star/ config tree under the current tjs-duplex hostname)
  • W0CHP - DMR config and notes.xlsx — per-hotspot configuration notes spreadsheet (talkgroup map, frequency plan, API key cross-references)
  • wpa_supplicant.conf.docx — Wi-Fi credentials in wpa_supplicant.conf format wrapped in a Word document (do NOT publish)
  • FBI_Surveillance_Van__3.nmconnection — NetworkManager Wi-Fi profile (same SSID + PSK in NetworkManager format)
  • Pix - My HotSpot Build/ — 7 build photos from April 2022 documenting the assembly
  • Nextion Display/MMDVM-Nextion-Screen-Layouts-master/ — WA6HXG’s HMI layout repository snapshot (HMI + TFT files for 2.4” / 3.2” / 3.5” Nextion variants, Blue and Green schemes, Simplex and Duplex flavours)
  • Nextion Display/Info Sheets/EDITOR NEXTION.pdf — Nextion Editor reference manual
  • Nextion Display/Info Sheets/NEXTION_Tutorial_v2.03.pdf — Nextion display tutorial
  • Nextion Display/Info Sheets/Status Codes and Fields.txt — MMDVM-to-Nextion command reference (GitHub snapshot of the WA6HXG repo’s status-codes file)
  • Nextion Display/STEP Files/Raspberry Pi 4 Model B.STEP — Pi 4B reference 3D geometry for enclosure design
  • Nextion Display/nextion-setup-vLTS/NextionEditor.exe — Nextion Editor vLTS (the layout editing tool, Windows-only)
  • pi-star-legacy/ — archive of pre-WPSD Pi-Star configurations:
    • Pi-Star_RPi_V4.1.5_30-Oct-2021.zip — original upstream Pi-Star image (October 2021)
    • Pi-Star_Config_2022-Mar-24.zip — first-build configuration snapshot (24 March 2022)
    • BridgeCom_Pi-Star_Config_2022-Mar-26.zip — BridgeCom-skinned variant tried briefly two days later
    • Duplex/Pi-Star_Config_pi-star-duplex_2022-Apr-20.zip — duplex configuration at the earlier pi-star-duplex hostname

Upstream open-source projects:

Nextion (vendor and tooling):

MMDVM hat vendors and references:

DMR network registration and infrastructure:

Cross-references within this series:

Cross-references into the sibling Hack Tools/Antennas project:

  • [Antennas Vol 29 (Use-case Matrix)](../../../Hack Tools/Antennas/02-inputs/volume_sources/vol29.md) — hotspot-antenna recommendations (low-gain wins for hotspots), per-radio antenna treatment
  • [Antennas Vol 31 (Regulatory & RF Safety)](../../../Hack Tools/Antennas/02-inputs/volume_sources/vol31.md) — Part 97 regulatory framing for low-power amateur transmitters

Wider amateur DMR references: