A-GPS download fails mid session

[MJD093]

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

[Hakon]

MJD093 said:

Does the code call CFUN=20 correctly in the trace after A-GPS failure?

 Yes that is called and LTE is turned off. Modem still seems to do some wakeups every 1.28 seconds.

[MJD093]

Is there anything I can add to the sample that will prevent the GPS side of the application from failing to utilise cold start GPS locating after a failed A-GPS run. I'd imagine that even a successful A-GPS download would fail to start the GPS socket as well.

As I mentioned, the GPS code on it's own works fine so it's whatever is going in the handover between the LTE and GPS configs.

[MJD093]

Hi Hakon,

Has there been any word on this issue. I appreciate that the recent holidays have caused disruptions but we really need a resolution for this issue ASAP. It's been 25 days since we wanted to improve our custom devices with A-GPS.

Michael

[Hakon]

A couple of things have been mentioned since last time...

"Looking at his log in devzone the SUPL connection was totally unsuccessful, and not similar to the previous case.

The modem trace shows to me that transmitter is requested to send at full power which indicates a poor connection. Strange is that RX SNR is still positive +4dB which should be good enough."

And there is a discussion about what is happening in the trace I'm assuming, but that would be internal information so I can't share it.

[MJD093]

Hi Hakon

I work from home a lot, I live in the countryside and the transmitter would be expected to run at max TX power due to low signal strength. AT logs show that I can still achieve at least values as shown below for the RSRP:

Sending AT command: AT+CESQ                                                     
Modem response: +CESQ: 99,99,255,255,22,23

Is there an expected minimum value of RSRP that is required to improve success rates? My application requires at least values of 21 RSRP before I will allow the device to initiate UDP transfers or FOTA. It would be expected to do the same when I impliment A-GPS into my radio scheduler code in the future.