Maybe it doesnt support L2C?
Same “issue” as here?
Maybe it doesnt support L2C?
Same “issue” as here?
Ya I saw this post, do you think I should try to update to the dev firmware as explained in the last answer ? It looks it solve some data who are dropped in L2 during the export to rinex…
Yes. You probably should. I’ve had no issues with missing epochs nor L2 carrier phase signals since I updated my firmware.
ok thanks, I am updating now, will see in couple minutes…
RS2 records L2C only, it does not record L2P.
L2C is only available for new satellite generation. While L2P is available for all satellites.
That means: if a satellite is older generation, RS2 only log L1.
Unfortunately, their is still many satellites with only L2P (in such case RS2 does not log L2).
In Americas, where we mostly used GPS and Glonass having a receiver that only records L2C can be an issue since there is still many satellites that do not offer L2C.
what version of RTKConv are you using?
I recently got a response on another thread regarding RINEX conversion for L1 only
Also, I’d like to point out that RTKLib version 2.4.3 Emlid b28 is designed for Reach RS+ and Reach M+ receivers and, therefore, outputs L1 data only after conversion. I assume that’s the reason why OPUS aborted the submitted data.
For Reach RS2, there is an RTKLib version 2.4.3 b31 that can be downloaded from our docs.
Omg I hope it is not this, because I was not expecting to buy another GNSS antenna now…mostly I imagine the minimum price is about 6000/8000$…
I use the RTKLib demo5 b33b2. I saw before the recommendation in the doc.
BTW, I updated my antenna to 2.21.2, and It’s still not possible to post-process the data… I am lost
May I ask you to share your logs so that we can take a closer look?
Yes sure, this is the logs downloaded directly from the anthena :
How can I know if I have L2C/L2P GPS/GLONASS records in these logs? Because one of the engineers told me there is no record for the L2 GPS, but I am scared if it is the fault of the pospac software who is not able to read the L2C records.
You can convert the UBX in RTKconv, and then open the resulting Rinex file in RTKplot.
Doing that shows no L2C data in your ubx, which is quite odd.
Can you update to the dev software and try a 30 min collection?
On that firmware there are some fixes to L2. (I take it the provided data is not from the dev-firmware?)
Thanks Christian for your message.
My RS2 is already in 2.21.2 firmware, which is the last one. The raw I uploaded above are from approximately 1H20min of observation and from this firmware too.
Btw, in the logging page in reachview, I set up the RAW data to RINEX2.11 directly, but the anthenna, at the end of the logging (when I switch off the logging), it generate two files : the rinex and the UBX. Do you advice to choose only UBX and process to the conversion manually with RTKConv ?
I’ll compare to some of my own logs later.
Personally I like ubx the most. The ubx is the raw file, and with that I can do a lot of manipulation.
Rinex is a processed version of the ubx.
You can compare it to the photoworld. Your camera can shoot raw, you can process that raw to a jpeg. Rinex is sort of the jpeg of the geospatial world
You are right, but if we continue to compare to the photo-world, the raw photos are much heavier than the jpeg, but here, the UBX is half size of the rinex file, it is why I am a bit confuse or wondering if there is not a bug or missing data. or I guess it is just a question of compression…
Btw, I was thinking that the antenna is recording directly the raw in rinex, but after taking a look inside the file I saw that the rinex file is converted from the ubx by the antenna.
Please note that, as Stephanie has mentioned, Reach doesn’t track L2P frequency. It tracks only L2C frequency.
According to your RINEX log, your Reach RS2 has recorded the L2C frequency. I’ve attached the screenshot of the log.
Please check if your software is capable of processing L2C frequency.
Shouldn’t there be entries for GPS for L2C?
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 :
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.