If you see the default “Welcome to nginx!” page after installation, it means the default Nginx configuration is still active and taking priority over ChroGPS Dash.

To resolve this, run the following commands to disable the default site and restart the web server:

sudo rm /etc/nginx/sites-enabled/default && sudo systemctl restart nginx

If you ran the hardware provisioning script in GPIO mode and Chrony is failing to start with an error like:

Fatal error: Could not open /dev/pps0: No such file or directory

or systemctl status chrony shows the service in a failed state immediately after running the provisioning script – this is expected behavior and not a bug. In GPIO mode, the pps-gpio Device Tree overlay (added to config.txt) must activate before /dev/pps0 is created, and that only happens after a reboot. Reboot and the error will not recur:

sudo reboot

USB mode does not have this issue – GPSd and Chrony are restarted by the provisioning script immediately and no reboot is required.

After rebooting following GPIO mode setup, if GPSd reports no device or no data from the GNSS receiver:

1. Confirm the serial device exists:

   ls -la /dev/serial0 /dev/ttyAMA0
   

2. Confirm the disable-bt and pps-gpio overlays are active:

   dtoverlay -l
   

   Both should appear in the output. If they don’t, verify your config.txt contains the entries added by the provisioning script and that you have fully rebooted (not just restarted services).
3. Verify GPSd is pointed at the correct device:

   cat /etc/default/gpsd
   

4. Check GPSd logs for errors:

   journalctl -u gpsd -n 50
   

If graphs appear but have no data:

1. Verify Chrony is logging: sudo ls -l /var/log/chrony/
2. Wait a few minutes for logs to populate.
3. Run the installer again to re-apply permission fixes.

Your GPS receiver may be using u-blox-style gnssid values instead of the NMEA standard. ChroGPS Dash handles both automatically by validating gnssid against PRN ranges.

To verify which scheme your receiver is using:

gpspipe -w | grep '"class":"SKY"' | head -3 | jq '.satellites[]? | {PRN, gnssid}'

sudo apt-get install -y gpsd-clients jq

If you see GLONASS satellites (PRN 65-96) with gnssid=6, that’s u-blox numbering. If you see gnssid=2, that’s NMEA numbering. ChroGPS Dash handles both correctly.

Some receivers report satellites across multiple gpsd messages. ChroGPS Dash caches satellites for 30 seconds to accumulate all of them - the satellite count should grow from ~15 to ~25 over a few refreshes.

To inspect the cache directly:

cat /var/tmp/cgpsd-sat-cache.json | jq '.satellites | length'

Check that you have:

• A clear view of the sky.
• At least 4 satellites with good signal (> 25 dBHz).
• HDOP < 5.0.
• Waited 30–60 seconds for the initial fix after startup.

If DASHBOARD_REQUIRE_AUTH is enabled and you have lost or forgotten the admin token, you cannot authenticate through the browser - the gate lock screen will reject all attempts. To regain access:

Option 1 - Display the current token (no change):

curl -fsSL https://chro.gpsda.sh/install | sudo bash -s -- -dt

This prints the token currently stored in cgpsd-settings.php without modifying anything.

Option 2 - Read it directly from the settings file:

sudo grep ADMIN_TOKEN /var/www/chrogps-dash/cgpsd-settings.php

Option 3 - Temporarily disable the gate via SSH:

sudo sed -i 's/\$DASHBOARD_REQUIRE_AUTH = true/\$DASHBOARD_REQUIRE_AUTH = false/' \
    /var/www/chrogps-dash/cgpsd-settings.php

This disables the gate immediately (no restart needed). Re-enable it from the Admin Panel once you have your token.

curl -fsSL https://chro.gpsda.sh/install | sudo bash -s -- -rt