Sorry for causing the misunderstanding! Let me correct myself.
RTKLib shows different observation codes. The observation code refers to the frequency according to the RINEX format specification. So, the L2C code of observation in RINEX roughly equals the G2 frequency of GLONASS, as it’s shown in the screenshot I’ve posted in the previous post.
As Christian has correctly mentioned, L2C frequency is to be provided by the GPS constellation. According to the RINEX specification, the observation code for this frequency is L2X.
According to Arnaud’s log, we can be sure that the Reach RS2 has recorded the L2C frequency. The correct screenshots to prove this are below: the first one shows that the L2 frequencies have been recorded and the second one shows that the L2C frequency has been recorded.
Hi @polina.buriak Polina, thank you so much for your time and for your help.
So to resume :
I have now the confirmation that I have L2 record in my logs (thanks to you @polina.buriak)
I get also the confirmation that Applanix (pospac software) support the L2C record
But my post-processing is still not working… So I guess it is an issue from the RS2 who don’t export the RINEX2,11 in the right format…as I guess a Rinex2.11 from trimble or Emlid should match the same “architecture” and standard for the files right?
I am sorry, but I just need to know which side I have to ask, if it is Emlid who has to fix the export format file, or if Applanix has to support your brand because you have a different format…
I just made a small test with RTKConv to try to exclude the hypothesis of a bug from RTKLIB.
I download an observation file from the public GNSS network, from an antenna at 22km away from my flight test. The Original file is in Rinex 2.11. I took this File and put in RTKConv and I converted with the same option as I tried before with the EMLID observation file.
And it’s work. So I believe I can trust the RTKconv for the postpac process as the file it made works with my software to compute RTX.
Now we have to know why it’s not working with the RS2…
I would suggest asking Applanix if their software absolutely requires an antenna model in the RINEX header. It’s one of the only things that is lacking for files exported from Emlid receivers. Without those values, software that was built to account for phase center offsets might bug out if they are missing.
Does the Applanix app have an option outside of the Rinex files to set the antenna type? Like post processing software, you can set your antenna type and the software will include the preset values in its computation. If yes, then select any antenna type to see if it will process completely.
You are right guys, the applanix software give the hand on the choice of the antenna, and choosing another type of antenna is already what I do. During my training at the lidar company office, the engineer advised me to “cheat” the software and put the reference of another antenna, because it is what they do too, as their own antenna is not officially listed in the software also. This is the setting I put during my tests :
Height: 13,5cm (height specified by emlid from the bottom of the antenna to the GPS receiver)
Method: Antenna Phase center
Manufacturer : Trimble
Type: Zephyr - Model 2
I just made a test with a modified header with these options, but it failed again :
So, the only one difference I saw with the file who is working is on the "TYPES OF OBSERV "
The file who is working has the P1 and my converted file doesn’t contain the P1 obs
This won’t solve your problem, but in your antenna settings, the height isn’t the 134mm (what you marked as 13,5cm) value. You should choose the Bottom of antenna mount method, enter the height from your ground marker to the bottom of the RS2 unit in the height field, then in the Offset from Measure Point to APC field that will now be enabled, enter 0.134m.
Or altenatively, if you choose the Antenna Phase Center method, then measure from the ground marker to the bottom of the unit and add 0.134m, then enter the result in the height field. I don’t know if you intentionally entered 0.135m as the height or not but it looks suspiciously like a common mistake.
My mistake, you are completely right, the correct value is 0.134m and not 0.135m, I miss read the schema previously.
About the setting “bottom of antenna” when we choose this option the offset is automatically set to 0.085m and it is not possible to change it. So it is why, (i think) during the training they advise me to put antenna phase center.
About the height, I am a bit confused…because I want to believe you but they told me to put only the value from the bottom to the antenna to the GPS receiver, and not from the ground. I completely agree that we have to set the height when we record a GCP during a survey in (“pole height” in the survey tab of reach view) but as the antenna, (in my case) is only here for observation, I don’t know if it is necessary to put the exact height of the pole.
My assumption is that the software would use the height and offset like in RINEX files where they are two separate measurements (one controlled by the antenna model, the other manually entered). I might be mistaken though.
By observation, do you mean you aren’t measuring a specific ground marker and just the antenna’s location? Because even if doing static observation for post-processing, it seems to me that you’d still need instrument height so that the calculation is reduced down to the marker itself.
No, I am not measuring a specific ground marker, only logging the satellite info, and my base station has to be less than 10km from my flight path to keep the best absolute accuracy.
“Normally”, if I am not wrong, I don’t need to measure the height of the tripod to the bottom of antenna as the altitude will be used and calculate with the post-processing and the height of the land will be determined with the difference of altitude of the base, altitude of the drone and distance to the ground recorded by the lidar. To give another example, I am in the same configuration if I use the data provided by a public GNSS network, I have all the coordinates, but not the height of the antenna from the ground. But IF I want to come back on the same site and put the base station at the same spot and using the coordinates previously calculated, I will need to measure the height of the tripod above the same reference point to position my base at the same coordinates.
From the screenshot you’ve posted it seems like the public GNSS receiver didn’t record the C2 data.
May I ask you to post the raw data log you collected from the drone and also specify the model you use? It’d be great to have them because it’ll allow us to check the specs and to try to post-process your logs.
Is that a generic message you get when it asks for unempty header?
NrCan does something similar but just to warn you that the final result might be wrong du to lack of Rinex information.
no there is no message about a rinex header empty issue, it is just the process who failed without detailed information. And the last answer from the software support team is that the process failed because the header is empty. Previously I tried different header with random info or info based on real antenna and it changed nothing.
Ok I see. To me it doesnt sound like a empty header error, more like the software doesnt understand the RINEX file. Something simple as number instead of letter or a box is ticked that should not be ticked might be the problem, or the RINEX format version.
Also recent RTKlib version might not work with software outside the Reach family.
Have you run this by the RTKlib version from the processing guide?
yes I tried this version before, but it is true, I didn’t make all the deep test as I did with the recent version of RTKLib, as I was expecting they will keep the change made in the b31. I will redo the test with this version and see what happens.
