Anders Wallin <address@hidden> writes:
> you could try Teqc (now no longer developed (?) but working binaries should
> be available) - it has some sanity-check functions
> https://www.unavco.org/software/data-processing/teqc/teqc.html
good advice, despite the proprietary nature of teqc.
I have downloaded and run teqc.exe on my observation file, but I got the message that rinex version 3.03 is too large. rinex <= 2.11 seems to be wanted input.
> also maybe try to submit a known-good RINEX-file for processing and see how
> that goes (gzipped version, vs. unzipped, rinex v2 vs v3, etc. might be
> simple things that go wrong)
FWIW, I have recorded observations from a M8T using the Emlid Reach in
ublox raw, used the emlid reach software (convbin from rtklib) to
convert to rinex, and uploaded those to NRCAN site and gotten useful,
sane solutions (that are similar to the online nav solution and a second
receiver's solutions, but with a cleaner track).
I recorded a rinex file on aug 24th 2019 and posted this to csrs-ppp just now and got a proper location calculation back. Unfortunately for me, that was a test location to verify that the software chain worked. When I moved the antenna to the roof for more permanent placement, the problems started.
I have been looking into RTKLIB to see if there is something which can be used for verification, but I do not yet understand how I can analyse my observation file with that toolkit.
There has been a notion previously that some processing software needs
30s interval rinex to be lined up on the even 30s (of UTC, or GPS time -
not really sure which).
I use option -i 30 to gpsrinex which is suggested in the PPP howto and record for 24h max. currently I am recording 12h or less until I get the current issue solved.