Has anyone attempted to submit a Rinex file of Reach RS2 observations to the AUSPOS positioning service?
Using rtklib Demo5_b31 (and also tested latest b33a), I used convbin to convert the file to Rinex 2.11, outputting 30 second interval observations from the source 5Hz data. rtkconv was not used as checking/changing the data interval resulted in to .obs file, despite deleting the .ini file each time.
So my test data set has nominally 3 hours of data, not ideally but satisfactory for testing. On submission of this data set to AUSPOS, the emailed error message is “Data sampling interval in test.obs may change”. AUSPOS cannot get a solution.
Looking at the rinex file, this is the case, the observation times vary in the milliseconds. In my case observations vary from 13 to 6 ms behind the even second over 3 hours.
I note that PPP-CSRS yielded an acceptable solution.
I would be interesting if other users have attempted and AUSPOS solution with RS2 data, and their experiences.
Please see below my question to the AUSPOS support team at Geoscience Australia;
I am attempting to obtain an AUSPOS solution from data observed using an Emlid Reach RS2 GNSS receiver. I have down-sampled the data to 30 second interval epochs, but am receiving the error below. On inspection of the data, I note the each observation epoch is not precisely “on the second”, in this case the epochs are 6ms delayed (0.006) at the start of the file, and 1 ms advanced at the end (9.999). Can you advise if this is the error source.
And this was the response from the the Manager of AUSPOS;
Yes, this is the reason why you has got an error message. AUSPOS cannot process data with sampling interval changes. Also you may setup your instrument with integer seconds 0.0000s and 30.0000s for epochs.
We’ve converted RINEX data from Reach RS2 so that the time becomes integer and tested it with AUSPOS, however, the data couldn’t be processed as well.
Reach RS2 tracks GPS L1C and L2C signals. According to AUSPOS, their service can’t work with L2C data. Therefore Reach logs won’t process with AUSPOS. However, AUSPOS is working on the update that will enable this functionality in future versions.
We can confirm that the current iteration of AUSPOS started to support the L2C data, and thus the RINEX logs from RS2 can be uploaded from now. We’ve submitted our test data and it was processed just fine.
I have tried uploading to Auspos but it says (when ‘Scan’ ) No valid antenna type found in raw_202010300125.obs
I have tried uploading the .ubx and similar issue.
NB: I am unzipping the RS2 generated Rinex 3.03 log.
Am I not doing something really basic?
I am still confused.
Still new to GPS processing, So even though the RS2 creates a Rinex obs file, it still has to go through RTKlib Conv & RTKlib Post? Can you tell me in a nutshell what is being done in CONV & POST? Whats being changed. Why isn’t the RS2 raw Obs file good to go straight into AUSPOS?
When I run Convert on the Base data and then ‘Process’ , opening up POST, it inserts the Base obs file into the Rover field and Base is waiting for a file location. If it doesn’t matter, why label them?
In the diagram you did, should I be entering in the OPTIONS tab: BASE, RS2, EML_REACH_RS2 when using obs files (like in your diagram) or only when using ubx files? And if yes, where is that in the manual! I thought “default(none)” was the recommended option and should work. Are the Emlid documents out of date?
Sorry if I sound frustrated, I am
(I am also using the RS2 Base with Teodrone AGNSS PPK modification to a Phantom drone. within that process, I have more luck with ubx than obs files. I am wondering if Emlid Rinex 3.03 is buggy.)
Not in all cases.
Because some post-processing software for example requires that we do a little more special conversion.
Some post-processing softwares accept RINEX v3.03 (Receiver Independent Exchange Format) others no etc…
RTKCONV is a tool that allows you to enter the parameters manually to add or modify ubx files to obtain a RINEX file that can be used by all local or online post-processing software.
Take the example of AUSPOS (it requires the type of antenna linked to the calibration file) to calculate the position more exactly and correctly even if the influence of the type of antenna in the calculations does not seem very significant to you.
Calibrations files can also be used with RTKLIB when you want to calculate a PPP Static: Precise Point Positioning with static mode.
For the case of AUSPOS The RINEX file obtained directly from the RS2 receiver does not contain the type of antenna That’s why we do it manually with RTKCONV.
As I said before RTKLIB in general and these modules and more particularly RTKCONV (which recognizes several formats not only ubx) and RTKPOST allow to enter all the parameters which help to obtain a more correct and precise result.
So you can post-process the data coming from the RS2 receiver with data coming from other receiver models.
Entring options tab: BASE, RS2, especially helps the user if he uses several receivers in order to distinguish between them and to avoid any confusion in order to avoid errors which could be fatal for calculations without realizing.
I just discovered that the type of antenna is added very recently as mentined by Tatiana here :
Finally, I prefer to choose the conversion parameters in almost all cases (RINEX v3.03) Otherwise I go to version 2.11 or 2.10.
Hi Zinou, Thanks for clearing up those points. I think I have a better understanding off RTKlib OPtions now.
For the time being, until I get used to the RS2, in particular RV3, I think I will strive to use known points and Auspos. I will log everything but use RTKlib just as a backup if I have a problem.
I swear the antenna was not in the list on Thursday but it is now (sunday) YAY!
I tried submitting several times to AUSPOS and sometimes they email the result and sometimes nothing. I usually use AUSPOS as a 2nd check on OPUS. Results are off by decimeters depending on ephemeris used I would assume. Off course they use different reference points. I am interested only in relative positions of submitted points. I swear there was an instance or two where an actual person emailed me saying there is something wrong with their servers. Can’t imagine someone would individually handle every submitted file.