I’m getting pre-processing errors on AUSPOS. I am very new to this. My goal is to be able to setup Known Points in remote areas to do simple point surveys using a base/rover situation.
Basic Steps:
-I’ve set my Base Station to the parameters on the EMLID AUSPOS - Online Processing Service How to Guide (Position mode to Static, Rinex [various versions] and AusPos settings).
-I have to change the name of the file to submit to AUSPOS. I change the filename to ‘Emlid.22O’. This fails AUSPOS pre-processing.
-I have converted the file using Emlid Studio. This fails AUSPOS pre-processing.
I am getting a solution on OPUS - but I’d rather be using AUSPOS for our work.
This is the error message from AUSPOS: ERROR (PrePPP-Processing, Please check the Span, Types of Obs (L1 and L2), Quality (L1 and L2), and Format of RINEX file (BASE15DEC22.22O)) from AUSPOS
This is my header data from the RINEX file:
3.03 OBSERVATION DATA M: Mixed RINEX VERSION / TYPE
ES dev:627ffa9c-Dev 20221219 080010 UTC PGM / RUN BY / DATE
log: C:\Users\adam.diaz\OneDrive - Gold Road Resources\EmlidCOMMENT
input_format: RINEX, option: -TADJ=0.1 COMMENT
PERsm01 MARKER NAME
MARKER NUMBER
MARKER TYPE
OBSERVER / AGENCY
EMLID REACH RS2 REC # / TYPE / VERS
EML_REACH_RS2 NONE ANT # / TYPE
-2363611.9644 4873729.9667 -3356280.4202 APPROX POSITION XYZ
5.0000 0.0000 0.0000 ANTENNA: DELTA H/E/N
G 8 C1C L1C D1C S1C C2X L2X D2X S2X SYS / # / OBS TYPES
1.000 INTERVAL
2022 12 14 23 59 0.9990000 GPS TIME OF FIRST OBS
2022 12 15 5 56 0.0040000 GPS TIME OF LAST OBS
G SYS / PHASE SHIFT
0 GLONASS SLOT / FRQ #
C1C 0.000 C1P 0.000 C2C 0.000 C2P 0.000 GLONASS COD/PHS/BIS
END OF HEADER
But as a newbie, and with a week’s worth of reading, I can’t seem to make sense of why my RINEX file isn’t being processed.
The checklist:
Before submitting your GPS RINEX file/s, please ensure:
AUSPOS only provides a network solution (relative positioning) using a double-difference strategy. Dual-frequency (L1 and L2) measurements are necessary. I think this means I need to set the base station GNSS settings to Static
Please make sure all RINEX files submitted to the same job contain an overlapping period of more than one hour. Otherwise, submit them individually to different jobs. I’m only submitting one file
DO NOT submit measurements for the current UTC day. Please wait until the next UTC day after 0300 (3 am) UTC time. This allows the RINEX files of reference stations to be downloaded for the current UTC day. I have been recording on one day and submitting 24hrs later
DO NOT submit receiver raw binary files (for example files with extension: M00, T01, T02, DAT, SBF, TPS…). I am only submitting the observation file
ONLY submit RINEX observation “.O” files. DO NOT submit RINEX files with extensions: “N”, “M”, “G”, “L”, “P”, “H”. The observation file that is downloaded from the RS2+ is written as name.22O, I’m not sure if the ## part matters.
RINEX filenames should NOT contain any special characters, symbols or spaces. The file name that is downloaded from the RS2+ is BASE-Emlid1_raw_20221214235825.22O which I rename to BASE.22O simply by renaming it Explorer…not sure if this is corrupting the file
The station name will be read from the first 4 letters of the “MARKER NAME” line in the RINEX header. I’ve set the Marker Name in the RS2+ Settings and can see it in the .22O file
Please make sure the interval (INTEGER only) of measurements is equal to or bigger than ONE second. It is better to have all RINEX files with the same interval. I’ve set this in the settings and have tried to set it in the RINEX convertion tool using Emlid Studio. The readings still come out with a long decimal where the seconds are. Not sure if this is the issue.
DO NOT use special characters for “MARKER NAME” and “MARKER NUMBER” in the RINEX header. ONLY use numbers and/or letters from the modern English Alphabet. Check
After the “END OF HEADER” line in the RINEX header, only observation data should be present (Epoch time and Measurements). Please check before submission. After inspecting the RINEX file in Notepad, I feel this is ok. Although the Sat_IDs? are on each line…I would think this is necessary.
If BOTH C1 and P1 (C2 and P2) code measurements exist in a RINEX v2 file, P1 (P2) is given priority to be processed. Please make sure all GPS satellites contain P1 (P2) measurements. I don’t know how to investigate this
If only C1 (C2) code measurements exists in RINEX v2 file, Please make sure all GPS satellites contain C1 (C2) measurements. I don’t know how to investigate this
For RINEX v3 files, C2S (code measurement) and L2S (phase measurement) from L2 frequency will NOT be accepted. I don’t know how to investigate this
For RINEX v3 files, currently, the accepted measurements from L1 frequency are C1P and L1P; C1W and L1W; C1C and L1C; and C1X and L1X. I don’t know how to investigate this
For RINEX v3 files, currently, the accepted measurements from L2 frequency are C2P and L2P; C2W and L2W; C2C and L2C; C2D and L2D; and C2X and L2X. I don’t know how to investigate this
If RINEX files are Hatanaka compressed, please use the lower case “d” for the filename extension. I’m not using Hatanaka compressed.
Hi @svetlana.nikolenko ,
Here are the two zips from the Emlid.
These aren’t sensitive data. They are just recordings to work out the AUSPOS side of things.
I think there is just not enough data for AUSPOS to provide you with the results. The data is quite noisy and SNR is unstable. You may see a lot of small red dashes–cycle slips–during the whole log. They mean interruptions in data reception. It’s ok to have them when a satellite is low above the horizon. But if the sat is almost in zenith and there are cycle slips, it tells us about not that good environmental conditions.
Also, the Signal-to-Noise ratio is quite jumpy.
AUSPOS works with GPS only, so GPS signals should be almost ideal. By these logs, I’d say you’re working with obstructed sky view. Is it so? Can you share pics of your worksite?
Other than leaving the Emlid soaking for longer and ensuring a clear sky view, you could also try using the Time Rounding setting in Emlid Studio. Not sure if AUSPOS prefers it, but OPUS does, and I’ve had issues with other software (Applanix POSPac) not liking the native Emlid logs without the time resampling being used.
Thanks @mikeb .
Svetlana was on point. Basically my site location had poor visibility, especially on the horizon. The GPS signals were patchy and inconsistent which made for bad data which I submitted to AUSPOS.
The lesson was pick a better location, and check the data in EmlidStudio for quality.
The Emlid Tutorials were spot on.
AUSPOS doesn’t give a ‘bad data’ error…it just fails at pre-processing.
I also used EmlidStudio to format the RINEX file and to round the seconds.
