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

A-GPS download fails mid session

Hello,

I am trying to run the A-GPS sample program but am encountering a bit of difficulty with the SUPL code.

I had to modify the LTE connection code to allow access for NB-IoT, APN and User/Pass for the SIMs we are using but encounter this error during the connection and download process:

New AGPS data requested, contacting SUPL server, flags 59
Established LTE link
ip 4a7d:8cc0:: (c08c7d4a) port 7276
Starting SUPL session
ULP encoding length: 38
Bytes sent: 38
Bytes received: 34
ULP ossDecode success, choice 3
SUPL server responded using version 2.0.4
SUPL response received
ULP encoding length: 57
Bytes sent: 57
read again
Bytes received: 708
ULP ossDecode more input 4
Bytes received: 2996
ULP ossDecode success, choice 5
Failed to send AGNSS data, type: 1 (err: 5)
UTC conversion/injection failed, rc: 3
Generic assistance data injection failed, rc: 3
SUPL error: 2
ULP encoding length: 34
Bytes sent: 34
SUPL session internal resources released
SUPL session finished
Done

While building the sample program, I also was warned about an error in the SUPL code:

[38/138] Building C object modules/nrf/lib/supl/CMakeFiles/..__nrf__lib__supl.dir/os/lte_params.c.obj
/Users/xxxxxx/Downloads/ncs/nrf/lib/supl/os/lte_params.c: In function 'parse_lte_mcc':
/Users/xxxxxx/Downloads/ncs/nrf/lib/supl/os/lte_params.c:73:3: warning: implicit declaration of function 'memset' [-Wimplicit-function-declaration]
   memset(lte->mcc, 0, 3);

Could I get a bit of help decyphering what went wrong here? I have made no modifications to the SUPL code and only added code to enable connection to the Network in my local area.

	static const char     at_commands_NB[][50]  = {
					AT_CFUN_OFF,
					AT_XSYSTEMMODE,
	#ifdef CONFIG_BOARD_NRF9160_PCA10090NS
					AT_MAGPIO_LTE,
					AT_BANDLOCK,
					AT_APN,
					AT_USER_PASS,
	#endif
					AT_ACTIVATE_LTE
				};
				
*********************************

static int activate_lte(bool activate)
{
	if (activate) {
		for (int i = 0; i < ARRAY_SIZE(at_commands_NB); i++) {

			if (at_cmd_write(at_commands_NB[i], NULL, 0, NULL) != 0) {
				printk("Error with at_commands_NB\n");
				return -1;
			}
		}

The above should be working correctly if the device was able to connect to the SUPL library in the first place so I doubt it's the above changes.

Many thanks,

MJD

  • Hi Michael

    Depending on the network your device is connected to, SUPL and NB-IoT might block one another, and therefore not be a great combo. Most networks do not block TCP on NB-IoT by default but can drop TCP packets when there is too much strain on the network traffic. What you can try to do, is to use the legacy PCO instead of ePCO to see if that makes a difference (if you haven't already). The Asset Tracker sample has one version with and without this that you can use for reference to see how this is enabled/disabled

    As for the error code Failed to send AGNSS data, type: 1 (err: 5) that seems to point to an I/O error from the POSIX error list, located here: 

    Can you confirm that you have enabled the SUPL client support in your project by setting CONFIG_SUPL_CLIENT_LIB=y in the prj.conf file? You can see Configuring your application for information on how to change config. options.

    Best regards,

    Simon

  • Hi ,

    Yes, I added in strerror() into the error logging for that printk() and it does indicate an I/O error.

    I have added the entire prj.conf below for review, I can confirm that the SUPL support was enabled. I could have a look at enabling legacy PCO and see if that helps. It could very well be some sort of issue with TCP as the application I have designed is purely UDP so I have zero experience with TCP on the nRF9160.

    #
    # Copyright (c) 2019 Nordic Semiconductor ASA
    #
    # SPDX-License-Identifier: LicenseRef-BSD-5-Clause-Nordic
    #
    CONFIG_BSD_LIBRARY=y
    CONFIG_STDOUT_CONSOLE=y
    CONFIG_UART_INTERRUPT_DRIVEN=y
    CONFIG_NEWLIB_LIBC=y
    CONFIG_NEWLIB_LIBC_FLOAT_PRINTF=y
    CONFIG_AT_CMD=y
    CONFIG_AT_NOTIF=y
    
    # Enable SUPL client support
    CONFIG_SUPL_CLIENT_LIB=y
    
    # Networking
    CONFIG_NETWORKING=y
    CONFIG_NET_SOCKETS_OFFLOAD=y
    CONFIG_NET_SOCKETS=y
    CONFIG_NET_SOCKETS_POSIX_NAMES=y
    CONFIG_NET_SOCKETS_SOCKOPT_TLS=y
    
    # Disable native network stack to save some memory
    CONFIG_NET_NATIVE=n
    
    # Main thread
    CONFIG_HEAP_MEM_POOL_SIZE=2048
    CONFIG_MAIN_STACK_SIZE=4096

    Looking at the AT manual, seems to be just using the AT command %XEPCO. Should be very simple to add that to my AT command array

    Kind regards,

    Michael

  • UPDATE:
    I added in the command to change to legacy PCO:

    #define AT_LEG_PCO							"AT\%XEPCO=0"

    Unfortunately, it doesn't seem to have made any improvements. (strerror() response is in this log)

    Scanning [/] [1;1H[2J
    New AGPS data requested, contacting SUPL server, flags 59
    Established LTE link
    ip 4a7d:8cc0:: (c08c7d4a) port 7276
    Starting SUPL session
    ULP encoding length: 38
    Bytes sent: 38
    Bytes received: 34
    ULP ossDecode success, choice 3
    SUPL server responded using version 2.0.4
    SUPL response received
    ULP encoding length: 57
    Bytes sent: 57
    Bytes received: 708
    ULP ossDecode more input 4
    Bytes received: 1416
    ULP ossDecode more input 4
    Bytes received: 2124
    ULP ossDecode more input 4
    Bytes received: 2994
    ULP ossDecode success, choice 5
    Failed to send AGNSS data, type: 1 (err: 5|I/O error)
    UTC conversion/injection failed, rc: 3
    Generic assistance data injection failed, rc: 3
    SUPL error: 2
    ULP encoding length: 34
    Bytes sent: 34
    SUPL session internal resources released
    SUPL session finished
    Done

  • Hi

    I've forwarded this issue internally to confirm whether this might be due to TCP not cooperating with NB-IoT or not (and hopefully find a fix or workaround to this issue). Please note that we are moving into the summer vacation period here in Norway, so it might take a bit longer to get to the bottom of this than expected, as staff during the month of July will be reduced. I'm sorry about the inconvenience, but please be patient. And I'll get back to you as soon as I hear something from the devs.

    Best regards,

    Simon

Related