GNSS sample

[John]

I am using the GNSS sample to gather GPS. Whilst it is working it seems incomplete. 

The following prj.conf settings seem to have little or no effect:

CONFIG_GNSS_SAMPLE_MODE_PERIODIC=y
CONFIG_GNSS_SAMPLE_PERIODIC_INTERVAL=120
CONFIG_GNSS_SAMPLE_PERIODIC_TIMEOUT=120

The version that I am using is from V1.9.1 however I have also downloaded and managed to compile the version from the latest SDK V2.5.1 which also does not sleep between the interval defined above.

What I'm trying to achieve is a GPS using LTC commands, however I never wish to connect to cellular, therefore PSM is of no value to me.

The difficulty is when I wish to disable the GPS and sleep with a low current draw, I was hoping to be able to achieve this using CONFIG_GNSS_SAMPLE_PERIODIC_INTERVAL and in addition preserve the hot fix capability.

My only workable option at the moment is to sleep before gaining a fix, then perform a reboot, however this also means that I am always doing a cold GPS fix.

Any help would be great.

[JONATHAN LL]

John said:

The following prj.conf settings seem to have little or no effect:

Have you tested with different interval and timeout values? and have you tested with a interval that is longer then the timeout?

Or is it specifically this combo that does not work?

Regards,
Jonathan

[JONATHAN LL]

Update:

In periodic mode, GNSS gets one fix with the configured interval. Between the fixes, the modem sleeps.

If you set both interval and timeout to the same value, GNSS will run continuously until it gets the first fix.
If the the device is getting GNSS fixes then the GNSS/modem should be sleeping between the fixes.

The GNSS sample does not enable LTE, when assistance is not used.
If assistance is used then you can enable CONFIG_GNSS_SAMPLE_LTE_ON_DEMAND which only keeps LTE connected whenever needed to fetch A-GNSS data.

And when you don't need cellular connection then set GNSS only system mode.

But if cellular connection is needed then PSM/eDRX should be configured.

Regards,
Jonathan

[John]

Thank you for your help. I have changed the timeout to 120 and the fix interval to 300 and made sure that edrx was set to n.

Things have improved a lot.

I'm using an unmodified sample from V1.9.1, now it "sort of" sleeps. Upon start it will try and obtain a fix for 119 seconds, if successful it will sleep for 300 - 119 seconds or what ever lesser time taken to get a fix. Slightly confusing but that seems to be what is happening. It will work properly for about 3 fixes.

Then or eventually soon you will notice that once it has obtained a fix it will continue to obtain fixes rapidly until it understands that it shouldn't be doing it and "comes to it's senses" and begins to sleep. It will then work properly for a while and repeat the annoying behavior.

I've tried for a long time to fix the issue...now had to give up :( 

I'm trying to make this a low current draw GPS and with the above random or predicably random behavior I can't.

Any help would be very much appreciated.

In the above image, you will be able to see the correct GNNS activity which is set at 300 seconds sleep. However there are numerous activity, that just seems to do what ever it feel like doing, which is clearly wrong.

The wider large current draw is GNSS continuing to obtain fixes when it should be sleeping.

I'm using modem firmware 1.3.6

Here is something interesting, it seems to perform properly for 2 intervals, then goes nuts for a while.

				if (last_pvt.flags & NRF_MODEM_GNSS_PVT_FLAG_FIX_VALID) {
                                        fix_timestamp = k_uptime_get();
                                        if (((k_uptime_get() - Too_Fast) / 1000) < 20) {
                                           printk("Whoa, hold your horses....Big Fella \n");
                                           last_pvt.flags = 0;
                                           Too_Fast = k_uptime_get();
                                        } else {
                                           Too_Fast = k_uptime_get();
                                           last_pvt.flags = 0;
					   print_fix_data(&last_pvt);
                                        }
				} else {
					printk("Seconds since last fix: %lld\n",
					       (k_uptime_get() - fix_timestamp) / 1000);
					cnt++;
					printk("Searching [%c]\n", update_indicator[cnt%4]);
				}

My work around is quite crude, but I don't think I can do much else until someone identifies that it maybe a modem problem.

Hmmm, same process still running a bit later. The pattern is not quite as I indicated.

[JONATHAN LL]

Hi,

Try to update the nRF Connect SDK to v2.2.0 or v2.5.1, these two are listed as compatible with modem firmware 1.3.6. 
See: https://infocenter.nordicsemi.com/topic/comp_matrix_nrf9160/COMP/nrf9160/nrf9160_modem_fw.html?cp=2_1_3_5 



Regards,
Jonathan

[John]

Thank you for the very useful information. I'm unable to move to the latest SDK until Nordic fix the Parse json string issue created in a separate post. I did however down grade the modem version to 1.3.2 which was indicated as being compatible with the V1.9.1 SDK.

The same issue is still happening as shown above. I would be grateful if you would run a test to confirm what it is that I am experiencing please.

As mentioned I'm stuck with V1.9.1 for a while and it would be great to be able to make this work.

I noticed this in the documentation for GNSS

In periodic navigation mode, when GNSS determines it needs to download ephemerides or almanacs from the broadcast, the fix interval and fix retry parameters are temporarily ignored. GNSS will perform scheduled downloads until it has downloaded the data it needs, after which normal operation is resumed.

That's wonderful, but while it is fluffing around doing that is it possible that it is also explaining that it has obtained a fix and therefore forcing me to deal with it when I don't want to ?