NRF_SO_GNSS_FIX_RETRY seems to have no effect for First Fix

[Marcel Graber]

Hi,

Perhaps I have a misunderstanding of this GNSS Socket Option.

In the GPS Sample Project (samples/nrf9160/gps) with a nrf9160-dk and no connected GPS Antenna, I set:

- Interval to 0 (Single Fix)

- Retry to 60 (60 Seconds timeout for getting Fix)

But the GNSS Module will not stop searching for the First Fix. Regarding the documentation, the GNSS Module should powerdown after 60 seconds.

Best,

Marcel

[Martin Lesund]

Hi Marcel,
From your description it does not sound that you are not running a timeout, every 60sec.

You may have mismatched something in your application.
Could you please double check what you are doing in the socket calls?

[Marcel Graber]

HI Martin,

Thank you for your feedback, perhaps I was not clear enough.

To reproduce this behaviour, I have used the GPS Sample, in the NCS (nrf/samples/nrf9160/gps), I do not use my own application. 

I have changed the following lines in main.c:

static int gnss_ctrl(uint32_t ctrl)
{
int retval;

nrf_gnss_fix_retry_t fix_retry = 40;
nrf_gnss_fix_interval_t fix_interval = 0;

I have removed the external Antenna and I use the DK indoor, so there is no chance to get a fix.

When I start this Sample App, the GPS Receiver will not stop searching after 40 Seconds.

.... or do I have a misunderstanding of the NRF_SO_GNSS_FIX_RETRY setting?

[Marcel Graber]

I do not agree, even when I set 

nrf_gnss_fix_retry_t fix_retry = 120; 

it will not stop after 2 Minutes,

This is a huge problem for us, because also the gps driver (nrf9160_gps.c) will never fire GPS_EVT_SEARCH_TIMEOUT 

[Martin Lesund]

Hi Marcel,
Could you make sure you are using NCS v1.4.0 and mfw 1.2.2?

[Marcel Graber]

Hi Martin,

Yes, only to be sure, I reflashed the DK to 1.2.2 and did a clean checkout of the 1.4.0 Branch.

Then I set in main.c of the gps demo:

nrf_gnss_fix_retry_t fix_retry = 90;
nrf_gnss_fix_interval_t fix_interval = 0;

but the GPS Modul will not stop to search for the Fix:

Tracking: 0 Using: 0 Unhealthy: 0
---------------------------------
Seconds since last fix: 413
Searching [|]

NMEA strings:

$GPGGA,000653.09,,,,,0,,99.99,,M,0,,*3E
$GPGLL,,,,,000653.09,V,N*43 | |
$GPGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99,1*2D 
$GPGSV,1,1,0,,,,,,,,,,,,,,,,,1*54 | |
$GPRMC,000653.09,V,,,,,,,060180,,,N,V*01 
---------------------------------

Did you try the same on your side and it did stop searching?

[Marcel Graber]

Hi Martin, 

Any news regarding this Problem?

Greetings,

Marcel

[Martin Lesund]

Hi Marcel,

I am sorry for the delay.

There search for a 60sec minimum for the first fix of the GPS independent of the retry-value if for "periodic mode".
For single fix it will search until a valid fix, and when the retry period is over it will instantaneous do a off-on sequence.

This behavior is by design for "single-fix". (unfortunately this is not mentioned in the public documentation).

---

The alternative for you is to either run "single fix" and then turn OFF manually after a given time or run "periodic mode" to first fix and then turn OFF manually.

Another option is to run "continuous mode" to first fix or set a given time and then turn OFF manually in both cases.

Best regards,
Martin L

[Marcel Graber]

The Problem is (as mentioned in a previous post) that the nrf9160_gps.c driver cant be used then, because it's not implemented in the way you describe the workaround about this bug.

[Martin Lesund]

Hi Marcel,
I understand that this is not the most optimal solution and we will look into this internally on possible ways to improve this.

As for now, you should be able to implement this workaround by implementing some delayed works:

1. gps_start()

2. start a delayed work with your prefered timeout, where gps_stop() would be running

3. if you get a fix before the delayed work has run, then everything is fine and you can call the k_delayed_work_cancel() function.

best regards,
Martin L.

[Marcel Graber]

Thank you Martin,

Will do it like this, but it's not clean and nice, because it needs additional Resources (nrf9160_gps.c already has an additional Thread) and it's a bug-fix, which you should do on your side, not on the users code.

[Martin Lesund]

Hi Marcel,
I understand your frustration, and I agree.
There will be some improvements from our side with regards to this.
So your options is to implement this workaround on the app-level or wait for the fix on our side.

best regards,

Martin L.