tomojitakasu
commented
6 years ago The offset parameter Asys and Ksys to convert Javad [r*] short psuedorange of Galileo to RINEX were changed in several F/W versions. For details, refer the Javad GREIS reference p.85.
http://www.javad.com/downloads/javadgnss/manuals/GREIS/GREIS_Reference_Guide.pdf
RTKLIB 2.4.2 p12 is based on F/W 3.4.0 and 2.4.3 b29 is based on F/W 3.6.7. Please check your receiver's F/W version, modify the constants in the function rtklib/src/rcv/java.c:decode_rx() and rebuild APs if needed.
A receiver dependent option will be added in future releases to cope with any F/W versions.
breuper-tud
Scenario:
When using RTKCONV to convert raw .jps files to RINEX v3.02 observation files, I noticed some strange behavior: All the Galileo code-based pseudoranges have an added bias of 5 ms (or roughly 1500 km). This applies to the observation codes C1X, C5X, C7X and C8X. When processing the observations afterwards (with my own code), you get a different receiver clock bias for GPS and Galileo (they differ by 5 ms). When converting from .jps to RINEX v3.02 with JPS2RIN, this difference does not appear and the receiver clock bias is the same for GPS and Galileo. Pseudoranges for GPS are exactly the same in both RTKCONV and JPS2RIN. My calculated receiver clock error for RTKCONV's GPS pseudoranges is the same as the one JPS2RIN gives out in the RINEX obs file. The one for Galileo is 5 ms higher and has no counterpart in JPS2RIN.
I'm not sure if this is a bug or intended behavior. If the latter is true, can it be turned off in RTKCONV's settings somewhere?
PS: Keep up the good work, this is just a minor issue in an otherwise very good and versatile program!