GPS location not working 100%

Hi all,
I am using the le_gnss API on a WP7702 and I have noticed that occasionally the satellite signal jumps around a little bit.
The le_gnss_GetLocation() will return:
-32.095882415771484 115.96153259277344
-32.095794677734375 115.96141815185547
-32.095703125 115.96129608154297
-32.09560775756836 115.96116638183594
-32.101348876953125 115.96318054199219
-32.10155487060547 115.96296691894531
-32.09540939331055 115.9609146118164
-32.094993591308594 115.96037292480469
-32.09478759765625 115.9601058959961
-32.09468460083008 115.95996856689453
-32.094581604003906 115.9598388671875

In my code, before printing the position I check:
// Get position state
result = le_gnss_GetPositionState(positionSampleRef, &state);

I am also logging other parameters:
hAccuracy: 3,
altitude: 21,
vAccuracy: 30,
hSpeed: 1500,
satsInViewCount: 25,
satsTrackingCount: 23,
satsUsedCount: 16
which are pretty much the same for every sample.

At first sight I would say this is to do with the positioning giving (occasionally) the wrong value, so I was wondering if anyone had experience with this and how to fix it?
Should I filter out samples, or this could be related with antenna I am using?
Or I should not be using the gnss API but something else instead?

For instance I see there are two separate API, one is GNSS and one is Positioning, I was wondering if the positioning is already performing some sort of filtering on the acquired samples, so I don`t need to mess around with them.

So my immediate question is increasing the time for le_gnss_SetAcquisitionRate() will average the positioning? I have it set to 1000ms, possibly the GPS engine is getting samples every xxms and will avarage these out depending on the acquisition rate? I have tried with1000ms and 2000ms and it didn`t seem to make any difference…

Appreciate any feedback on this.

Hi @claudio.baldini

Can you tell more about “Wrong value”? Which parameters are not as expected? Can you compare with the correct values?
Can you please share the FW which are you using ? How percent the module gets wrong values in your testing?

@Vianney if you look at the sample series I have posted above, the 5th and 6th element you can see our out of the positioning (did try to put them in bold but it doesn`t come up properly).
you see the latitude is slowly decreasing, then it suddenly jumps up and then start following the same trend.
This is random, but enough to give problems with our navigation map.

Do you have experience with the legato framework?
Have posted in both the mangOH and legato forums but no answer so far.
Should I use the le_gnss or le_pos app for getting the location?
I did check source code for both and it does seem they get the position the same way, so I am not sure that swapping to le_pos will fix this problem.

Hi @claudio.baldini ,
I believe the keypoint here is Acquisition rate but legato app. That value is used to set the interval between two fix requests
Qualcomm-based platform hot start performance is about 1~3s, it’s an average value. So you may notice a void NMEA string (and the corresponding Legato position sample notification) during hot start and then the valid NMEA string on an AcquisitionRate minimum time interval. But it’s should not be so accurate, you may have 1~3s error-range.
So please try to adjust the time to match with your condition
You can find more details in the link below
Let free feel share any question you have. Help us tick “Solution” if it is useful. It might help someone getting same concern

I read that document but to me is only at starting of the GNSS engine?
Or this can also happen during operation?
Can set a 4s acquisition rate, but this would make our navigation application quite bad, how can we determine if the service is running properly?

Hi @claudio.baldini ,
As we all know, most of the time needed to calculate the fix is spent for the acquisition process and to read the navigation data (satellite ephemeris and clock corrections) for the calculation of the pseudoranges to the satellite. Hot start performance is about 1~3s, it’s an average value. But you may have 1~3s error-range as the document mentioned. That is how it work. The application ran perfectly when you set >= 4s acquisition rate as you confirmed so I believe that is the good solution for this scenario
Please share if you have any questions. Help us tick Solution under my response if it is useful. It might be beneficial to someone have same concern