+- PINE64 (https://forum.pine64.org)
+-- Forum: PinePhone (https://forum.pine64.org/forumdisplay.php?fid=120)
+--- Forum: PinePhone Hardware (https://forum.pine64.org/forumdisplay.php?fid=122)
+--- Thread: Unsatisfactory GPS reception on PinePhone? (/showthread.php?tid=11680)
Unsatisfactory GPS reception on PinePhone? - LinAdmin2 - 09-30-2020
When looking at the results of GPS reception by typing in the console
Code:
mmcli -m 0 --location-enable-gps-nmea # Once only
mmcli -m 0 --location-get # Many timesThis command does not report any fix even after 30 minutes trial.
Is this the adequate method and what are your experiences?
RE: Unsatisfactory GPS reception on PinePhone? - wibble - 09-30-2020
It's hugely better if you use AGPS, which pretty much every smartphone does most of the time. If you're using Mobian you can try the proof of concept python script to fetch the AGPS data and load it into the modem:
https://gist.github.com/alastair-dm/263209b54d01209be28828e555fa6628
If you're using a different distro you'll need to tweak it somewhat. ModemManager (as used by Phosh) gets most of its Quectel modem support from its generic Qualcom interface, but the AGPS part of that seems not to work with this modem - at least it hasn't when I've tried it. Using the Quectel AT commands as in the script does work, and gets a much faster and more stable fix than without the assistance data.
The unassisted performance isn't good, somewhat worse than an unassisted Garmin Geko or the old OpenMoko GTA02 doing a cold start. I suspect this is largely down to the antenna required to fit in the modern smartphone hardware, but there may be an unidentified interference issue similar to the early days of the GTA02. Whatever the cause, a marginal signal to noise ratio is a problem in an unassisted cold start as any interruption in the slow collection of the data from the sat signal means restarting collection. A small difference in signal makes the difference between a lock in ~2min and not getting one at all (or at least until the sats move into an advantageous position). The AGPS sidesteps this by downloading the necessary data from the internet.
I'm surprised you only get 3 sats though - I usually see more than that, but it does vary with the sat positions especially with the buildings around here. I've sometimes had no fix in 30 minutes, and sometimes got one in <2. I've not tied an unassisted cold start with another modern phone - they don't usually have an option to disable the AGPS. You'd need to remove network access and have the GPS disabled for long enough for any stored data to expire - 4hrs for ephemeris, up to 2 weeks for almanac - to make an apples-to-apples comparison.
RE: Unsatisfactory GPS reception on PinePhone? - LinAdmin2 - 10-01-2020
(09-30-2020, 12:21 PM)wibble Wrote: It's hugely better if you use AGPS, which pretty much every smartphone does most of the time. If you're using Mobian you can try the proof of concept python script to fetch the AGPS data and load it into the modem:Thanks for this help. With AGPS I got a fix within a few minutes and GPS reception works as expected
https://gist.github.com/alastair-dm/263209b54d01209be28828e555fa6628
RE: Unsatisfactory GPS reception on PinePhone? - sog8b - 11-27-2020
(10-01-2020, 05:30 AM)LinAdmin2 Wrote:(09-30-2020, 12:21 PM)wibble Wrote: It's hugely better if you use AGPS, which pretty much every smartphone does most of the time. If you're using Mobian you can try the proof of concept python script to fetch the AGPS data and load it into the modem:Thanks for this help. With AGPS I got a fix within a few minutes and GPS reception works as expected
https://gist.github.com/alastair-dm/263209b54d01209be28828e555fa6628
Just wanted to report I am unable to get a fix on my new pinephone manjaro ce edition.
I've installed the updated modem firmware from https://forum.pine64.org/showthread.php?tid=11815 so I have "EG25GGBR07A08M2G_01.002.07"
As well as the AGPS fix mentioned in this thread as can be seen from the assistance server output in the console output I've included below.
Code:
[root@manjaro-arm ~]# mmcli -m 0 --location-statusCode:
--------------------------------Code:
Location | capabilities: 3gpp-lac-ci, gps-raw, gps-nmea, agps-msa, agps-msbCode:
| enabled: 3gpp-lac-ci, gps-nmeaCode:
| signals: noCode:
--------------------------------Code:
GPS | refresh rate: 5 secondsCode:
| supported assistance: xtraCode:
| assistance servers: http://xtrapath1.izatcloud.net/xtra3grc.binCode:
| http://xtrapath2.izatcloud.net/xtra3grc.binCode:
| http://xtrapath3.izatcloud.net/xtra3grc.binCode:
[root@manjaro-arm ~]# mmcli -m 0 --location-getCode:
--------------------------Code:
3GPP | operator code: XXXXCode:
| operator name: XXCode:
| location area code: XXXXCode:
| tracking area code: XXXXCode:
| cell id: XXXXXXXXCode:
--------------------------Code:
GPS | nmea: $GPGSA,A,1,,,,,,,,,,,,,,,,*32Code:
| $GPRMC,,V,,,,,,,,,,N*53Code:
| $GPGSV,3,1,10,01,,,,02,,,,03,,,,06,,,,1*61Code:
$GPGSV,3,2,10,10,31,210,,12,33,042,,15,,,,16,,,,1*62Code:
$GPGSV,3,3,10,17,,,,18,,,,1*6ACode:
| $GPVTG,,T,,M,,N,,K,N*2CCode:
| $GPGGA,072623.52,,,,,0,,,,,,,,*4DI've tried waiting for a number of hours and based on what I can understand from the output on the GPGSV line it looks like it's tracking 10 satellites with varying degrees of signal strength. I'm unsure why it's unable to get a fix though.
Is anyone else having difficulties, or does anyone have any other tips?
Thanks!
RE: Unsatisfactory GPS reception on PinePhone? - wibble - 11-27-2020
Tracking sats for a long time without getting a fix is not unusual if you haven't loaded the AGPS data. There's more about this in the mobian wiki:
https://wiki.mobian-project.org/doku.php?id=location
Can you post the output from the AGPS uploader script? I assume you're aware that it needs to be run every time you need a GPS cold start, not just once.
RE: Unsatisfactory GPS reception on PinePhone? - sog8b - 11-27-2020
(11-27-2020, 06:30 AM)wibble Wrote: Tracking sats for a long time without getting a fix is not unusual if you haven't loaded the AGPS data. There's more about this in the mobian wiki:I wasn't aware that I needed to run the script every time I was doing a cold start. It makes sense though as otherwise the data wouldn't be up to date.
https://wiki.mobian-project.org/doku.php?id=location
Can you post the output from the AGPS uploader script? I assume you're aware that it needs to be run every time you need a GPS cold start, not just once.
Running the script didn't appear to make any difference in the ability to obtain a fix.
I've included the full output below from the script I used to disable the modem service, run the python script, re-enable the modem, and then finally enable nmea on the modem.
Quote:[root@manjaro-arm ~]# mmcli -m 0 --location-get
--------------------------
3GPP | operator code: XXX
| operator name: XXX
| location area code: XXXX
| tracking area code: XXXX
| cell id: XXXXXXXX
[root@manjaro-arm ~]# mmcli -m 0 --location-status
--------------------------------
Location | capabilities: 3gpp-lac-ci, gps-raw, gps-nmea, agps-msa, agps-msb
| enabled: 3gpp-lac-ci
| signals: no
--------------------------------
GPS | refresh rate: 30 seconds
| supported assistance: xtra
| assistance servers: http://xtrapath3.izatcloud.net/xtra3grc.bin
| http://xtrapath1.izatcloud.net/xtra3grc.bin
| http://xtrapath2.izatcloud.net/xtra3grc.bin
[root@manjaro-arm ~]# ./start_gps.sh
Removed /etc/systemd/system/multi-user.target.wants/ModemManager.service.
Removed /etc/systemd/system/dbus-org.freedesktop.ModemManager1.service.
open serial port
Check modem will talk to us
AT
[b'\r\n', b'OK\r\n']
Is GPS turned on?
AT+QGPS?
[b'\r\n', b'+QGPS: 0\r\n', b'\r\n', b'OK\r\n']
Turn off GPS
AT+QGPSEND
[b'\r\n', b'+CME ERROR: 505\r\n']
Is AGPS enabled?
AT+QGPSXTRA?
[b'\r\n', b'+QGPSXTRA: 1\r\n', b'\r\n', b'OK\r\n']
Precautionary enabling of AGPS
AT+QGPSXTRA=1
[b'\r\n', b'OK\r\n']
Is valid AGPS data already loaded?
AT+QGPSXTRADATA?
[b'\r\n', b'+QGPSXTRADATA: 0,"1980/01/05,19:00:00"\r\n', b'\r\n', b'OK\r\n']
download status: 200
delete previous AGPS data file
AT+QFDEL="RAM:xtra.bin"
[b'\r\n', b'+CME ERROR: 418\r\n']
upload new AGPS data
AT+QFUPL="RAM:xtra.bin",38653
[b'\r\n', b'CONNECT\r\n']
[b'+QFUPL: 38653,e3a4\r\n', b'\r\n', b'OK\r\n']
set current UTC time using local system time
AT+QGPSXTRATIME=0,"2020/11/28,00:45:58"
[b'\r\n', b'OK\r\n']
set AGPS data to file we uploaded
AT+QGPSXTRADATA="RAM:xtra.bin"
[b'\r\n', b'OK\r\n']
what does it day about data validity now?
AT+QGPSXTRADATA?
[b'\r\n', b'+QGPSXTRADATA: 0,"1980/01/05,19:00:00"\r\n', b'\r\n', b'OK\r\n']
NOTE: it's given us the same response as before, despite having new data uploaded
enable gps
AT+QGPS=1
[b'\r\n', b'OK\r\n', b'\r\n', b'+QGPSURC: "xtradataexpire",0,"1980/01/05,19:00:00"\r\n']
close serial port
Created symlink /etc/systemd/system/dbus-org.freedesktop.ModemManager1.service → /usr/lib/systemd/system/ModemManager.service.
Created symlink /etc/systemd/system/multi-user.target.wants/ModemManager.service → /usr/lib/systemd/system/ModemManager.service.
successfully setup location gathering
[root@manjaro-arm ~]# mmcli -m 0 --location-status
--------------------------------
Location | capabilities: 3gpp-lac-ci, gps-raw, gps-nmea, agps-msa, agps-msb
| enabled: 3gpp-lac-ci, gps-nmea
| signals: no
--------------------------------
GPS | refresh rate: 30 seconds
| supported assistance: xtra
| assistance servers: http://xtrapath3.izatcloud.net/xtra3grc.bin
| http://xtrapath1.izatcloud.net/xtra3grc.bin
| http://xtrapath2.izatcloud.net/xtra3grc.bin
*** waited around 10 minutes ***
[root@manjaro-arm ~]# mmcli -m 0 --location-get
--------------------------
3GPP | operator code: XXX
| operator name: XXX
| location area code: XXXX
| tracking area code: XXXX
| cell id: XXXXXXXX
--------------------------
GPS | nmea:
| $GPGSV,3,1,10,02,45,167,,05,64,036,,06,03,149,,07,12,040,,1*6F
$GPGSV,3,2,10,09,,,,12,,,,13,76,278,,15,38,254,,1*6C
$GPGSV,3,3,10,16,,,,18,10,319,,1*51
| $GPGSA,A,1,,,,,,,,,,,,,,,,*32
| $GPRMC,,V,,,,,,,,,,N*53
| $GPVTG,,T,,M,,N,,K,N*2C
| $GPGGA,,,,,,0,,,,,,,,*66
As an aside I ran into someone on reddit who seemed to think it might be a hardware issue. I'm not entirely sure though if that's the case for my phone.
https://www.reddit.com/r/PinePhoneOfficial/comments/jzw10j/gps_fails_to_acquire_satellites/
RE: Unsatisfactory GPS reception on PinePhone? - Lousy Fisherman - 11-28-2020
You need to enable agps first, then gps-raw then gps-nmea. The detail are somewhere in this forum
HTH
LF
RE: Unsatisfactory GPS reception on PinePhone? - wibble - 11-28-2020
My script is based on the process described in the Quectel docs. I thought these were already in the wiki but apparently not:
https://www.quectel.com/UploadImage/Downlad/Quectel_EC2x&EG25-G&EG9x&EM05_FILE_AT_Commands_Manual_V1.0.pdf
https://sixfab.com/wp-content/uploads/2018/09/Quectel_EC25EC21_GNSS_AT_Commands_Manual_V1.1.pdf
The 'CME ERROR: 505' is because the GPS is already off.
The 'CME ERROR: 418' is a failure to delete the file, which suggests it's the first time you've run the script since a modem reset.
I don't see anything obviously wrong, although it seems I didn't paste the output into my notes so I'm going from memory. How good is your view of the sky? I was testing from indoors by a window, and it was usually hard to get a fix without AGPS. With AGPS it was often very quick, but not always. When I was testing I kept modemmanager disabled and used picocom to access the serial devices directly.
I can't comment with certainty on a potential hardware error on the 1.2a boards as I only have a 1.1, but there's no mention of changes to the GPS antenna board layout.
RE: Unsatisfactory GPS reception on PinePhone? - sog8b - 11-30-2020
(11-28-2020, 09:53 AM)Lousy Fisherman Wrote: You need to enable agps first, then gps-raw then gps-nmea. The detail are somewhere in this forum
HTH
LF
I tried doing this and waiting 10 seconds in between enabling each, it didn't effect the end result I was still unable to obtain a lock/fix on a single satellite, let along enough to actually acquire my location. I'm going to troubleshoot with a friend who also has the phone and see if they can get it working, then I can copy there configuration and see if mine is a hardware issue or something else. Thanks for your tips though, any one else with other tips is more very welcome to suggest.
By the way there are two agps modes, agps-msa and agps-msb, which one are you enabling and using?
(11-28-2020, 11:49 AM)wibble Wrote: My script is based on the process described in the Quectel docs. I thought these were already in the wiki but apparently not:
https://www.quectel.com/UploadImage/Downlad/Quectel_EC2x&EG25-G&EG9x&EM05_FILE_AT_Commands_Manual_V1.0.pdf
https://sixfab.com/wp-content/uploads/2018/09/Quectel_EC25EC21_GNSS_AT_Commands_Manual_V1.1.pdf
The 'CME ERROR: 505' is because the GPS is already off.
The 'CME ERROR: 418' is a failure to delete the file, which suggests it's the first time you've run the script since a modem reset.
I don't see anything obviously wrong, although it seems I didn't paste the output into my notes so I'm going from memory. How good is your view of the sky? I was testing from indoors by a window, and it was usually hard to get a fix without AGPS. With AGPS it was often very quick, but not always. When I was testing I kept modemmanager disabled and used picocom to access the serial devices directly.
I can't comment with certainty on a potential hardware error on the 1.2a boards as I only have a 1.1, but there's no mention of changes to the GPS antenna board layout.
Thanks for the comment, perhaps once I am more familiar I will feel more comfortable to use picocom to interact with them directly instead of using modem manmager.
I contacted pine microsystems about the post on https://www.reddit.com/r/PinePhoneOfficial/comments/jzw10j/gps_fails_to_acquire_satellites/ and they said that there shouldn't be any hardware issue "Please to inform that we had confirmed with design engineer is the GNSS ant suppose short to ground and this is normal behavior."
So if there is some hardware issue it is most likely internal to the modem module itself in my case, I will need to diagnose further. Thanks for your feedback.
RE: Unsatisfactory GPS reception on PinePhone? - wibble - 11-30-2020
So far as I can tell ModemManager is treating the modem as a generic Qualcom device via QMI for many purposes, including its AGPS capability, rather than using the Quectel AT commands. I did try enabling AGPS using ModemManager's commands, and the URLs it provides, but either it doesn't work with the Quectel modem or I didn't use it correctly. You'll see that the URLs are similar to, but not quite the same as, the ones in Quectel's documentation, and the data they return isn't the same.
If you do use picocom (or whatever other serial terminal you prefer) you'll need to turn on local echo for the terminal sending commands, otherwise you won't be able to see what you're sending.