Scanners & Radios

Scanners & Radios · Volume 18

SkyBridge Plus

BridgeCom commercial DMR hotspot — turnkey appliance

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 BridgeCom SkyBridge Plus is the turnkey commercial DMR hotspot in Jeff’s lineup — a small Raspberry Pi Zero W / MMDVM-hat appliance assembled in a BridgeCom-branded enclosure, factory-flashed with a customised WPSD (W0CHP-PiStar-Dash) image, with a small OLED status display on the front and a single-port SMA antenna jack on top. It earns the bench slot as the set-and-forget DMR hotspot: pre-configured at the factory, sold as a complete unit by a US distributor with US support and warranty, no soldering, no firmware compile, no Pi-flash, no MMDVM-hat sourcing. Power it up, walk it through the captive-portal Wi-Fi onboarding from a phone, point a browser at its hostname, fill in the BrandMeister and TGIF and W0CHP credentials, and start talking. That is what the SkyBridge product line solves — the time-to-first-QSO penalty of a DIY MMDVM build, in exchange for the appliance premium and a slight lag on the cutting-edge feature flags that the upstream MMDVM and WPSD communities release first.

The contrast that runs through this volume and the next is the duality between this appliance and the DIY WPSD hotspot in Vol 19 (DIY WPSD HotSpot). Both are based on the same upstream open-source stack — a Linux distribution on a Raspberry Pi (Zero W for the SkyBridge, anything from Zero W through Pi 4 for the DIY) running W0CHP’s WPSD fork of the MMDVMHost / DMRGateway / YSFGateway / NXDNGateway / P25Gateway / DAPNETGateway family of MMDVM-protocol bridge daemons. Both can serve the AnyTone D878UVII PLUS (Vol 5) sitting on Jeff’s desk; both bridge that radio’s local low-power UHF DMR signal to BrandMeister, TGIF, W0CHP, FCS reflectors, and XLX rooms over the internet. The DIY hotspot (Vol 19) costs roughly USD 50 to build, takes a few hours of assembly and configuration, and gives Jeff a Nextion 3.5” touch display, full SSH and Pi-Star-CLI access, and the ability to track WPSD nightly builds. The SkyBridge Plus retails at BridgeCom for around USD 230-280 mid-2026 (TBD — verify with Jeff against the current bridgecomsystems.com price), comes in a finished enclosure with the small OLED instead of a touch display, ships with the BridgeCom SkyBridge custom dashboard skin (which gates some of the wilder WPSD options behind their support model), and runs whatever firmware BridgeCom has currency-tested and signed off on. Jeff owns and runs both — the SkyBridge is the home-base hotspot that sits on the shelf next to the desk and stays up for months between reboots, the DIY WPSD is the experiment platform that gets reflashed and reconfigured when an upstream WPSD feature is worth chasing.

Why someone picks the SkyBridge over the DIY: appliance reliability, factory burn-in, US distributor support, no firmware-flash anxiety, no MMDVM-hat sourcing in a market full of clones with varying-quality TCXOs, no enclosure 3D-print or laser-cut, a label on the back, and a serial number that means something to a vendor when something breaks. Why someone picks the DIY WPSD instead: cost (BOM around USD 50 vs USD 230+ retail), customisation freedom, the Nextion display instead of the OLED, the learning experience of building the stack from a flashed SD card up, and faster access to upstream-WPSD feature flags. Both produce essentially the same on-air experience — the same MMDVM protocol on the air, the same network bridges to BrandMeister and TGIF, the same talkgroup quality on the audio side. The difference is in the support model and the tinker-friendliness, not in what comes out of the speaker on the other end of the link.

Cross-link discipline: the network on the other end of the bridge — what BrandMeister and TGIF and W0CHP actually are, how talkgroups are addressed, what colour codes and slots mean at the protocol layer — is the load-bearing subject of Vol 20 (DMR Network Architecture), and most of what’s in this volume about TG numbers and slot conventions is shorthand for the deep treatment over there. The radio that talks to this hotspot is the AnyTone AT-D878UVII PLUS in Vol 5. The frequency-coordination question — pick a hotspot frequency that doesn’t stomp on the local repeater plan — is in Vol 22 (Frequency Planning & License Envelope) and gets a cross-tool regulatory framing in [Antennas Vol 31 (Regulatory & RF Safety)](../../../Hack Tools/Antennas/02-inputs/volume_sources/vol31.md). The hotspot-specific antenna case (you actually want a low-gain antenna here, an unusual conclusion) is in [Antennas Vol 29 (Use-case Matrix)](../../../Hack Tools/Antennas/02-inputs/volume_sources/vol29.md).

