Unsatisfactory GPS reception on PinePhone?

[calinb]

I just replaced my original -002 Pinephone touchscreen with a -001 revision that I recently received from the Pine Store. My original screen suffered from the ever worsening delamination defect (or whatever causes the highly visible and, under direct lighting conditions, annoying defect around the edges of the screen). It's a tedious job to replace it but an unanticipated reward was my GPS now works quickly and for more than a few intermittent minutes, best case, for the first time ever!

After powering up my new screen and, motivated by my desire to record some signal strengths before attempting the aluminum foil hack (hoping for improvement), I ran the alastair proof of concept AGPS script and I was surprised to see record signal strength and a good GPS position almost immediately, instead of the usual zero to low signal and terrestrial-based position errors of several miles, minimum.

In the year I've owned my Pinphone, my GPS has never been able to obtain a fix in the canyon where I live, or nearly anyplace else for that matter, except for very brief periods in flat open country. Satellite signal strengths, as reported my mmcli, were always very low or zero.

I did not notice any problem with the antenna paint on my midframe or the contact fingers on my mainboard, but I suspect that seating the midframe against the contact fingers a few times while fussing with the two parts against each other in trying to mate them correctly, resulted in the metal pins scratching the paint a little bit, improving connectivity.

Either that or a recent Mobian Bookworm software update set it right, but the problem wasn't corrected by my modem firmware update of several months ago, which I'd hoped would solve it. The firmware update made no difference in my signal strength.

[moxx]

There's some movement on getting assistance data loading into distros.

OpenSuse have this:
https://build.opensuse.org/package/view_...y?expand=1

Dylan Van Assche has been working on Mobian via egs5-manager as well as upstream ModemManager:
https://gitlab.com/mobian1/devices/eg25-...equests/15
https://gitlab.freedesktop.org/mobile-br...issues/357

Good Morning
Thank you for your attention and I leave a photo that I hope to be able to add in the post with an addition of aluminum paper on the gps antenna, fixed with transparent adhesive tape to make the photo, which considerably increased the signal level, obtaining a good signal-to-noise ratio. best.
I suggest it be researched to confirm and implemented if possible in the next phones, so I hope I could have contributed to this project in some way.

Using your hardware-hack, yesterday I got my first GPS fix! Maybe now we need to iterate on the geometry.

Yesterday I had a wild combination of the agps script and mmcli commands, so I can't tell what really worked.

Today I placed the phone under a south-oriented roof-window with open sight to the sky, started the turned-off phone and just ran:

Code:

sudo mmcli -m any --location-enable-agps-msb
sudo mmcli -m any --location-enable-gps-unmanaged

After a few minutes I had a fix! I didn't use the script. Either the amanac was received from the satelites or ModemManager downloaded it. Somehow I got the feeling that the agps-script doesn't work in central Europe.

Right now, the gpsd stack only works if I activate unmanaged gps over ModemManager and I prefer to use gpsmon to see the progress of getting a fix. Is there an alternative using the NMEA output from dbus?

Another strange thing is that gpsmon shows the GPS sattelites and xgps and cgps only show GLONASS satelites. After deep investigation now I can read the NMEA output and could see that both kinds of satelites were used.

Still, the quality is not perfect. SNR is around 20 for any satelite.

[wibble]

gpsd only works with --location-enable-gps-unmanaged as in the other modes the port gets grabbed for geoclue.

You should be able to put the commands for startup and shutdown into /etc/gpsd/device-hook to automate startup when the first gpsd client requests a connection, and shutdown when the last client disconnects. It won't help you if something is already using it via geoclue though.

I never had any luck with msa or msb. Could be carrier dependent?

https://gitlab.freedesktop.org/mobile-br...ge_size=20

[robin.com.au]

Hi I'm the latest victim of this GPS issue. Based on https://forum.pine64.org/showthread.php?tid=14114, I ran the following in order to get longitude and latitude.

Code:

sudo rc-service modemmanager stop # May or may not be necessary

echo at+qgps=1 | sudo atinout - /dev/EG25.MODEM - # turn on the GNSS
echo at+qgpsgnmea=\"gsv\" | sudo atinout - /dev/EG25.MODEM - # show the satellites tracked
echo at+qgpsgnmea=\"gga\" | sudo atinout - /dev/EG25.MODEM - # show the location if it is fixed
echo at+qgpsend | sudo atinout - /dev/EG25.MODEM -  # turn off the GNSS

And this is my output:

Code:

pine64-pinephone:~$ echo at+qgps=1 | sudo atinout - /dev/EG25.MODEM -

OK
pine64-pinephone:~$ echo at+qgpsgnmea=\"gsv\" | sudo atinout - /dev/EG25.MODEM -

+QGPSGNMEA: $GPGSV,4,1,16,02,00,116,,05,15,285,,06,,,,07,19,085,,1*58
+QGPSGNMEA: $GPGSV,4,2,16,08,,,,09,,,,11,,,,12,,,,1*67
+QGPSGNMEA: $GPGSV,4,3,16,13,56,223,,14,52,157,,15,20,223,,17,58,047,,1*6A
+QGPSGNMEA: $GPGSV,4,4,16,19,43,012,,20,08,320,,21,,,,22,67,201,,1*55
+QGPSGNMEA: $GLGSV,3,1,11,78,39,224,,66,14,002,,86,04,144,,77,31,149,,1*79
+QGPSGNMEA: $GLGSV,3,2,11,76,,,,79,07,268,,69,02,203,,88,18,040,,1*4C
+QGPSGNMEA: $GLGSV,3,3,11,87,25,097,,67,53,317,,68,42,232,,1*47

OK
pine64-pinephone:~$ echo at+qgpsgnmea=\"gga\" | sudo atinout - /dev/EG25.MODEM -

+QGPSGNMEA: $GPGGA,,,,,,0,,,,,,,,*66

OK
pine64-pinephone:~$ echo at+qgpsend | sudo atinout - /dev/EG25.MODEM -

OK
pine64-pinephone:~$

And this result is what I'm focusing on:

Code:

$GPGGA,,,,,,0,,,,,,,,*66

Which is lacking a bunch of information other than the 0 which means an 'invalid' quality indicator:

Code:

$GPGGA,hhmmss.ss,llll.ll,a,yyyyy.yy,a,x,xx,x.x,x.x,M,x.x,M,x.x,xxxx*hh

The interpretation of the 15 fields is the following,

1    = UTC of Position
2    = Latitude
3    = N or S
4    = Longitude
5    = E or W
6    = GPS quality indicator (0=invalid; 1=GPS fix; 2=Diff. GPS fix)
7    = Number of satellites in use [not those in view]
8    = Horizontal dilution of position
9    = Antenna altitude above/below mean sea level (geoid)
10  = Meters  (Antenna height unit)
11  = Geoidal separation (Diff. between WGS-84 earth ellipsoid and
      mean sea level.  -=geoid is below WGS-84 ellipsoid)
12  = Meters  (Units of geoidal separation)
13  = Age in seconds since last update from diff. reference station
14  = Diff. reference station ID#
15  = Checksum

I believe user 'sog8b' from page 1 had that exact "$GPGGA,,,,,,0,,,,,,,,*66" in the earlier post years ago, but he somehow solved it.

I just bought this Pine Beta Edition, and I ran JumpDrive to install postmarketos running sxmo. I bought it for the sole purpose of scripting GPS. I test it mainly via SSH and in a room with a window, and I did try putting the phone outside the house. I also started suspecting the problem is because the sim does not have a data plan.

There's just so many variables, is there a sure-fire way to determine whether it's a hardware, firmware, software, user issue?