GPS timeout and interval (with SUPL A-GPS)

[anicare-tero]

Hi,

OS: Windows 10
Editor: SEGGER Embedded Studio for ARM (Nordic Edition) V5.50c (64-bit)
nrfjprog version: 10.13.0
JLinkARM.dll version: 7.50a
nRF Connect SDK version: 1.6.0
SUPL client library version: v0.7.0
nRF9160 modem firmware version: 1.2.3

I'm having some problems with GPS and SUPL client library on our custom nRF9160 device. I'm using the nRF9160 GPS driver with a periodic GPS search mode and I have a similar gps_controller than Asset Tracker has. I also have PSM enabled.

In purpose, I tested the device inside a building so it won't get a GPS fix and see what the device is doing then. I'm not happy with the results. I see that timeout and interval is not working properly there.

Below is parts of the project configuration, code and also logs from the device.

prj.conf

# GPS
CONFIG_NRF9160_GPS=y
CONFIG_GPS_CONTROL_FIX_CHECK_INTERVAL=1200
CONFIG_GPS_CONTROL_FIX_TRY_TIME=180

# AGPS
CONFIG_AGPS=y
CONFIG_AGPS_SRC_SUPL=y
CONFIG_FPU=y

# Heap and stacks
CONFIG_HEAP_MEM_POOL_SIZE=16384
CONFIG_MAIN_STACK_SIZE=8192
CONFIG_APPLICATION_WORKQUEUE_STACK_SIZE=4096
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=8192
CONFIG_IDLE_STACK_SIZE=2048
CONFIG_NRF_MODEM_LIB_HEAP_SIZE=2048
CONFIG_NRF9160_GPS_THREAD_STACK_SIZE=4608

gps_controller.c

/* GPS search configuration */
struct gps_config gps_cfg = {
	.nav_mode = GPS_NAV_MODE_PERIODIC,
	.power_mode = GPS_POWER_MODE_DISABLED,
	.use_case = GPS_USE_CASE_SINGLE_COLD_START,
	.accuracy = GPS_ACCURACY_NORMAL,
	.timeout = CONFIG_GPS_CONTROL_FIX_TRY_TIME,
	.interval = CONFIG_GPS_CONTROL_FIX_TRY_TIME +
		CONFIG_GPS_CONTROL_FIX_CHECK_INTERVAL,
	.delete_agps_data = false,
	.priority = true,
};

main.c

#if defined(CONFIG_AGPS)
/* Request A-GPS data no more often than every hour (time in milliseconds). */
#define AGPS_UPDATE_PERIOD (60 * 60 * 1000)
static struct gps_agps_request agps_request;
static struct k_work_delayable send_agps_request_work;
#endif /* CONFIG_AGPS */


#if defined(CONFIG_AGPS)
/**@brief Request AGPS data. */
static void send_agps_request(struct k_work *work)
{
	ARG_UNUSED(work);

	int err;
	static int64_t last_request_timestamp;

	if ((last_request_timestamp != 0) &&
	   (k_uptime_get() - last_request_timestamp < AGPS_UPDATE_PERIOD)) {
		LOG_WRN("A-GPS request was sent less than 1 hour ago");
		return;
	}

	LOG_INF("Sending A-GPS request");

	err = gps_agps_request_send(agps_request, GPS_SOCKET_NOT_PROVIDED);
	if (err) {
		LOG_ERR("Failed to request A-GPS data, error: %d", err);
		return;
	}

	last_request_timestamp = k_uptime_get();
}
#endif /* CONFIG_AGPS */


/**@brief Callback for GPS events. */
static void gps_handler(const struct device *dev, struct gps_event *evt)
{
...
	case GPS_EVT_AGPS_DATA_NEEDED:
		LOG_INF("GPS_EVT_AGPS_DATA_NEEDED");
#if defined(CONFIG_AGPS)
		/* Send A-GPS request with short delay to avoid LTE network-
		 * dependent corner-case where the request would not be sent.
		 */
		memcpy(&agps_request, &evt->agps_request, sizeof(agps_request));
		k_work_reschedule_for_queue(&application_work_q,
						&send_agps_request_work,
						K_SECONDS(1));
#endif /* CONFIG_AGPS */
		break;
...
	}
}

/**@brief Main function. */
void main(void)
{
...
#if defined(CONFIG_AGPS)
	k_work_init_delayable(&send_agps_request_work, send_agps_request);
#endif /* CONFIG_AGPS */
...
}

log