2. Hardware tour

Physically the SkyBridge Plus is a small cube, roughly 3”x3”x2” (76x76x51 mm) in a black anodised aluminium or black-PC enclosure with the BridgeCom SkyBridge logo silk-screened on the top face. Weight ~150 g with the antenna. It is small enough to sit on a bookshelf, on a desk under a monitor stand, or atop a Wi-Fi router without making the user feel they have lost shelf space.

Front face carries the 0.96” OLED display (SSD1306 controller, white-on-black, 128x64 pixels, four lines of small status text). The display cycles between several screens — current TX/RX state, current talkgroup, network connection status, IP address, callsign and DMR ID — at a configurable interval. The font is small but legible at desk distance. Below the OLED sit three status LEDs: a green power LED, a blue network/Wi-Fi LED that flickers with traffic, and a bi-colour TX/RX LED that lights green on receive and red on transmit. The LED layout makes the appliance read-at-a-glance from across the room — “is it talking”, “is it listening”, “is it connected” are all visible without looking at the OLED.

Top edge carries the antenna jack and, on some revisions, a small reset hole that pokes a momentary switch on the MMDVM hat for resetting the Pi without unplugging. The antenna jack is SMA-female on the box, mating with an SMA-male centre-pin antenna — the same convention as the AnyTone D878 (see Vol 5 §2 for the SMA-male / SMA-female trap that catches every first-time owner). The bundled stock antenna is a small straight whip, roughly 10 cm long, helically wound and tuned for the amateur 70 cm band (430-450 MHz). TBD — verify the exact antenna jack flavour (SMA-female vs RP-SMA) with Jeff against the bench unit; both flavours have been shipped on hotspots in the broader market and the antenna in the box has to match.

Rear face carries the USB-C power input and the microSD slot. The power input is a plain 5 V DC USB-C — no USB-PD negotiation, no fancy power-delivery handshakes; any reputable 5 V 2 A USB-C supply works (the bundled BridgeCom supply is a 5 V 2 A unit). The microSD slot accepts the standard Pi-flashable card; the BridgeCom factory image is on a card pre-installed at assembly. On some hardware revisions the microSD is accessed from the rear of the enclosure directly; on other revisions the enclosure has to be cracked open to swap the SD card (TBD — verify with Jeff against the bench unit). Ethernet is not present — the SkyBridge is Wi-Fi only, which simplifies the enclosure and matches the wireless-by-default deployment posture of a personal DMR hotspot but ties the device to Wi-Fi reliability (see §7 for the most-common-failure-mode discussion).

Internal architecture: a Raspberry Pi Zero W (the original ZW with the BCM2835 single-core ARM11 at 1 GHz, 512 MB LPDDR2, 802.11n single-band 2.4 GHz Wi-Fi, BLE 4.1) is the host. TBD — verify whether the current SkyBridge Plus revision still ships on Zero W or has moved to Pi Zero 2 W (BCM2710A1 quad-core Cortex-A53 at 1 GHz, same 512 MB but faster); both are footprint-compatible and BridgeCom does refresh the SBC over the life of the product. On top of the Pi sits the MMDVM hat — the small daughter-board with a TCXO, an MCU (typically STM32F103 class), the RF baseband and modulator/demodulator, and a single-port radio module that handles TX/RX on the 70 cm (or 2 m) amateur band at 10-20 mW. TBD — verify the exact MMDVM hat model (BridgeCom has historically used the ZUM Radio MMDVM_HS_HAT, Jumbo-Spot clones, and at one point a BridgeCom-branded variant; the supply chain on MMDVM hats has moved over the years and which one ships in the current SkyBridge depends on the build date). The single-port (vs duplex two-port) decision is meaningful — see §3 — and is verifiable from the visible PCB through the enclosure or by checking the WPSD dashboard’s “Modem” panel which reports the hat ID at boot.

Power consumption: ~250 mA at idle, ~400 mA at TX, peaks below 600 mA. A 5 V 1 A supply is technically enough but the headroom of 5 V 2 A handles the boot-time current spike on Pi Zero W gracefully; see §7 for the underpowered-supply failure mode.

3. Operating modes

The MMDVM stack on the SkyBridge Plus is the same stack that runs on every Pi-Star and WPSD derivative, so the modal capability list reads identically:

