WP8548 / FX30 16.10.3/4 GNSS GPS Time to first fix

1

Does anyone know how to improve the time to first fix for the WP8548?

By experimentation I have discovered that running the “poweroff” command when shutting down the system makes a massive improvement to TTFF. Unfortunately this isn’t a practical long term approach for our project as the power is removed by the user with no prior notification. Is an alternative method available which doesn’t require a system reboot

Thanks

John

I have posted a similar question here - I’m not sure what the cross forum rules are - could be that the SW forum is being read by different folks

https://forum.sierrawireless.com/t/fx30s-16-10-1-m3-wp85-gnss-time-to-first-fix-issues/16243

2

hi @johnofleek,
how to handle the gnss part, is it using legato api and service or is it by another way?
best regards

3

Hi plu

In this case I was just testing so I used the USB serial port which streams NMEA into my host computer. I then observed the satalite data with the SW GPS tool which does a reasonable job of displaying the data

On the target device I controlled the GPS with the Legato command line tool “gnss” - of course this tool uses the Legato API to talk to the Qualcomm device.

I think that on the Target device linux command line the command

gnss fix

gives a reasonable indication of the TTFF

4

Hi @johnofleek,

TTFF value depends on GNSS conditions and also on GNSS Data availability/validity. Moreover, generally TTFF value refers to probability (50%, 95%) or average value, tested in very good conditions: all GNSS constellations available, open sky (ie. signal level = -130dBm).
Regarding GNSS Data, they are stored when GNSS is stopped. Before shutting down the module, you should enter “gnss stop” target command.
Did you perform that test in “open sky” condition, urban canyon, inside a building, …? What type of antenna did you use? How many test did you performed?
Could you try “cold restart” several times and check satellites information?

  • gnss start
    Then loop
    // wait 60 minutes
  • gnss get ttff
  • gnss get posInfo
  • gnss get satInfo
  • gnss restart cold
    End of loop

Best regards

5

Hi

I have carried out a simple test to try to compare the FX30S against a WP7702 - the testing used

  • Sky visibile southern half - in building in the window facing south
  • Active GNSS antenna on groundplane
  • FX30S_WP8548
  • FX30S_WP7702
  • WP7702 fitted to simple dev board
  • No SIM fitted

I have uploaded a couple of NMEA log files taken some time after the devices had fixed

fx30sgnss.nma (247.5 KB)
WP7702gnss.nma (246.6 KB)

  • Logged at approx the same time of day FX30 first - then WP7702
  • Same antenna used
  • Devices had been powered down for 3 weeks +
  • TTFF FX30S WP8548 ~ 10 minutes
  • TTFF WP7702 ~ 30 seconds
  • TTFF FX30S WP7702 ~35 seconds

The WP7702 seems to have a greater CN than the FX30S typically 44dB-Hz vs 35dB-Hz

I’m wondering if there is an issue with the GNSS performance on the FX30S WP8548 ?

6

Hi @johnofleek,

Thanks for your feedback.
I had a look on those logs. As example, those timestamps below:
From logs WP7702gnss.nma
$GPRMC,095535.00,A,5306.408958,N,00201.504135,W,0.0,165.2,100619,4.5,W,A39
$GPGSV,3,1,10,12,28,085,31,14,31,246,32,25,68,082,30,26,14,274,227A
$GPGSV,3,2,10,29,68,175,31,31,54,289,33,32,19,227,45,02,29,057,79
$GPGSV,3,3,10,06,06,023,49,4040
From logs fx30sgnss.nma
$GPRMC,092646.0,A,5306.404553,N,00201.517146,W,0.0,0.0,100619,4.5,W,A04
$GPGSV,3,1,12,12,39.4,78.8,25.0,14,38.7,260.2,25.0,24,6.3,139.2,32.8,25,81.6,61.9,21.942
$GPGSV,3,2,12,29,54.8,185.6,32.1,31,42.9,298.1,24.6,32,30.9,236.2,34.5,49,27.4,170.2,34.37C
$GPGSV,3,3,12,02,30.9,71.7,03,2.8,326.3,06,14.8,32.3,26,3.5,268.6,7F
$GPGSV,3,1,12,12,39.4,78.8,25.0,14,38.7,260.2,25.0,24,6.3,139.2,32.8,25,81.6,61.9,21.942
$GPGSV,3,2,12,29,54.8,185.6,32.1,31,42.9,298.1,24.6,32,30.9,236.2,34.5,49,27.4,170.2,34.37C
$GPGSV,3,3,12,02,30.9,71.7,03,2.8,326.3,06,14.8,32.3,26,3.5,268.6,*7F

From logs WP7702gnss.nma, Satellites SNR (C/No) values are from 22 to 45 dB-Hz
From logs file named fx30sgnss.nma, Satellites SNR (C/No) values are from 21.9 to 34.5 dB-Hz
SNR values are different for some SVs, about 5 dB-Hz. It could be explained by test environment (indoor, obstructed view thru window) on different timestamps (about 30 min).
Nevertheless, SNR is similar for SVID 29, as shown below:
$GPGSV,3,2,10,29,68,175,31
$GPGSV,3,2,12,29,54.8,185.6,32.1

So it seems we cannot confirm that performance issue from those logs. Do you agree?
Moreover, I’ve got one FX30_WP8548, and tried it in “open sky” condition (roof top antenna). Results was as expected, ie. TTFF for “Cold start” is ~30 seconds.
Checking the Product Technical Specification document, those Devices have similar result with regard to TTFF performances.

I would recommend to compare those Devices in “open sky” environment, or same antenna connected to both Devices at the same time (using splitter and DC blocker for one of them).

Hope it helps !

Regards

7

Hi wdev

I am still experimenting with this issue. But have made some progress. At the time I raised the post I didn’t have an FX30S WP7702

  1. The FX30S WP8548 device I was testing - it seems that it was an earlier prototype. A colleague had later production device - this performed much more like the WP7702
  2. Whilst trying to understand why the indoor performance was so variable we discovered by experimentation that proximity to IT equipment has a massive impact on the TTFF and to lesser extent after a fix - satellite CNR. Looks like this could indicate in band interference but of course it could be something else like a mixing product in the active antenna.

For this project I am limited to COTS GNSS active antennas - I have improved performance by +3dB by selecting a better antenna but of course it probably still isn’t optimum - for example the LNA gain is way to high at 25dB

8

Hi @johnofleek,

Thanks for those information! It could explain that issue indeed.
For GNSS active antenna specifications, you should refer to GNSS Antenna Recommendations detailed in Product Technical Specification document.
Regarding GNSS performances, usually they are measured in “good” conditions (open sky, SV RF signal level = -130dBm, with all GNSS constellations, …).
If you have to evaluate it, I would recommend outdoor with open sky condition or GNSS simulator, it is better than indoor condition, as GNSS is not supposed to work in pure indoor condition.

Hope it helps!

BR