[00:00:24.650,848] [1B][0m<inf> gps_control: GPS config set: Timeout = 180, Interval = 1380[1B][0m
[00:00:24.659,881] [1B][0m<inf> application: Enabling GPS[1B][0m
[00:00:24.665,954] [1B][0m<inf> gps_control: GPS starting in 0 seconds[1B][0m
[00:00:24.673,675] [1B][0m<dbg> nrf9160_gps.enable_gps: GPS mode is enabled[1B][0m
[00:00:24.686,340] [1B][0m<dbg> nrf9160_gps.start: GPS operational[1B][0m
[00:00:24.692,901] [1B][0m<inf> gps_control: GPS started successfully. Searching for satellites 
to get position fix. This may take several minutes.
The device will attempt to get a fix for 180 seconds, 
before the GPS is stopped. It's restarted every 1200 seconds[1B][0m
[00:00:24.718,627] [1B][0m<inf> application: GPS_EVT_SEARCH_STARTED[1B][0m
[00:00:24.725,708] [1B][0m<dbg> nrf9160_gps.gps_thread: A-GPS data update needed[1B][0m
[00:00:24.733,642] [1B][0m<inf> application: GPS_EVT_AGPS_DATA_NEEDED[1B][0m
[00:00:25.693,237] [1B][0m<dbg> nrf9160_gps.gps_thread: Waiting for time window to operate[1B][0m
[00:00:25.702,117] [1B][0m<inf> application: GPS_EVT_OPERATION_BLOCKED[1B][0m
[00:00:25.740,905] [1B][0m<inf> application: Sending A-GPS request[1B][0m
[00:00:25.747,772] [1B][0m<dbg> agps.init_supl: Using GPS driver to input assistance data[1B][0m
[00:00:25.756,622] [1B][0m<inf> agps: SUPL is initialized[1B][0m
[00:00:25.884,735] [1B][0m<dbg> agps.open_supl_socket: ip 142.250.150.192 (c096fa8e) port 7276[1B][0m
[00:00:25.971,160] [1B][0m<inf> agps: Starting SUPL session[1B][0m

[00:00:28.325,286] [1B][0m<dbg> agps.supl_logger: SUPL session finished[1B][0m
[00:00:28.332,366] [1B][0m<inf> agps: SUPL session finished successfully[1B][0m
[00:00:28.339,599] [1B][0m<dbg> net_sock.z_impl_zsock_close: (application_work_q): close: ctx=0x20021200, fd=1[1B][0m
[00:00:35.718,322] [1B][0m<dbg> nrf9160_gps.gps_priority_set: GPS priority enabled[1B][0m
%CESQ: 255,0,255,0
[00]+CSCON: 0
[00][00:00:40.088,928] [1B][0m<dbg> lte_lc.at_handler: +CSCON notification[1B][0m
[00:00:40.096,038] [1B][0m<inf> application: RRC mode: Idle[1B][0m
[00:00:40.152,313] [1B][0m<dbg> nrf9160_gps.gps_thread: GPS has time window to operate[1B][0m
[00:00:40.160,797] [1B][0m<inf> application: GPS_EVT_OPERATION_UNBLOCKED[1B][0m
[00:00:40.168,334] [1B][0m<dbg> nrf9160_gps.print_satellite_stats: Tracking: 0 Using: 0 Unhealthy: 0[1B][0m
[00:00:40.178,222] [1B][0m<dbg> nrf9160_gps.print_satellite_stats: Seconds since last fix 40[1B][0m

[00:03:24.098,236] [1B][0m<dbg> nrf9160_gps.print_satellite_stats: Seconds since last fix 204[1B][0m
[00:03:29.107,727] [1B][0m<inf> application: GPS_EVT_SEARCH_TIMEOUT[1B][0m
[00:03:29.114,685] [1B][0m<inf> application: GPS will try to get fix again after 1200 seconds,
and will try again 2 more times[1B][0m
[00:12:15.414,703] [1B][0m<inf> application: GPS_EVT_SEARCH_STARTED[1B][0m
[00:12:15.421,661] [1B][0m<dbg> nrf9160_gps.print_satellite_stats: Tracking: 0 Using: 0 Unhealthy: 0[1B][0m
[00:12:15.431,549] [1B][0m<dbg> nrf9160_gps.print_satellite_stats: Seconds since last fix 735[1B][0m

[00:26:24.443,939] [1B][0m<dbg> nrf9160_gps.print_satellite_stats: Seconds since last fix 1584[1B][0m
[00:26:29.453,521] [1B][0m<inf> application: GPS_EVT_SEARCH_TIMEOUT[1B][0m
[00:26:29.460,479] [1B][0m<inf> application: GPS will try to get fix again after 1200 seconds,
and will try again 1 more times[1B][0m
[00:37:15.449,981] [1B][0m<inf> application: GPS_EVT_SEARCH_STARTED[1B][0m
[00:37:15.456,939] [1B][0m<dbg> nrf9160_gps.print_satellite_stats: Tracking: 0 Using: 0 Unhealthy: 0[1B][0m
[00:37:15.466,857] [1B][0m<dbg> nrf9160_gps.print_satellite_stats: Seconds since last fix 2235[1B][0m

[00:49:24.476,348] [1B][0m<dbg> nrf9160_gps.print_satellite_stats: Seconds since last fix 2964[1B][0m
[00:49:29.485,961] [1B][0m<inf> application: GPS_EVT_SEARCH_TIMEOUT[1B][0m
[00:49:29.492,919] [1B][0m<inf> application: Disabling GPS[1B][0m
[00:49:29.499,084] [1B][0m<inf> gps_control: GPS stopping in 0 seconds[1B][0m
[00:49:29.506,134] [1B][0m<dbg> nrf9160_gps.stop_gps: Stopping GPS[1B][0m
[00:49:29.521,514] [1B][0m<inf> gps_control: GPS operation was stopped[1B][0m
[00:49:29.528,503] [1B][0m<inf> application: GPS_EVT_SEARCH_STOPPED[1B][0m

I read this ticket and I think that almanac downloads might have something to do with this. But shouldn't it already have ephemerides and almanacs downloaded from SUPL?

Is there any way to avoid those downloads or make timeout and interval working properly?

Or am I doing something wrong on A-GPS request?

It's killing the battery pretty fast when GPS is active for so long.

Regards,
Tero

[anicare-tero]

Just FYI: I updated the SUPL client library to version v0.7.1 and disabled FPU from project configuration.

[Øyvind]

Hi Tero, 

Did your last comment make it better, worse or no change? Have you tested the A-GPS sample, to verify behavior? You should look at this sample for the correct usage.

Kind regards,
Øyvind

[pemar13]

Hi Öyvind!

Many thanks for the quick response!

Øyvind said:

"See Modem firmware compatibility matrix for an overview of which modem firmware versions have been tested with this version of nRF Connect SDK."

I guess I was mislead by the table's preable "This section shows compatibility between nRF9160 modem firmware and nRF Connect SDK versions", possibly overinterpreting the word "compatibility". Maybe this should be rephrased using your words like "This section shows which which modem firmware versions have been tested with different versions of nRF Connect SDK", which, to me, has a much less stringent meaning.

Øyvind said:

Are you testing with the GPS sample or your application?

I am using the nRF9160 agps sample. Am I interpreting your above statements correctly in that you recommend using the methodology from the gps sample (i.e., using the new GNSS library) rather than the old GPS driver? In that case, an upgrade of our code to ncs v1.6.1 using the GNSS library with modem 1.2.3 for B0 and 1.3.0 for B1 would seem like the best way forward for us.

Edit: This seems related to the modem FW version. With 1.3.0 the timeout works fine in single-fix mode, but not with 1.2.3.

Best regards,

Per

[Øyvind]

Hi Per, 

pemar13 said:

Maybe this should be rephrased using your words like "This section shows which which modem firmware versions have been tested with different versions of nRF Connect SDK",

Noted. I will forward this feedback to the responsible person. 

 

pemar13 said:

Am I interpreting your above statements correctly in that you recommend using the methodology from the gps sample (i.e., using the new GNSS library) rather than the old GPS driver?

Yes, that is correct, but as mentioned, the mfw 1.2.3 is not tested with NCS v1.6.1, so we cannot guarantee all functionality. As long as it works for your application, then it's OK.

Kind regards,
Øyvind 

[pemar13]

Hi again!

I have now also tested the gps sample, which uses the new GNSS library.

Also when using this sample in single-fix mode with modem FW 1.3.0, I can set the timeout AND I receive the event NRF_MODEM_GNSS_EVT_SLEEP_AFTER_TIMEOUT as expected. However, I cannot set the timeout when using modem FW v1.2.3. This is a problem.

Have I understood the following correctly:

1. For the new GNSS library, the event NRF_MODEM_GNSS_EVT_SLEEP_AFTER_TIMEOUT will NOT occur when using modem FW v1.2.3 despite that the old driver had the event GPS_EVT_SEARCH_TIMEOUT.

2. The new GNSS library has no equivalent to the old GPS_EVT_SEARCH_STARTED for single-fix mode.

3. Just as the old driver, the new GNSS library has no equivalent to the event GPS_EVT_SEARCH_STARTED  for continuous mode.

For us, the GPS_EVT_SEARCH_STARTED, _STOPPED, and _TIMEOUT are very important to control the flow of events in a multithreaded application. Is there another way of knowing that these events occurred?

Best regards,
Per

[Øyvind]

Hi Per, 

Have a look at nrfxlib\nrf_modem\include\nrf_modem_gnss.h. NRF_MODEM_GNSS_EVT_SLEEP_AFTER_TIMEOUT is only supported in modem fw 1.2.3:

/** @brief GNSS enters sleep because fix retry timeout was reached in periodic or single fix mode.
 *
 * @details This event doesn't have any payload.
 *
 * @note This event is only supported by modem firmware v1.3.0 or later.
 */
#define NRF_MODEM_GNSS_EVT_SLEEP_AFTER_TIMEOUT 8

There are several functions that only supported by v1.3.0. If the new GNSS library does not fit your needs, we will need to look into your needs in a new support ticket. 

Kind regards,
Øyvind

[mbytelab]

I have same issue as pemar13.

I am using modem firmware v1.2.3 and NCS v1.6.0. Event GPS_EVT_SEARCH_TIMEOUT never occurs. I am using GPS driver (no new GNSS library). It works fine when using NCS v1.5.1.

Anyone found fix?

[Øyvind]

Hello mbytelab, please register a new ticket with your issue. This way we can track issues regarding GPS. 

Thank you. 

Kind regards,
Øyvind