DMR (the primary mode — Tier I and Tier II)

DMR is what this hotspot is bought for. The MMDVM modem on the SkyBridge is a duplex-capable design — it can operate simplex (single frequency, TX and RX on the same channel) or duplex (separate TX and RX frequencies with an offset, the classic repeater split). For amateur hotspot use the simplex mode is the common configuration: a single 70 cm or 2 m frequency, typically in the local repeater coordinator’s published “low-power simplex / hotspot” allocation, with the radio’s TX and RX on the same frequency at low power. The duplex mode is used when the hotspot is operated as a small repeater (the SkyBridge becomes the time-multiplexed RF point that two amateur radios both link into independently, on a +/- 600 kHz or +/- 5 MHz split). Both Tier I (FDMA simplex DMR between two radios direct, no infrastructure) and Tier II (TDMA repeater-style with two timeslots interleaved on a 12.5 kHz channel) are supported in firmware; the practical operational mode for a personal hotspot is Tier II simplex, where the hotspot acts as the repeater and the radio (the D878) is the only client. See Vol 20 §3 (DMR protocol layer) for the deep treatment of Tier I vs Tier II and what slots mean at the radio link level.

The hotspot connects out to one of four DMR network families: BrandMeister (the largest, ~140k registered DMR users worldwide as of mid-2026), TGIF Network (smaller and more community-driven, easier and lower-friction hotspot onboarding), W0CHP (the network associated with the WPSD dashboard the SkyBridge software is based on), and the FCS reflector / XLX room ecosystem (a federated bridge of regional reflectors). Selection is per-channel — the WPSD dashboard’s DMR Configuration page lets you pick a primary network and optionally bridge a second network onto the second slot, so a single hotspot can serve BrandMeister talkgroups on slot 1 and TGIF talkgroups on slot 2 simultaneously, or any combination. Vol 20 covers the network-architecture distinctions.

D-STAR, YSF (Yaesu System Fusion), P25, NXDN, M17

The MMDVM stack supports all five of these digital amateur modes in firmware — the MMDVM modem is mode-agnostic, the per-mode protocol decode happens in the daemon on the Pi, and the Gateway daemon for each mode bridges to that mode’s network (D-STAR connects to REF/XRF/XLX reflectors, YSF to YSF reflectors, P25 to P25Reflector / PiStarReflector, NXDN to NXDN reflectors, M17 to the M17 network). Whether the SkyBridge Plus enables each of these by default depends on the BridgeCom factory image — the upstream WPSD makes all of them available out of the box, and BridgeCom’s customisations generally preserve that. Enabling a non-DMR mode is a matter of flipping the corresponding “Modem Type” toggle in the dashboard and configuring the gateway server for that mode. For an operator with the AnyTone D878 (Vol 5) as the only radio, only DMR is practically useful — the D878 doesn’t transmit D-STAR or YSF or P25 — but enabling YSF and pointing the hotspot at YSF reflector “YSF America” for ambient listening is a no-cost feature given the firmware already supports it.

Cross-mode (DMR-to-YSF, DMR-to-D-STAR via DMRGateway)

DMRGateway can bridge DMR talkgroups to YSF rooms or D-STAR reflectors via the cross-mode protocols (DMR2YSF, DMR2NXDN, etc.). This lets a DMR-only radio (the D878) effectively talk on a YSF reflector by keying a DMR talkgroup that DMRGateway has cross-routed to a YSF gateway. The mode is mature on WPSD; on the SkyBridge the BridgeCom dashboard exposes the most-common cross-mode bridges as toggleable features. Useful for talking to a YSF-only contact without owning a Yaesu radio.

Frequencies and band selection

The MMDVM modem on the SkyBridge supports both amateur 2 m (144-148 MHz) and amateur 70 cm (430-450 MHz) bands, software-selectable per channel. The common deployment is 70 cm — 433-435 MHz simplex hotspot frequencies are the convention in the US after coordination with the local repeater coordinator. 2 m is supported but the band is more congested and the smaller hotspot antenna is less efficient at 2 m; in practice most US amateur hotspot operators run 70 cm. Frequency selection should be coordinated against the local repeater plan — see Vol 22 for the deep treatment and §4 below for the operational discipline. The 222 MHz (1.25 m) band is not supported by the MMDVM modem; if you want a 1.25 m DMR hotspot you’re shopping in a different product category.

4. Hotspot configuration workflow

