-
Notifications
You must be signed in to change notification settings - Fork 34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
support multiple signal_type/observation_code in add_sv_states_rinex #161
Comments
Hi @mikehb, I wonder if It's also definitely possible we have a bug in the code or don't have observation files like yours in our testing scheme. If you're able to attach your full/cropped observation file to this issue, I'd be happy to take a look at what happens when I try to run the file myself. |
Looks like the QZSS is not supported by function add_sv_states_rinex. This the observation file which could reproduce RuntimeError: Some ephemeris data is missing.
|
Ahh, yes you are correct. Sorry for that confusing error statement and that I didn't realize sooner that you were trying to add satellite states using the Rinex broadcast data and not the SP3/CLK precise data format. My colleague, @kanhereashwin, was working on additional compatibility to the An alternate approach would be to use the SP3/CLK "precise" data source instead of Rinex. I've demonstrated how to use the "precise" file types in this Google colab.
I've attached the CSV output when using "precise" data here: navdata.csv |
I followed your google colab example, and noticed that the residuals is very large, not as what the tutorial showed, is there any thing wrong with the code or observation data? I am wondering if I can use glp's residuals as a feature of deep learning. With RTKLIB, I can get a small pseudorange error, with following equation, psr_error = raw_psr - (geometric_distance - CLIGHT * sv_bias) where raw_psr is the pseudorange measurement reported by receiver hardware, sv_bias is calculated from broadcast ephemeris, and geometric_distance is caculated by RTKLIB's geodist,
for example, the [P0/P1]_residual is within a few meters,
the date_time is the seconds since 1970/1/1 00:00:00 After modifying RTKLIB code to dump the sv position, I noticed that it has a huge difference, about 20KM along x/y/z, between RTKLIB and GLP. The RTKLIB uses broadcast ephemeris which was saved by the receiver, while GLP use SP3 downloaded from website. Is it a bug of add_sv_states? maybe leap second is not aligned? @betaBison @kanhereashwin Here is a piece of G03 output from GLP
|
add_sv_states works for me
|
Describe the proposed feature
My observation data has multiple signal and observation code, but add_sv_states_rinex prints 'Some ephemeris data is missing'. I have to add the sv states one by one
obs_signal=obs_data.where('gnss_id','gps').where('signal_type','l2').where('observation_code','2X')
sv_states=glp.add_sv_states_rinex(obs_signal)
Motivate the proposed feature
This features make it easier to use in case that multiple GNSS signals need to be considered.
The text was updated successfully, but these errors were encountered: