I'm having similar problems with the same GPS module. I see many corrupted inbound messages and many garbage characters.

I got improved messages by amending the UART config:

stty -F /dev/serial0 cs7
cat /dev/serial0

After a few seconds, inbound messages were then good; full NMEA sentences and no more garbage characters.

According to the datasheet, the GPS UART should be running cs8. So it is odd that setting it to cs7 helped things. I picked up trying cs7 from an Oracle tutorial on using the same GPS unit; see link here.

Edit:

Found an improved answer to why you were seeing all the bad characters.

The Pi UART is by default set to echo mode. This means GPS data on TX is echoed back to the GPS RX. It caused my GPS unit to get confused and start sending garbage characters, like OP saw.

This presumably reflects Pi UART original purpose of working as a tty console. Echo is required for normal console behaviour.

Fix is simply to reconfigure the Pi UART by disabling the echo.

Worked as expected after I'd configured with:

stty -F /dev/serial0 -echo

As a useful side effect, the "cs7" workaround was no longer needed & the default "cs8" worked fine.

I'm having similar problems with the same GPS module. I see many corrupted inbound messages and many garbage characters.

I got improved messages by amending the UART config:

stty -F /dev/serial0 cs7
cat /dev/serial0

After a few seconds, inbound messages were then good; full NMEA sentences and no more garbage characters.

According to the datasheet, the GPS UART should be running cs8. So it is odd that setting it to cs7 helped things. I picked up trying cs7 from an Oracle tutorial on using the same GPS unit; see link here.

Edit:

Found an improved answer to why you were seeing all the bad characters.

The Pi UART is by default set to echo mode. This means GPS data on TX is echoed back to the GPS RX. It caused my GPS unit to get confused and start sending garbage characters, like OP saw.

This presumably reflects Pi UART original purpose of working as a tty console. Echo is required for normal console behaviour.

Fix is simply to reconfigure the Pi UART by disabling the echo.

Worked as expected after I'd configured with:

stty -F /dev/serial0 -echo

As a useful side effect, the "cs7" workaround was no longer needed & the default "cs8" worked fine.

I'm having similar problems with the same GPS module. I see many corrupted inbound messages and many garbage characters.

I got improved messages by amending the UART config:

stty -F /dev/serial0 cs7
cat /dev/serial0

After a few seconds, inbound messages were then good; full NMEA sentences and no more garbage characters.

According to the datasheet, the GPS UART should be running cs8. So it is odd that setting it to cs7 helped things. I picked up trying cs7 from an Oracle tutorial on using the same GPS unit; see link here.

I'm having similar problems with the same GPS module. I see many corrupted inbound messages and many garbage characters.

I got improved messages by amending the UART config:

stty -F /dev/serial0 cs7
cat /dev/serial0

After a few seconds, inbound messages were then good; full NMEA sentences and no more garbage characters.

According to the datasheet, the GPS UART should be running cs8. So it is odd that setting it to cs7 helped things. I picked up trying cs7 from an Oracle tutorial on using the same GPS unit; see link here.

Edit:

Found an improved answer to why you were seeing all the bad characters.

The Pi UART is by default set to echo mode. This means GPS data on TX is echoed back to the GPS RX. It caused my GPS unit to get confused and start sending garbage characters, like OP saw.

This presumably reflects Pi UART original purpose of working as a tty console. Echo is required for normal console behaviour.

Fix is simply to reconfigure the Pi UART by disabling the echo.

Worked as expected after I'd configured with:

stty -F /dev/serial0 -echo

As a useful side effect, the "cs7" workaround was no longer needed & the default "cs8" worked fine.