The SkyBridge Plus is web-managed end to end — once it is on the local network there is no command-line discipline required to configure it for normal operation. The configuration sequence below is for first-power-up out of the box.

Onboarding — the Wi-Fi captive-portal trick

On first power-up, the SkyBridge boots into an AP mode — it advertises a Wi-Fi network with a SSID like “BridgeCom-Pi-Star-Setup” or similar (the BridgeCom variant of the upstream WPSD Wi-Fi-onboarding pattern), with an open-network captive portal that lets the user join their home Wi-Fi from a phone or laptop. Connect a phone to that SSID, accept the captive-portal redirect, fill in the home SSID and PSK, and the SkyBridge writes a wpa_supplicant.conf to the boot partition, reboots, and joins the home network as a client. The whole onboarding flow takes 2-5 minutes. Jeff’s wpa_supplicant.conf.docx in ../../programs/wpsd-hotspot/ holds the credentials for both hotspots (the SkyBridge and the DIY WPSD); the NetworkManager-style profile at ../../programs/skybridge-plus/FBI_Surveillance_Van__3.nmconnection is the modern alternative for environments where NetworkManager is the supplicant rather than wpa_supplicant — the SSID in the filename is the Wi-Fi network the SkyBridge is currently joined to (it has previously been on FBI_Surveillance_Van_3 and FBI_Surveillance_Van_4 — the family Wi-Fi keeps the same prefix and bumps the trailing number as routers get swapped). Both supplicant flavours produce the same end-state — the Pi Zero W on board the SkyBridge is joined to the home Wi-Fi as a DHCP client.

Finding the device on the LAN

After the SkyBridge joins the home network, it advertises mDNS as skybridge.local (or a similar BridgeCom-customised name; TBD — verify against the bench unit), and it accepts a DHCP-assigned IP from the home DHCP server. The browser-side workflow is to point a browser at http://skybridge.local/ (or the IP from the router’s DHCP-lease table) and the WPSD dashboard appears. Default login credentials are pi-star / raspberry (the upstream WPSD default, unchanged by BridgeCom on the factory image) — change them on first login from the dashboard’s Configuration > Security panel. The WPSD dashboard is the entire administrative surface.

Core configuration items

In the WPSD dashboard’s Configuration panel, fill in the following for a working DMR hotspot:

  • Callsign — the operator’s amateur callsign (Jeff’s N0SWN). Used as the identifier on every DMR transmission and on the dashboard.
  • DMR ID — the 6- or 7-digit DMR ID from radioid.net, registered against Jeff’s amateur callsign with proof-of-license. The same DMR ID is used in the radio’s codeplug (Vol 5 §6).
  • Frequency (TX and RX) — the hotspot’s operating frequency. For simplex operation, TX = RX; for duplex, set the +/- offset. Pick a frequency in the local repeater coordinator’s published low-power-simplex / hotspot allocation. 70 cm common choices in the US fall in the 433-435 MHz range; verify against your local repeater plan before committing.
  • Colour code — DMR’s per-channel layer-1 squelch tone, integer 0-15. Convention for a personal hotspot is CC 1, which is also the default in the BridgeCom factory image and matches the default on a fresh AnyTone D878 channel.
  • TX power — typically 10-20 mW on the hotspot. The MMDVM hat exposes a “TX Level” parameter (range 0-255, with the BridgeCom factory default around 60-80 which corresponds to roughly 10-20 mW EIRP on the small stock antenna). The hotspot is a same-room companion to the radio; it does not need more power. See §7 for the “don’t try to extend range” point.
  • Network selection — choose one or more of BrandMeister / TGIF / W0CHP / DAPNET / FCS / XLX. Each network has its own dashboard sub-panel with a server hostname, a personal API key (BrandMeister and TGIF require account registration on the network’s website to issue a key), and a connection-status indicator. The BridgeCom factory image pre-populates the network server hostnames; the user fills in the API keys.
  • Talkgroup routing — split between static talkgroups (always-on, the hotspot transports traffic from these talkgroups onto the local RF channel without requiring the radio to key) and dynamic talkgroups (the hotspot subscribes when the radio keys to that talkgroup, holds the subscription for a timeout period (typically 15 min), then releases). The static / dynamic distinction is a BrandMeister network concept; TGIF handles it differently. See Vol 20 §6 (Talkgroup hygiene) for the operational treatment.
  • Modem type — the dashboard’s Modem panel; pick the MMDVM hat model that matches what’s installed in the SkyBridge. The BridgeCom factory image has this pre-set correctly; only change it if the hat has been swapped.

