Issue with `rinex2snr` Command in GNSSREFL 3.10.0
Closed this issue · 8 comments
I encountered an issue while using GNSSREFL 3.10.0 to perform RINEX conversion. The specific problem and command details are as follows:
Command Used:
rinex2snr epl100nld 2019 287 -year_end 2020 -doy_end 359 -snr 88 -orb gbm -samplerate 1 -stream S -nolook T -strip T
Problem Description:
- Starting from day of year (DOY) 139 in 2020, the command reports the following error:
- After DOY 360 in 2020, I used
-stream R, but the same error persists.
Additionally, I noticed that the generated SNR files are smaller than expected. I am unsure if this is related to the error.
Environment:
- GNSSREFL Version: 3.10.0
- Operating System: Windows WSL2 with Docker
- RINEX Files: Combined using GFZ into daily files, RINEX 3.05 format
Could you please help me identify the cause of this issue and suggest a solution? Let me know if additional details or logs are needed.
Thank you in advance for your assistance!
If you need me to provide more details or additional files, please feel free to let me know.
the current version is 3.10.4. not saying that is your problem - but just letting you know that you are not using the latest version.
your screenshots suggest that the code is failing when the file is
converted from RINEX 3 to 2.11. gnssrefl does not do this conversion - gfzrnx does this conversion. so i think one test you could do is to do the conversion separately, outside of rinex2snr. try using
rinex3_rinex2 and see if that gives you the same error messages.
secondly, you could do the translation by yourself using gfzrnx. only have it write out
SNR observables. once you have a rinex 2.11 file try translating it with rinex2snr.
other comments:
-strip T is not needed when you use a RINEX 3 file. it is only used for RINEX 2.11 files that have >25 observables.
I don't understand why you are varying the stream parameter. it is not a choice.
it is how you named the files (or the person who gave the files to you named it).
i honestly can't say what is wrong given that you are using your own RINEX files. it could be that you are trying to use illegal RINEX 3 files. or it could be the gfzrnx executable needs to be updated (i.e. the one provided in the docker is not good enough anymore). you cannot upload RINEX files to github - but if that file is available at an archive i could check it for you.
you could also check to see if the gnssrefl code works for another RINEX 3 file at another site.
that way you would know if the problem is specific to your station or whether it is all RINEX 3 files.
if you find that you have illegal lines in your RINEX file - i can't help you with that. but if the problem is gfzrnx, you could upgrade your gfzrnx executable and see if that helps. the guy in charge is at GFZ.
Thank you for your response.
I am using 1-second sampling rate data provided by ngsi.nl. The station I used is EPL1. The data can be accessed via the following link:
https://gnss-data.kadaster.nl/data/highrate/2024/003/
I am not sure if the issue occurred during the process of combining 96 15-minute files into one daily file using GFZRNX, but the data before 2020 DOY 139 was processed using the same method without any issues. Due to the need to preserve the observations for other calculations, this process has taken a lot of time. I am unsure if there is a better way to achieve this.
I didn’t use version 2 because I am unsure whether it can correctly preserve BeiDou observations.
As you mentioned, the issue with the stream parameter might be related to the naming convention. I will recheck the format using GFZRNX and attempt the conversion again.
Please let me know if additional information is needed.
Best regards
i would always encourage you to use RINEX 3 over RINEX 2. having said that, i have to wonder if you made a mistake when you merged the 96 separate files. I'm not saying you did - but clearly you were given complaint lines indicating problems at specific lines in your file. and that is why your
resulting snr files are small - gnssrefl code is not going to go past fatal errors. but
you would have to look at the RINEX files to know what is wrong with them.
for me it was easier to add the kadaster archive to rinex2snr than figure out what is wrong with your files. thank you for sending me the url for kadaster.
i also tested that it works using the docker (though i am not using Windows - but i can't do anything about that). this is the command i tested:
rinex2snr epl100nld 2024 5 -samplerate 1 -dec 5 -orb gnss -archive kadaster
it downloads 96 1-second files from kadaster, merges and decimates to 5 seconds and uses multi-GNSS orbits and creates a SNR file. the stream parameter for this site is R, and that is the default,
so i did not have to set it. if samplerate is 1, the code is smart enough to know that the rate
parameter is high (as opposed to the default of low).
you of course may want to keep the 1 second files. i am surprised to see you using -snr 88 .
i hope you need those high elevation angle data -because they are useless for reflectometry.
if you still want to figure out what is wrong with your files - you could still follow my other advice, i.e.
check other stations and RINEX 3 files from other archives.
if the only station that gives you trouble is using
files you merged, and you can't manually convert them from rinex 3 to rinex 2, then your
files are the problem.
ps if you already downloaded 96 files and you want rinex2snr to merge them for you, you can put the 96 crx.gz or rnx files in the working directory and set the archive to kadaster. if it does not find them it will download them again. the code is in highrate.py. look for the word kadaster in the code for details.
pps i hope it is clear that you have to download the new code to get access to kadaster.