as you are probably well aware the UART here is an asynchronous serial communication line. Asynchronous being the key word - this means there is no clock signal in place, hence there are only two pins in use (one for receive and one for transmit). Since there is no clock in place, the timing of the pulse-train needs to be tightly controlled. The receiver is going to sample the square wave regularly and note whether it’s high or low. This sampling needs to always be inside the pulse - so you have a margin of error of +/- 0.5 pulse width (assuming you’re aiming to sample in the middle of the pulse).
for dedicated HW this is easy for systems like the Pi though it’s harder. The reason for this is that OS’s like Raspbian are not able to guarantee the timing of operations. So, when you try and do things that require tight timing (like sampling a serial line), the timing can be so bad that you just completely misread the data.
so if you are going down this path, then you need to write some code that will sample the GPIO pins consistently enough to reconstruct the data line, and you will find that the upper limit of baud rate is pretty low for reliability. A few posts up I posted a few links, I’ve never tried it myself though so can’t provide any feedback. if i get some spare time I might try it as it’s an interesting challenge
From my experience (using the serial option driver) you enable GNSS via an AT command on the main UART. You then just get NMEA data streaming constantly on the GNSS UART - you can’t post AT commands or run PPP on that UART
it wont be possible to CMUX the UART on pins 32/33 as its a dedicated GNSS UART, its only the main UART that is able to be CMUX’d - as i type now, I’m not sure if you can get NMEA data on a CMUXd UART though - a typical use case for CMUX would be to have a PPP and AT command simultaneously. sorry for that oversight.
I’m just looking at the GNSS Application Note, AT+QGPSCFG sets the output port for GNSS, you can choose none, usb, uart or aux (aux refers to the debug UART) the debug port though doesn’t appear to be connected on the HAT you have.
how often do you need to get location information? there is AT+QGPSLOC which will give you the location data in response. Since you have a PPP session you would either need to disconnect that session to send the AT command. Otherwise use CMUX to the main UART then keep one for PPP and one for AT - again, not tested
looking back at the waveshare - there is a single pin contention between the Pi and the expansion hat - Pin24 which is used for IRQ on the waveshare is also the Powerkey on the IoT HAT. So, you would need to sacrifice that to use the waveshare…and then deal with that the GNSS UART pins go to the Pi and the Waveshare - so you would route a cable from the RX/TX on the waveshare back to pins 32/33 on the HAT… so you would need to absolutely guarantee nothing stray will come from the Pi itself on those pins… not sure how good a solution that would be… so that whole solution is getting kinda crazy… and messy. The concept of the Waveshare is cool - you could make your own with a proto board and header - then just connect the pins you want to - but more work than it’s worth perhaps
a couple more options anyway - this conversation is good for me, its forcing me to think outside the box and a few thigns im interested to try myself. But ill be fascinated to see what the end result it!