1) Fix: U-blox-5 device (and probably many others) sends both type of sentences GGA and GSA in every cycle. And this is problem, because original version of driver sent up valid data with "fix" from the first one and zeroed invalid data with "fix" from the second one. Navigation software was confused, especially speed and altitude values were zero or incorrect.
2) Fix: Time computation wrongly used plus sign in "fix_time = mktime( &tm ) + r->utc_diff;". E.g. GMT+1 time zone was shifted by 2 hours. I used simpler method to compute time difference and result has the opposite sign.
3) Fix: Used UBX commands 40 is proprietary and most of SatNav devices must not support it or must not recognize its format. E.g. u-blox-5 chipset expects 5 rate parameters because it has 5 I/O ports. In addition, UBX 40 command doesn't change fix computation frequency, so it cannot influence a power consumption of USB module. But we can use another UBX command CFG-RATE which is probably supported by more devices and its format is simply and clear. CFG_RATE controls computation frequency and thus it influences a power consumption. So, rate settings "ro.kernel.android.gps.max_rate" works now, at least on u-blox devices and devices which support UBX protocol.
4) New feature: I added reading of two build.prop parameters: ro.kernel.android.gps.max_rate (see above) and ro.kernel.android.gps.time_sync. The max_rate has default value 1 (second). Parameter allows set GPS fix-measure period in seconds (if it is in the range 1...65) or in milliseconds (if it is in the range 250...65000). Default value of second added parameter ro.kernel.android.gps.time_sync is zero which means that time synchronization (see below) is turned off.
5) New feature: System time synchronization - Parameter ro.kernel.android.gps.time_sync which is greater than zero is taken as threshold in seconds. If difference between system time and GPS time will grow over given threshold then system time will be set to GPS time with the respect to current time zone. Recommended value of threshold is 20 or 30.
Martin-Kolaci
commented
5 years ago
1) Fix: U-blox-5 device (and probably many others) sends both type of sentences GGA and GSA in every cycle. And this is problem, because original version of driver sent up valid data with "fix" from the first one and zeroed invalid data with "fix" from the second one. Navigation software was confused, especially speed and altitude values were zero or incorrect.
2) Fix: Time computation wrongly used plus sign in "fix_time = mktime( &tm ) + r->utc_diff;". E.g. GMT+1 time zone was shifted by 2 hours. I used simpler method to compute time difference and result has the opposite sign.
3) Fix: Used UBX commands 40 is proprietary and most of SatNav devices must not support it or must not recognize its format. E.g. u-blox-5 chipset expects 5 rate parameters because it has 5 I/O ports. In addition, UBX 40 command doesn't change fix computation frequency, so it cannot influence a power consumption of USB module. But we can use another UBX command CFG-RATE which is probably supported by more devices and its format is simply and clear. CFG_RATE controls computation frequency and thus it influences a power consumption. So, rate settings "ro.kernel.android.gps.max_rate" works now, at least on u-blox devices and devices which support UBX protocol.
4) New feature: I added reading of two build.prop parameters: ro.kernel.android.gps.max_rate (see above) and ro.kernel.android.gps.time_sync. The max_rate has default value 1 (second). Parameter allows set GPS fix-measure period in seconds (if it is in the range 1...65) or in milliseconds (if it is in the range 250...65000). Default value of second added parameter ro.kernel.android.gps.time_sync is zero which means that time synchronization (see below) is turned off.
5) New feature: System time synchronization - Parameter ro.kernel.android.gps.time_sync which is greater than zero is taken as threshold in seconds. If difference between system time and GPS time will grow over given threshold then system time will be set to GPS time with the respect to current time zone. Recommended value of threshold is 20 or 30.