|
Francesco Mancino: Well as a practical matter, you really do not to want to record RINEX in the field, it is better (much smaller) to use the device's native binary format or an RTCM3 format and post process that to RINEX. > I've not RINEX files of local observations taken by a rover I am not sure I read this correctly but the above statement remains true. > So I'm thinking to use RINEX observation data of a network station like rover static data and correct them with NRTK-VRS technique. Should work fine. For this you need to gather either live caster data (use a free tool like SNIP and have it record whatever NTRIP data stream you need, see: use-snip.com) or use after the fact FTP data. You may be able to use the FTP files provide by NGS and CORS. The problem that many people have with those files is that after a week the data is decimated for long term storage, so your 1Hz data becomes 5/15 second data. So it is common to record the live data when you can get it off NTRIP and make your own records. [Beside SNIP, the BNC tool is also adept at this] Another issue is that NGS is only interested in high grade base stations about 70km apart, and many states in fact have sites with closer spacings. As matter of current policy, NGS does not record those. Its worth the time and trouble to learn about who has local stations you might want to get data from. If you are limited to L1, you really need to find a station that is <15km from your rovers to do RTK things. The other advantage of post processing is you can use better orbital and clock products which you can get from various places (and you can also get live from many NTRIP sources). On the whole your approach is quite sound IF (the big if) your L1 only rover devices can in fact give code (pseudorange) AND carrier data. If it can only give you code, you are more or less screwed. [If that is the case, try to send it RTCM2.x data because is probably has some sort of primitive Hatch filter to do some carrier smoothing and multipath rejection] Good luck with this. Regards, David Kelley PS: the carrier field in any RINEX file is the "L" (L1 or L2 etc.), if you do not see that field you do not have carrier data, here is a fragment from a uBlox 6T (an L1 only device). You can see the carrier for SV "G20" was missing in this data set (which was dropping out of view as the high negative Doppler rate and low SNR shows). 4 C1 L1 D1 S1 # / TYPES OF OBSERV 2016 6 7 17 42 46.0000781 GPS TIME OF FIRST OBS 2016 6 7 18 3 27.0000781 GPS TIME OF LAST OBS END OF HEADER 16 6 7 17 42 46.0000781 0 12G 7G 8G26G20G21G15G16G27G18G10S20G 4 24315075.481 127776517.3292 448.410 29.000 22629267.575 118917537.1101 2271.698 32.000 21895722.936 115062756.905 -3156.582 42.000 25179786.705 -3549.886 20.000 23308387.593 122486312.002 -2759.055 46.000 25514482.824 134079506.961 333.453 33.000 20601440.208 108261249.8101 -1454.798 43.000 20620768.706 108362926.6981 797.603 40.000 22056801.307 115909274.4371 -833.425 46.000 21617601.357 113601266.278 1698.172 47.000 37871568.996 199016439.7911 -286.053 29.000 23186586.975 121846252.716 -3871.296 40.000 On 10/10/2016 5:55 PM, Francesco
Mancino wrote:
-- Regards, David Kelley ITS Programs Manager SubCarrier Systems Corp. (SCSC) 1833 East Foothill Blvd. Glendora, CA USA 91741 626-485-7528 (Cell) 888-950-8747 (Main) 626-513-7715 (Office) 888-613-0757 (Fax) <davidkel...@itsware.net> |
_______________________________________________ This message is sent to you from FOSS-GPS@lists.osgeo.org mailing list. Visit http://lists.osgeo.org/mailman/listinfo/foss-gps to manage your subscription For more information, check http://wiki.osgeo.org/wiki/FOSS-GPS
