[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ZED-F9P and PPP processing
From: |
Greg Troxel |
Subject: |
Re: ZED-F9P and PPP processing |
Date: |
Wed, 06 May 2020 09:34:36 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.3 (berkeley-unix) |
"Gary E. Miller" <address@hidden> writes:
>> Most processing sites will reject dual-frequency observations that
>> only have data for a single channel, so NRCan throws out all the -F9*
>> observations from the older satellites. That results in more epochs
>> without enough birds to do a solution.
>
> Should gpsrinex have an option to not include L2C data?
Huge can of worms here. Basically, gpsrinex should not turn into an
arbitrary RINEX processing tool. Really what we want is
gpsrinex foo.ubx | rinexgrep -v L2C
but it remains to write rinexgrep. A lot of the problem is that people
were willing to use teqc for years, which is proprietary software to
process RINEX, and of course it should have been open source, but it is
tangled up with proprietary information for some receiver formats.
However, a lot of it is just RINEX, and that's been collateral damage in
being kept proprietary.
- Re: ZED-F9P and PPP processing, (continued)
Re: ZED-F9P and PPP processing, John Ackermann N8UR, 2020/05/05
Re: ZED-F9P and PPP processing, Svenn Are Bjerkem, 2020/05/05
Re: ZED-F9P and PPP processing, Greg Troxel, 2020/05/06
Re: ZED-F9P and PPP processing,
Greg Troxel <=