How does GNSS works on WP7702?

Hello !

I am using the GPS on my mangOH Yellow, and I wanted to understand what impacts the Time To First Fix (TTFF).

I made an app that enters ULPM for x seconds, then make a GPS fix and go back to sleep for x seconds. I tried different values for x, from 1 min to 12h.
However, it seems like the TTFF is always the same (30 seconds approximately), regardless of how much time is spent in ULPM.

Then I tried to deactivate the radio with:

$  cm radio off

And it appears that without radio, the TTFF after 6h of ULPM is bigger (something like 1min30 / 2min).

So my guess is that the board downloads some ephemeris / almanac data from a server when the radio is ON to make a fix quicker.
But I would like to know more precisely how GNSS information is dealt with on WP7702 ?

Hope someone can help, have a good day !

1 Like

If radio is off, it cannot use agps, so the ttff will be increased.

Some more idea on gps:

1 Like

Thanks for your reply, this post was really helpful !

However this is surprising because I thought I configured my board in standalone mode with:

$ gnss set agpsMode alone

Also running AT!GPSXTRADATAENABLE? returns:

XTRA Data Enabled: 2
XTRA Data Retry Number: 3
XTRA Data Retry Interval: 10
XTRA Data Autodownload Enabled: 0
XTRA Data Autodownload Interval: 24
XTRA Data Validity Time: 168

Apparently Autodownload was disabled, yet the board was still able to get GPS data from the server upon boot without using AT!GPSXTRAINITDNLD. How is this possible ?

Maybe you can try at! gpsfix command with standalone mode and see if it use the stored agps data.

Ok I tried that but I witnessed some strange behavior: I can’t use AT!GPSFIX when the radio is powered OFF.

When I do:

$ cm radio off

I get this when I try to make a fix with AT commands:

>> AT!GPSFIX=1,120,50
ErrCode = 15

The error code apparently means there is an “Error in Fix” as it’s written in the documentation.
Strangely I can still get a fix by using the gnss tool on the board with:

$ gnss start 
$ gnss fix

As soon as I power the radio ON, I can get a fix with AT!GPSFIX without errors…

I thought these 2 commands were the same, but apparently not :confused:

Thak you for your time @jyijyi !

I remember gnss command is not equal to AT command.
You can check "gnss set constellation " and AT command is not changed.

Do you mean you want to start with clean gps fix each time waking up from ulpm mode?

If yes, have you tried “gnss restart” command with cold boot?

Okay that’s weird, so the 2 commands don’t change the same data ? ._.

Not really, I just wanted to understand where and how I could configure the Assisted Mode for the GNSS, as it seems like XTRA is not what’s used by default on the board ?
Because the board is downloading GPS data automatically even with the XTRA Data Autodownload option disabled, and this confuses me… :expressionless:

Have a good day !

Please ignore my previous comment “gnss command is not equal to AT command”.
This is for WP75/WP85 only.
On WP76 module, I can see the following:
root@swi-mdm9x28-wp:~# gnss get constellation
ConstellationType 15
GPS activated
GLONASS activated
BEIDOU activated
GALILEO activated
QZSS not activated
root@swi-mdm9x28-wp:~#
root@swi-mdm9x28-wp:~# microcom /dev/ttyAT
at
OK
at!gnssconfig?
GPS: 1
GLONASS: 1
BDS: 1
GAL: 1

OK
at!gnssconfig=1,0,0,0
OK
root@swi-mdm9x28-wp:~# gnss get constellation
ConstellationType 1
GPS activated
GLONASS not activated
BEIDOU not activated
GALILEO not activated
QZSS not activated
root@swi-mdm9x28-wp:~# cm info
Device: WP7607
IMEI: 359779081234565
IMEISV: 6
FSN: VN730485080103
Firmware Version: SWI9X07Y_02.28.03.05 000000 jenkins 2019/07/08 11:04:16
Bootloader Version: SWI9X07Y_02.28.03.05 000000 jenki[ 6352.577629] i2c-msm-v2 78b8000.i2c: NACK: slave not responding, ensure its powered: msgs(n:1 cur:0 tx) bc(rx:0 tx:2) mode:FIFO slv_addr:0x3a MSTR_STS:0x0c1300c8 OPER:0x00000090
ns 2019/07/08 11:04:16
[ 6352.598467] i2c-msm-v2 78b8000.i2c: NACK: slave not responding, ensure its powered: msgs(n:1 cur:0 tx) bc(rx:0 tx:2) mode:FIFO slv_addr:0x3a MSTR_STS:0x0c1300c8 OPER:0x00000090
MCU Version: 002.011
PRI Part Number (PN): 9908958
PRI Revision: 001.000
Carrier PRI Name: GENERIC
Carrier PRI Revision: 002.073_000
SKU: 1104301
Last Reset Cause: Reset, User Requested
Resets Count: Expected: 107 Unexpected: 4

I found that you can do the testing by AT+CGATT=0 to disable the PS attachment.

at+cgatt=0
OK
at!gstatus?
!GSTATUS:
Current Time: 6899 Temperature: 34
Modem Mitigate Level: 0 ModemProc Mitigate Level: 0
Reset Counter: 9 Mode: ONLINE
System mode: WCDMA PS state: Not attached
IMS reg state: NOT REGISTERED IMS mode: Normal
IMS Srv State: NO SMS,NO VoIP
WCDMA band: WCDMA 2100
WCDMA channel: 10663
GMM (PS) state:NULL —
MM (CS) state: IDLE NORMAL SERVICE

WCDMA L1 state:L1M_PCH_SLEEP LAC: 2F13 (12051)
RRC state: DISCONNECTED UTRAN Cell ID: 0014B79A (1357722)
RxM RSSI C0: — RxD RSSI C0: —
RxM RSSI C1: — RxD RSSI C1: —

OK
ati3
Manufacturer: Sierra Wireless, Incorporated
Model: WP7607
Revision: SWI9X07Y_02.28.03.05 000000 jenkins 2019/07/08 11:04:16
IMEI: 359779081234565
IMEI SV: 6
FSN: VN730485080103
+GCAP: +CGSM,+DS,+ES

OK
at!gpsfix=1,120,50
OK