add presetting of ublox position from LastGPSPosition

[gast04]

[robbederks]

How bad is the TTFF if this last position is significantly wrong? Can imagine this happens quite often in the field

[gast04]

I will check it, why you think that happens often? locationd updates LastGPSPosition every minute

[adeebshihadeh]

I will check it, why you think that happens often? locationd updates LastGPSPosition every minute

Regardless of whether this happens often (or even at all), we should understand failure modes like this, especially for changes that appear to be a simple, strict improvement. This actually happens on every fresh boot since LastGPSPosition is a persistent param; you drive, LastGPSPositionis properly set, device shuts off after 30 hours offroad, you go to drive again, device boots up while you're driving, and now the position is off.

[gast04]

yea, very true, didnt consider that case

[adeebshihadeh]

So I think there's three things left for the u-blox improvement project:

• understand the effects that varying degrees and combinations of wrong assistance data has on TTFF
• optimize TTFF for the online case; <15s is good, <10s is great
• test the offline TTFF case to ensure it's consistent
  • once we understand #1 better, perhaps we can do some stuff like putting in the last position. doesn't matter too much though, since there's no nav anyway

[gast04]

I got some results, first of all this cannot be reliably tested inside the GPS test box, most likely cause of too strong signal as robbe mentioned. Different test scenarios inside the box give similar timing, which cannot be true. So tests have been done outside the box.

ttfm, time to first measurement (ubloxGnss)
ttfl, time to first location (gpsLocationExternal), basically ttff
values in seconds

scenario 1, no reset, flash backup available (very likely case)
ttfm: 6.29, ttfl: 4.28
ttfm: 8.40, ttfl: 5.03
ttfm: 7.80, ttfl: 3.92

scenario 2, no reset, flash backup available, online data (wrong location, 9miles off)  (very likely case)
ttfm: 7.93, ttfl: 3.22
ttfm: 8.68, ttfl: 2.84
ttfm: 13.58,ttfl: 9.33
ttfm: 9.48, ttfl: 2.58

scenario 2, device reset with online assistance data
ttfm: 26.70, ttfl: 28.85
ttfm: 38.11, ttfl: 39.04
ttfm: 23.61, ttfl: 25.25
ttfm: 25.01, ttfl: 25.85

scenario 3, device reset with online assistance data, with location preset
ttfm: 20.58, ttfl: 21.81
ttfm: 23.87, ttfl: 24.72
ttfm:  9.98, ttfl: 11.61
ttfm: 20.88, ttfl: 22.32

with reset and online data(wrong location, 181miles off)
ttfm: 93.30, ttfl: 97.25
ttfm: 19.90, ttfl: 19.86
ttfm: 139.31,ttfl: 142.05
ttfm: 81.95, ttfl: 82.01

flash backups are tolerant against location changes up to 20miles, no noticeable time increase (tested inside box)

Summary, using online assist and flash backup, we can assure a ttff below 10seconds, will add this to this PR and remove the location change

[gast04]

reverted the change, final testing outside the box showed that UTC time setting and the flash backup gives the best result without online assist data, we hit about 10-12seconds until first location, the timing issue was that the spoofed signal has a wrong time...

[robbederks]

It might be nice to try to modify the testing box to be more alike to a real-life scenario, either by:

• Attenuating the signal to the point that the natural noise in the ublox amp and ADC is strong enough
• Adding gaussian (?) noise on top of the gps samples to mimic the real life signal quality that way

I guess the second method might be more desirable, since that would be most resistant to outside factors like ambient noise, temp,...

[gast04]

there is an attenuation setting in the limeGPS, will try this one later today, about adding gaussian I need to check the limeCode, but should be doable do, moved to testing outside the GPS box for now

[adeebshihadeh]

@gast04 what's the conclusion on this? close for now?

[gast04]

yes, I would close it for now, wanna bring the GPS box into the CI, and address the attenuation at a later point