bug in reading precise ephemeris (number of satellites) #67
Comments
|
As I understand the documentation, chapter E.4, only SP3-c files are supported, i.e. SP3 version 'c'. The newer SP3-d files which allow >85 satellites would require a rewrite/update of the respective functions. |
|
The sp3-c to sp3-d modification has been made here: tomojitakasu#529 |
rtklibexplorer
added a commit
that referenced
this issue
Nov 21, 2020
… consistent with RTK/PPK solutions - Port changes/address issues raised in PR #41, #63 and issue #67 - Port changes from 2.4.3 PR tomojitakasu#529, tomojitakasu#554 - Update igs14.atx file with newer version - Fix an illegal memory access bug - Fix a bug in reporting single point solutions for static mode
|
Added 2.4.3 PR tomojitakasu#529 into 11/21/20 commit |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I think the arguments are mixed up here:
https://github.com/rtklibexplorer/RTKLIB/blob/demo5/src/preceph.c#L83
ns=(int)str2num(buff,4,2);The third line of the SP3-file contains the text: number of satellites
+__114 C06C07C08C09C10C11C12C13C14C16C19C20C21C22C23C24C25It reads two characters starting from position 4, gets 14. But I must on the contrary to get 114.
Now he reads the first 14 entries for each epoch, and these turn out to be BeiDou. Accordingly, nothing further works without GPS.
The text was updated successfully, but these errors were encountered: