Difficulty Reading GPS L2/S2W Data with rinex2snr: Seeking Explanation for Missing Signal-to-Noise Ratios
Closed this issue · 6 comments
I noticed that when using rinex2snr, the GPS L2 or S2W data was not successfully read and written. I tried both Rinex 3.02 and Rinex 3.05 after performing format checks using gfzrnx, but encountered the same issue. However, what's strange is that last year, when I converted SNR files using the old gnssrefl, the L2 signal-to-noise ratios were included. For other satellite systems and bands, everything seems normal, although I haven't conducted an in-depth comparison. Could you please explain what might be causing this?
`
root@fb8bfc44be2c:/usr/src/gnssrefl# rinex2snr qdkz00xxx 2023 105 -snr 88 -orb gnss3 -rate high -nolook T -screenstats T
Only one day being analyzed, parallel processing turned off
No parallel processing
/etc/gnssrefl/refl_code/2023/snr/qdkz/qdkz1050.23.snr88
SNR file does not already exist. Which means I will try to make it.
/etc/gnssrefl/refl_code/2023/rinex/qdkz/
Will first assume RINEX file qdkz year: 2023 doy: 105 is located here : /usr/src/gnssrefl
try looking for RINEX 3 in /etc/gnssrefl/refl_code/2023/rinex/qdkz/
Apparent Rinex version 3.02
The RINEX 3 file exists locally QDKZ00XXX_R_20231050000_01D_01S_MO.rnx
Minimal feedback is written to /etc/gnssrefl/refl_code/logs/qdkz/2023//105_translation.txt.gen
GFZ0MGXRAP_20231050000_01D_05M_ORB.SP3 GBM0MGXRAP_20231050000_01D_05M_ORB.SP3
ftp://ftp.gfz-potsdam.de/pub/GNSS/products/mgex/2257_IGS20/gbm22576.sp3.Z
ftp://ftp.gfz-potsdam.de/pub/GNSS/products/mgex/2257_IGS20/GBM0MGXRAP_20231050000_01D_05M_ORB.SP3.gz
100% [..........................................................................] 1043915 / 1043915Orbit file: /etc/gnssrefl/refl_code/2023/sp3/GBM0MGXRAP_20231050000_01D_05M_ORB.SP3
Seeking permission from Earthscope to use their archive - wish me luck
That download experience took 1 seconds.
SUCCESS: SNR file was created
/etc/gnssrefl/refl_code/2023/snr/qdkz/qdkz1050.23.snr88
That took 152.46 seconds
`
do you want me to add a flag so you can keep L2W?
I apologize for missing your message and not responding in a timely manner.
I understand that if L2W performs poorly, it would be reasonable to discard it. If L2C is accepted in the observation file, it would be placed in the third column of the SNR data, correct? Can I assume that if the current SNR data file includes L2C, it cannot also include L2W? What happens if both L2W and L2C are present in the observation file?
I believe that having an additional option could improve the code, but if L2W is indeed too unreliable, there is no need to waste your time on it.
Thank you for all your contributions to gnssrefl.
Best regards
I think I've got it figured out. I'll rule out s2w. Thank you for your answer.