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

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

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

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

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

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 ?