The dashboard’s Save button writes the changes to the WPSD config tree under /etc/pi-star/ (the legacy WPSD path retained for backward compatibility with the upstream Pi-Star tooling), restarts the affected daemons (MMDVMHost, DMRGateway, etc.), and shows the new state in the live dashboard panels within ~10 seconds. No reboot is required for any change other than network-mode toggles.

Firmware updates

BridgeCom periodically releases SkyBridge firmware updates — these are bundled as a WPSD-formatted update package that the dashboard’s Configuration > Update panel can download and apply. The cadence is roughly monthly; major updates (new WPSD upstream releases) are quarterly. The update preserves the user’s configuration; the BridgeCom support apparatus is the right escalation path if an update misbehaves on a specific deployment. As of mid-2026 the current SkyBridge image is built on a WPSD release from a few months back (TBD — verify exact build date and version against the bench unit by reading the dashboard’s “About” panel). The conservative cadence — compared to running upstream WPSD nightlies on the DIY hotspot in Vol 19 — is precisely the appliance-vendor tradeoff that distinguishes the SkyBridge from the DIY: BridgeCom validates each release before pushing it, at the cost of running a few weeks behind the upstream cutting edge.

Optional advanced configuration

For the operator who wants more than the dashboard exposes, SSH is available — ssh pi-star@skybridge.local, password raspberry (change on first login). The SSH access opens up the underlying Linux filesystem, the WPSD daemon configurations, and the standard MMDVMHost / DMRGateway / YSFGateway config files. BridgeCom’s support stance is that SSH access is unsupported — if you change something via SSH and break the dashboard, you’re on your own to fix it — but the door is open. Most operators never need to. The configuration items that occasionally justify SSH access: editing the MMDVMHost RxLevel and TxLevel parameters more finely than the dashboard’s slider, custom cron jobs for log rotation, manually editing DMRGateway.ini for advanced routing rules. For routine operation the dashboard is enough.

5. Network config backups

The WPSD dashboard’s Configuration > Backup/Restore panel exports the entire /etc/pi-star/ config tree plus MMDVM.ini, MMDVMHost.ini, DMRGateway.ini, the YSF/NXDN/P25/M17 gateway INIs, and the Wi-Fi credentials into a single timestamped ZIP file. The ZIP is downloadable through the browser to the local machine; restore is the inverse — upload the ZIP through the same dashboard panel and the WPSD stack writes back the saved tree and restarts the daemons. The Backup/Restore mechanism is the only sanctioned way to migrate a configuration between SkyBridge units (e.g. RMA replacement) or between major firmware updates.

Jeff’s local backup hierarchy lives under ../../programs/skybridge-plus/:

programs/skybridge-plus/
├── SkyBridge Plus.xlsx                  ← config notes, serial number, DMR ID, frequency, talkgroup map
├── WPSD_Config_skybridge_2025-Dec-29.zip ← most recent WPSD export
└── FBI_Surveillance_Van__3.nmconnection ← NetworkManager profile for the SkyBridge's Wi-Fi

The SkyBridge Plus.xlsx spreadsheet is Jeff’s per-device configuration record — sheet tabs for the serial number / asset tag / purchase date, the configured DMR ID and callsign, the operating frequency (TX and RX, colour code, slot, network), the static talkgroup list, the dynamic talkgroup allowance, the bound API keys (redacted in the spreadsheet — the actual API keys live in the WPSD config ZIP), and a free-form notes column for “what I changed and why.” The spreadsheet is the cross-check against the dashboard — if the dashboard shows a different state than the spreadsheet, one of them is wrong and the operator’s first task is to figure out which.

The WPSD_Config_skybridge_2025-Dec-29.zip is the most recent dashboard export, dated 2025-12-29. The cadence Jeff maintains: re-backup quarterly, before every firmware update, and after any non-trivial configuration change (new talkgroup added, network changed, frequency changed, API key rotated). The filename convention is WPSD_Config_skybridge_YYYY-MMM-DD.zip to match the BridgeCom-side timestamping.

The FBI_Surveillance_Van__3.nmconnection file is the NetworkManager-format profile for the SkyBridge’s Wi-Fi connection — the SSID (the family Wi-Fi prefix is “FBI_Surveillance_Van_” with a trailing version number, currently “_3”), the PSK, and the supplicant configuration. The file is Linux-formatted (newline conventions, file permissions in the comments) and would be dropped into /etc/NetworkManager/system-connections/ on a NetworkManager-driven Pi if the SkyBridge ever needed its supplicant rebuilt from scratch outside the dashboard. For a vanilla wpa_supplicant.conf reconstruction, the same credentials are also captured in ../../programs/wpsd-hotspot/wpa_supplicant.conf.docx (which covers both the SkyBridge and the DIY WPSD).

