You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Firstly, I am very thankful you for sharing your various work (gnss_comm, GVINS, VINS mono and ublox driver). Each of them is very impressive and instructive for me.
I want to ask you, is there any bug in this function (UbloxMessageProcessor::sig_freq). This function returns GPS L2 frequency 1.22760E9 for Galileo E5b signal instead of 1.20714E9 if I am not wrong. Also your GVINS dataset outputs frequency as I previously mentioned. I used a workaround for processing GVINS data because it passed through ublox driver package before it saved. As I guess, GVINS algorithm also uses this signal frequency for several calculations in order for factor generation.
Thank you for your sharing your effort and knowledge to worldwide researchers.
The text was updated successfully, but these errors were encountered:
Hello dear HKUST researchers,
Firstly, I am very thankful you for sharing your various work (gnss_comm, GVINS, VINS mono and ublox driver). Each of them is very impressive and instructive for me.
I want to ask you, is there any bug in this function (UbloxMessageProcessor::sig_freq). This function returns GPS L2 frequency 1.22760E9 for Galileo E5b signal instead of 1.20714E9 if I am not wrong. Also your GVINS dataset outputs frequency as I previously mentioned. I used a workaround for processing GVINS data because it passed through ublox driver package before it saved. As I guess, GVINS algorithm also uses this signal frequency for several calculations in order for factor generation.
Thank you for your sharing your effort and knowledge to worldwide researchers.
The text was updated successfully, but these errors were encountered: