nRF9160 AGPS sample and nRF Cloud

[WesC]

I am using

MF V1.3

NCS V1.6.0

nRF9160Dk V0.15.0

Project: AGPS Sample

If i set the Interval in the gps_config structure to any number under 240 and run the sample i will see a message received in the terminal window of the nRF Cloud after every FIX and "GPS Position Sent to Cloud" message in the LTE Link Monitor.

struct gps_config gps_cfg = {
		.nav_mode = GPS_NAV_MODE_PERIODIC,
		.power_mode = GPS_POWER_MODE_DISABLED,
		.timeout = 120,
		.interval = 200,  //WRC changed to 200
		.priority = true,
	};

If i set the interval to greater than 300 i only get the message in the nRF Cloud after bootup, but never get another message received even though the LTE link Monitor says there is a FIX and "GPS Position Sent to Cloud"

D: NMEA: Position fix
I: GPS position sent to cloud

thoughts?

[Øyvind]

Hi Wes, 

This may be an issue with the nRF Cloud connection. Will need to investigate. 

Kind regards,
Øyvind

[WesC]

ITthas been a while, is there any update?

[WesC]

Any Update??

[Øyvind]

Hello, 

No, I'm afraid no updates at the moment. Will poke our developers. 

Kind regards,
Øyvind

[WesC]

I tried to log GPS performance over serial log last night but for some reason board only sends data for first half an hour and stops. For my comparison test it is ok if data is not coming to nRF Cloud but if can GPS fixes data over serial terminal I can manage my test. 

[Øyvind]

Hello, the nRF Cloud team responds with the following answer:

The AGPS sample does not handle long intervals like this, as it does not implement complete error detection and recovery of link errors. This sample, like all samples in the nRF Connect SDK, are only meant to demonstrate a particular aspect of the SDK, and are not meant to be used as production-ready examples.

If the final application is to only obtain a fix every 4+ hours, then the application should disconnect from the cloud immediately after AGPS is received and data is sent to the cloud, and then reconnect again 4 hours later to repeat the process. I'm assuming for simplicity that there are no other cloud services needed during the 4 hour wait time. This will save a lot of power and prevent wasted data bandwidth with all the required keepalive messages.

The asset_tracker_v2 application is a much more complete example of how to do this correctly.

Kind regards,
Øyvind

[Øyvind]

Hey Wes, 

Here is an update from the cloud team: 

"I did make some general improvements to the nRF Cloud use of MQTT to help detect and report NAT-timeout-caused disconnects. They were merged into the sdk-nrf main branch earlier this week.

I suggest the customer set the keepalive shorter (to 250 or so) as a stop-gap measure. The design of the keepalive mechanism is such that if the application has sent or received data with the cloud the keepalive will be delayed, so it does not unnecessarily send keepalives when they are not needed."

Any updates from your side or should we close this ticket?

Kind regards,
Øyvind