Asset Tracker V2: A-GPS not working? LOCATION_MODULE_EVT_AGPS_NEEDED but no CLOUD_WRAP_EVT_AGPS_DATA_RECEIVED

Question

Hi there!

I'm evaluating A-GPS performance on the Asset Tracker V2 app packaged with nRF Connect SDK v2.2.0-rc1 on a Thingy:91 on NB-IoT with a contract SIM. The modem FW is mfw_nrf9160_1.3.2

The nRF9160 platform is new to me and maybe my understanding is not correct yet. From my observation it appears that the Thingy:91 is requesting A-GPS data from nRF Cloud but it is never received(?)

I have enabled debug level log output for the Cloud, Data, Location and Modem module. Here is the captured log:

thingy91.log

I can see that the LOCATION_MODULE_EVT_AGPS_NEEDED event is generated and that the Data module sends an "A-GPS request":

[00:01:19.190,338] <dbg> data_module: State transition STATE_CLOUD_DISCONNECTED --> STATE_CLOUD_CONNECTED                                                       
[00:01:19.192,230] <dbg> location: A-GPS request from modem (ephe: 0xffffffff alm: 0xffffffff flags: 0x3b)                                                      
[00:01:19.383,300] <dbg> location: Waiting for the RRC connection release...                                                                                    
[00:01:19.387,420] <inf> app_event_manager: SENSOR_EVT_ENVIRONMENTAL_DATA_READY                                                                                 
[00:01:19.434,570] <inf> app_event_manager: MODEM_EVT_MODEM_STATIC_DATA_READY                                                                                   
[00:01:19.486,694] <inf> app_event_manager: MODEM_EVT_MODEM_DYNAMIC_DATA_READY                                                                                  
[00:01:19.538,330] <inf> app_event_manager: MODEM_EVT_BATTERY_DATA_READY                                                                                        
[00:02:21.802,764] <dbg> modem_module: RRC mode: Idle                                                                                                           
[00:02:21.805,450] <dbg> location: Starting timer with timeout=90000                                                                                            
[00:02:21.805,511] <dbg> location: Request A-GPS data from application: ephe 0xffffffff, alm 0xffffffff, data_flags 0x3b                                        
[00:02:21.805,511] <dbg> location_module: Requested A-GPS data                                                                                                  
[00:02:21.805,603] <inf> app_event_manager: LOCATION_MODULE_EVT_AGPS_NEEDED                                                                                     
[00:02:21.861,663] <dbg> data_module: A-GPS request sent                                                                                                        
[00:02:22.294,494] <dbg> modem_module: Incoming RSRP status message, RSRP value is -104                                                                         
[00:02:22.615,173] <dbg> modem_module: RRC mode: Connected

I don't see the CLOUD_WRAP_EVT_AGPS_DATA_RECEIVED event in the log output. I have also put a breakpoint in cloud_module.c line 347 but it is never hit where agps_data_handle() must be called:

	case CLOUD_WRAP_EVT_AGPS_DATA_RECEIVED:
		LOG_DBG("CLOUD_WRAP_EVT_AGPS_DATA_RECEIVED");
		agps_data_handle(evt->data.buf, evt->data.len);
		break;

I can see the AGPS message on the nRF Cloud dashboard:

I also see that nRF Cloud sends an error message to the device:

I suspect that the JSON packet that request AGPS data is not correctly formatted... am I correct? Does this have to do with the modem FW version? When I started to evaluate the Thingy:91 I programmed v1.3.2 but I see that there is a newer version v1.3.3

Thanks in advance,

Pieter

glarsennordic · Accepted Answer

Apologies for the long delay in my reply. I've tested the latest code in the github repo (2.2.99). Here is the full timestamped log: Not a problem at all! I've taken a detailed look at your logs, and the GNSS fix time is actually much better than is readily apparent! The "search time" field reported by the location_module is actually a measurement of the total time the entire location acquisition process took. That means it includes: Time spent waiting for AGPS/PGPS download to finish (if the location search triggered such a download, such as on the first request after startup) Time spent waiting for RRC release Time spent on location methods other than GNSS (though this only applies if GNSS times out) So pretty much none of the search times in your list are the actual fix times, at least as far as the GNSS module is concerned. In other words, your modem is performing GNSS fix search for significantly less time than is implied by the "search time" field Currently, the best way to determine how long the GNSS modem was active is to check the timestamp difference between the: location: Starting request timer with timeout=300000 and location: Location acquired successfully: messages. For instance, on the first fix that reports a "search time" of 133573 ms, the timestamps of the two messages are, respectively, 00:06:01 and 00:06:05, so the actual fix time was approximately 5 seconds Taking a look at some of your other outliers: The 17143 ms fix actually ran from 00:30:15 to 00:30:18, and so took around 4 seconds The 25863 ms fix actually ran from 00:40:14 to 00:40:27, and so took around 14 seconds The 23624 ms fix actually ran from 01:12:22 to 01:12:25, and so took around 4 seconds I think you get the picture. A for why these outliers report such a long search time, despite the actual fix time being so short, it is because the location library is being interrupted by various things before it can actually start the GNSS fix process. On the first download, it has to wait for AGPS data to finish downloading before starting the GNSS fix. In other cases, the sample transmits some device messages, and so the location library has to wait for RRC release, so on.

Asset Tracker V2: A-GPS not working? LOCATION_MODULE_EVT_AGPS_NEEDED but no CLOUD_WRAP_EVT_AGPS_DATA_RECEIVED

Top Replies