GNSS data/fix running at minimum of 1Hz (1 per second)?

[Bruce Chase]

Can any of you give me some direction of where to find out if Android OS or hardware is limiting GNSS data and fixes to 1Hz -- once per second. I need better than 1 second accuracy of GNSS data and fixes for an application.  Or more succinctly, have you ever seen GNSS data/fixes come in significantly under 1Hz? 

I have built a number of small apps (based on other peoples' work) to test this hypothesis across two phones of different manufacturers and found both had 1Hz refresh -- no matter the variables employed for the Android function calls.    

The apps tests various combinations of:

-- interval setting below 1000 milliseconds with distance=0 setting;

-- a number of different parameters to requestLocationUpdates functions

-- fused location under Android "P"

-- a minimum requirements of Android "P" for the application builds;

-- use of Google Services 

-- use of requestSingleUpdate (it was worse!)

-- about anything I can think of to get the location updates to less than 1 second.

But I have never seen where GNSS data/fixes fall essentially less than a second apart.  The fixes zero in on a millisecond number and repeat at 1Hz thereafter

My phone is an Mi8 with Android Pie. The dual-frequency works.  BTW, the phone's GPS is quite accurate compared to an older phone. The Mi8 GPS can run a meter or two off at times, but I am quite impressed.

[Sean Barbeau]

Bruce,

tl;dr - it's very likely a hardware issue

Long version:

The last time I did a deep dive on this topic was 2012, in the context of this issue:

https://android-review.googlesource.com/c/platform/frameworks/base/+/34230

In short, developers were passing larger intervals for location updates (e.g., 30 seconds) to the LocationManager, but the device would ignore value and update the app at 1 Hz, and I was trying to figure out why this was happening, which largely boils down to the same question of how location updates are scheduling.

At the time, the Android platform would check in with the native location implementation to see if the hardware could handle location scheduling.  Hardware scheduling is more energy-efficient than software Android platform scheduling because the main processor can go to sleep.  The source of the above issue was that the native code would report to Android that it could handle location scheduling, but then it ignored the parameters passed in and always went with 1 Hz.  At the time Android engineers implemented more CTS tests to try and prevent OEMs from making this mistake going forward.

Fast-forward to now - it looks like the same general concept is still in use - here's the AOSP GnssLocationProvider code that checks if the native code can handle update scheduling:

https://android.googlesource.com/platform/frameworks/base/+/master/services/core/java/com/android/server/location/GnssLocationProvider.java#1340

From quickly skimming the code, it looks like if hardware can't schedule updates, then AOSP schedules the hibernation here:

https://android.googlesource.com/platform/frameworks/base/+/master/services/core/java/com/android/server/location/GnssLocationProvider.java#1568

...which says:

// stop GPS until our next fix interval arrives
stopNavigating();
mAlarmManager.cancel(mTimeoutIntent);
mAlarmManager.cancel(mWakeupIntent);
long now = SystemClock.elapsedRealtime();
mAlarmManager.set(AlarmManager.ELAPSED_REALTIME_WAKEUP, now + mFixInterval, mWakeupIntent);

This uses the AlarmManager and the system clock elapsedRealtime value (which is in milliseconds) and the fix interval (which the app passed in, also in milliseconds) to schedule the next wake up to fire up the GNSS again.  So it looks like this entire pipeline is indeed in milliseconds, which in theory should allow for update frequencies greater than 1 Hz (i.e., intervals less than one second).

However, on most devices launched in the last few years this AOSP code most likely isn't used, and instead hardware should handle the update scheduling.  The last few iterations of Android have focused a lot of effort on better battery life, and moving location scheduling to hardware was one of these tasks.

Unfortunately, on your own device I don't think there is an easy way to see whether the location scheduling is happening at the hardware or Android level, unless you flash a modified version of AOSP on a device like I did when testing back in 2012.

I'd welcome thoughts from anyone else who might have ideas on how to confirm this.

Sean

[Bruce Chase]

Sean, thanks for your detailed response. I was hoping that just one person has seen less than 1hz GNSS data -- at least in Android Studio -- in order to prove that an Android device can achieve this. 

--
You received this message because you are subscribed to the Google Groups "GPSTest" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gpstest_andro...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

--------------------------------------------------
Bruce  Chase
413 Inglewood Drive
Westerville, OH 43081


(614) 638-8094 (cell)
(614) 890-0006 (home)

[Lodro Gyamtso]

- prologue
1. without hardware capabilities .... what we can expect from software ????
2. some people want to pay for Hyundai i30 and buy a Porsche 911 GT3 RS

- main theory explain
there are 2 main categories of satellite navigation products, for civilian and for military. Military devices there are ONLY in the mind of the enthusiast people.
Civilian category split into 2 subcategories -
1. for amateurs
2. professional
into the market, from the end of '90 we have seen the first PND devices like Garmin or TomTom (and may others). But the last 10 years we have smartphones (or tablets) with navigation capabilities. All this years (20+), into this price category we have "low specs", compared with professional devices. It's very logical this philosophy to continue for a lot of years into the future. Is there anyone who believes that if he spends $ 500-600, he hopes to get the same features on his device as someone to pay 5,000-10000$
1. accuracy (cm)
2. multi frequency band (L1 L2 L5)
3. fast update rate ( 1 - 20 Hz)

about professional solutions (there are 2)
1. all in one (also with Android)
2. external receiver

1. some examples
Trimble Nomad 5
Trimble TDC100
spectraprecision MobileMapper 50
Spectra Precision SP20 (this device has 2 receivers, one u-blox M8 chip and one Spectra Precision high-accuracy GNSS module)

the above examples using u-blox M8 chip. it has ...
Receiver type 72-channel u-blox M8 engine
GPS/QZSS L1 C/A, GLONASS L10F, BeiDou B1
SBAS L1 C/A: WAAS, EGNOS, MSAS, GAGAN
Galileo E1B/C
Nav. update rate Concurrent GNSS: up to 4 Hz (multi systems) or 10Hz (1 GNSS system)
(the above specs are from pdf manuals)

I hope into the next 1-2 years, the new models adopt the ublox F9 chip. It support 184 channel, multi frequency band and update rate: up to 20Hz

2. some examples
eos arrow gold
SXblue iSXBlue Premier
Trimble R10

they can send data with cable or RF communication : serial, Bluetooth, wi-fi, UHF
they support Android, iOS, windows, Linux

i hope to help you