Restore workflow (the recovery procedure if the SkyBridge SD card fails or the image is corrupt):

  1. Acquire a replacement microSD with the BridgeCom factory SkyBridge image (BridgeCom sells these as a support service; or for a more involved recovery, the WPSD upstream image can be flashed and then customised back to SkyBridge configuration).
  2. First-power-up onboarding: connect to the AP-mode Wi-Fi, complete the captive-portal Wi-Fi join.
  3. Log into the dashboard at http://skybridge.local/, change the default password.
  4. Configuration > Backup/Restore > Upload the most recent WPSD_Config zip → click Restore. The dashboard unpacks the config tree and restarts the daemons.
  5. Verify the dashboard shows the expected callsign / DMR ID / frequency / talkgroups; verify the hotspot connects to BrandMeister and TGIF; key the AnyTone on the configured frequency and confirm the LED behaviour and the dashboard’s “Last Heard” list shows the transmission.

End-to-end recovery takes 15-30 minutes given a fresh SD card and the most recent backup. Without a backup, the recovery falls back to re-entering all the configuration items from the SkyBridge Plus.xlsx — which is precisely why the spreadsheet is the cross-check.

6. Network use

Talkgroup choice

The operational question with the highest impact on the on-air experience is which talkgroups the hotspot subscribes to. The deep treatment is in Vol 20 (DMR Network Architecture) — talkgroup numbering, geographic scope, ragchew etiquette per talkgroup, the static-vs-dynamic distinction, the difference between BrandMeister’s and TGIF’s talkgroup numbering spaces. The short version for SkyBridge operation:

  • TG 91 (BrandMeister Worldwide English chat) — the global English-language talkgroup. Always traffic; useful for “is my path up at all” verification. Don’t subscribe statically — it generates near-constant audio that drowns out everything else; subscribe dynamically only when you specifically want to listen.
  • TG 3100 (BrandMeister USA Nationwide) — US-wide. Moderate traffic; static subscription is reasonable if you want general ambient US chatter.
  • TG 31XX (BrandMeister US state talkgroups; 3162 is Michigan, 3148 is Massachusetts, etc.) — geographic state-level. Lower traffic; the right level for “I want to hear what’s going on in my state.” Static subscription is the usual choice.
  • TG 9990 (BrandMeister Echo Test) — the parrot. Key, talk, key again, the hotspot echoes back. The “is my path up and is my audio quality good” diagnostic.
  • TG 5057 (BrandMeister APRS gateway) — the DMR-to-APRS bridge. See Vol 5 §7 (APRS over DMR via TG 5057).
  • TGIF talkgroups are numbered differently and live in their own namespace — see Vol 20 §5 (TGIF). A common static subscription is TGIF 31 (US Nationwide on the TGIF side) for variety.

The general etiquette principle: don’t permanently link high-traffic talkgroups onto your local hotspot frequency — every transmission on that talkgroup will be transported to your hotspot’s local RF channel, which is fine when you want it and a noise pollutant when you don’t. The SkyBridge defaults that BridgeCom ships are conservative on this front; the dashboard’s talkgroup-static configuration tab is where Jeff curates the always-on set.

Antenna placement and RF posture

The hotspot antenna case is unusual in the broader antenna decision space: you want a low-gain antenna, not a high-gain one. The argument is:

  • The hotspot exists to bridge a same-room (or same-house) HT-to-internet link. The intended communication distance is feet, not miles.
  • Hotspot TX power is 10-20 mW — orders of magnitude below what a real repeater puts out.
  • A high-gain antenna on the hotspot does not extend useful range; it instead radiates the low-power signal more directionally, increases the local-RFI footprint into nearby electronics, and makes the hotspot a more conspicuous spur in the local RF environment.
  • If you actually need wide-area DMR coverage, you want a real repeater on a real tower with real power and real coordination — the hotspot is the wrong tool to scale up.

