Reading RPLS is free for the whole profession. Members post, reply, and get the members-only rooms.
I want it! With an app that stores Rinex files.
Bill93, post: 376091, member: 87 wrote: I want it! With an app that stores Rinex files.
Can ANTEX calibrations for every phone antenna be far behind? 🙂
And the app will talk directly to IGS for orbits, clocks, intersystem biases, etc. (I assume everything is still L1.)
Might want a little choke ring.
I don't know if its possible to do RTK with L1 only?
And about time the UK opens up its real-time OS correction network!
Hopefully will push down the price of the GIS and then survey grade equipment.
I played with an Android phone with a L1RTK engine in it earlier this year. (Images below.)
Good for marketing, but I have spent a long time selling and supporting L1 only RTK devices (think PM3-RTK and PM120-RTK) and I am here to tell you that until they have L1/L2 engines and antenna, it is nothing to get excited about.
Ask anyone who uses ProMark 3 RTK units...Even the PM120's with GLONASS, but L1 only have marginal RTK performance in the open. And if there are any trees around, they just won't fix or stay fixed.
That said, there is a possibility of sending the observables up into the cloud and letting the server compute a fixed position, then return the position to the mobile user. That could save battery and result in a higher powered engine.
Mark Silver, post: 376170, member: 1087 wrote: I played with an Android phone with a L1RTK engine in it earlier this year. (Images below.)
Good for marketing, but I have spent a long time selling and supporting L1 only RTK devices (think PM3-RTK and PM120-RTK) and I am here to tell you that until they have L1/L2 engines and antenna, it is nothing to get excited about.
Ask anyone who uses ProMark 3 RTK units...Even the PM120's with GLONASS, but L1 only have marginal RTK performance in the open. And if there are any trees around, they just won't fix or stay fixed.
That said, there is a possibility of sending the observables up into the cloud and letting the server compute a fixed position, then return the position to the mobile user. That could save battery and result in a higher powered engine.
Yeah, you definitely need L1+L2 to do OTF ambiguity resolution and be productive with RTK.
But I expect L1-only should be fine for PPK over short baselines.
Certainly good enough for static positioning.
The antenna might be crap but averaging during long occupations would help.
-FGN.
A recent paper in the Journal of Geodesy looked at this problem more closely:
"... The experiment with low-cost receivers for the SF-DS [single-frequency, dual-system (L1 GPS+BDS)] reveals that it has the potential to achieve comparable ambiguity resolution performance to that of a DF-SS [dual-frequency, single-system (L1+L2 GPS)], based on the survey-grade receivers."
<"> http://doi.org/10.1007/s00190-016-0921-x>
Single-frequency, dual-GNSS versus dual-frequency, single-GNSS: a low-cost and high-grade receivers GPS-BDS RTK analysis
Robert Odolinski and Peter J. G. Teunissen
Mark Silver, post: 376170, member: 1087 wrote: I played with an Android phone with a L1RTK engine in it earlier this year. (Images below.)
Good for marketing, but I have spent a long time selling and supporting L1 only RTK devices (think PM3-RTK and PM120-RTK) and I am here to tell you that until they have L1/L2 engines and antenna, it is nothing to get excited about.
Ask anyone who uses ProMark 3 RTK units...Even the PM120's with GLONASS, but L1 only have marginal RTK performance in the open. And if there are any trees around, they just won't fix or stay fixed.
That said, there is a possibility of sending the observables up into the cloud and letting the server compute a fixed position, then return the position to the mobile user. That could save battery and result in a higher powered engine.
I am currently testing a L1-only GNSS RTK solution by using the open source RTKLIB ported to Android.
The receiver(s) I use is Sokkia GSR1700CSX without RTK firmware so I use the RTKLIB RTK engine.
I connect the receiver to a CORS using network solution (VRS or MAX) and if the conditions are good it fixes pretty quickly.
The results compared to the solution by L1/L2 GNSS are within 1-2cm which is very good but the L1-only solution is not so stable and it looses the fix easily.
The L1-only is comparable to L1/L2 only in small baselines about 3km although I had good results in 7-8km baselines.
Trimble and Leica both have open Android L1 and L1+L2 receivers but Android N is going to open a ton of new Applications, Seriously cant wait!
what a good news, I am developing RTK app for android, currently I am taking rover raw data from my external gps receiver and base raw data come ove my own ntrip client (which is integral part of my app), and I run RTK processing on the phone. It would be really great not to to use my external receiver but instead to take GNSS raw data straight from the phone's GNSS module.
My app is not rtklib wrap - I developed all code by myself, Very often do get correct cm accurate vectors but I do now know when they are correct or when they are not, I am really struggling with statistics. when they are correct it takes only 1-2 minutes to initialize, L1 GPS only, for short baselines. But with VRS baselines are always short.
Felipe G. Nievinski, post: 377879, member: 10769 wrote: Single-frequency, dual-GNSS versus dual-frequency, single-GNSS: a low-cost and high-grade receivers GPS-BDS RTK analysis
Robert Odolinski and Peter J. G. Teunissen
Just found http://gnss.curtin.edu.au/wp-content/uploads/sites/21/2016/06/Odolinski2016Single-frequency.pdf&apos ;">that article (free).
"First look at Android N GNSS raw measurements"
http://rokubun.cat/2016/06/30/android-n-preview-gnss-measurements/
Thank you,
Looks like it is applicable to GPS only no other constellation's raw data are opened up, but that is not bad at all:
ÛÒ The collection of raw measurements reported by the preview Android N API https://developer.android.com/reference/android/location/GnssMeasurementsEvent.html#getMeasurements%28%29&apos ;">getMeasurements() contains only GPS measurements on the tested devices. Neither GLONASS nor satellites for other constellations are reported by this method, despite the fact that the specs for both devices indicate that they are capable of tracking GLONASS. It is still unclear if this is due to the API itself or related to the hardware.
ÛÒ In general the Nexus 5X tracks a higher number of satellites than the Nexus 6 (see plot), this might be due to the fact that, as shown below, the Nexus 5X tracks satellites with lower C/N0.
looks like qallcoom gnss modules installed in those smartphones do track glonass and others as well. but the raw data output is limmited to gps only. but is is still great to have gps only raw data flow;)
