This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

AGPS with SUPL vs NRF Cloud

Hi!

(My apologies in advance in case the information I need is to be found elsewhere. There are numerous tickets related to GPS/A-GPS, but everybody seems to have his/her own twist)

I use ncs v1.3.0 installed using Toolchain Manager (Windows 10). The end goal is to implement GPS with A-GPS together with MQTT and NTP on a custom board without using NRF Cloud.

At the moment, I am running (modified) sample applications on a nRF9160 DK v0.8.5 with mixed results.

1. The gps sample with SUPL library connecting to supl.google.com works fine when using NB-IoT with legacy PCO but not when using Cat-M1, which might be due to limitations in the Swedish network I’m using. I'm investigating this further...

2. The asset_tracker sample doesn’t work:

a. Using Cat-M1, the sending of the A-GPS request seems to fail. The log shows the following:

[00:00:22.188,629] [1B][0m<dbg> nrf9160_gps.start: GPS operational[1B][0m
[00:00:22.194,641] [1B][0m<inf> gps_control: GPS started successfully. Searching for satellites [1B][0m
[00:00:22.203,216] [1B][0m<inf> gps_control: to get position fix. This may take several minutes.[1B][0m
[00:00:22.211,822] [1B][0m<inf> gps_control: The device will attempt to get a fix for 360 seconds, [1B][0m
[00:00:22.220,672] [1B][0m<inf> gps_control: before the GPS is stopped. It's restarted every 30 seconds[1B][0m
[00:00:22.230,102] [1B][0m<dbg> nrf9160_gps.gps_thread: A-GPS data update needed[1B][0m
[00:00:22.237,365] [1B][0m<inf> asset_tracker: GPS_EVT_AGPS_DATA_NEEDED[1B][0m
+CEREG: 1,"009D","0187EA20",7,,,"00000010","00000110"
[00:00:22.248,809] [1B][0m<dbg> lte_lc.at_handler: +CEREG notification: +CEREG: 1,"009D","0187EA20",7,,,"00000010","00000110"
[1B][0m
[00:00:22.260,467] [1B][0m<dbg> lte_lc.parse_psm_cfg: TAU: 3600 sec, active time: 4 sec
[1B][0m
[00:00:22.466,125] [1B][0m<dbg> nrf_cloud_transport.nct_mqtt_evt_handler: MQTT_EVT_PUBACK: id = 2 result = 0[1B][0m
[00:00:22.477,294] [1B][0m<dbg> nrf_cloud_transport.nct_mqtt_evt_handler: MQTT_EVT_PUBACK: id = 1 result = 0[1B][0m
[00:00:22.521,850] [1B][0m<dbg> aws_fota.on_publish_evt: Received topic: $aws/things/nrf-352656100221533/shadow/update/delta[1B][0m
[00:00:22.533,050] [1B][0m<dbg> aws_fota.on_publish_evt: received an unhandled MQTT publish event on topic: $aws/things/nrf-352656100221533/shadow/update/delta[1B][0m
[00:00:22.547,149] [1B][0m<dbg> nrf_cloud_transport.nct_mqtt_evt_handler: MQTT_EVT_PUBLISH: id = 3 len = 109[1B][0m
[00:00:22.560,211] [1B][0m<dbg> nrf_cloud_codec.nrf_cloud_decode_requested_state: No valid state found![1B][0m
[00:00:22.569,641] [1B][1;31m<err> nrf_cloud_fsm: nrf_cloud_decode_requested_state Failed -2[1B][0m
[00:00:22.577,941] [1B][1;31m<err> nrf_cloud_fsm: Handler failed! state: 9, type: 3[1B][0m
[00:00:22.585,449] [1B][1;31m<err> nrf_cloud_transport: nct_input: failed -2[1B][0m
[00:00:22.592,529] [1B][0m<dbg> aws_fota.on_publish_evt: Received topic: $aws/things/nrf-352656100221533/shadow/update/delta[1B][0m
[00:00:22.603,698] [1B][0m<dbg> aws_fota.on_publish_evt: received an unhandled MQTT publish event on topic: $aws/things/nrf-352656100221533/shadow/update/delta[1B][0m
[00:00:22.617,797] [1B][0m<dbg> nrf_cloud_transport.nct_mqtt_evt_handler: MQTT_EVT_PUBLISH: id = 4 len = 109[1B][0m
[00:00:22.629,699] [1B][0m<dbg> nrf_cloud_codec.nrf_cloud_decode_requested_state: No valid state found![1B][0m
[00:00:22.639,160] [1B][1;31m<err> nrf_cloud_fsm: nrf_cloud_decode_requested_state Failed -2[1B][0m
[00:00:22.647,460] [1B][1;31m<err> nrf_cloud_fsm: Handler failed! state: 9, type: 3[1B][0m
[00:00:22.654,968] [1B][1;31m<err> nrf_cloud_transport: nct_input: failed -2[1B][0m
[00:00:23.182,342] [1B][0m<dbg> nrf9160_gps.gps_thread: Waiting for time window to operate[1B][0m
[00:00:23.190,490] [1B][0m<inf> asset_tracker: GPS_EVT_OPERATION_BLOCKED[1B][0m
[00:00:23.243,927] [1B][0m<inf> asset_tracker: Sending A-GPS request[1B][0m
[00:00:23.260,345] [1B][1;31m<err> modem_info_params: Link data not obtained: 20 -5[1B][0m
[00:00:23.267,852] [1B][1;31m<err> modem_info_params: Network data not obtained: -5[1B][0m
[00:00:23.275,329] [1B][1;31m<err> nrf_cloud_agps: Could not obtain cell information[1B][0m
[00:00:23.282,897] [1B][1;31m<err> asset_tracker: A-GPS request failed, error: -11[1B][0m
+CSCON: 0
[00:00:27.538,391] [1B][0m<dbg> lte_lc.at_handler: +CSCON notification[1B][0m
[00:00:27.545,135] [1B][0m<dbg> nrf9160_gps.gps_thread: GPS has time window to operate[1B][0m
[00:00:27.552,886] [1B][0m<inf> asset_tracker: GPS_EVT_OPERATION_UNBLOCKED[1B][0m
[00:00:27.559,661] [1B][0m<dbg> nrf9160_gps.print_satellite_stats: Tracking: 0 Using: 0 Unhealthy: 0[1B][0m
[00:00:27.568,725] [1B][0m<dbg> nrf9160_gps.print_satellite_stats: Seconds since last fix 27[1B][0m
[00:00:28.543,121] [1B][0m<dbg> nrf9160_gps.print_satellite_stats: Tracking: 0 Using: 0 Unhealthy: 0[1B][0m
[00:00:28.552,124] [1B][0m<dbg> nrf9160_gps.print_satellite_stats: Seconds since last fix 28[1B][0m

b. Using NB-IoT (with regular or legacy PCA), the sending of the A-GPS request seems to succeed, but no response is received. The log shows the following:

[00:00:19.853,881] [1B][0m<inf> asset_tracker: Starting GPS[1B][0m
[00:00:19.897,644] [1B][0m<dbg> nrf_cloud_transport.nct_cc_send: mqtt_publish: id = 1 opcode = 1 len = 612[1B][0m
[00:00:19.909,790] [1B][0m<dbg> nrf_cloud_transport.nct_cc_send: mqtt_publish: id = 2 opcode = 1 len = 57[1B][0m
[00:00:19.920,013] [1B][0m<inf> gps_control: Enabling PSM[1B][0m
[00:00:19.925,689] [1B][0m<dbg> nrf_cloud_transport.nct_mqtt_evt_handler: MQTT_EVT_PUBLISH: id = 1 len = 109[1B][0m
[00:00:19.926,483] [1B][0m<inf> gps_control: PSM enabled[1B][0m
[00:00:19.941,986] [1B][0m<dbg> nrf9160_gps.enable_gps: GPS mode is enabled[1B][0m
[00:00:19.950,714] [1B][0m<dbg> nrf_cloud_codec.nrf_cloud_decode_requested_state: No valid state found![1B][0m
[00:00:19.960,815] [1B][1;31m<err> nrf_cloud_fsm: nrf_cloud_decode_requested_state Failed -2[1B][0m
[00:00:19.969,360] [1B][1;31m<err> nrf_cloud_fsm: Handler failed! state: 9, type: 3[1B][0m
[00:00:19.977,020] [1B][1;31m<err> nrf_cloud_transport: nct_input: failed -2[1B][0m
[00:00:19.953,735] [1B][0m<inf> asset_tracker: GPS_EVT_SEARCH_STARTED[1B][0m
[00:00:19.990,997] [1B][0m<dbg> nrf9160_gps.start: GPS operational[1B][0m
[00:00:19.997,009] [1B][0m<inf> gps_control: GPS started successfully. Searching for satellites [1B][0m
[00:00:20.005,615] [1B][0m<inf> gps_control: to get position fix. This may take several minutes.[1B][0m
[00:00:20.014,190] [1B][0m<inf> gps_control: The device will attempt to get a fix for 360 seconds, [1B][0m
[00:00:20.023,040] [1B][0m<inf> gps_control: before the GPS is stopped. It's restarted every 30 seconds[1B][0m
[00:00:20.032,440] [1B][0m<dbg> nrf9160_gps.gps_thread: A-GPS data update needed[1B][0m
[00:00:20.039,642] [1B][0m<inf> asset_tracker: GPS_EVT_AGPS_DATA_NEEDED[1B][0m
+CEREG: 1,"0485","0187EA26",9,,,"00010000","11100000"
[00:00:20.286,926] [1B][0m<dbg> lte_lc.at_handler: +CEREG notification: +CEREG: 1,"0485","0187EA26",9,,,"00010000","11100000"
[1B][0m
[00:00:20.298,553] [1B][0m<dbg> lte_lc.parse_psm_cfg: TAU: -1 sec, active time: 32 sec
[1B][0m
[00:00:20.682,098] [1B][0m<dbg> nrf_cloud_transport.nct_mqtt_evt_handler: MQTT_EVT_PUBACK: id = 2 result = 0[1B][0m
[00:00:20.737,274] [1B][0m<dbg> nrf_cloud_transport.nct_mqtt_evt_handler: MQTT_EVT_PUBACK: id = 1 result = 0[1B][0m
[00:00:20.817,260] [1B][0m<dbg> nrf_cloud_transport.nct_mqtt_evt_handler: MQTT_EVT_PUBLISH: id = 1 len = 109[1B][0m
[00:00:20.829,254] [1B][0m<dbg> nrf_cloud_codec.nrf_cloud_decode_requested_state: No valid state found![1B][0m
[00:00:20.838,684] [1B][1;31m<err> nrf_cloud_fsm: nrf_cloud_decode_requested_state Failed -2[1B][0m
[00:00:20.847,045] [1B][1;31m<err> nrf_cloud_fsm: Handler failed! state: 9, type: 3[1B][0m
[00:00:20.854,553] [1B][1;31m<err> nrf_cloud_transport: nct_input: failed -2[1B][0m
[00:00:20.920,166] [1B][0m<dbg> nrf_cloud_transport.nct_mqtt_evt_handler: MQTT_EVT_PUBLISH: id = 2 len = 109[1B][0m
[00:00:20.932,098] [1B][0m<dbg> nrf_cloud_codec.nrf_cloud_decode_requested_state: No valid state found![1B][0m
[00:00:20.941,589] [1B][1;31m<err> nrf_cloud_fsm: nrf_cloud_decode_requested_state Failed -2[1B][0m
[00:00:20.949,829] [1B][1;31m<err> nrf_cloud_fsm: Handler failed! state: 9, type: 3[1B][0m
[00:00:20.957,641] [1B][1;31m<err> nrf_cloud_transport: nct_input: failed -2[1B][0m
[00:00:20.953,765] [1B][0m<dbg> nrf9160_gps.gps_thread: Waiting for time window to operate[1B][0m
[00:00:20.973,693] [1B][0m<inf> asset_tracker: GPS_EVT_OPERATION_BLOCKED[1B][0m
[00:00:21.046,173] [1B][0m<inf> asset_tracker: Sending A-GPS request[1B][0m
[00:00:21.107,879] [1B][0m<inf> asset_tracker: A-GPS request sent[1B][0m
[00:00:21.481,140] [1B][0m<dbg> nrf_cloud_transport.nct_mqtt_evt_handler: MQTT_EVT_PUBACK: id = 2 result = 0[1B][0m
+CSCON: 0
[00:00:27.208,282] [1B][0m<dbg> lte_lc.at_handler: +CSCON notification[1B][0m
[00:00:27.214,996] [1B][0m<dbg> nrf9160_gps.gps_thread: GPS has time window to operate[1B][0m
[00:00:27.222,778] [1B][0m<inf> asset_tracker: GPS_EVT_OPERATION_UNBLOCKED[1B][0m
[00:00:27.229,492] [1B][0m<dbg> nrf9160_gps.print_satellite_stats: Tracking: 0 Using: 0 Unhealthy: 0[1B][0m
[00:00:27.238,525] [1B][0m<dbg> nrf9160_gps.print_satellite_stats: Seconds since last fix 27[1B][0m
[00:00:28.213,012] [1B][0m<dbg> nrf9160_gps.print_satellite_stats: Tracking: 0 Using: 0 Unhealthy: 0[1B][0m

c. Using NB-IoT with today’s code in the ncs repo, the A-GPS request seems to succeed, but again no response is received. The log is different from that for the v1.3.0 code:

[00:00:15.747,467] [1B][0m<inf> asset_tracker: Starting GPS[1B][0m
[00:00:15.755,371] [1B][1;33m<wrn> nrf_cloud_codec: Unhandled data received from nRF Cloud.[1B][0m
[00:00:15.763,641] [1B][0m<inf> nrf_cloud_codec: Ensure device firmware is up to date.[1B][0m
[00:00:15.771,484] [1B][0m<inf> nrf_cloud_codec: Delete and re-add device to nRF Cloud if problem persists.[1B][0m
[00:00:15.781,341] [1B][1;31m<err> nrf_cloud_fsm: nrf_cloud_decode_requested_state Failed -2[1B][0m
[00:00:15.801,025] [1B][1;31m<err> nrf_cloud_fsm: Handler failed! state: 9, type: 3[1B][0m
[00:00:15.808,959] [1B][1;31m<err> nrf_cloud_transport: nct_input: failed -2[1B][0m
[00:00:15.800,689] [1B][0m<inf> gps_control: Enabling PSM[1B][0m
[00:00:15.823,486] [1B][0m<inf> gps_control: PSM enabled[1B][0m
[00:00:15.834,350] [1B][0m<inf> gps_control: GPS started successfully. Searching for satellites [1B][0m
[00:00:15.843,017] [1B][0m<inf> gps_control: to get position fix. This may take several minutes.[1B][0m
[00:00:15.851,623] [1B][0m<inf> gps_control: The device will attempt to get a fix for 360 seconds, [1B][0m
[00:00:15.860,504] [1B][0m<inf> gps_control: before the GPS is stopped. It's restarted every 30 seconds[1B][0m
[00:00:15.869,842] [1B][0m<inf> asset_tracker: GPS_EVT_SEARCH_STARTED[1B][0m
[00:00:15.876,251] [1B][0m<inf> asset_tracker: GPS_EVT_AGPS_DATA_NEEDED[1B][0m
+CEREG: 1,"0485","0187EA26",9,,,"00010000","11100000"
[00:00:16.834,716] [1B][0m<inf> asset_tracker: GPS_EVT_OPERATION_BLOCKED[1B][0m
[00:00:16.882,843] [1B][0m<inf> asset_tracker: Sending A-GPS request[1B][0m
[00:00:16.945,281] [1B][0m<inf> asset_tracker: A-GPS request sent[1B][0m
[00:00:17.026,519] [1B][1;33m<wrn> nrf_cloud_codec: Unhandled data received from nRF Cloud.[1B][0m
[00:00:17.034,790] [1B][0m<inf> nrf_cloud_codec: Ensure device firmware is up to date.[1B][0m
[00:00:17.042,541] [1B][0m<inf> nrf_cloud_codec: Delete and re-add device to nRF Cloud if problem persists.[1B][0m
[00:00:17.052,276] [1B][1;31m<err> nrf_cloud_fsm: nrf_cloud_decode_requested_state Failed -2[1B][0m
[00:00:17.060,577] [1B][1;31m<err> nrf_cloud_fsm: Handler failed! state: 9, type: 3[1B][0m
[00:00:17.068,115] [1B][1;31m<err> nrf_cloud_transport: nct_input: failed -2[1B][0m
[00:00:17.077,575] [1B][1;33m<wrn> nrf_cloud_codec: Unhandled data received from nRF Cloud.[1B][0m
[00:00:17.085,815] [1B][0m<inf> nrf_cloud_codec: Ensure device firmware is up to date.[1B][0m
[00:00:17.093,566] [1B][0m<inf> nrf_cloud_codec: Delete and re-add device to nRF Cloud if problem persists.[1B][0m
[00:00:17.103,302] [1B][1;31m<err> nrf_cloud_fsm: nrf_cloud_decode_requested_state Failed -2[1B][0m
[00:00:17.111,602] [1B][1;31m<err> nrf_cloud_fsm: Handler failed! state: 9, type: 3[1B][0m
[00:00:17.119,171] [1B][1;31m<err> nrf_cloud_transport: nct_input: failed -2[1B][0m
+CSCON: 0
[00:00:23.437,805] [1B][0m<inf> asset_tracker: GPS_EVT_OPERATION_UNBLOCKED[1B][0m
%CESQ: 58,2,24,3
%CESQ: 255,0,255,0
%CESQ: 58,2,19,2
[00:02:18.145,263] [1B][0m<inf> asset_tracker: GPS_EVT_OPERATION_BLOCKED[1B][0m
+CSCON: 1
+CSCON: 0
[00:02:30.792,907] [1B][0m<inf> asset_tracker: GPS_EVT_OPERATION_UNBLOCKED[1B][0m
%CESQ: 58,2,24,3
%CESQ: 255,0,255,0
%CESQ: 59,2,21,3

I realize that the outcome of the samples is affected by the configuration files. I use the provided prj.conf files except for the above-mentioned changes in LTE settings.

I have also modified the mqtt_simple sample by adding a variant of the gps sample code with SUPL library and a similar gps_controller as the asset_tracker. Just as the gps sample with SUPL library it works fine when using NB-IoT with legacy PCO but not when using Cat-M1.

I have the following concrete questions:

A. Can you think of an explanation for my problems with the asset_tracker example or do you have some suggestion of what I can try?

B. I find the asset_tracker code difficult to grasp. In particulat, I haven't understood where the events GPS_EVT_OPERATION_(UN)BLOCKED are generated and how the swicthing on/off of the LTE functionality to allow the A-GPS data exchange is achieved. Is this described somewhere?

C. I have tried two different approaches for swicthing on/off LTE to allow A-GPS: 

static int activate_lte(bool activate) {
	if (activate) {
		if (at_cmd_write(AT_ACTIVATE_LTE, NULL, 0, NULL) != 0) {
			return -1;
		}

		at_notif_register_handler(NULL, wait_for_lte);
		if (at_cmd_write("AT+CEREG=2", NULL, 0, NULL) != 0) {
			return -1;
		}

		k_sem_take(&lteReady, K_FOREVER);

		at_notif_deregister_handler(NULL, wait_for_lte);
		if (at_cmd_write("AT+CEREG=0", NULL, 0, NULL) != 0) {
			return -1;
		}
	} else {
		if (at_cmd_write(AT_DEACTIVATE_LTE, NULL, 0, NULL) != 0) {
			return -1;
		}
	}

	return 0;
}

which doesn't work at all.

static int activate_lte(bool activate) {
	if (activate) {
        lte_lc_offline();
        lte_lc_connect();
	} else {
        lte_lc_offline();
        lte_lc_system_mode_set(LTE_LC_SYSTEM_MODE_GPS);
        lte_lc_normal();
	}

	return 0;
}

which works, but seems to do more than necessary.

Which is the method you recommend?

Berst regards,

Per

Parents
  • Hi Per,

    Common for all the issues you're seeing is that they're hard to debug without knowing more about what the device sends to the SUPL server using LTE-M and to nRF Cloud in the asset tracker case. It would be very useful if you can follow the guide here and gather modem traces, which will help a lot in understanding what fails: 

    https://devzone.nordicsemi.com/nordic/cellular-iot-guides/b/getting-started-cellular/posts/how-to-get-modem-trace-using-trace-collector-in-nrf-connect

    Also, I need to know which modem firmware version you're using.

    Anyway, I'll try to answer your questions based on the information you've added here.

    A)

    In the first log ouput you provide, this line says that gathering information for the A-GPS request fails:
    <err> modem_info_params: Link data not obtained: 20 -5

    Some networks/SIM cards don't provide all information that is requested, which can cause failures like this. I think you should be able to fix that issue by setting this configuration in your Kconfig:

    CONFIG_MODEM_INFO_ADD_DATE_TIME=n
    B)

    The GPS_EVT_OPERATION_(UN)BLOCKED events indicate whether the GPS is allowed to use the radio resources to receive GPS signals. By default, LTE has priority, which causes the GPS to be blocked from using the radio whenever the LTE modem requires it.
    To use A-GPS, LTE has to be enabled while data is being transfered. When the download of A-GPS data is done, you can switch off LTE to let GPS operate. That's what's done in the GPS sample.
    In the asset tracker a different approach is used, where the device instead Power Saving Mode (PSM) from the network, which, when granted, will let the GPS operate uninterrupted by LTE for the duration of the PSM interval, or until the device itself initiates a data transfer. The reason for this approach in the asset tracker is power consumption. Attaching to and detaching from network consumes relatively much power, compared to just let the modem go to sleep. In addition a TLS handshake would have to be done with the cloud server every time data is sent, and this is also a quite costly affair in terms of power consumption and bytes sent on air. It's not unusual that a TLS hanshake requires to send and receive 5k - 8k bytes. Staying in PSM and keeping the MQTT connection alive by periodic pings to the broker may therefore be preferred, depending on your use-case.
    C)
    I would go for the seconds approach. There seems to be missing a line setting the system mode in the case where LTE should be activated, but other than that it looks reasonable. 
    The link controller library will soon also support activating GPS and/or LTE only, which will simplify this switching.
    To sum up, I'd need modem traces and modem firmware version to continue. It will also be useful to know which network you are using. If you wish to share code or information that should not be public, you can make this ticket private.
    Best regards,
    Jan Tore
  • Hi Jan Tore!

    Many thanks for the insights provided in your answers above! Especially what you write under B) is very good info for me as I haven't understood these (for me) intricate details until now.
    The modem firmware version I use is 1.2.0 (sorry for not including this in my original ticket).

    Providing you with modem traces will take some time depending on which priorities I have to make. I leave this ticket open for now, and will decide if it needs to be made private when I know how to proceed.

    Thanks for now!

    Besxt regards, Per

Reply
  • Hi Jan Tore!

    Many thanks for the insights provided in your answers above! Especially what you write under B) is very good info for me as I haven't understood these (for me) intricate details until now.
    The modem firmware version I use is 1.2.0 (sorry for not including this in my original ticket).

    Providing you with modem traces will take some time depending on which priorities I have to make. I leave this ticket open for now, and will decide if it needs to be made private when I know how to proceed.

    Thanks for now!

    Besxt regards, Per

Children
Related