Keep the stock whip on the hotspot. Place the hotspot near the radio — same room, within ~5-30 ft (1.5-9 m) at the configured 10-20 mW. Avoid placing the hotspot inside a metal cabinet, behind a refrigerator, or on top of a Wi-Fi router (the 2.4 GHz Wi-Fi and the 70 cm DMR don’t directly conflict, but co-location with switching power supplies and high-current digital electronics generates broadband noise that degrades the receive sensitivity). Bookshelf, desk, or shelf height is the sweet spot. The deep antenna treatment for the hotspot pair (SkyBridge and DIY WPSD) is in [Antennas Vol 29 (Use-case Matrix)](../../../Hack Tools/Antennas/02-inputs/volume_sources/vol29.md) and the regulatory framing on low-power amateur transmitters is in [Antennas Vol 31](../../../Hack Tools/Antennas/02-inputs/volume_sources/vol31.md).

Radio-side configuration

The AnyTone D878 codeplug zone for the SkyBridge is a mirror of the WPSD-zone described in Vol 5 §6 — one zone called “HS-SkyBridge” (or “SkyBridge” or a shorter abbreviation), one channel per talkgroup of interest, all on the SkyBridge’s configured frequency (currently the 70 cm simplex frequency Jeff has provisioned — TBD — verify exact frequency against SkyBridge Plus.xlsx), all on slot 2 (community convention for hotspots), all on colour code 1. The talkgroups on those channels — 91, 3100, 3162, 9990, 5057, etc. — mirror the static and dynamic subscriptions configured on the hotspot. The 878’s promiscuous mode (see Vol 5 §7) is useful here for discovering what’s actually on the hotspot’s slot 2 even outside the codeplug’s curated set.

Bridging two hotspots in the same house

Jeff runs both the SkyBridge Plus and the DIY WPSD (Vol 19) at the same house. The two hotspots must operate on different frequencies — same colour code, same slot, but different RF channels — otherwise they desense each other and both lose receive sensitivity. The convention is to put them ~1-3 MHz apart in the 70 cm hotspot-frequency band, with each one configured against its own set of talkgroups (typical split: the SkyBridge handles BrandMeister, the DIY WPSD handles TGIF, so each network has a dedicated hotspot and the dashboards remain easy to read). The radio’s codeplug carries two zones, “HS-SkyBridge” and “HS-WPSD”, with one channel per (hotspot, talkgroup) tuple. Zone-knob switching between the two hotspots is one button on the 878.

Posture

The SkyBridge sits on a shelf, powered up 24/7, on the home Wi-Fi, on the home subnet, at the configured 70 cm simplex frequency, with the static talkgroup set BridgeCom and Jeff have agreed on. It is the always-on home-base hotspot. Reboots happen monthly-ish (during firmware updates) or when the home internet has been out long enough that the hotspot has lost its network connections and not reconnected cleanly. Cycle time is ~90 seconds from cold boot to “ready to bridge.”

7. Tips and tricks

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

BridgeCom firmware updates — the support-portal cadence

BridgeCom pushes SkyBridge firmware through their support portal rather than via the upstream WPSD auto-update flow. The dashboard’s Configuration > Update panel checks the BridgeCom update server, not the upstream WPSD update server. The practical implication: you can be a few weeks behind upstream WPSD on the SkyBridge, which is the appliance-vendor tradeoff at work. Check monthly; if a security advisory hits the upstream WPSD community, BridgeCom usually pushes a matching update within a week, but the latency exists and the user has no control over it. If immediacy on a specific feature matters, that is the DIY WPSD’s job — see Vol 19.

Last-heard transmissions across the network

The WPSD dashboard’s “Live Caller” and “Last Heard” panels show every transmission the hotspot has decoded, with caller’s callsign, DMR ID, talkgroup, duration, and RSSI. The view is intoxicating once you realise it — the “is anyone talking on the talkgroups I’m subscribed to” question goes from “press PTT and hope” to “scroll the dashboard panel.” Use it to find active talkgroups before committing them to the static-subscription set; use it to verify that a transmission you keyed was actually heard by the network.

OLED customisation

The 0.96” OLED on the front cycles through a small set of pre-defined screens (TX/RX state, talkgroup, network status, IP, callsign). The cycle interval and the screens shown are customisable via the dashboard’s Display panel — typically you can pick which screens to include, adjust the dwell time per screen, and pick a font flavour. Useful customisation: turn off the IP-address screen if you have the IP memorised, and increase the dwell on the “current talkgroup” screen, which is the one you actually look at when the radio’s mid-QSO.

Ghost activity

