Pi-Star troubleshooting
Flaming hoop vector art
by 31moonlight31, Shutterstock
Revised: Jan 2023; CC BY-SA; PDFs
As of Jan 1, 2024, this site is no longer being updated. It will remain available for some time for legacy reference.
Most up-to-date version:
amateurradionotes.com//pi-star-troubleshooting.htm
Part of the fun of exploring a feature-rich app like Pi-Star is to kick all the tires, flip all the switches, and jump through all the flaming hoops we can find. Of course, that means that sometimes things may break or we may fall down a rabbit hole and find ourselves standing before a door we don't quite fit through. When things aren't working as expected, here are some steps that may help.
Be persistent! Troubleshooting takes time and may really test a person's patience, but I also find that persistence usually pays off: it feels great to finally figure things out, and I almost always learn some things along the way. Also, make use of the Pi-Star User Forum. There are some very talented people helping out there; on many occasions, they helped me get past a issue I couldn't solve on my own.
Some possible troubleshooting steps
- Toggle – If a feature isn't working correctly, turn it off, then back on.
- Update and upgrade – Run a Pi-Star update via an SSH app like Termius, which in addition to updating the dashboard binaries and the hostfiles will also update the OS. And then run Pi-Star upgrade enough times until it says "You are already running the latest version."
- mount: / is busy – The Update process automatically switches Pi-Star into Read-Write mode, writes the updates, and then switches Pi-Star back into Read-Only mode. Occasionally, the process will fail to complete the switch back to Read-Only mode, and a message is displayed: "
mount: / is busy."
Other times, Pi-Star will start up in Read-Write mode.
When this happens, it typically doesn't work to manually switch Pi-Star back into Read-Only mode using the "rpi-ro" command. To fix this, there's a couple things that might work:
- The most reliable solution I've found is to shut down Pi-Star, power off the hotspot, and then quickly power it back on. After that, it often starts up properly in Read-Only mode.
- Sometimes it works to re-run Pi-Star Update and then Pi-Star Upgrade (even if you're on the latest version).
- Trouble re-opening the dashboard after updating – Sometimes after performing a Pi-Star update or a firmware update, for some reason the dashboard won't re-open in the browser when using the standard http://pi-star/ or http://pi-star.local/ URLs. When that happens, find the hotspot's IP address and use that. After the dashboard opens the first time using the IP address, the URLs should work again.
To find the IP address, I use an Android LAN scanner app.
- mount: / is busy – The Update process automatically switches Pi-Star into Read-Write mode, writes the updates, and then switches Pi-Star back into Read-Only mode. Occasionally, the process will fail to complete the switch back to Read-Only mode, and a message is displayed: "
- Apply changes – On the Pi-Star Configuration page, even if nothing there has been changed, click Apply Changes. I always do this after running a Pi-Star update, too.
- Clear your browser's cache – Close the Pi-Star dashboard, clear your browser's cache, then restart the Pi-Star dashboard.
- Mode disabled – If a mode is red in the dashboard's Modes Enabled section, that means an error has caused MMDVMHost to stop running. There are several possible causes, including:
- Using a blocked frequency in the satellite range. Take a look at the frequency selected on the Configuration page. If it is highlighted red, it is in the satellite frequency range and you'll need to select a different frequency. For more info, see Change frequency below.
- Incorrect radio/modem selected, for example, a simplex radio/modem is selected but the hardware is duplex (or vice versa). Verify your Radio/Modem Type selected in the General Configuration settings.
- Firmware is corrupted or out of date, or the incorrect firmware was flashed for the radio/modem board. You may need to re-flash the firmware. Make sure the firmware you're flashing matches the board. For more info, see Update or re-flash firmware below.
- One thing you can do to troubleshoot this issue is to open the Live Logs view in a second browser tab, Apply Changes on the Configuration page, and read through the resulting logging to see if you can spot the issue.
- Move radio – Try moving the radio; in some cases, being too close can desense the hotspot's receiver. Also, try turning your radio off and back on.
- Verify Radio/Modem type – Make sure you have selected the correct Radio/Modem type in the General Configuration settings.
- Change frequency – Try a different frequency. To find the range to choose from, see your country's band plan (U.S. Band Plan) or the info that Ron, VE1AIC, has posted: Digital Voice frequencies.
- Important! Avoid frequencies used for other purposes, for example, 435.0 - 438.0 and 145.8 - 146.0, used internationally for satellite communication, which can be disrupted by even low power hotspot transmissions.
- Pi-Star reminder: Beginning with dashboard v20181216, when you change a frequency, the frequency field displays red when it is within the satellite range and green when it is safely outside that range. Pi-Star itself doesn't enforce frequency ranges; however, hotspots running firmware ZUMspot/MMDVM_HS v1.4.12 or later won't work on satellite frequencies.
- Band plan: See your country's band plan and your local frequency use plan. For example, for the U.S., see: U.S. Band Plan. For the U.S. State of Colorado, see: Colorado Frequency Use Plans (especially, CCARC Guidelines on Hotspots). To find links for other U.S. states, refer to the Amateur Radio: Frequency Coordinators list by Tom, W2XQ. See also the info posted by Ron, VE1AIC: Digital Voice frequencies.
- POCSAG: The default POCSAG frequency is outside satellite frequencies, but if you changed it to a frequency in the blocked range, it can cause problems even if the POCSAG mode is not enabled.
- Fine tune to reduce BER – If you're experiencing high (greater than 1%) Bit Error Rate (BER) with your radio, you may have trouble with transmitting (the hotspot won't receive your transmission). This is especially a problem with some of the JumboSPOT clone boards, which have inconsistent TCXO chips. To reduce BER, try adjusting the RX Offset.
- Reseat and reboot – If you're using a modem mounted via a GPIO header to a Raspberry Pi or similar, remove and reseat the modem.
- For example, if you have an MMDVM-based board connected to an RPi via the GPIO header and see "Failure to Init device" in the log lines for a Pi-Star Update, then the RPi isn't communicating with the board via the upgrade pins, 38 and 40.
- Also, double check that you have the correct modem type selected in the General Configuration settings, and then reboot the hotspot.
- Can't hurt to also reboot the computer you're using to navigate to the Pi-Star dashboard. And it might even help to reboot your router, too.
- Expand the filesystem
[Note: For Pi-Star version 4 and above, this happens automatically as part of the first boot up.]
Pi-Star itself takes up very little room on the microSD card, but sometimes you can run out of available space if, for example, if you have some process running that does a lot of logging. One thing you can try is expanding the filesystem so that it fills all the available space on the card. See Expanding the filesystem
- Double check your IDs and passwords – Ensure there are no typos and that you're using IDs correctly:
- Double check that your callsign and CCS7 ID are correctly entered in Pi-Star General Configuration and also in your radio or codeplug. Note that if your General Configuration Node Type is set to Private, then the callsign in the radio must match the Node Callsign in Pi-Star, or he CCS7 ID in the radio must match the CCS7 ID in Pi-Star.
- If you're having trouble connecting to Pi-Star from within a browser, make sure you're using the hostname that is entered in General Configuration settings (default = pi-star).
- Double check that your callsign and CCS7 ID are correctly entered in Pi-Star General Configuration and also in your radio or codeplug. Note that if your General Configuration Node Type
- Beware special characters – Some special characters work for directly accessing Pi-Star Admin and Configuration settings, but may not work for logging into Pi-Star via SSH. Some special characters also create issues for the BrandMeister Hotspot Security password.
Hint: In general, avoid using special characters in the passwords that may cause issues, such as: ?{}|&~!()^"
- Check your WiFi settings and router – Because of all the different network setups and routers, this is a tricky area to troubleshoot, but if Pi-Star isn't connecting to your WiFi network:
- Double check that you entered the network name and password correctly in Pi-Star. Typos happen!
- A space in the network name can cause problems connecting to some routers.
- Some radio/modem boards require the WPA or WPA2 security standard, and won't work with WEP.
- Note: This is a good thing. In fact, even WPA isn't secure enough. To be safe, use WPA2, and make sure the firmware on your network devices is up to date. A good article about all of this: WiFi security.
- Note: This is a good thing. In fact, even WPA isn't secure enough. To be safe, use WPA2, and make sure the firmware on your network devices is up to date. A good article about all of this: WiFi security
- Make sure your wireless network doesn't have "Wireless Isolation" (a.k.a., Client Isolation) enabled, which could prevent your computer and hotspot from communicating with each other.
- Might help to reboot your router, too.
- If your hotspot is losing connectivity after running for awhile, one thing to check is whether WiFi Power Save is on:
iw wlan0 get power_save - This is an issue I had with my hotspots that are running 4.1.x prior to the upgrade to RC8, which fixed it: quite often they didn't connect as they should to my wireless network; instead, they would flip into Auto AP (Access Point) mode after 3 - 4 minutes, but it would be a broken Auto AP mode as I'd be unable to connect to the AP as I usually would; the username and password wouldn't work (on the Nextion screen, the IP address would be listed as "(address unknown)".
KC7NGC posted a simple workaround, which I tried with 100% success on seven of my hotspots running 4.1.0-RC7 or earlier, including ones based on the RPi 4B, 3A+, and Zero W. Just connect to Pi-Star via SSH and then run one command:
sudo apt-get install rng-tools
Again, Pi-Star 4.1.0-RC8 added rng-tools, so this issue should now be fixed, but I'm going to keep track of this fix in case the issue reappears. - This is a hint from Ron, AE5E: He and a group of friends he helps out with their hotspots were experiencing a problem with their hotspots that they used to connect to their home and work WiFi networks, and while driving back and forth (via their cellphone hotspots). If Auto AP was enabled, the transition from one connection to another would frequently fail and the hotspots would go into Auto AP mode, requiring a power cycle to re-establish a connection. Worse, they experienced multiple instances of microSD card corruption during this process, so often that they started carrying spare cards with copies of their images. Once they disabled Auto AP, the problem completely disappeared. They report that once Auto AP is disabled, Pi-Star will search through all the saved wireless connections, and will then repeat the search seamlessly, so it never needs to be power cycled.
- This is a hint from Greg, K2COP (I haven't tried this myself yet, but it seems like a valuable network troubleshooting step, so I want to remember it):
If your hotspot is having trouble connecting to your network, one thing you can try is connecting it directly to your router via an ethernet cable to check whether your router or DSL is at fault instead of your RPi's WiFi. If your RPi doesn't have an ethernet port (like the Zero W/Zero 2 W or the 3A+), you can use a USB (or micro USB) to RJ45 Gigabit Ethernet Network Adapter. If your network doesn't show up when you run theifconfigcommand in Pi-Star SSH Access, try adding the following lines to /etc/network/interfaces:
allow-hotplug usb0
iface usb0 inet dhcp
Then either restart the networking service or reboot.
Apparently, the command will enable the adapter to be probed, and it should then show up in theifconfigresults with an IP address assigned by the router. - This is a hint from Robert, KV0A (another procedure I haven't tried myself but want to remember):
If you can't connect to Pi-Star in Windows following a reboot of your hotspot, try flushing your DNS by running this command in Windows:
ipconfig /flushdns
- This is a hint for iPhone users from Ed, AK7AN (which I haven't tried myself): In order for your hotspot to connect to your iPhone on startup you have to be on the "Personal Hotspot" screen on your iPhone, even if you have the "qallow others to join" turned on (green). I think that the SSI goes to sleep if nothing is connected to it, and it has to be woke up.
- Do a factory reset – Back up your configuration, do a factory reset, and then restore the backed up configuration.
Note: A factory reset sets all the configuration setting back to what they are when a fresh image is first installed, with two exceptions: your WiFi setup is retained, and if you have enabled the BrandMeister Manager module, your BrandMeister API Key is retained. It does not affect the Pi-Star update dashboard version nor the Pi-Star upgrade version.
- Flash a fresh image – Try using a different, good quality microSD card, and then download and flash a totally fresh Pi-Star image.
Note: At this time, the regular Pi-Star RPi image doesn't support the new RPi 3B+, 3A+, or 4B; however, there is a Pi-Star v4.0 release candidate version that supports the 3B+ and 3A+, as well as a v4.1 release candidate in development that also will support the 4B: Pi-Star Beta Downloads.
Upgrading from V3 to V4? See Upgrading to Pi-Star V4
- Find info about the radio/modem board and about what is using the hotspot's modem or USB port – The findmodem command, which can be run via SSH, reads directly from the hardware, not the firmware. It can be helpful if you need more info about the radio/modem board (model, firmware version, TCXO speed) or about what is connected, for example, when troubleshooting a Nextion display connected via USB.
sudo pistar-findmodem
For example, running this command on a ZUMspot hotspot with a Nextion display plugged into the RPi's USB port shows:
Detected MMDVM_HS (GPIO): /dev/ttyAMA0 (ZUMspot-v1.5.2 20201108 14.7456MHz ADF7021 FW by CA6JAU GitID #89daa2073A7373111303831FFFFFFFF)
Detected Nextion (USB) : /dev/ttyUSB0 (Model: NX4832K035_011R Serial: DB682C37CB1B2932 Touch: Yes)
For a similar setup using the MMDVM_HS_Hat by Florian, DF2ET, and Mathis, DB9MAT, running findmodem shows:
Detected MMDVM_HS (GPIO): /dev/ttyAMA0 (MMDVM_HS_Hat-v1.4.14 20181209 12.2880MHz ADF7021 FW by CA6JAU GitID #8d77ff3)
Detected Nextion (USB) : /dev/ttyUSB0 (Model: NX4832K035_011R Serial: DB682C37CB1B2932 Touch: Yes)
Note 1: The findmodem command doesn't read info for displays plugged directly into the radio/modem board itself.
Note 2: If you're on a really old version of the firmware, not all of this information will be returned.
- Update or re-flash firmware – It's important to keep your modem board firmware update, and sometimes things can get messed up if the firmware is corrupted or the wrong firmware is flashed.
Note: Beginning with Pi-Star dashboard v20181214, you can see in the Radio Info section which TCXO chip (12.288 or 14.7456 MHz) a ZUMspot/MMDVM_HS board is running. This info is needed to determine which firmware update to apply, for example, with the MMDVM_HS_HAT or MMDVM_HS_DUAL_HAT, there are separate firmware update script commands for the different chips.
See Updating hotspot firmware via Pi-Star.
- Check live logs – Take a look at Pi-Star Live Logs view. It can be helpful to open Live Logs view in a new tab or a different browser so you can look back and forth between the dashboard to run the feature, and then the log to see if you can spot the problem.
Hint: There's a link at the bottom of Live Logs view to download it as a text file.
Note: There also are more specific logs you can check in the /var/log/pi-star directory, for example, specific logs for ircDDBGateway, MMDVM, etc.
- Take a break – At this point in troubleshooting, I usually turn everything off and walk away for a few hours or a day or two, and then return with a fresh mind to try troubleshooting again. That sometimes helps.
- Ask for help on the Pi-Star User Forum – Ultimately, if I'm unable to figure out how to solve an issue myself, I visit the Pi-Star User Forum or the Pi-Star Support Group and ask for help. There are some very smart, experienced people sharing their expertise there, including some of the core members of the Pi-Star team: Andy, MW0MWZ, Craig, W1MSG, and Andrew, M1DNS.
- Be detailed – When reporting an issue on the forum, the more details you can provide, the better. In addition to the description of the issue itself, share your Pi-Star version and dashboard date (for example, v4.1.5, dashboard 20210721), the model and version of the modem board you're using, its firmware version, what steps you've already tried, any related log entries you have, and any other details you can think of that can help others understand the issue.
- Be nice – Everyone working on Pi-Star and answering questions in the forum is a volunteer. Many of them, including the lead developer, have day jobs and are doing all of this for free in their spare time. It's all a gift!
- Give back to the user community – If someone takes the time to answer your question and the suggested solution works, then jump back into the forum and post a reply that it did work. That let's everyone who reads your topic know that there is a valid solution. Even better, once you get a little experience with using Pi-Star, jump back into the forum and pay it forward by helping someone else.