Suggestions for this App: Resolution, Satellite limitation, time-averaging,
359 views
Skip to first unread message
Jim bell
Jul 8, 2023, 11:29:17 PM7/8/23
to GPSTest
I am starting a long-delayed pet project, setting markers visible from space. Mostly I intend to set them at lat/lon degree/degree intersections in Oregon and southwest Washington. (Okay, everybody needs a hobby, right?)
I've finally acquired a Nord Oneplus 20 phone that is capable of dual-frequency GPS, and I want to be able to set these markers at the highest accuracy the hardware is capable of doing. (Previously, I had bought a Moto One 5g Ace, thinking that it contained not only the Broadcom BCM47755 hardware, AND appropriate software support, but I was disappointed...)
I've seen references to claims that dual-frequency accuracies can be as good as 30 centimeters, which is far better than single-band GPS. (10-11 meters?). But I would not be surprised to learn that a substantial amount of 'care' must be used to actually achieve that value.
Therefore, I have some suggestions:
1. I think the displayed resolution of the GPS output should be increased to reflect the higher accuracy potentially available from dual-frequency GPS: Seemingly, an accuracy increase about a factor of 10-11 meters ->0.30 meters, or about 33x. Having an extensive scientific and engineering background, I fully understand that merely calculating a value to more digits of precision (resolution) doesn't itself make things more accurate,
While I don't intend to get it, at least not immediately, there is a $1150 device sold in Amazon that is a survey-grade GPS, claiming accuracies of 2.5 centimeters. I don't necessarily expect dual-frequency smartphones to achieve this, it would be useful to learn how close (stable?) they are getting. And they might improve in the future.
I notice that on GPSTest, in DD.ddddddd mode the value is displayed to 7 digits past the decimal point. A degree of latitude is approximately 111.11 kilometers, so a least digit is about 11.1 centimeters. Good, but in my experience values are typically measured to 10x more precision than the expected accuracy. So I suggest adding a digit.
Similarly, the DD.MM.mmmm and DD MM SS.ss should display with similar resolutions.
I know of one location in the Pacific Northwest with a location surveyed to the highest precision: https://en.wikipedia.org/wiki/Willamette_Stone whose location has been measured to be at: 45_31_10.23551_N_122_44_37.89866W (But since there is seafloor spreading at the mid-Atlantic ridge to about 1 inch per year, that suggests there is some compensation in order.)
2 About half the GPS satellites appear to be capable of dual-frequency. What I DON'T know is if the inclusion of the readings of single-frequency satellites somehow 'contaminates' the overall GPS calculations, or if it does not. If the former, I think it would be better if the user could specifically tell the device to use "only" use dual-frequency-capable satellite signals. And, I wonder if fixes can be made using both GPS and Galileo dual-frequency satellites, used simultaneously.
3. Time averaging. I have been experimenting with another GPS App, named "Precision GPS". Unfortunately, it appears to be abandoned, despite still being available. It appears to be at least as old as 2015, but it makes no reference to dual--freqency GPS, so I doubt it would give me improved-accuracy readings.
Its one apparent advantage is that it does time-averaging. I am willing to take readings for hours, and I assume that this should improve overall accuracy. For that reason, I suggest that you incorporate a time-averaging feature into GPSTest.
4. Post-processing. I am vaguely aware of the concept of "post-processing", or the correction of as-measured readings using calculations based on later-available data. I've seen reference to "RINEX", https://en.wikipedia.org/wiki/RINEX
Thank you
Stewart Holt
Jul 9, 2023, 5:02:20 PM7/9/23
to Jim bell, GPSTest
I think you would be lucky to get better than 3 meters accuracy with a dual frequency cell phone. I have a Pixel 6 Pro with the
BCM47755 chip. I was disappointed to find that Google has disabled Beidou (in the US) and does not support WAAS which the
BCM47755 chip is capable of. In addition to those self-inflicted wounds, the cell phone lacks a good antenna with a ground plane. Achieving sub meter accuracy will require some type of correction such as WAAS or better, one of the paid services.
Google responded to my complaint about Beidou and WAAS. They are considering Beidou and on WAAS cited processing overhead. Ideally the WAAS correction would be done in the
BCM47755. I have found very little info about the
BCM47755 other than a 2 page marketing type flyer.
I have done some extensive experiments with a sub-meter GNSS unit collecting many hours of data at one location and averaging. In one case I collected 48 hours of data and used that average as an assumed precise point and then with the same data averaged for 1, 2, 5, 15, 30, 60, 120,... minutes and compared the average, min, max error of each with the overall average. I have been meaning to do the same test on the Pixel 6 but have not gotten around to it.
To test your phone's GPS collect data outside in an open area you feel ok leaving the phone for hours.
Below are two tests. The first was done at the top of a mountain which rises about 700 feet above the surrounding terrain. The GPS was an SXblue II. The comparison was done against a USGS survey marker with its coordinates translated to ITRF2014 to match the WAAS output from the GPS.
CSV: 2021-03-11_134637_kt1.csv Location: Kennesaw Reset (33.976180360000, -84.579369620000) Alt: 1808.0 Count: 3713
--------- Location Err (ft) ------- -------------- Elevation (ft) --------------
Time Count Min Max Avg Stdev 1Stdv 2Stdv Min Max Avg Stdev +1Stdv +2Stdv
1 s 3713 0.06 1.47 0.58 0.22 0.79 1.01 1802.6 1808.5 1805.5 1.3 1806.8 1808.1
10 s 371 0.09 1.45 0.58 0.22 0.79 1.01 1802.6 1808.4 1805.5 1.3 1806.8 1808.1
30 s 123 0.16 1.39 0.57 0.21 0.79 1.00 1802.8 1808.3 1805.5 1.3 1806.8 1808.1
1 m 61 0.15 1.26 0.57 0.20 0.77 0.97 1803.2 1808.1 1805.5 1.3 1806.8 1808.0
2 m 30 0.23 1.00 0.57 0.19 0.76 0.95 1803.7 1807.8 1805.5 1.2 1806.7 1807.9
5 m 12 0.25 0.90 0.56 0.16 0.72 0.88 1803.9 1807.6 1805.5 1.2 1806.7 1807.8
10 m 6 0.32 0.77 0.55 0.14 0.69 0.83 1804.0 1807.5 1805.5 1.2 1806.6 1807.8
30 m 2 0.49 0.59 0.54 0.05 0.59 0.64 1804.5 1806.4 1805.5 1.0 1806.4 1807.4
30 m 56 s 2 0.47 0.59 0.53 0.06 0.59 0.65 1804.5 1806.6 1805.5 1.0 1806.6 1807.6
1.0 h 1 0.53 0.53 0.53 0.00 0.53 0.53 1805.5 1805.5 1805.5 0.0 1805.5 1805.5
--------- Location Err (ft) ------- -------------- Elevation (ft) --------------
Time Count Min Max Avg Stdev 1Stdv 2Stdv Min Max Avg Stdev +1Stdv +2Stdv
1 s 3713 0.06 1.47 0.58 0.22 0.79 1.01 1802.6 1808.5 1805.5 1.3 1806.8 1808.1
10 s 371 0.09 1.45 0.58 0.22 0.79 1.01 1802.6 1808.4 1805.5 1.3 1806.8 1808.1
30 s 123 0.16 1.39 0.57 0.21 0.79 1.00 1802.8 1808.3 1805.5 1.3 1806.8 1808.1
1 m 61 0.15 1.26 0.57 0.20 0.77 0.97 1803.2 1808.1 1805.5 1.3 1806.8 1808.0
2 m 30 0.23 1.00 0.57 0.19 0.76 0.95 1803.7 1807.8 1805.5 1.2 1806.7 1807.9
5 m 12 0.25 0.90 0.56 0.16 0.72 0.88 1803.9 1807.6 1805.5 1.2 1806.7 1807.8
10 m 6 0.32 0.77 0.55 0.14 0.69 0.83 1804.0 1807.5 1805.5 1.2 1806.6 1807.8
30 m 2 0.49 0.59 0.54 0.05 0.59 0.64 1804.5 1806.4 1805.5 1.0 1806.4 1807.4
30 m 56 s 2 0.47 0.59 0.53 0.06 0.59 0.65 1804.5 1806.6 1805.5 1.0 1806.6 1807.6
1.0 h 1 0.53 0.53 0.53 0.00 0.53 0.53 1805.5 1805.5 1805.5 0.0 1805.5 1805.5
Here is a test done in the woods in my back yard about 60 feet away from houses uphill. This is a much more challenging location which you can see in the numbers. Above, 5 minutes of averaging gets to 0.56 foot and below to 2.8 feet.
------ Location Err (ft) ------ -------------- Elevation (ft) --------------
Time(s) Count Min Max Avg Stdev 1Stdv 2Stdv Min Max Avg Stdev 1Stdv 2Stdv
1 11944 0.0 10.9 3.1 1.3 4.4 5.6 952.4 993.5 972.6 4.2 976.8 981.0
10 1194 0.1 10.8 3.1 1.2 4.4 5.6 952.7 993.5 972.6 4.2 976.8 981.0
30 398 0.2 10.2 3.1 1.2 4.3 5.5 954.5 989.7 972.5 4.2 976.7 980.9
60 199 0.4 8.6 3.0 1.2 4.2 5.4 959.4 989.7 972.5 4.2 976.7 981.0
120 99 0.5 6.6 2.9 1.1 4.0 5.0 959.4 989.7 972.6 4.4 977.0 981.3
300 39 0.8 5.1 2.8 0.9 3.7 4.6 960.7 989.7 972.6 4.7 977.3 982.0
600 19 0.7 3.9 2.7 0.8 3.4 4.2 964.9 989.7 973.3 5.4 978.7 984.1
1800 6 2.0 2.9 2.5 0.3 2.8 3.1 964.9 989.7 974.3 8.4 982.7 991.2
3600 3 2.0 2.7 2.4 0.3 2.7 3.0 965.0 989.7 977.5 10.1 987.6 997.7
Maybe I will get around to testing the Pixel 6.
Stewart
--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/gpstest_android/ec19e6dc-d2c5-4a19-882c-addfd4e87066n%40googlegroups.com.
Jim bell
Jul 9, 2023, 6:37:39 PM7/9/23
to GPSTest
"Achieving sub meter accuracy will require some type of correction such as WAAS or better, one of the paid services."
Can WAAS be handled as some sort of post-processing?
Also, I wonder if GPS in a smartphone can/does download WAAS or ephemerides data through the Internet? I'm not expecting continuous WAAS corrections, in real-time, but I'd like to be able to correct a static location 'eventually'.
" have done some extensive experiments with a sub-meter GNSS unit collecting many hours of data at one location and averaging."
I think it would be very useful to have GPSTest automate this kind of accuracy (or, at least, stability) determination. I'd like to be able to activate the dual-frequency smartphone, set it at a (relatively unknown) location, and let it collect data for hours. This could be used to more-accurately identify the location, but it could also be used to determine the accuracy or stability of the smartphone.
Also, I mentioned that perhaps it would achieve better results if a (smartphone) GPS determination could use ONLY dual-frequency-capable satellite data. I can't imagine how they could incorporate single-frequency satellite data in such a way that wouldn't contaminate the accuracy of the determination.
Sean Barbeau
Jul 10, 2023, 9:28:20 AM7/10/23
to Jim bell, GPSTest
Hey Jim,
Author of GPSTest here. Thanks for the feedback!
>About half the GPS satellites appear to be capable of dual-frequency. What I DON'T know is if the inclusion of the readings of single-frequency satellites somehow 'contaminates' the overall GPS calculations, or if it does not. If the former, I think it would be better if the user could specifically tell the device to use "only" use dual-frequency-capable satellite signals. And, I wonder if fixes can be made using both GPS and Galileo dual-frequency satellites, used simultaneously.
GPSTest shows the position computed by the GNSS chipset (GPS_PROVIDER) in the phone. The process of computing this position is effectively a black box, so GPSTest doesn’t have any control over which signals get used.
That being said, Android does have APIs for raw GNSS measurements that allow apps to compute its own position - https://g.co/gnsstools. I’d like to use this in future GPSTest versions. Google’s GnssLogger app, in addition to showing the chipset position, currently computes a position using raw measurements and WLS as a demo - https://play.google.com/store/apps/details?id=com.google.android.apps.location.gps.gnsslogger. But that app doesn’t offer a feature of controlling which signals get used in WLS.
> I've seen references to claims that dual-frequency accuracies can be as good as 30 centimeters, which is far better than single-band GPS. (10-11 meters?). But I would not be surprised to learn that a substantial amount of 'care' must be used to actually achieve that value.
Check out this paper for an example of the state of the art:
Jacek Paziewski, Marco Fortunato, Augusto Mazzoni, Robert Odolinski. "An analysis of multi-GNSS observations tracked by recent Android smartphones and smartphone-only relative positioning results", Measurement, Volume 175, 2021, https://doi.org/10.1016/j.measurement.2021.109162
>I notice that on GPSTest, in DD.ddddddd mode the value is displayed to 7 digits past the decimal point. A degree of latitude is approximately 111.11 kilometers, so a least digit is about 11.1 centimeters. Good, but in my experience values are typically measured to 10x more precision than the expected accuracy. So I suggest adding a digit.
Good point. I haven’t seen a GNSS chipset that supplies this level of accuracy, but it’s something I’ll look at changing in future updates.
>3. Time averaging. I have been experimenting with another GPS App, named "Precision GPS". Unfortunately, it appears to be abandoned, despite still being available. It appears to be at least as old as 2015, but it makes no reference to dual--freqency GPS, so I doubt it would give me improved-accuracy readings.
Its one apparent advantage is that it does time-averaging. I am willing to take readings for hours, and I assume that this should improve overall accuracy. For that reason, I suggest that you incorporate a time-averaging feature into GPSTest.
This is a feature I’m planning on for GPSTest - https://github.com/barbeau/gpstest/issues/532.
GnssLogger does have this feature (using both mean and median values), which is used as a ground truth value for WLS positioning and computing individual signal residuals (see Plot tab).
>4. Post-processing. I am vaguely aware of the concept of "post-processing", or the correction of as-measured readings using calculations based on later-available data. I've seen reference to "RINEX", https://en.wikipedia.org/wiki/RINEX
GPSTest doesn’t directly export RINEX, but you can use this tool to convert the GPSTest log to RINEX - https://github.com/rokubun/android_rinex.
GnssLogger supports a direct RINEX export feature, and from what I've heard this is better than converting the GPSTest output.
Sean
To view this discussion on the web visit https://groups.google.com/d/msgid/gpstest_android/53df0075-f8f2-454e-80f7-d8c09cef3fb6n%40googlegroups.com.
Jim bell
Jul 12, 2023, 2:54:29 AM7/12/23
to GPSTest
"GPSTest shows the position computed by the GNSS chipset (GPS_PROVIDER) in the phone. The process of computing this position is effectively a black box, so GPSTest doesn’t have any control over which signals get used."
Yikes! That's terrible! And you have no idea HOW they derive a solution!!! I am truly astonished that these guys, who are supposed to know their jobs, could screw up in such an amazing fashion! Eventually all GPS satellites will be dual-frequency, but until then, they have doomed us to a world in which single-frequency satellite data contaminates that of dual frequency data. How many people will think that dual-frequency smartphone receivers 'aren't that much better' simply because of this phenominal oversight?
This makes me wonder if the typical amount of extra error could be measured using a survey-grade unit, if it has the abiity to only use dual frequency?
I also wonder about whether Galileo would be better than intermixed dual-freq and single-freq GPS?
"That being said, Android does have APIs for raw GNSS measurements that allow apps to compute its own position - https://g.co/gnsstools. I’d like to use this in future GPSTest versions. Google’s GnssLogger app, in addition to showing the chipset position, currently computes a position using raw measurements and WLS as a demo - https://play.google.com/store/apps/details?id=com.google.android.apps.location.gps.gnsslogger. But that app doesn’t offer a feature of controlling which signals get used in WLS."
Are these people utterly clueless?! They don't give the option of using ONLY dual-frequency satellite data? That would have been trivial FOR THEM to do, if they just thought about it for a minute. They had to have known that those single-frequency satellites wouldn't be instantaneously replaced with dual-freq!
""Check out this paper for an example of the state of the art:"
"Jacek Paziewski, Marco Fortunato, Augusto Mazzoni, Robert Odolinski. "An analysis of multi-GNSS observations tracked by recent Android smartphones and smartphone-only relative positioning results", Measurement, Volume 175, 2021, https://doi.org/10.1016/j.measurement.2021.109162 "
Looks like excellent reading.
>I notice that on GPSTest, in DD.ddddddd mode the value is displayed to 7 digits past the decimal point. A degree of latitude is approximately 111.11 kilometers, so a least digit is about 11.1 centimeters. Good, but in my experience values are typically measured to 10x more precision than the expected accuracy. So I suggest adding a digit.
"Good point. I haven’t seen a GNSS chipset that supplies this level of accuracy, but it’s something I’ll look at changing in future updates.
Except: Oops!! I screwed up! One ten-millionth of 111.111 kilometers is 11.1 milliimeters, not 11.1 centimeters. So, it looks like no change is really necessary, at least for the DD.ddddddd representation. But as for DD MM.mx or DD MM SS.sx, THOSE need to be checked! I don't think a person should be forced to use DD.ddddddd merely because his equipment and software is artificially weak in resolution due to an arbitrary software limitations.
>3. Time averaging. I have been experimenting with another GPS App, named "Precision GPS". Unfortunately, it appears to be abandoned, despite still being available. It appears to be at least as old as 2015, but it makes no reference to dual--freqency GPS, so I doubt it would give me improved-accuracy readings.
Its one apparent advantage is that it does time-averaging. I am willing to take readings for hours, and I assume that this should improve overall accuracy. For that reason, I suggest that you incorporate a time-averaging feature into GPSTest.
"This is a feature I’m planning on for GPSTest - https://github.com/barbeau/gpstest/issues/532.:
Excellent. I hope this would be relatively easy for you to do. At least, in comparison with doing the calculation of the results as a substitution for Broadcom's horrendous mistake, above.
"GnssLogger does have this feature (using both mean and median values), which is used as a ground truth value for WLS positioning and computing individual signal residuals (see Plot tab).
>4. Post-processing. I am vaguely aware of the concept of "post-processing", or the correction of as-measured readings using calculations based on later-available data. I've seen reference to "RINEX", https://en.wikipedia.org/wiki/RINEX
GPSTest doesn’t directly export RINEX, but you can use this tool to convert the GPSTest log to RINEX - https://github.com/rokubun/android_rinex.
GnssLogger supports a direct RINEX export feature, and from what I've heard this is better than converting the GPSTest output.
Sean
Jim bell
Jul 13, 2023, 6:19:10 AM7/13/23
to GPSTest
I looked into the issue of the various resolutions DD MM.mmm, and DD MM SS.ss. It turns out that the former presentation ought to have two more decimal places, to become DD MM.mmmmm, and so a resolution of 18.5 millimeters, (for latitude) and the latter presentation should have one more decimal place, to become DD MM SS.sss, and thus a resolution of 30.9 millimeters (for latitude), in order to approach the resolution of DD.ddddddd. (Which is 11.1 millimeters, for latitude.).
As you can see, a user of your app is now essentially forced to use the DD.ddddddd presentation, or he loses a great deal of resolution, especially losing about two deciminal places of resolutioon on the DD MM.mmm presentation. I don't see any 'display-space' limitation on the screen that would prevent the addition of these digits.
For my particular application at the moment, positioning markers visible from space on the intersections of Lat/Lon degree/degrees lines, that is not an inconvenience, but other people may want to have high resolutions using 'minutes' or 'minutes/seconds'.
Question: Are all currently-functioning Galileo satellites capable of dual-frequency operation? If so, I would hope to be able to use them instead of depending on the Broadcom (?) GPS-engine, which would presumably (deleteriously) incorporate single-frequency-satellite data into its solutions. I cannot tell if I can limit fixes to ONLY Galileo satellites. It does show ways to limit the DISPLAY to various subsets, for example 'only Galileo', but I cannot tell if this also limits the fixes to using ONLY Galileo satellites. (Or Beidou, or Glonass, etc.)
I certainly wonder if the Broadcom "black box" uses BOTH GPS and Galileo satellites under ordinary circumstances.
I am going to try to find the Broadcom data sheets for their various GPS chips. I've been reading IC data sheets for 50+ years.
A thought just occurred to me, but I don't know if it would be practical: Perhaps, the goal is prevent the GPS receiver from using those specific signals from GPS satellites that only emit single frequeny signals. Presmably, these emitted signals come at very precise, pre-arranged patterns. What if a device could be designed that would momentarily 'jam' ONLY those GPS satellites that are single-frequency, and NOT jamming at times the signals are expected from dual-frequency satellites?
As far as the GNSS receiver 'knows', those single-freqency satellites will seem to 'disappear' from space. They simply won't be there, and so the GNSS engine cannot employ them. But I don't know if this synchronization is possible.
I wonder if the most practical way is for the writer of a GNSS app to repeatedly drive an external 'jammer board', which causes VERY brief jamming pulses to be generated.precisely at the times that signals are expected from single-freqency GPS satellites. Such 'jams' might only have to occur for a microsecond, or even less, just enough to disable the GNSS chip's ability to use the incoming GPS pulse. There would only have to be a very limited number of those 'jams', one for each single-frequency-only GPS satellite, and really only for those satellites which are know to be above the local horizon.
The power of this jamming signal would be very tiny, as it would be very close to the GPS receiver. (see the inverse-square law). Perhaps only picowatts.
Sean Barbeau
Jul 13, 2023, 2:28:47 PM7/13/23
to Jim bell, GPSTest
>Question: Are all currently-functioning Galileo satellites capable of dual-frequency operation?
To my knowledge yes. You could check their system website to see which ones are fully operational. Check out the bottom of this page that I've maintaining of various GNSS resources for that and more:
In GPSTest you can see which satellites are currently being used by the GNSS hardware to compute a position on the Status screen. The records that have a "U" next to them indicates it was used in the previous solution.
You can also see on Status that your phone will likely lock on to L1 first, and then use that to acquire L5. There are solutions for L5 acquisition and tracking on the horizon:
So unfortunately jamming L1 would also likely interfere with L5.
Sean
To view this discussion on the web visit https://groups.google.com/d/msgid/gpstest_android/6bb3af05-df92-42e5-ab5f-9590c02e2b54n%40googlegroups.com.
Jim bell
Jul 13, 2023, 5:21:51 PM7/13/23
to Sean Barbeau, GPSTest
I want to make sure I'm understanding what you are saying. I want to be able to do fixes with only dual frequency satellite data. With GPS, that is not possible because about half of the current GPS satellite constellation is single frequency satellites.
And, you describe the Broadcom chip as being like an uncontrollable black-box: it is not possible to tell that black box to only use the subset of GPS satellites that are capable of doing frequency. Naturally, that is very distressing.
However, if all Galileo satellites are dual frequency, am I correct in thinking that GPSTest can be told to only use Galileo satellites for the fix calculated?
And do I do that by going to the GPSTest page where I have the option to only display a specific constellation of satellites, in this case Galileo? If I select only Galileo, and then return to the main screen, are my position fixes going to be made solely by using Galileo satellites?
That would be good news. However, I would still be in a slight quandary. I could use Precision GPS (an old, abandoned app) for the advantage of averaging over periods of many minutes or hours, but it would be using all of the visible GPS satellites including single frequency satellites.
Or, I could use GPSTest, with Galileo satellites, but without any ability to average its results over many minutes or indeed hours.
Perhaps you can see why this choice is frustrating.
I will look at that GNSSLogger.
Sean Barbeau
Jul 13, 2023, 6:07:51 PM7/13/23
to Jim bell, GPSTest
>However, if all Galileo satellites are dual frequency, am I correct in thinking that GPSTest can be told to only use Galileo satellites for the fix calculated?
Nope. Unfortunately GPSTest cannot control what the GNSS hardware black box does to actually compute the position shown, so when you're filtering signals, you're just filtering what shows up on the Status page to make it easier to zero in on status of certain signals. This doesn't do anything to change how the position is computed.
Again, I hope to add the computation of position from raw measurements as a future feature in the app, at which point the feature you're requesting would be possible, and is certainly something I would consider. I see it being very useful to be able to manually filter signals to understand the effect they have on the position. But computing a position from raw measurements takes a reasonable amount of effort to implement, especially considering that GPSTest has always been a personal side project for me.
Sean
Sean Barbeau
Jul 13, 2023, 6:10:45 PM7/13/23
to Jim bell, GPSTest
I should mention that GPSTest has always focused on evaluating the capabilities of the hardware in the device. This is because it's that same hardware that generates the positions that you see in all the other apps on the device. If GPSTest implemented its own position calculation, this wouldn't reflect the position accuracy you see in other apps.
Sean
Jim bell
Jul 14, 2023, 4:09:19 AM7/14/23
to Sean Barbeau, GPSTest
You said:
"I should mention that GPSTest has always focused on evaluating the capabilities of the hardware in the device."
However, I hope you agree that SOMEBODY should implement an app which produces the best possible location system for a given piece of hardware, if it is technically possible to do so.
And, keep in mind that you can't effectively evaluate the hardware unless you can identify and compensate for momentary factors other than that hardware. For example, if you want to know whether errors are correctable by averaging, you must do that averaging and observe the result, comparing it to the instantaneous values. It is the momentary variation of the instantaneous values to the long-term average which could tell you how credible the hardware actually is.
So, the reason I think you need to do those calculations is so that you can compare their results with the results presented by the Black box broadcom chip.
Should there be a mode where you can activate GPStest, set the device down, and let it take data for many hours, observing the variation in apparent location? A good hardware implementation would presumably have smaller momentary variations in those numbers compared with the long-term average.
GPS accuracy went from many tens of meters error prior to S/A being turned off in 2000, and subsequently to 10 or so meters. We know that GPS has the technical ability to do much better, see the survey grade receivers, one I found quite recently for less than $1,200. It, like other survey grade devices, promises accuracies of about 2.5 cm.
I found this page for some broadcom gnss/GPS chips.
Get list six different components, but the one that I previously had become aware of, the bcm47755 is labeled not recommended for new design. This is the typical clue by IC manufacturers that this product is old and you should not design it in.
Similarly not recommended for new design is the bcm-47531
There are however for other devices which are labeled as active. I will have to study them and figure out if any of them don't have the limitations that the other chips do: the most obvious is the inability to choose specific satellites and to ignore others based on factors such as dual-frequency capability.
The device BCM4778 so far I see merely a one-page document called a product brief. The date on the product brief is September 22nd, 2021, so it is about 2 years old. Curiously, the documentation for this identifies the chip as having a seven nanometer IC process, which is clearly cutting edge. The Bcm-4778 is said to have seven nanometer CMOS technology, which is cutting edge. This device is identified as a third generation dual frequency GPS / gnss device.
So, I suspect that I should search for this part number, bcm-4778, when I am looking for the most up-to-date dual frequency smartphones. The device I currently have is a OnePlus Nord 200 5g.
Yet weirdly, another device called the bcm-47765 says it has a 28 nanometer technology, which is rather old. Now I'm looking at a reference that labels the bcm-47765 as being a second generation dual frequency gnss chip.
The device bcm-47755 is said to be built with a 28 nanometer process. The overview document does not call it a first generation dual frequency device, but perhaps that is what it is.
Another device is called LTO-A-GPS. It appears to be a device that allows the download of ephemeris data from the internet, rather than from the satellite transmissions themselves.
Sean Barbeau
Jul 14, 2023, 10:18:00 AM7/14/23
to Jim bell, GPSTest
>However, I hope you agree that SOMEBODY should implement an app which produces the best possible location system for a given piece of hardware, if it is technically possible to do so.
Agreed!
>Should there be a mode where you can activate GPStest, set the device down, and let it take data for many hours, observing the variation in apparent location?
The closest thing we currently have to this is the Accuracy mode in GPSTest. I'd like to flush this feature out with more details.
Sean
Jim bell
Jul 16, 2023, 6:35:39 PM7/16/23
to GPSTest
Maybe we can hope that those who designed the various GNSS chips chose to program them to avoid the use of single-frequency satellite signals if "enough" dual-frequency satellite signals were available. Especially, since it appears that there are plenty of Galileo satellites, all of which are apparently dual-frequency capable. I'm now interested in the BCM 4778, mostly because I think they must have learned something with their history of the BCM47755.
But even if we cannot "control" them in that way, I'd sure like to be able to DETECT how consistent their readings are. If an implement is to be 'accurate', it at the very minimum must be 'consistent'.
I will try the GPSTest "Accuracy" function: I saw the beginnings of a plot over a satellite-image, which is a step in the right direction.
Jim bell
Jul 17, 2023, 2:13:12 AM7/17/23
to GPSTest
I just got some good news...and then some bad news...and then weird news.
I was just informed that the Galileo system has an accurizing feature available. It's called "HAS", "high accuracy service". Free, they say. That's the good news.
Sounds good, right? But rather than merely accepting this as 'good news', I decided to look into it. I found that website to be truly irritating, BTW. But eventually, I found a section which purported to show whether or not any given smartphone would actually work with this HAS (High Accuracy Service.)
After having to dig through a VERY excessively intricate search, I found the following:
It says:
"How do I know if my equipment is Galileo enabled?
In www.usegalileo.eu website it is possible to consult a complete list of different Galileo enabled receivers, chipsets or modules that can be found on the market classified by sector and type of device."
Aha! I thought...I'm getting close!
https://www.usegalileo.eu/EN/inner.html#data=smartphone
Looking at that list, I found a reference to my dual-frequency device: A Oneplus Nord 200. Oh no! It says:
OnePlus
Nord N200 5G
Single frequency
In other words, according to this, it doesn't work in dual-freqency mode! So why the hell did I bother buying a "dual-frequency" smartphone, only to discover that this Galileo system doesn't support it?!?
At this point, getting rather angry, I printed out the entire list of smartphones, wondering if I could solve the problem by buying a different phone. At this point, I looked through the list, and I decided to study the section of Motorola smartphones, as all my prior smartphones have been Motorola. Looking through that list, I saw my OTHER phone: The Moto One 5g Ace. Now, imagine my surprise when I saw the following:
Motorola
One 5G Ace
Dual frequency
One 5G Ace
Dual frequency
Huh? At least according to THIS, my OTHER phone would work in dual-frequency mode with Galileo!
So what's the problem, you ask? Well, despite the fact that I had originally THOUGHT that the Moto One 5g Ace would do dual-frequency, as I recall because it had a BCM 47755 installed, I subsequently was astonished, and not merely a little outraged, to learn it DIDN'T do dual-freqency. How did I learn that? Well, I ran GPSTest, and I noticed...or more precisely I DIDN'T notice...any "L5" or "E5a" entries in the display.
So, getting even angrier, I really have to wonder whose head is up whose ass?
I now have TWO phones, one of which the Galileo documention says is SUPPOSED to handle dual-frequency...but software (GPSTest) claims it doesn't. And I have a SECOND phone that the documentation says DOESN'T work, but nevertheless it is SUPPOSED to be a dual-frequency phone, and the GPSTest program does indeed display L5 (and E5a) on the screen.
Now, I'd go off and buy YET ANOTHER phone, but these facts have totally destroyed my confidence that ANYBODY knows what's going on!
Jim bell
Jul 17, 2023, 3:19:46 AM7/17/23
to GPSTest
More lying detected. Somebody said to me:
""Then it sounds like the Galileo organization is LYING. This is on a page:
""Then it sounds like the Galileo organization is LYING. This is on a page:
Tony Tschanz
Jul 19, 2023, 11:00:49 PM7/19/23
to GPSTest
I think people are expecting way too much accuracy from smartphones.
Lay two IDENTICAL same brand, same model high-end model smartphones side by side and start any GNSS App and observe location info, averaged or not.
The GNSS processors perform really great but other things such as the cheapo antennas limit high precision.
Having more decimal places just makes results harder to read (and compare).
When I need cm accuracy I use the u-blox ZED-F9P chip, multi-frequency mushroom type antenna on a pole and RTK over any cheap smartphone.
I typically get a fix (1-2 cm accuracy) in a minute or so.
Just my thoughts :)
dnw...@gmail.com
Jul 20, 2023, 12:16:00 AM7/20/23
to GPSTest
This report may be relevant to the current discussion.
Retscher, G., Weigert, T. Assessment of a dual-frequency multi-GNSS smartphone for surveying applications. Appl Geomat 14, 765–784 (2022). https://doi.org/10.1007/s12518-022-00467-7
Baard covington
Jul 20, 2023, 1:24:48 AM7/20/23
to GPSTest
What I experience is that smartphones will deliver a position and speed reading at lower c/no levels than professional equipment. Something like a Racelogic Performance Touch uses the Ublox M9 chipset (L1 only) , but doesn't calculate position/speed from satellite signals with c/no levels less than 30.
Whereas most smartphone chips will give you an estimated GPS position based on all signals available. I'm guessing Google uses some other assistance to try and improve / clean the data.
Jim bell
Jul 20, 2023, 5:41:35 PM7/20/23
to Tony Tschanz, GPSTest
| Jul 19, 2023, 8:00 PM (18 hours ago) | | ||
| ||||
"I think people are expecting way too much accuracy from smartphones."
If the problem is lack of a GOOD antenna, I can certainly understand that limitation.
To view this discussion on the web visit https://groups.google.com/d/msgid/gpstest_android/bc83f4ef-a46c-4f26-a15f-d527c0829099n%40googlegroups.com.
Sean Barbeau
Jul 24, 2023, 8:51:38 AM7/24/23
to Jim bell, Tony Tschanz, GPSTest
Re: determining the GNSS capabilities of specific device models - this is definitely a known issue.
See this article I wrote on a feature in GPSTest that helps with this:
In short, users can upload their device capabilities from the app, and it shows up in this spreadsheet:
Sean
To view this discussion on the web visit https://groups.google.com/d/msgid/gpstest_android/CAMvzYphLNcMYT%2Bcx2THMV2%3DhEznpsHVf3236vfNu2e8gpVkKTQ%40mail.gmail.com.
Jim bell
Aug 20, 2023, 8:58:25 PM8/20/23
to GPSTest
Thank you very much for your project and your very valuable assistance.
A few weeks ago, I was quite disappointed to be informed by somebody else that my newly-acquired phone, the OnePlus Nord N200 5g, while it is "Dual frequency GPS", is NOT "dual-frequency Galileo".
Naturally, I am mystified by that limitation. Your GPSTest, run on that smartphone, reports seeing the Galileo Dual Frequency signals, E5a as I recall, as well as the dual-freqency L1 and L5 signals from GPS. I read about Galileo HAS (high-accuracy service), only to discover that my phone would not be able to use dual-frequency Galileo. At least, assuming that this limitation is real.
Further, I am further disappointed and confused since the table referred to above shows my Moto One Ace 5g as being capable of "dual frequency", when it apparently is NOT capable: When I use your GPSTest app on my Moto One Ace 5g, it does not report seeing any L5 nor E5a signals.
I had actually bought that Moto One Ace 5g about 2 years ago, thinking that it was going to be capable of dual-frequency operation: Perhaps that was because I read that it employed a Broadcom BCM47755 chip. Maybe the creators of this Galileo list made a similar error? Assuming that if the phone employed a BCM47755, then it must be capable of dual-frequency service?
Unfortunately, these errors also cast doubt on the accuracy and reliability of that table of smartphone capabilities. I might get yet another smartphone which claims dual-frequency Galileo service, only to be disappointed yet again.
I still haven't figured out how to use Galileo with HAS (High Accuracy Service), even in single--frequency mode. And, it is unclear what the accuracy of the Galileo HAS service will be, with only single-frequency service. It claims 20 centimeters, but it doesn't say whether that results from using single-frequency, or using dual-frequency capable units.
Perhaps the main unavoidable limitation of smartphones is the lack of a good antenna. Okay, point taken. Nevertheless, I think that smartphone GPS will be able to become far more accurate than the 10-11 meters commonly quoted for single-frequency GPS, and quite possibly as good as 30 centimeters, and even better with corrections added.
As stated in the Galileo HAS FAQ:
from that:
What will be the typical Galileo HAS accuracy?
Galileo HAS accuracy typical 95% horizontal accuracy should be less than 20cm and 95% vertical should be less than 40cm.
Yet, even with some searching, I cannot find a straightforward (or even otherwise!) method to add Galileo HAS service to a smartphone. I go to the Google Play, look for 'galileo HAS', and yet I don't see anything relevant to this. They have apparently been planning and implementing Galileo for years, and I'd think by now they would have implemented a straightforward accuracy-improving app.
Even so, I have decided to buy a Sparkfun product, the centimeter-level kit. It claims to be able to do about 1.5 centimeter accuracy "with RTK". Myself, I don't plan to use RTK, but I hope that corrections are available on the web so that I can achieve similar levels of accuracy with just a base unit.
It claims to use L1 and L2 signals, not L5.
Jim bell
Aug 21, 2023, 4:29:48 AM8/21/23
to GPSTest
It turns out that I am going to get a ZED-F9P kit through Amazon. A kit for about $570. Pole or tripod extra. One thing I'm wondering is how to use this for a single-location measurement, ideally corrected using some kind of correction factors obtained by the web.
You said:
"When I need cm accuracy I use the u-blox ZED-F9P chip, multi-frequency mushroom type antenna on a pole and RTK over any cheap smartphone.
I typically get a fix (1-2 cm accuracy) in a minute or so."
My understanding is that "RTK" uses TWO receivers, communicating through a link. I don't need such a thing, but I DO want that accuracy. (but not necessarily real-time.) How can I get that?
Emilio González
Aug 24, 2023, 6:01:33 AM8/24/23
to GPSTest
Dear Jim,
I am sorry about you being dissapointed by the useGalileo table accuracy. In fact, that list reflects what the manufacturers and other device spec lists advertise. Of course, there could be errors, but it is, overall, a useful tool for the community. I must say that the GPSTest list is a wonderful resource to get an accurate view of what's going on into each device. But, even so, please note that there are cases where different versions of the same device display different constellation or frequency capabilities in the GPSTest list... So, in fact, this is a tricky problem, without a black-or-white solution (and it is out of the responsibility of the Galileo programme).
Regarding the use of Galileo HAS, there are useful resources at the GSC website: https://www.gsc-europa.eu/electronic-library/programme-reference-documents#ACCURACY. There, all the information about how to use this service is provided.
As per your interest in using it in smartphones:
- The Galileo HAS is not oriented at single-frequency operation. There is, though, some research on the field: the corrections may still be useful with one frequency, but of course far from the performance levels committed in the Galileo HAS SDD.
- The Galileo HAS can be used with the corrections coming from the E6 band (not yet in smartphones) or with the corrections coming from the alternative NTRIP interface (through the Internet). The latter is the only way, to date, where HAS corrections could be used in smartphones. To use them, you would need to register to the Internet Data Distribution interface and to have a PPP engine in the phone (able to apply corrections from the IDD caster). The Galileo HAS PPP reference algorithm has not been released yet, but any other PPP engine should do.
- Still, the smartphone chipset and antenna are not good enough to get the most from the Galileo HAS service: only submeter accuracy can be achieved, but this happens also with other correction services. There is a paper by Google on this regard in the past ENC congress, whose presentation I can provide to you, where it shows how Galileo HAS is performing with several Android terminals.
There are already several solutions about Galileo HAS in the market, I expect a list will become public in the GSC site real soon. This material was already presented in the Galileo HAS days, organized in Madrid last June. If you are interested, I can give you more information on the topic. I hope, though, that more solutions become available in the LBS market soon, which is unfortunately not yet the case.
Best regards,
--
Emilio González
Jim bell
Aug 24, 2023, 6:39:11 PM8/24/23
to GPSTest
The ZED-F9P has arrived. about $57- Upon research, it appears that RTK correctiions are indeed available: One provider is ODOT (Oregon Dept of Transportation), which offers them for free, and in fact a network-derived set of RTK corrections, without the necessity of me operating a base station at a well-known location. So, that will do for now.
And there is also CWU PANGA:
https://www.geodesy.cwu.edu/about/
I am still wondering what is the best way forward for smartphones. We can say that the limitation of the lack of a "good' antenna is insurmountable, given the physical limitations of the smartphone outline, but that does not mean that other things cannot be improved. I was (temporarily) happy to learn of Galileo HAS (High-Accuracy Service), but since then I have been mystified to be unable to find any reference to "how to actually install" this service onto actual Galileo-enabled smartphones.
Is that indeed possible? Where is the app? Am I wrong to think I should be able to go to the Google Play Store, search for 'Galileo High Accuracy Service', find at least one app, select it, download it, and activate it?
The Galileo Constellation is apparently complete. "They" have had years to plan for accessories for it. If the Galileo system had merely magically appeared one day, without warning, it would be perfectly understandable that it would take the technical world many months, and even a few years, to provide these features. But no.
Jim bell
Aug 26, 2023, 9:03:23 PM8/26/23
to GPSTest
I will intersperse my responses to you, below:
On Thursday, August 24, 2023 at 3:01:33 AM UTC-7 erlang...@gmail.com wrote:
Dear Jim,I am sorry about you being dissapointed by the useGalileo table accuracy. In fact, that list reflects what the manufacturers and other device spec lists advertise.
That makes me wonder why the list claims that my older smartphone, the Moto One 5g Ace is listed as being "dual frequency". It simply is not. Running the GPSTest program, it shows neither L5 nor E5a signals. Does Motorola actually claim dual-frequency capability for it?
And: My OnePlus Nord N200 is listed as "single-frequency", yet the GPSTest program clearly shows L5 and E5a signals. So, why does the table say "single-frequency"? Does this mean that this phone is actually dual-frequency capable?
Of course, there could be errors, but it is, overall, a useful tool for the community. I must say that the GPSTest list is a wonderful resource to get an accurate view of what's going on into each device. But, even so, please note that there are cases where different versions of the same device display different constellation or frequency capabilities in the GPSTest list... So, in fact, this is a tricky problem, without a black-or-white solution (and it is out of the responsibility of the Galileo programme).Regarding the use of Galileo HAS, there are useful resources at the GSC website: https://www.gsc-europa.eu/electronic-library/programme-reference-documents#ACCURACY. There, all the information about how to use this service is provided.As per your interest in using it in smartphones:
I assume you are aware that there are over one BILLION smartphones operational right now. I think that the number of smartphones must exceed the number of survey-grade GNSS devices by a factor of at least 100, and probably a factor of 1000. In other words, the number of potential 'customers' of Galileo HAS corrections vastly exceeds any other market!
- The Galileo HAS is not oriented at single-frequency operation. There is, though, some research on the field: the corrections may still be useful with one frequency, but of course far from the performance levels committed in the Galileo HAS SDD.
If single-frequency Galileo HAS can correct to about 1 meter accuracy, that would be great. But I still cannot tell what it can do. Without specifying whether we are talking about single-frequency or dual-frequency, the HAS literature suggests "20 centimeters" horizontal, which would be excellent. I assume from what YOU say that this must refer only to dual-frequency Galileo HAS. So be it.
- The Galileo HAS can be used with the corrections coming from the E6 band (not yet in smartphones) or with the corrections coming from the alternative NTRIP interface (through the Internet).
I understand this. And I assume this cannot be "fixed" by software or firmware. So, for existing phones, corrections must come over the Internet, and for smartphones, that generally means either cell data or WiFi data. Can this be done either by real-time, or by post-processing, or both?
But I also wonder: The planning for this, Galileo HAS, must have been going on for years. Designers of smartphones must have seen this system coming. Are you saying that NO smartphones today have the capabiity to receive this E6 band? None at all?!?!? That certainly sounds improbable! Unless they concealed this system until quite recently. THAT would be truly insane.
And there's another thing: My commentary that I bought a "dual frequency"-capable phone, the OnePlus Nord N200 5g, only to see on the table that it is supposed to be 'single-frequency Galileo' only. Yet, when I run the GPSTest App, it clearly shows not only GPS L5 signals, but also Galileo E5a signals as well. What am I to make of this astonishing behavior? Is there some sort of RELIABLE method for a person to determine whether the phone he has in his pocket is capable of dual-frequency Galileo operation? Or, even better, a RELIABLE method to decide which new smartphone to buy, especially if the advertised documentation is not at all clear?
The latter is the only way, to date, where HAS corrections could be used in smartphones. To use them, you would need to register to the Internet Data Distribution interface
THAT part sounds simple enough.
and to have a PPP engine in the phone (able to apply corrections from the IDD caster)
Who is supposed to understand what that means? And WHO puts that "PPP engine" "into the phone"? Do you mean the end-user? The writer of an app? The manufacturer of the phone? Does the version of Android have to be updated? WHEN will that happen?
. The Galileo HAS PPP reference algorithm has not been released yet, but any other PPP engine should do.
Where do I find this "any other PPP engine"? How do I install it?
- Still, the smartphone chipset and antenna are not good enough to get the most from the Galileo HAS service: only submeter accuracy can be achieved, but this happens also with other correction services.
Fine by me! If they can achieve the "20 centimeter" accuracy that is claimed to be their target, using a dual-frequency Galileo phone and installed HAS algorithms and Internet-accessible data, they are already a factor of 50 better than single-frequency GPS has been (10-11 meters).
There is a paper by Google on this regard in the past ENC congress, whose presentation I can provide to you, where it shows how Galileo HAS is performing with several Android terminals.
Yes, I'd like to see this. And yes, I find this vaguely understandable, but it would probably would be confusing to 99%, and possibly 99.9% of current smartphone users. It seems to me that for the vast majority of people, if you make such HAS corrections usage more complicated than "download the app from the Google App Store", as a practical matter it simply won't be useable to them. How could this possibly be the case?
There are already several solutions about Galileo HAS in the market,
Could you name AT LEAST ONE OF THEM?!?!? Or, what should I search for, in Google Search? Would Google 'galileo high accuracy service app' do it? If not, why not? Are they TRYING to make this process as difficult as possible?
I expect a list will become public in the GSC site real soon. This material was already presented in the Galileo HAS days, organized in Madrid last June. If you are interested, I can give you more information on the topic. I hope, though, that more solutions become available in the LBS market soon, which is unfortunately not yet the case.
Am I wrong to think that potential developers of Galileo apps should have been informed of what would be needed, 2-3 years ago, or even longer?
gpsfan
Aug 27, 2023, 4:57:13 AM8/27/23
to GPSTest
@Jim - Thanks for sharing your findings and...frustration. I went through part of that a couple of years ago, experimenting with all kind of apps I installed on my Xiaomi Mi 8 and finding "high accuracy GPS" on a smartphone was a confusing "no man's land" at the end of the day. Some apps came from "contests" organized by the ESA, others from private providers, generally came with no instructions, little documentation and zero user community with the odd message here and there in this group. With a search you can find the summary threads I'd started at the time. The bottom line is that there was no consumer solution then and there is no consumer solution now ! There might be one at some point with Galileo's HAS but I wouldn't hold my breath because it's a niche market; of interest almost exclusively to pro's and they already have (very expensive) solutions that arguable will always give better solutions than a phone with a tiny antenna so why would manufacturers bother ?
Case in point the uBlox 8 chipset that could be used to handle RTK corrections but that feature was disabled on the $20 receivers sold on AliExpress, fortunately I found some "medicine" after trawling Russian forums and got it to work...not that I needed the accuracy. What consumer is going to need better accuracy than what Google Maps provides ? What are you going to compare it too ?
Emilio González
Aug 28, 2023, 4:46:14 AM8/28/23
to Jim bell, GPSTest
Dear Jim,
The useGalileo list is updated when the devices haven't hit the market yet, or just have, hence the GPSTest likely has no records on those specific models. It just shows what the manufacturers and spec sites display. Sometimes the information is not coherent among sites, mostly of the times it is (although there have been times that, even in that case, the information turns out to be wrong, or area/version-dependent).
So, to have full confidence that you get a double-frequency model, check first that it is listed that way in all sources (GPSTest, spec sites like gsmarena, the manufacturer's spec sheet) without weird counterexamples.
As per your specific models, gsmarena says the Motorola One 5g Ace is GPS L1+L5, whereas Motorola site doesn't usually specify bands, but the GPSTest list includes it as L1-only. The OnePlus Nord N200 is GPS L1+L5 according to gsmarena or the manufacturer site so it should not get E5a but GPSTest says it is L1+L5/E5a. Similar mismatches appear in other models, e.g. the Xiaomi Redmi 9. The GPSTest outcome should prevail, as it comes from the ultimate user experience.
In any case, don't worry, the useGalileo records for those two models will be corrected according to your experience.
Regarding the lack of high-accuracy in smartphones, I agree with gpsfan: smartphone manufacturers don't really bother, as positioning is just one of many features. I.e., they don't sell a positioning device, but a smartphone. I have come across your frustration many times and welcome any new development in this area (which usually comes from enthusiast developers).
I haven't found, to date, any smartphone with E6 capability. There could be some interest by manufacturers if a massive customer pull on this subject appears, which is not yet the case: cost is hindering any change.
Regarding the "submetre" accuracy, this means roughly below 1m or from 50cm to 1m; 20cm is considered "decimetre accuracy".
The PPP engine is just an algorithm which is part of an app. I haven't used them myself, but you should be able to use PPP (precise point positioning) corrections with apps such as the Spaceopal's 3PGo or CNES's PPP WizLite. I would really appreciate a list of such apps from the community. There are many PPP engines in the desktop environment. There is also a reference algorithm for Galileo HAS PPP, which has not been published yet, but an implementation for a geodetic receiver exists.
Besides, there are other solutions in the market: I am sending below the list of HAS-capable GNSS receivers and modules we have notice as of today.
| Manufacturer | Model | Segment or applications | Status | ||
| ANavS | Multi-Sensor RTK/PPP Module | Autonomous Vehicles, Robots, UAVs and Vessels | Available | ||
| BeyondGravity | PODRIX | Space, LEO POD | Available (TRL 7) | ||
| BeyondGravity | NavRIX PinPoint | Space, LEO POD | Available (TRL 7) | ||
| EOS | Arrow Gold+ (using P34 module) | GIS, mapping, maritime pilotage | Available | ||
| Rokubun | SPEAR (SW engine) | Road, robotics, LBS, agriculture or IoT | Available | ||
| SpaceOpal | HAUT (SW libraries available as well) | HAS validation: surveying, maritime, machine control, aviation | Available (licensing process from EC underway) | ||
| ComNav | K803 module | Maritime, int. driving, agriculture, GIS | Available | ||
| Unicore Comm. | UM980 module | Surveying and mapping, agriculture, UAVs, and autonomous robots | Should be available (firmware update Q2 2023) | ||
| Hemisphere | P34 module | GIS, agriculture, OEM and machine control | Available | ||
| Hemisphere | Vega, Phantom boards | Agriculture, machine control, marine | Almost available (firmware to be released by August) | ||
| Bad Elf | BE_GPS-6500 (Flex Extreme, using P34 module) | Mapping and surveying | Under development | ||
| Deimos | G3STAR | Space, POD | Under development | ||
| Eltehs | ELT201 mass-market Galileo HAS correction module ELT202...ELT208 Galileo HAS boards | LBS | Under development | ||
| Telit | IoT (module) | Under development | |||
| Core corp. | Surveying, robotics | Under development | |||
Note: readiness of Receivers as stated by manufacturers (i.e. not tested by EUSPA) by 26/07/2023.
This table has updated information from what was presented in the HAS Days. By the way, you can find the presentations from Galileo HAS Days here. The Google presentation I referred to is there.
Regarding the availability of all the information to developers: it has been made public since it has become available. All the main references are in the GSC website, do read them. It is now the time for the industry to seize the opportunity to launch the first developments.
I strongly believe the adoption of high accuracy in the LBS market is being made realistically. I mean, if it were as simple as "plug an app and get your cm-accuracy", then it would have been that way, but it isn't. (And I am not only referring to Galileo HAS, which is the latest service to come, but to the application of any PPP or RTK corrections to smartphone users.)
Best regards,
--
Emilio
You received this message because you are subscribed to a topic in the Google Groups "GPSTest" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/gpstest_android/24oscSfQpA4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to gpstest_andro...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gpstest_android/9c85c452-8317-47ba-8d1c-ebbcd8bb1f08n%40googlegroups.com.
Emilio González
Jim bell
Aug 28, 2023, 7:10:03 PM8/28/23
to GPSTest
My reaction interspersed...
On Sunday, August 27, 2023 at 1:57:13 AM UTC-7 gpsfan wrote:
@Jim - Thanks for sharing your findings and...frustration. I went through part of that a couple of years ago, experimenting with all kind of apps I installed on my Xiaomi Mi 8 and finding "high accuracy GPS" on a smartphone was a confusing "no man's land" at the end of the day.
It is somewhat reassuring to hear that my concerns are shared, and that I am not misinterpreting the situation.
Some apps came from "contests" organized by the ESA, others from private providers, generally came with no instructions, little documentation and zero user community with the odd message here and there in this group. With a search you can find the summary threads I'd started at the time. The bottom line is that there was no consumer solution then and there is no consumer solution now !
Awful! After all this time? I first heard about the Xiomi Mi 8 about 2018, and it looked very promising, adding dual--frequency corrections into the mix. And, I've been reading about WAAS corrections for much longer than that. But I didn't 'jump' immediately, figuring that the market would sort this out. I waited much longer than I anticipated, and yet, the actual implementation appears still to be delayed.
>There might be one at some point with Galileo's HAS but I wouldn't hold my breath because it's a niche market; of interest almost exclusively to pro's and they already have (very expensive) solutions that arguable will always give better solutions than a phone with a tiny antenna so why would manufacturers bother ?
I quite recently saw a picture which pointed out that a whole armful of 'gadgets', from the 80's,90's, and 2000's has already been subsumed into the modern smartphone. It may sound funny, but the "survey-grade geodetic receiver' may, and I believe should, be next. Again, with the antenna limitation being the main remaining impediment. Could they be improved to 20 centimeters?
And yes, I just bought a ZED-f9p, since I could tell that the market DIDN'T 'sort this out'. The sudden appearance of the $570 price tag (tripod and smartphone extra...) convinced me. But with the exception of the lack of 'good' antenna, I am not aware of any obvious impediments to the further improvements of smartphone GPS/GNSS/Galileo.
If the appropriate 'hooks' were available in the phone/Android software, I wonder why this couldn't be done by adding correction factors using an app. Maybe the Android people screwed up?
Case in point the uBlox 8 chipset that could be used to handle RTK corrections but that feature was disabled on the $20 receivers sold on AliExpress, fortunately I found some "medicine" after trawling Russian forums and got it to work...not that I needed the accuracy. What consumer is going to need better accuracy than what Google Maps provides ? What are you going to compare it too ?
Right now, for me, it's just a hobby.
Thanks for replying.
Jim bell
Aug 28, 2023, 8:16:34 PM8/28/23
to GPSTest
I have just received the following material: From: help...@gsc-europa.eu
Dear GSC User,
Please find below the reply from our expert team.
First of all, thank you very much for your interest in Galileo.
The Galileo HAS Initial Services - Service Definition Document (SDD) describes the Galileo HAS service and its expected performance. Section 2.4 of the Galileo HAS SDD describes the relevant assumptions at user level and the use of Galileo HAS on smartphones has not been verified. This is due to:
- The minimum level of quality and stability required on the GNSS observables (code and phase) collected by the user receiver to support high accuracy positioning.
- The unavailability of smartphones on the market capable to track Galileo E6 signal and implementing the Galileo HAS SIS ICD.
As it is stated on the FAQs section of the GSC website, “you need a compatible Galileo-enabled receiver capable of receiving, decoding and properly applying (refer to the corresponding interface control documents) the HAS corrections from the Signal-In-Space (SIS) or the Internet Data Distribution (IDD) interface. Additionally, in order to compute a HAS positioning solution, an appropriate PPP user algorithm is required”. This means:
- For HAS SIS, a chipset capable of retrieving HAS corrections (E6-B) and navigation information (E1/E5a, E1/E5b, E1/E5a + L1/L2C, E1/E5b + L1/L2C) as well as a PPP algorithm compliant with the instructions provided in Appendix D of the Galileo HAS SDD.
- For HAS IDD, companies willing to develop this option need to be registered to HAS IDD in order to retrieve HAS corrections via Ntrip, as well as a chipset with dual/triple frequency (E1/E5a, E1/E5b, E1/E5a + L1/L2C, E1/E5b + L1/L2C) capabilities. All this information needs to be computed together by a PPP algorithm compliant with the instructions provided in Appendix D of the Galileo HAS SDD.
Please, be aware of the following remarks:
- For HAS SIS, as of now, there aren’t any chipsets capable of tracking Galileo E6-B that, at the same time, are integrated in smartphones.
- For HAS IDD, there aren’t any apps that implement both a HAS IDD decoder and PPP algorithm.
- Due to points 1) and 2), it is not possible for end-users to benefit from HAS through their smartphones just yet. As explained in our previous email, each app provider/manufacturer (i.e., Android, Apple, Google, etc.) should develop their own methods to apply HAS corrections to the navigation data received through the Open Service, whether they opt for HAS SIS or HAS IDD.
The current limitations are published under a news item in the EUSPA website:
Finally, we will take note of your feedback for future updates of the applicable HAS documentation.
We hope that this replies to your request, and please let us know if we can be of further assistance.
Thank you for contacting the GSC.
GSC Helpdesk
European GNSS Service Centre (GSC),
Torrejón de Ardoz
the Galileo Service Operator (GSOp) is operating the GSC, under a contract funded by the European Union and concluded with the EUSPA, which is the Galileo Service Provider.
De: Jim bell <jimd...@gmail.com>
Enviado el: 27 August 2023 09:12
Para: GSC Help Desk <help...@gsc-europa.eu>
Asunto: Re: [GSC][USER REQUEST][Ticket #1589]
I am afraid that you have not answered my questions. I want to know, as an end-user, how to activate Galileo HAS corrections on my Android smartphones. What actions do I take, PRECISELY, and in detail. Do I run an App? What do I do? Exactly which steps do I take? In detail. One by one. Your literature DOES NOT claim that I cannot, successfully, do this NOW. But nevertheless, you do not explain HOW to accomplish this.
On Mon, Jul 17, 2023 at 12:56 AM GSC Help Desk <help...@gsc-europa.eu> wrote:
Dear GSC User,
Your request (ID ticket #1589) has now been addressed by the European GNSS Service Centre. Please find below the reply from our expert team.
First of all, thank you very much for your interest in Galileo.
The Galileo High Accuracy Service (HAS) provides free of charge access, through the Galileo signal (E6-B, HAS SIS) and by terrestrial means (Internet, HAS IDD), to the information required to estimate an accurate positioning solution using a Precise Point Positioning algorithm in real-time.
This means that:
- When retrieving the corrections via HAS SIS, at least dual-frequency capabilities are needed, but, of course, the performance will improve when using triple-frequency.
- When the corrections are obtained through HAS IDD, only single-frequency capabilities are required. But, again, when using dual-frequency, better performance levels will be attained.
As of now, smartphones can be single (E1) or dual (E1/E5) frequency Galileo-enabled devices (or even not Galileo enabled for certain models). This means that smartphones are not currently capable of receiving the Galileo E6-B band, where HAS SIS corrections are broadcasted. Regarding HAS IDD, each app provider/manufacturer (i.e., Android, Apple, Google, etc.) should develop their own methods to apply HAS corrections transmitted through Ntrip to the navigation data received through the Open Service.
The following non-exhaustive list* shows some reference manufacturers of E6-enabled chipsets as starting point for a more detailed search depending on your needs.
Manufacturer
Chipset Model
Allystar
HD8040
Allystar
TAU1302/TAU1303
JAVAD GNSS
TRE-3
NOVATEL
OEM7700
NOVATEL
OEM 719
NOVATEL
OEM729
Septentrio
AsteRx4 OEM
Trimble
Trimble BD990
Trimble
Trimble BD992
* The above list shows chipset and modules with Galileo E6 capability and EUSPA does not assume any responsibility for the chipset you select for your solution. The correct selection will depend on the user requirements and the specific application you are intended to use the chipset for. We encourage you to contact the manufacturers for further details.
Thank you for contacting the GSC.
GSC Helpdesk
European GNSS Service Centre (GSC),
Torrejón de Ardoz
the Galileo Service Operator (GSOp) is operating the GSC, under a contract funded by the European Union and concluded with the EUSPA, which is the Galileo Service Provider.
Jim bell
Sep 4, 2023, 4:49:30 PM9/4/23
to GPSTest
Thank you, that is a very interesting paper. It's definitely an education for me!
Sean Barbeau
Sep 20, 2023, 10:13:34 AM9/20/23
to GPSTest
>The PPP engine is just an algorithm which is part of an app. I haven't used them myself, but you should be able to use PPP (precise point positioning) corrections with apps such as the Spaceopal's 3PGo or CNES's PPP WizLite. I would really appreciate a list of such apps from the community.
I have been trying to track these types of apps in my awesome-gnss list:
I'd welcome additions from the community via pull requests!
Sean
Jim bell
Sep 21, 2023, 5:20:19 AM9/21/23
to GPSTest
I received the Sparkfun ZED-F9P device kit ($575, through Amazon) a few weeks ago, added it to a tripod, and included a 38,800 mAh battery pack. I obtained a (free) account with the Oregon Department of Transporatioon (ODOT), which runs a network of CORS stations and creates and broadcasts (?) NTRIP corrections through the Internet. When exposed to the unmolested sky, it reports accuracies of about 18 millimeters horizontal, which I consider truly astounding.
As a minor project, I went to the Willamette Stone, https://en.wikipedia.org/wiki/Willamette_Stone the initial point from which the entire Pacific Northwest was surveyed starting about 1851. That point is now fairly heavily overgrown with trees, and the ZED-F9P reported an accuracy of about 25 millimeters horizontal. I suppose this difference was due to that overgrowth.
I suspect that my current readings, primarily of longitude, deviate substantially from that read in the Wikipedia article, perhaps mostly due to the effect of the mid-Atlantic-Ocean spreading that has occurred in the last few years. The article that was cited, in the Willamette Stone Wikipedia article, was published in 2009. My understanding is that the Atlantic seafloor has been spreading at the rate of about 1 inch per year. I haven't done the calculation yet, but 14 years multiplied by an inch per year is...14 inches. Presumably, surveyors have long since had to learn to compensate for this gradual shift in North American GPS location data.
I remain quite dismayed that the smartphone world does not appear to have a ready method of corrections, even today. And, ideally, a FREE one. WAAS has been talked about for 20+ years: So, where is it? How good would it be, if it were actually available? https://en.wikipedia.org/wiki/Wide_Area_Augmentation_System Much more recently, the Galileo HAS (High Accuracy Service) must have been designed over 5 years ago: where is it, too? The designers of the various smartphone chips, for instance Broadcom and Qualcomm, should have implemented Galileo HAS a few years ago, waiting for the actual transmissions to begin, which they did in late 2022. Missing, both, are the E6 signals (Signals In Space; SIS), but also the Internet Data Distribution (IDD) transmissions.
Why doesn't a version exist of single-frequency HAS exist for Galileo? Sure, I don't expect it to be as good as dual-frequency Galileo HAS could be, but I think it should be as good as a meter or so, a dramatic improvement over uncorrected GPS or Galileo.
Yes, I too can repeat the mantra that the achievable quality and accuracy of a smartphone's GPS readings may be limited by their un-ideal GPS antenna. But I should also point out that most people here (including me, a Ham) don't know just how bad (or good?) that limitation truly is. One interesting experiment that could be done would be to connect up a 'good' GNSS antenna, such as the type commonly used with survey-grade units, and then use that antenna's amplified output to 'drive' a smartphone. Not, of course, into some antenna connector (which doesn't exist, on any smartphone), but simply by 'capacitance'. I think it would be very interesting and informative to learn just how good a smartphhone's GNSS readings would be IF its antenna quality was made irrelevant in this way. It would tell us how good we can expect the output of smartphones can be expected to get once differential corrections were actually available.
The Galileo people claim that by employing those HAS corrections (in some kind of unspecified hardware) the accuracy of Galileo could be brought to 25 centimeters. Is it genuinely unrealistic to suspect that the antenna and electronics of a typical smartphone is good enough to achieve such a value? Given that the ZED-F9P can achieve errors of 18 millimeters with properly-generated corrections, it is hard for me to imagine why smartphones cannot achieve accuracies of 25 centimeters or even better. And THAT would be valuable!
i think the number of people who might benefit from corrected readings must number in the tens of millions, and even hundreds of millions. How could they have screwed up so badly? How could they, or Broadcom, or Qualcomm, etc, have waited so long that HAS isn't yet useable? And perhaps they cannot yet even give us an estimate of the current schedule?
gpsfan
Jan 19, 2024, 9:26:46 AMJan 19
to GPSTest
I finally found the time to read the full article and is it me or is it a bit...depressing ? It seems using smartphones for high accuracy could be considered a "lost cause" by now :-(
Reply all
Reply to author
Forward
0 new messages