When working with a Raspberry Pi, you will need to format an SD Card to boot the Raspberry Pi the first time. The most straight forward way to get the Raspberry Pi Operating System (OS), Raspbian, onto an SD Card is to use the Raspberry Pi Imager software. It may be downloaded by visiting https://www.raspberrypi.com/software/.
There are alternative methods for flashing the OS to an SD Card, such as balenaEtcher, but they will not be covered in this guide.
Materials Needed
SD Card – Most Raspberry Pi boards use microSD cards. The original Raspberry Pi boards used a full-size SD card.
PC with SD Card Reader – This may be Linux, Windows, or Mac.
Optional – If your PC has only a full size SD Card reader, you will need a microSD to SD card adapter.
Steps for Flashing the SD Card
Once you have Raspberry Pi Imager installed, you may follow the steps below to flash the OS to the SD Card.
Click the “Choose Device” button and select the Raspberry Pi model from the list. In the following examples, “Raspberry Pi 3” will be used. Replace “Raspberry Pi 3” to match your Raspberry Pi board.
Click the “Choose OS” button and select “Raspberry Pi OS (64-bit)”. NOTE: Raspberry Pi 1 and 2 as well as Raspberry Pi Zero and Zero W only support 32-bit OS. For those models, select 32-bit OS rather than a 64-bit OS. (64-bit should not be an option if one of those devices are selected.)
Click the “Choose Storage” button and select the SD Card from the list.
Click the “Next” button and follow the prompts. Once the card is validated and you receive a confirmation message that the image has been written to the SD Card, remove the card from the computer and move it to the Raspberry Pi Zero 2 W board and power it on.
30 June 2025 UPDATE: The fix outlined here seemed to work, but I noticed that some things were not right yesterday. I dug in deeper and I seem to have it working now. It appears that gpsd may have been the problem from the start. Below is a Copilot session that seemed to zero in on gpsd and the need to build a newer version.
After applying the changes, I tested three times and each time the correct location was identified, yes that was an issue, and the GPS had a fix in a reasonable time.
Uptime 11 Minutes to fix (reboot)
Uptime 9 Minutes to fix (reboot)
Uptime 21 Minutes to fix (shutdown, power removed, sat for a few minutes and restarted)
The rest of this post is here for information only. I plan to write another post once I test on another SD Card.
I purchased a WWZMDiB VK-172 USB GPS Dongle Receiver from Amazon to use with my Raspberry Pi Photobooth but ran into some issues with it. The Raspberry Pi recognized the GPS module straight away but I noticed the GPS was not getting a location fix even when it was outside with a clear view of the sky. I had read that some people had a similar issue or it would take nearly an hour or longer to get a fix on the location. Obviously this is not acceptable. My experience with u-blox products is that their products are very good, so this was not normal. Something else must have been amiss.
For context, I had already installed and configured gpsd on the Pi, using tools like cgps and xgps for monitoring. The cgps application appeared that everything was working, but it was not getting a fix.
Screenshot of cgps not having a fix.
To verify that the GPS could obtain a location fix and how long it would take, I connected the GPS to my Windows PC and installed the u-blox u-center software. On the Windows PC, I was able to get a location fix quickly. This helped me to target the configuration on the Raspberry Pi.
U-center running on the PC with a fix. (Lat/Long blacked out.)
Back on the Raspberry Pi, I looked at several things but suspected that the GPS unit was not configured properly. With the help of Copilot, I attempted to resolve the issue. What I uncovered is the GPS was not configured to send the proper NMEA messages.
I was able to properly configure the GPS to send NMEA messages but the GPS unit would not retain the configuration as it has no battery. I was able to write a script to run as a service and run on startup. All seemed to work well, but I needed to leave it and come back the next day. When I tested it again, things were no longer working as expected. Upon further investigation, it was noted that unplugging the USB GPS dongle and plugging it back in got everything working as expected.
I was able to land on a solution that mimicked the unplugging and plugging the dongle in. This final configuration seems to allow the dongle to work properly on the Raspberry Pi. I have not verified, but other Raspberry Pi versions may or may not have this issue.
Screen capture of cgps with location fix after applying the changes.
Below is the list of steps necessary to get the GPS module to work properly with gpsd on the Raspberry Pi.
My setup
Raspberry Pi 3
Raspbian bookworm
All updates applied as of 28 June 2025
Steps
Update the Raspberry Pi OS and install packages by running the following code.
sudo apt update -y && sudo apt upgrade -y
Install gpsd and related packages
sudo apt -y install gpsd gpsd-tools gpsd-clients
Install Python GPS client library
sudo apt install python3-gps
Configure gpsd
sudo nano /etc/default/gpsd
Edit the file to include the following content DEVICES="/dev/ttyACM0"
USBAUTO="true"
GPSD_OPTIONS="-n"
Enable and start gpsd service
sudo systemctl enable gpsd
sudo systemctl start gpsd
Reboot to ensure all changes take effect
sudo reboot now
Create the following script at /home/pi/setup-gps.sh to configure the USB GPS dongle on startup.
nano /home/pi/setup-gps.sh
#!/bin/bash # VK-172 USB GPS dongle was having issues sending messages # dmesg | tail -n 20 # Showed that the USB Bus was having with dwc_otg_hcd_urb_dequeue # The following commands mimic unplugging the USB and plugging it back in.
# Look for a serial device with 'u-blox' in the ID string DEVICE_PATH=$(readlink -f /dev/serial/by-id/*u-blox*)
# Extract the most specific USB path (e.g. 1-1.3) USB_ID=$(udevadm info -a -n "$DEVICE_PATH" | awk -F'"' '/KERNELS=="1-/ { if ($2 !~ /:/) { print $2; exit } }')
# Log what we found (optional for debugging) echo "Reinitializing USB device at $USB_ID"
Your USB Dongle may be appear as device other than /dev/ttyACM0. Running the command dmesg | grep tty or ls /dev/tty* tip will allow you to verify if your GPS is appearing as /dev/ttyACM0 or another device path.
Some of the commands used to troubleshoot were the following.
Disabling gpsd so it will not become active between reboots.
sudo systemctl disable gpsd.socket
sudo systemctl disable gpsd
sudo systemctl mask gpsd.socket
sudo systemctl mask gpsd
Run one of the following sets of commands
sudo systemctl stop gpsd.socket
sudo systemctl stop gpsd — or —
sudo reboot now
Reenabling gpsd once done troubleshooting.
sudo systemctl unmask gpsd.socket
sudo systemctl unmask gpsd
sudo systemctl enable gpsd.socket
sudo systemctl enable gpsd
Run one of the following sets of commands
sudo systemctl start gpsd.socket
sudo systemctl start gpsd
or
sudo reboot now
Checking if the GPS is sending NEMA messages. First disable gpsd Run one of the following commands
cat /dev/ttyACM0
cat < /dev/ttyACM0
stty -F /dev/ttyACM0 9600
With either command, you should see GPS NEMA messages being streamed to the output. If the command immediately returns with no output, then the GPS is not sending messages, which is a problem.
View USB Devices
lsusb
Sample output
pi@PhotoBooth1:~/TouchSelfie $ lsusb
Bus 001 Device 007: ID 1546:01a7 U-Blox AG [u-blox 7]
Bus 001 Device 004: ID 090c:1000 Silicon Motion, Inc. - Taiwan (formerly Feiya Technology Corp.) Flash Drive
Bus 001 Device 005: ID 2010:7638 USBKey Chip USBKey Module
Bus 001 Device 006: ID 0424:7800 Microchip Technology, Inc. (formerly SMSC)
Bus 001 Device 003: ID 0424:2514 Microchip Technology, Inc. (formerly SMSC) USB 2.0 Hub
Bus 001 Device 002: ID 0424:2514 Microchip Technology, Inc. (formerly SMSC) USB 2.0 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
pi@PhotoBooth1:~/TouchSelfie $
View the last 20 debug messages
dmesg | tail -n 20
Sample output This is a capture after the fix was applied.
[ 25.607598] WARN::dwc_otg_handle_mode_mismatch_intr:67: Mode Mismatch Interrupt: currently in Host mode
[ 26.641294] cdc_acm 1-1.3:1.0: ttyACM0: USB ACM device [ 57.963631] pps_ldisc: PPS line discipline registered
[ 117.664194] WARN::dwc_otg_hcd_handle_hc_fsm:2441: Unexpected IRQ state on FSM transaction:dev_addr=7 ep=2 fsm=7, hcint=0x00000022
pi@PhotoBooth1:~/TouchSelfie $
If there are several WARN messages such as below, then you may be having the same issue with the USB dongle not working unless it is unplugged and reinserted. The output below is before the issue was resolved and includes unplugging and plugging in the USB GPS dongle.
pi@PhotoBooth1:~ $ dmesg | tail -n 20 [ 39.437463] WARN::dwc_otg_hcd_urb_dequeue:639: Timed out waiting for FSM NP transfer to complete on 6 [ 39.437954] WARN::dwc_otg_hcd_urb_dequeue:639: Timed out waiting for FSM NP transfer to complete on 5 [ 39.438512] WARN::dwc_otg_hcd_urb_dequeue:639: Timed out waiting for FSM NP transfer to complete on 0 [ 39.439038] WARN::dwc_otg_hcd_urb_dequeue:639: Timed out waiting for FSM NP transfer to complete on 3 [ 111.617441] WARN::dwc_otg_hcd_urb_dequeue:639: Timed out waiting for FSM NP transfer to complete on 5 [ 111.617895] WARN::dwc_otg_hcd_urb_dequeue:639: Timed out waiting for FSM NP transfer to complete on 6 [ 111.618337] WARN::dwc_otg_hcd_urb_dequeue:639: Timed out waiting for FSM NP transfer to complete on 1 [ 138.125231] usb 1-1.3: USB disconnect, device number 6 [ 142.162832] usb 1-1.3: new full-speed USB device number 7 using dwc_otg [ 142.253315] usb 1-1.3: New USB device found, idVendor=1546, idProduct=01a7, bcdDevice= 1.00 [ 142.253362] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 142.253379] usb 1-1.3: Product: u-blox 7 - GPS/GNSS Receiver [ 142.253393] usb 1-1.3: Manufacturer: u-blox AG - www.u-blox.com [ 142.255827] cdc_acm 1-1.3:1.0: ttyACM0: USB ACM device pi@PhotoBooth1:~ $
Check the status of the gps-init service we created.
sudo systemctl status gps-init.service
Sample output The error, “Failed to start gps-init.service – Configure u-blox GPS at Boot.” may be ignored as it is expected when the line “gpsctl -s -f /dev/ttyACM0” is not commented out in /home/pi/setup-gps.sh.
pi@PhotoBooth1:~/TouchSelfie $ sudo systemctl status gps-init.service × gps-init.service - Configure u-blox GPS at Boot Loaded: loaded (/etc/systemd/system/gps-init.service; enabled; preset: enabled) Active: failed (Result: exit-code) since Sun 2025-06-29 14:21:24 EDT; 39min ago Process: 904 ExecStart=/home/pi/setup-gps.sh (code=exited, status=1/FAILURE) Main PID: 904 (code=exited, status=1/FAILURE) CPU: 15.794s
Jun 29 14:21:14 PhotoBooth1 setup-gps.sh[1378]: inProtoMask (UBX NMEA RTCM2) Jun 29 14:21:14 PhotoBooth1 setup-gps.sh[1378]: outProtoMask (UBX NMEA) Jun 29 14:21:14 PhotoBooth1 setup-gps.sh[1378]: UBX-ACK-ACK: Jun 29 14:21:14 PhotoBooth1 setup-gps.sh[1378]: ACK to Class x06 (CFG) ID x00 (PRT) Jun 29 14:21:24 PhotoBooth1 setup-gps.sh[1383]: gpsctl:ERROR: timed out after 8 seconds Jun 29 14:21:24 PhotoBooth1 setup-gps.sh[1383]: gpsctl:ERROR: no DEVICES response received. Jun 29 14:21:24 PhotoBooth1 systemd[1]: gps-init.service: Main process exited, code=exited, status=1/FAILURE Jun 29 14:21:24 PhotoBooth1 systemd[1]: gps-init.service: Failed with result 'exit-code'. Jun 29 14:21:24 PhotoBooth1 systemd[1]: Failed to start gps-init.service - Configure u-blox GPS at Boot. Jun 29 14:21:24 PhotoBooth1 systemd[1]: gps-init.service: Consumed 15.794s CPU time. pi@PhotoBooth1:~/TouchSelfie $
Once cgps is showing that gpsd is working properly, telnet may be used to view the messages being sent by gpsd.
If telnet is not installed, install telnet with the following command.
sudo apt install telnet
telnet localhost 2947
Sample output
pi@PhotoBooth1:~/TouchSelfie $ telnet localhost 2947
Trying ::1...
Connected to localhost.
Escape character is '^]'.
{"class":"VERSION","release":"3.22","rev":"3.22","proto_major":3,"proto_minor":14}
Issue the following command to view polling output.
?POLL;
Issue the following command to see JSON output.
?WATCH={“enable”:true,”json”:true}
Press <Ctrl>+] then type “quit” to exit the telnet session.
CAUTION: I did notice one time that the location reported by gpsd was off by 1,000 miles to the NW. Not certain what happened but I could not replicate it. I had let cgps run for about 10 minutes to see if gpsd would update with the correct location, but it did not.
Some other useful commands to see what is happening with USB and GPS on boot.
journalctl | grep -i gps
journalctl | grep -i usb
Additional commands to monitor GPS output while gpsd is running.
You must be logged in to post a comment.