Just as a further update: I decided to just start over, I did a clean install of the raspberry pi os, reformatted the SD card and then went through the setup like normal. When I got to the part of the setup where you run ‘minicom 115200 -D /dev/serial0’, I got the same “device or resource busy” error for the channel serial0 (gps module had been powered on for ~6 minutes by that point). Power cycling everything fixed this issue. Continuing on by setting up multiplexing then running the gps:
When running the module in assisted gps mode with ‘AT+UGPS=1,4,67’ (gpsd, cgps, gpsmon is still not installed at this point), I get correct NMEA strings with garbage data at the front of it in the same position every time a new set of strings gets sent (pic attached). After sitting in ttyGSM3 in minicom for a while with these errors, exiting the channel and then trying to immediately re-enter it resulted in ttyGSM3 outputting no data, and ttyGSM1 and 2 becoming unresponsive, requiring a restart to fix it. From my research, it seems like the random characters could be either just a signal integrity issue with the serial connection, or the module trying to send UBX binary messages with the NMEA strings. https://stackoverflow.com/questions/55831738/ublox-gps-strange-characters-interspersed-with-nmea-output
I don’t have the same garbage characters appear in ttyGSM3 with unassisted gps mode ‘AT+UGPS=1,1,67’, despite having the cellular radio enabled and connected as if I was going to use the assisted gps mode.
At this point, I hadn’t installed gpsd yet, so I’m thinking that the issue might be with the GPS module instead? I don’t really know what else could be the problem at this point. The gps module clearly has some settings that are persistent between power cycles because the cellular radio will automatically turn itself on on powerup, which it didn’t originally do, and also it says in the documentation that it saves certain settings between power cycles. I haven’t tried updating the firmware on the gps or resetting to factory defaults, which I guess would be the next thing to try, not sure what your thoughts on any of that are.
As a side note, I could never get cat or screen to work to connect to the serial0 channel, even with the correct baud rate of 115200. Running either cat or screen would just make the SSH terminal unresponsive. Not sure if this is an actual issue or just a quirk of the module.
