Nrf9160 GPS long time to fix with healthy RF electronics

[bjornshnrf]

Helo Nordic support team,

I am supporting a client that has designed a product using the NRF9160 with GPS. The product has a small patch antenna mounted on the pcb board, a saw filter and a LNA upstream the GPS port of the NRF9160.

The product has been tested extensively in the open and they experience long time to fix - in some cases 10 to 15 minutes from cold start (and some time no fix at all). It was suspected that the antenna gain and match could explain long fix time due to lov SNR for the received GPS signal. The antenna match was investigated using a network analyser and found to be around -10dB RL for the GPS band.

We have compared the product respons with a Thingy:91 using a larger patch antenna with integrated LNA. This gave similar results with long time to fix (not tested as thorough as the product).

Next test was done in a lab version of an anechoic chamber called GTEM cell. It is not a perfect environment for antenna performance tests but gives a good indication on performance. Using this GTEM device with a signal source we were able to apply a -90dbm CW signal to the product (now running only with test software and battery power). The test software logged the SNR and RSSI using the AT AT%XRFTEST=2,1,-90 at command and after the test we extracted the data from the product to a log file using a J-link SEGGER with RTT Viewer. We did a similar test with the Thingy:91 with the external antenna and got similar results.

Our preliminary conclusion is that the product (and the Thingy:91) has good RF performance (around 14dB gain including LNA, SAW and antenna gain).

I tend to conclude that the long time to fix can be explained by software. 

There are no other use of the radio between GPS read, the LTE is not used.

Can the Nordic team comment on why do we experience long time to fix from cold condition even with apparently healthy RF electronics ?

Thanks,

Regards

Bjørn

[JONATHAN LL]

Hi Bjørn,

What modem firmware version was used ?

We did a similar test with the Thingy:91 with the external antenna and got similar results.

 What SW did you use? have you tested  with our gps sample?


We have listed time to fix here, with cold start and no AGPS it should be around 36 s in good conditions. 

Regards,
Jonathan

[bjornshnrf]

Hi,

The nrf9160 was updated with the modem software version 1.2.3. The GPS program was built with nrf-sdk 1.4 with some patches but none for the gps.

Your "thingy91_nrf52_connectivity_bridge_2020-10-30_5522ca2b.hex" hex file was downloaded to the nrf52 to get a bridge between the nrf9160 and the nrf52 in order to extract log data directly to a pc with usb2com driver. I have attached one of the log files here.

The nrf9160 software is based on a nordic printout gps and measures the gps continuously. I can upload the code when I receive it if of interest. 

We experience fix time much higher than 36seconds. 

Thanks,

Bjørn

[JONATHAN LL]

bjornshnrf said:

I have attached one of the log files here.

 There does not seem to be a file attached. Could you try to attach again ?

 

Regards,
Jonathan

[bjornshnrf]

An upload file needs to have an extension name. In this case the Thingy_3 file had to be renamed to Thingy_3.txt .

thingy_3.txt

[JONATHAN LL]

I dont se anything obvious errors that would lead to this type of behavior, i will discuss this with R&D and get back to you.
Regards,
Jonathan

[JONATHAN LL]

Hi, 

can you share the code when you have access to it? 

And where is the teste done, does the device have access to the GPS signals from the start of the test?  If the devise does goes in to a deep-search prolonged periods will happen. This can happen if the device for example is in doors at first then taken outside where GPS signals are readily available. 

I tend to conclude that the long time to fix can be explained by software. 

This is most likely software issue. 


Regards,
Jonathan

[JONATHAN LL]

After going trough the GPS log, R&D had this to say:

I do not find any malfunction of GPS in the trace. It picks up PRN#30, #5 and #13 within a minute. It then picks up PRN#18 but fails to get its ephemeris due to extremely low CN0. It then picks up PRN#7 but before it can make a fix it drops #13 (PRN#13 is high up, so this is peculiar; is this due to a head or body of the user obscuring the satellite ?). After yet some time it finds PRN#14 and is able to make a fix using PRN#30, #5, #7 and #14.

Yes it takes a long time to find the satellites and get the fix, but what does stand out in the trace are the extremely low CN0 value*s. The best value seen is 34 dB, but mostly the CN0s are in the 20-30 dB range. Given that some of the satellites have a quite high elevation, *I would say the device is missing 10 dB SNR.




Regards,
Jonathan