My reply wouldn’t post, Im guessing because I put links in it, so here it is with the pictures just attached.
Thanks for the reply, I believe the serial interface is disabled since I did that step during setup. Here is the output of ‘stty -F /dev/serial0 -a’ (pic attached). Resetting the GPS with ‘AT+UGUBX=”b56206040400ffff02000e61″‘ didn’t work unfortunately. The command did successfully run, picture of output: (pic attached) (same result in ttyGSM2). I tried it a couple times, doing a power cycle after each time, but after configuring the cellular connection again and going through all that, same result unfortunately: Still random characters in the NMEA strings the same as my previous attached pictures. After exiting gpsmon and trying to enter ttyGSM1 or 2 after having the gps run for a few minutes results in the serial channel ends up becoming unresponsive, and reentering gpsmon makes it no longer display data, same as before.
I opened up a second ssh terminal and monitored the resource usage as I was running the gps with the ‘top’ command. The cpu usage went up when running the python scripts which I think is normal, but when just using the minicom channels, running gpsmon, etc. the cpu usage was around 2%: (pic attached)
Part of whats so frustrating is that its so inconsistent. If I start the gps with ‘AT+UGPS=1,4,67’ (or some other combination of gps systems i.e. 71 instead of 67), enter gpsmon, then exit it and enter ttyGSM1 or 2, I can still send commands and get responses back, but if I wait 1-3 minutes, it doing the same things results in the channel becoming unresponsive: can’t type in it, and becomes laggy when trying to quit out of minicom, and restarting gpsmon will result in it having no data, all with pi cpu usage staying around ~2% or so. If I stay in gpsmon it will continue to print NMEA strings and try to get a fix for as long as I keep it open, but closing it results in the above issues.
After sending ‘AT+UGPS=1,4,71’ and entering gpsmon I get the following for the first few seconds after launching (pic attached), then back to only NMEA strings. Not 100% sure but I think gpsd tries to filter out what it considers garbage data i.e. not NMEA strings, so it may still be that those are UBX messages or something in that specific case. Attached are pictures of the output from ttyGSM3, then the result of running gpsmon right after: attached below
