stty -F /dev/ttyAMA5 9600 cs8 -cstopb -parenb Now cat /dev/ttyAMA5 showed garbage. Good—data was flowing.
Marta was a firmware engineer for a small agricultural robotics startup. Her team had just switched from an old U-Blox GPS to the UG-353 (a common, low-cost 10Hz GPS module with a UART interface). The robot’s navigation stack was failing. “No fix,” the logs said. “No fix.”
The Silent NMEA Sentence
Marta checked the datasheet. UG-353 defaults to 9600 baud , but the Linux kernel expected 115200 for the UART. She fixed the stty settings:
Now $GPGGA sentences appeared cleanly.
Still no fix in gpsd . Marta ran gpsd -N -n -D 5 /dev/ttyAMA5 (foreground, debug mode). The debug output revealed:
sudo gpsd /dev/ttyAMA5 -F /var/run/gpsd.sock But cgps showed a blank screen. Zero satellites. Sky was clear. ug-353 gps driver
gpsd: gpsd: command socket at /var/run/gpsd.sock gpsd: device /dev/ttyAMA5 is a UG-353 (NMEA) gpsd: no fix: no GPS signal But the UG-353 was outputting valid GGA sentences with a 3D fix. Why ignore them? She realized the UG-353 outputs , but gpsd ’s autobaud logic was misreading the sentence interval as corrupted data. She forced the baud rate and enabled raw NMEA mode :
The garbage was not NMEA sentences (which start with $GP or $GN ). It was random binary noise. Marta grabbed an oscilloscope: the UG-353’s TX was 3.3V, but the CM4’s RX was configured for 1.8V logic due to a broken device tree overlay. She fixed the config.txt : stty -F /dev/ttyAMA5 9600 cs8 -cstopb -parenb Now
dtoverlay=uart5,uart5_rx_pullup=on
The UG-353 was wired to UART5 on a Raspberry Pi Compute Module 4. Marta had written a simple systemd service to start gpsd with the correct options: Her team had just switched from an old
