I probably need to retry some of this stuff so I can be sure it still works as it used to. I should probably try updating the modem firmware and checking that the GPS still works the same way too - I'm still on the version that came with the Brave Heart.
I didn't enable agps-msa or agps-msb except when I tried using ModemManager's agps enabling methods. They didn't work which is why I tried the AT command based route, which did work. From what I can tell ModemManager uses the generic Qualcomm interface for this, and I guess it doesn't work with Quectel's implementation.
When testing the AGPS loading script I stopped ModemManager and connected to the two serial interfaces with picocom. Other serial consoles are available - just remember that you need to enable local echo on the command interface or you won't see what commands you're sending. This will let you check almost all of that the script does manually and get used to what you ought to be seeing from the scripted commands. You can then disconnect from the command interface and use the script. Only when I could see the AGPS data loading was working and improving the fix speed and stability did I restart ModemManager, then write a wrapper script to do the stop, load and restart. If you're having trouble then go back to the basics and make sure they're working before adding complications like ModemManager. All this was usually done via ssh over WiFi for easier typing, using Mobian with automatic sleep disabled.
The script was pretty reliable for me with the phone indoors by a window, and consistently significantly better than without AGPS, but not 100%. This is in the nature of GPS - the sats are constantly moving so there's an element of chance as to whether you get a favourable or unfavourable condition for your test. At the very least you should be seeing sats in the NMEA messages, even if you don't get a lock. Before trying the AGPS I could see sats, and if I was lucky I'd get a lock in a similar time to a Garmin Geko 201 doing a cold start. If you don't see any sats at all then something's not right.
At best I was getting a fix within a few seconds of running the AGPS loading script, and that's indoors by a window.
Thanks @ wibble for your reply. I had another look at the issue today and took ModemManager completely out of the equation, as you suggested. I played through all the steps needed to set xtra data via AT commands, while reading the Quectel specs to double check. No dice. I just can't get any satellites. All I get after minutes of waiting is something like this:
Code: $GPGGA,132754.08,,,,,0,,,,,,,,*46
$GPVTG,,T,,M,,N,,K,N*2C
$GPRMC,,V,,,,,,,,,,N*53
$GPGSA,A,1,,,,,,,,,,,,,,,,*32
$GPGGA,132755.08,,,,,0,,,,,,,,*47
$GPVTG,,T,,M,,N,,K,N*2C
$GPRMC,,V,,,,,,,,,,N*53
$GPGSA,A,1,,,,,,,,,,,,,,,,*32
$GPGGA,132756.08,,,,,0,,,,,,,,*44
$GPVTG,,T,,M,,N,,K,N*2C
$GPRMC,,V,,,,,,,,,,N*53
$GPGSA,A,1,,,,,,,,,,,,,,,,*32
$GPGGA,132757.08,,,,,0,,,,,,,,*45
$GPVTG,,T,,M,,N,,K,N*2C
$GPRMC,,V,,,,,,,,,,N*53
$GPGSA,A,1,,,,,,,,,,,,,,,,*32
$GPGGA,132758.08,,,,,0,,,,,,,,*4A
$GPVTG,,T,,M,,N,,K,N*2C
$GPRMC,,V,,,,,,,,,,N*53
$GPGSA,A,1,,,,,,,,,,,,,,,,*32
$GPGGA,132759.08,,,,,0,,,,,,,,*4B
$GPVTG,,T,,M,,N,,K,N*2C
$GPRMC,,V,,,,,,,,,,N*53
$GPGSA,A,1,,,,,,,,,,,,,,,,*32
$GPGGA,132800.08,,,,,0,,,,,,,,*48
$GPVTG,,T,,M,,N,,K,N*2C
$GPRMC,,V,,,,,,,,,,N*53
$GPGSA,A,1,,,,,,,,,,,,,,,,*32
By now, I'm ready to accept that this could be a hardware issue. I'm currently still contemplating whether I should dismantle the phone and check the antenna connectors. But since this has taken so much time already, it's more likely that I'll just move on and check other use cases from my requirements list. I'll consider GPS broken on the PinePhone (or at least on mine) for now and revisit this later this year.
(01-06-2021, 07:20 AM)xelalex Wrote: However, it's usually pretty far off the actual position (100 to 200m), and since GPS actually doesn't see satellites, I guess that's location via the cell towers.
Questions:
- Am I missing anything?
- In step 4, should I enable agps-msb, gps-nmea, and gps-raw via separate calls to mmcli, in that order?
- Has anyone found a reproducible procedure for reliably getting GPS location?
- Could there be a hardware failure? Has anyone experienced an actual broken GPS receiver?
- What kind of performance can we expect at best from the particular GPS receiver that's built into the modem?
Kind regards,
Alex Yeah--your location is derived with 3gpp rather than sats. Most of the time I think 3gpp is based entirely on cell towers and perhaps service providers (including Internet providers via wifi), but theoretically, I think it could be other radio sources too, including the position of actual access point radios. 3gpp has put my position as much as 500 miles off from where I was located here in rural Idaho! At home, it puts me only about 2 or three miles away.
I only once got a sat position and, even then, the sat SNRs were very weak. I plan to get out my tiny screwdriver set and check the GPS antenna connection. Martijn Braam shows us how to open up the phone:
https://www.youtube.com/watch?v=5GbMoZ_zuZs
and megous took some hi-res photos:
https://xnux.eu/devices/photos/pp-1.2.html
I suspect the GPS/GNSS cable may be the one in the lower right here:
https://xnux.eu/devices/photos/pp-1.2/mpv-shot0002.jpg
Hmm...what's that open socket to its immediate left? Might the assembler have plugged the cable into the wrong socket? At any rate, my GPS has never been useful.
Check the schematic and the top side component placement - you'll find ANT_GNSS using ANT1501 and ANT1503 which are the two spring contacts in the extreme bottom left of the photo. The 3rd contact to the right of them is ANT1400 for the WiFi/BT. The antenna itself is printed in conductive ink on the mid frame.
(01-10-2021, 08:16 PM)calinb Wrote: ...
I suspect the GPS/GNSS cable may be the one in the lower right here:
https://xnux.eu/devices/photos/pp-1.2/mpv-shot0002.jpg
Pretty sure that is the WiFi (and maybe BT?) - the cable runs to the bottom USB-C slave board that again has pins to connect to antennae in the midframe. Reason I say WiFi is I broke the connector off my USB-C slave board when playing and that phone no longer has WiFi!
- ROCKPro64 v2.1 2GB, 16Gb eMMC for rootfs, SX8200Pro 512GB NVMe for /home, HDMI video & sound, Bluetooth keyboard & mouse. Arch (6.12 kernel, Openbox desktop) for general purpose daily PC.
- PinePhone Pro Explorer Edition, daily driver, rk2aw & U-boot on SPI, Arch/SXMO on eMMC
- PinePhone BraveHeart now v1.2b 3/32Gb, Tow-boot with pmOS/SXMO on eMMC
Is there any issue or merge request for the upstream fix for AGPS? I'd be interested to follow when a proper fix might be available.
01-19-2021, 12:30 AM
(This post was last modified: 01-19-2021, 12:36 AM by calinb.)
(01-15-2021, 05:08 AM)dukla2000 Wrote: (01-10-2021, 08:16 PM)calinb Wrote: ...
I suspect the GPS/GNSS cable may be the one in the lower right here:
https://xnux.eu/devices/photos/pp-1.2/mpv-shot0002.jpg
Pretty sure that is the WiFi (and maybe BT?) - the cable runs to the bottom USB-C slave board that again has pins to connect to antennae in the midframe. Reason I say WiFi is I broke the connector off my USB-C slave board when playing and that phone no longer has WiFi! Ahh--thanks! Guess I'll have to trace the GPS/GNSS from the G25 pinout when I get it opened up.
(01-14-2021, 11:10 PM)wibble Wrote: Check the schematic and the top side component placement - you'll find ANT_GNSS using ANT1501 and ANT1503 which are the two spring contacts in the extreme bottom left of the photo. The 3rd contact to the right of them is ANT1400 for the WiFi/BT. The antenna itself is printed in conductive ink on the mid frame. I'm working my way backwards though this thread and just saw your info here, wibble. Thanks! It doesn't sound like its likely to be an assembly issue, given that those contacts should reliably align and connect to the antenna when the mid frame is in position, but I'll inspect it regardless. I guess there's perhaps some chance the conductive inking operation was omitted on my mid frame.
(01-17-2021, 08:27 AM)atoft Wrote: Is there any issue or merge request for the upstream fix for AGPS? I'd be interested to follow when a proper fix might be available. There's this one for Mobian. I was intending to file one for upstream ModemManager but didn't get round to it. oFono would probably need something similar for it to work with Plasma Mobile, Sailfish etc.
(12-27-2020, 07:21 PM)calinb Wrote: (12-24-2020, 11:40 AM)Benatti Wrote: (12-22-2020, 04:14 AM)calinb Wrote: (12-18-2020, 10:56 AM)Benatti Wrote:
Agradeço a atenção de todos, mas não consegui fazer funcionar ainda, vou continuar tentando e se funcionar aviso por aqui.
Google translation:
I appreciate everyone's attention, but I haven't been able to make it work yet, I will keep trying and if it works, notice here. I am sorry it does not work for you. Based on mmcli commands, my phone GPS is not as sensitive as my other phones and it has trouble receiving sufficiently strong signals from satellites to find a position unless it has a very clear view of the sky. Olá pessoal, finalmente o gps do pinephone está funcionando, vamos ao passo a passo:
1 Instalei kde-marble, foxtrotgps, gpsd e gpsd-clients.
2 Editei o arquivo com o comando: sudo nano /etc/default/gpsd para ficar como assim:
# Devices gpsd should collect to at boot time.
# They need to be read/writeable, either by user gpsd or the group dialout.
DEVICES="$GPS_LINE /dev/ttyUSB1"
# Other options you want to pass to gpsd
GPSD_OPTIONS=""
# Automatically hot add/remove USB GPS devices via gpsdctl
USBAUTO="true"
GPS_LINE=/dev/ttyUSB1
Nos testes que eu fiz, demorou bastante para funcionar a primeira vez, e constatei que com o celular exposto ao sol ele pega sinal mais rapido, parece que com o aquecimento do aparelho ele melhora a sensibilidade, quando o aparelho está frio não pegou sinal de satélite.
Não é preciso realizar os comandos :
sudo mmcli -m 0 --location-enable-agps-msb
sudo mmcli -m 0 --location-enable-gps-raw
sudo mmcli -m 0 --location-enable-gps-nmea
sudo mmcli -m 0 --location-get
sudo mmcli -m 0 --location-status
Sem acionar estes comandos foi só abrir o programa navegador de gps, eu testei tanto com marble quanto foxtrotgps e depois de algum tempo funcinou normalmente.
Sugiro o marble, parece que esta mais maduro. Consegui marcar ponto de saida e ponto de chegada, definir rota, ele realça a rota no mapa e falta viajar para teste de estrada com ele, mas isto vai demorar.
Voce pode usar o cabo serial/usb e monitorar no notebook com o programa cgps ou gpsmon no terminal, para verificar o andamento do processo de descoberta de satélites do gpsd.
Abraços, e boa passagem de ano a todos. I am happy to hear it is working! Thanks for the report. Very interesting about the cold. It was cold outside (Idaho, USA winters...brrrr) when I had problems too.
(12-23-2020, 06:42 PM)wibble Wrote: You should investigate navit, or Pure Maps with the companion OSMScoutServer for caching map data, but both require a bit of manual configuration still. There's a fair bit on navit in this thread:
https://forum.pine64.org/showthread.php?tid=10697 Thanks for the link, wibble!
Bom dia, gostaria de saber se o problema de baixa sensibilidade da antena de gps do pinephone foi resolvida no pinephone inner frame com antena revestida (peça de reposição) no store.pine64, ou se esta igual ao da ediçao postmarketing que eu adquiri, por que sinceramente hoje em dia um telefone sem gps ou com o maps e geoclue sem precisão de posição, deixa a desejar. Eu pergunto por que vejo que a impressão de uma antena na peça parece ser diferente do que veio no telefone.
grato pela atenção.
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
|