When the WPSD dashboard or the OLED displays TX/RX on a talkgroup you’re not listening to, it’s not a malfunction. The hotspot is receiving DMR network traffic from the talkgroup over the internet (because the talkgroup is in the dynamic-subscribe window or there’s a cross-mode bridge active), decoding it, queuing it for RF transmission, and turning on the TX LED. From the user’s perspective the hotspot looks like it’s “doing something” without being asked. This is normal — the dashboard’s “Live Caller” panel will show the inbound transmission. The only operational concern is that ghost activity on a busy talkgroup that’s been bridged onto your slot 2 will block your own transmissions until the inbound finishes; if this happens often, the talkgroup is too busy for static subscription and should be moved to dynamic.

Power supply quality matters more than it should

Pi Zero W is famously sensitive to USB-supply undervoltage. The factory BridgeCom 5 V 2 A supply is fine; a generic phone charger or a USB-C cable shared with a hub is sometimes not. The symptom is the WPSD dashboard’s “Under-voltage detected” warning at the top of the page; the on-air symptom is intermittent dropped transmissions and dashboard alerts. Use a known-good 5 V 2 A USB-C power supply or the BridgeCom-bundled one; don’t share the supply with another device through a hub. If you’re powering off a USB-C hub on a laptop, the laptop sleeping will drop the SkyBridge.

Frequency coordination is on you

Pick a hotspot frequency that is not used by local repeaters within roughly a 5-mile radius — the hotspot’s TX is low-power but its RX is wide-open, and a local repeater on the same frequency will desense the hotspot’s receiver into uselessness. Check your local repeater coordinator’s database (e.g. for Michigan, the Michigan Amateur Radio Council; for other regions, the corresponding state or regional coordinator) before assigning the hotspot’s frequency. Most regions publish a “low-power simplex / hotspot” allocation specifically for this case — use that range. The deep regulatory and band-plan treatment is in Vol 22 (Frequency Planning) and [Antennas Vol 31 (Regulatory & RF Safety)](../../../Hack Tools/Antennas/02-inputs/volume_sources/vol31.md).

Wi-Fi is the most common failure mode

The SkyBridge is Wi-Fi-only — no Ethernet. The Pi Zero W’s onboard 802.11n single-band 2.4 GHz Wi-Fi is functional but not robust under congestion; if the home Wi-Fi’s 2.4 GHz band is noisy (lots of neighbours’ APs, microwave ovens, baby monitors, USB 3 emissions) or if the router is on the other side of the house, the SkyBridge will intermittently drop its connection. The dashboard’s network status will show “disconnected” and the OLED will stop updating talkgroup activity. Most failures clear themselves on the next supplicant reconnect (which takes 30-90 seconds). Persistent failures usually mean the SkyBridge is too far from the access point — move the hotspot closer, add a 2.4 GHz mesh node near it, or accept that the appliance has a Wi-Fi reliability ceiling that the Ethernet-equipped DIY WPSD in Vol 19 doesn’t have. Keep wpa_supplicant.conf / the .nmconnection file backed up (already in ../../programs/skybridge-plus/ and ../../programs/wpsd-hotspot/) — if the SD card has to be reimaged, the Wi-Fi credentials are otherwise lost.

Don’t change colour code from 1 unless you have a reason

The DMR colour code is a per-channel layer-1 squelch — a radio with a different colour code on its channel won’t decode the hotspot’s transmissions even if everything else matches. CC 1 is the convention; the AnyTone D878 defaults to CC 1 on a new channel; every codeplug template uses CC 1; every shared-codeplug file uses CC 1. Don’t change it on the hotspot unless you have a specific reason (e.g. you’re operating two hotspots in close proximity on the same frequency and want to keep them from cross-talking, which is itself an unusual configuration). The hours-of-debugging trap is “I changed the hotspot to CC 5, forgot, then changed the radio codeplug and couldn’t figure out why nothing decoded.”

8. Resources

Local manuals and configuration backups (../../programs/skybridge-plus/):

  • SkyBridge Plus.xlsx — Jeff’s per-device configuration spreadsheet (serial, DMR ID, frequency, talkgroup map)
  • WPSD_Config_skybridge_2025-Dec-29.zip — most recent dashboard export (entire /etc/pi-star/ config tree)
  • FBI_Surveillance_Van__3.nmconnection — NetworkManager profile for the SkyBridge’s Wi-Fi (SSID + PSK + supplicant config)

Vendor pages:

Upstream open-source projects (the SkyBridge is built on these — useful for the SSH-and-tinker case):

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 (the “low-gain wins” argument), 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: