For some reason after fixing the header observation bug (take off L2 observables) does not correctly process in rtkconv_emlid_b27.exe
After many tries I seem to have achieved some success by filtering the RINEX with TEQC command “teqc -n_GLONASS 26 -S -E raw_201712152107.obs > test.obs” this eliminates Galileo and SBAS entries (not needed for my post-processing) but also gets rid of many unnecessary empty spaces in the RINEX.
After using TEQC I can process in rtkconv_emlid_b27.exe from 2017/12/15 21:08:15 to 2017/12/16 01:17:15, from 2017/12/16 10:22:40 to 2017/12/16 11:47:05 and from 2017/12/16 12:59:45 to 2017/12/16 19:59:55 the epochs outside those time frames are not processed.
I have manually increased TEQC GLONASS maximum slot number from 24 to 26 because the data included in the RINEX file from the Emlid receiver had GLONASS observables tagged as being 26 which, by default, causes TEQC to quit the process, I don’t think there is any particular problem with that, RTKlib seems to correctly digest GLONASS SVs with slot number over 24… The big question mark is why there are observational gaps when processing with rtkpost_emlid_b27.exe. Would you be suggesting that the processing gaps are related to GLONASS slot IDs over 24?
Unfortunately I deleted the UBX file from the Reach thinking that it was “redundant” to the RINEX file, boy I was wrong!
Today I extracted a different 24 hour UBX file from my Reach and after converting to RINEX in my PC I got 0 problems, to me it suggests that the real time conversion to RINEX is a waste of Reach resources (CPU + memory) which may be prone to conversion problems… From now on I’m sold to storing UBX only (and convert latter on)…
Thanks for your help
PS: Are you using Spectra Precision Survey Office to post process?
I have experienced problems using RTKCONV to convert long log files from 5Hz UBX to slower (1Hz or 0.1Hz). The problem manifested as large empty gaps in the RINEX files.
As a workaround, I kept 5Hz and just limited the duration of each conversion using start and end time.
Maybe your problem and mine stem from the same cause.
Not sure this is appropriat or/and valid comparable, but it helps me deside whether to use RAW or processed Rinex from Reach.
From my work with photography and dSLR, RAW format was the only option with postprocessing images back at the office. JPEG files only used for preview, onthfly work and simple tasks or non critical display.
So raw.ubx would be raw images and .jpg is Rinex. Now, Rinex has its benefits, no doubt about it. Just need to apply it under the right situation.
What is the reason for measuring such long sessions since 10 minutes is enough? See an example here, using VRS RTN (Figure 1)
Postprocessing in the L1 version only
Here is your whole log processed against the GARR base station. I didn’t concern myself with why it is mostly all float. Maybe the coordinates I used for the base weren’t correct. Anyhow, this is just to prove that all the data is there and is usable.
I used Emlid’s RTKCONV to reconvert your RINEX files to RINEX v3.03, and then I used Emlid’s rnx2rtkp (the Linux version of RTKPOST) to process the new RINEX. I chose that program because it can process huge log files that RTKPOST can’t.
I couldn’t help but try another one with rnx2rtkp. This was using your supplied RINEX with no additional conversion. Settings were: GPS and GLO only; combined solution; elevation mask 25 degrees; base coordinate set to the average of the single solution.
I made this screenshot of the ground track because it is a much tighter grouping than the previous one:
Hi Isaac, This is an example of postprocessing of your 30-minute session with fixed solution (extracted from 23h), longer than I mentioned because the 15-second interval of VRS and GPS L1 only. From my experience, a 10 minute GPS + GLONASS session, 1 second interval and RTN is just as accurate as the classic static 23h. VRS should be generated from a few hours session.
Lack of ubx file does not allow to determine what is the cause of these failures. Land Survey Overview ICGC.pdf (208.4 KB)
The reason I’m measuring such a long observation campaings is because I have a fixed antenna on the roof of my building I I would like to perform ublox neo-m8t raw data reliability studies (it is not cumbersome to perform long observations as it is a lab like environment) in a realistic environment (with multipath and partial sky view).
Eventually my objective is to see if it is possible to use such L1 only receivers for control deformations.
It really seems like taking off low elevation observations helps to converge the solution, this puzzles me a bit as I made sure the Tallysman antenna (recommendation from ublox) had a good ground plane (19 cm / one L1 wavelength instead of the recommended 10 cm).
Your data looks concerning as there are many (lots of) false ambiguity resolutions…
Would you mind to explain how did you came up with the results VRS13490.pdf? I’m used to submit RINEX files to NRCan PPP but how did you came up with the dual frequency data, was that a chop of one of the three base stations I provided? If so, what were you trying to prove?
Hi Isaac,
I tried to prove that suspicions about the rtkconv and teqc programs are unjustified. The cause was incorrect preprocessing. This is the topic of this thread after all.
VRS is generated from your three reference stations.
It looks that my good intentions have not been understood.
I find this thread quite interesting. Mixing high level profession/accuarcy and how to troubleshoot with different angle of attack. Just the way i like my coffe
This one confuses me, could you clearify the end goal.
It might be my lack of english skills but to me it sounds like you have two missions here.
1.Study the ublox neo-m8t raw for reliability and consistency data (e.g no gaps in the data stream and so on)
2.Study the L1 only receivers for control deformations
From what i understand, these two topics is different and nr 1 to be somewhat solved (without the .ubx raw file) here
And nr 2 solved by bide, pazus and igor later on.
Does this sound right?
On a different matter, i am not sure putting a device on your building to measure its accuracy is a good idea, not with a tool the actually is capable of measuring sub cm. Unless your building is specially made for this kind. Your building might not be that stable.
Who starts?