From Pi-Star to RadioStar: moving your hotspot to the DMRhub network

You already have a working MMDVM hotspot on Pi-Star — a Raspberry Pi with a modem, the web configurator at pi-star.local (on Windows — http://pi-star/), hand-editing of MMDVM.ini and the familiar fiddling with network settings. It's a great, time-proven foundation. But if you've decided to operate on the DMRhub network, there's an easier path: our RadioStar image. It detects the modem on its own, pulls its configuration from the portal and updates over the air — no manual MMDVM.ini editing. In this article we'll go over why RadioStar is more convenient than bare Pi-Star, how to migrate without losing data and what to check after the move. And most importantly — we'll definitely back up the working SD before overwriting it.

Why RadioStar is more convenient than hand-tuned Pi-Star

Pi-Star is a powerful all-in-one for every digital mode (DMR, D-STAR, YSF, P25, NXDN, M17, POCSAG paging). You pay for that versatility with configuration: you have to manually pick the modem type from a dropdown, enter frequencies, Color Code, DMR ID, networks and timeslots in the web configurator, and fine details have to be edited right in MMDVM.ini. For a single network those are extra steps. RadioStar is a narrowly focused image built exactly for DMRhub, and so it does almost everything itself:

• Modem auto-detection. On first boot the agent identifies the MMDVM modem (HS_Hat, Dual Hat, USB) by itself and applies the correct profile. On Pi-Star you pick the modem type by hand, and if you get it wrong the hotspot won't start.
• Configuration from the portal. Frequency, Color Code, talkgroups, timeslots — everything arrives from your DMRhub dashboard. Change the frequency on the site and the hotspot picks it up, without touching SSH or text files.
• The portal issues/binds the DMR ID. No need to register separately in a third-party registry and type the ID in by hand — the portal binds the identifier to your account automatically.
• OTA updates. The agent firmware and settings update over the air from the admin panel. No pistar-update over SSH and no risk of ending up with a half-updated system.
• BER calibration from the panel. Frequency drift of a cheap modem is cured with a BER sweep right in the dashboard — no manual tweaking of RXOffset/TXOffset in the ini.

Step 0. Full backup of the old Pi-Star card

This is not optional. We take a sector-by-sector image of the working card — it's both insurance and a ready-made "clone" for rollback. Power off the hotspot, remove the microSD and insert it into your computer's card reader.

• Windows. Win32 Disk Imager can read a card into a file: specify a .img file name, select the card's drive letter and click the Read button (Read, not Write). balenaEtcher won't do here — its Clone mode copies the card straight onto another card, and it can't save an image into a file.
• macOS / Linux. Via dd (find the device name with lsblk / diskutil list and triple-check it — a mistake in the name will wipe the wrong disk):

sudo dd if=/dev/sdX of=pistar-backup.img bs=4M status=progress
# sdX is your card. Get the letter wrong and you lose data on another disk.

Additionally, save the config backup of Pi-Star itself: in the web configurator, Configuration → Backup/Restore, the green down arrow — it downloads a zip with your settings. RadioStar doesn't need it directly, but it'll come in handy if you decide to go back to Pi-Star: on a new card with Pi-Star, in the same section you pick the file (Choose File) and click the green up arrow — the settings unpack back. Important: do not unzip the archive — Restore only accepts the whole archive. And separately write down on paper the key parameters from the configuration tab: the working RX/TX frequency, Color Code, modem type, any existing RXOffset/TXOffset (a hint for future calibration).

Step 1. What transfers automatically and what doesn't

The key difference in approach: RadioStar does not import the Pi-Star config — it builds the setup from scratch out of the "hardware + portal" combination. You barely need to transfer anything by hand. Here's where everything comes from:

So from the "paper note" of the previous step you'll really only need at most the frequency (to cross-check) and the old offsets as a starting reference for calibration. RadioStar and the portal will set up everything else themselves.

Step 2. Flashing the RadioStar image

The safest option is to take a separate, blank card for RadioStar and set the old Pi-Star card aside untouched for now. That way you keep an instant physical rollback: didn't like it — put the old card back in the Pi and everything's as it was. If you don't have a second card — that's exactly where the sector-by-sector backup from Step 0 saves you.

1. On the "Build image" page pick your Pi and modem — you get the file radiostar-pi.img.gz.
2. Flash it with Raspberry Pi Imager (Use custom) or balenaEtcher. Both programs read the compressed .gz — no need to unpack it. When asked about "OS customisation" in Imager, answer "No": the image is already preconfigured.
3. A detailed walkthrough of flashing the card, choosing a microSD and the first boot is in the separate article about the RadioStar image.

Step 3. Auto-provisioning: trust it or configure it

Insert the new card into the same Raspberry Pi with the same modem and antenna, apply power. From here on it's like a regular RadioStar install:

1. First boot — 60–120 seconds: the image expands the filesystem and starts the services. Don't pull the power.
2. The hotspot will bring up its own Wi-Fi network RadioStar-Setup — connect to it with your phone. If the page doesn't open by itself, go to http://10.10.10.10.
3. Pick your home Wi-Fi and enter its password — the same one the hotspot used to connect to that network on Pi-Star (it's your router's password, not the Pi-Star dashboard login). The hotspot will join your network.
4. Sign in with your DMRhub account. The agent will identify the modem, write MMDVM.ini itself, get the DMR ID and network profile from the portal and go on air.

This is exactly where the difference in approach shows: you don't open the Pi-Star web configurator, don't pick the modem from a list, don't type the frequency and Color Code into a form and don't dig into MMDVM.ini over SSH. Auto-provisioning does it for you, and further management moves into the dashboard on the portal.

Step 4. Checking after migration

The hotspot is up — now we make sure everything's in place:

1. Online in the dashboard. Open the DMRhub dashboard — the hotspot should show as online. That's the first and main sign of a successful migration: the portal ↔ agent link is established.
2. Cross-check the frequency and Color Code with what you wrote down from the old Pi-Star — they should match (or be the ones defined by the network profile).
3. Test call. Grab a radio, key up on a duty talkgroup, catch a reply. Check that you're heard and that you can hear.
4. BER calibration. If the radio "can't hear" the hotspot or the link drops — run a BER sweep right in the panel. Cheap modems drift in frequency; the panel will pick the correction automatically. The old offsets from Pi-Star are only a starting reference; the measurement gives the final result. See the details in the hotspot calibration guide.