Closed jigpu closed 3 months ago
gwbres
commented
3 months ago Hello @jigpu
Good catch, thanks for your contribution once again. I only used reference positions that are predefined in the file header so far, thats why this had not been caught yet.
FYI: i was planning on releasing a new version in early April, because I'd like to squeeze in some more work. But if you want me to, I can release a new version sooner
jigpu
commented
3 months ago @gwbres No need to change the schedule on my account. I'm literally just blindly playing around in waters far beyond my depth and reporting issues along the way :sweat_smile: I learned about "RINEX" only a week ago after looking into Android's raw GPS ability. I've been doing a lot of bumbling around in a (perhaps overly-ambitious :laughing:) attempt to get something to turn the data recorded from my phone into a position.
I'm still having trouble getting the rinex-cli position solver to do much with that data. ~It'll happily* correctly solve when I give it 24o, 24n, and sp3 files from a local reference station~, but not so much if I substitute out the 24o with one from my phone. I suspect the phone's data might be too poor for rinex-cli to handle, though I could also just be doing something wrong. (I was able to get RTKLIB to spit out a phone solution, but I'm under no illusions that the phone's data is going to be pretty terrible compared to anything you'd normally feed to rinex-cli).
Actually, it has a small* issue with the data from the reference station. It spits out a invalid Gregorian date: Carry error unless I truncate the file slightly. There's a "RINEX FILE SPLICE" near the end that I think rinex-cli doesn't like...
EDIT: Actually, looks like even the data from the reference station just shows a single point at the apriori position... I must definitely be doing something wrong :confused:
gwbres
commented
3 months ago @jigpu,
I've been doing a lot of bumbling around in a (perhaps overly-ambitious 😆)
really awesome, I can only encourage ! If you're motivated enough, let's just switch to our Discord channel (you can join in for free and tie it to your github account for instance), it will be better suited to discuss complex topics
I'm still having trouble getting the rinex-cli position solver to do much with that data [..] but not so much if I substitute out the 24o with one from my phone
Position solving is the most advanced topic, I'm the app author and probably the only person that has used this opmode to this day, so this is not surprizing. If I get it right, you manage to get your phone spit out its signal observations as a RINEX (Observation) file.
It'll happily* correctly solve when I give it 24o, 24n, and sp3 files from a local reference station
24o are the signal observations (carrier signals), 24n are the ephemerides (SV messages broadcasted over radio at that time), and SP3 are high precision orbits (SV attitude, post processed by some laboratories).
Keep in mind you need to gather 24n and SP3 for the very same day the signal was observed (24o), otherwise it will not work.
You can register for free on the NASA/CDDIS portal, to retrieve some of these files.
Ideally Rinex-cli should be able to resolve with a simpler context (24o+24n), but we're unable to do that.
I will try to fix that soon
There's a "RINEX FILE SPLICE" near the end that I think rinex-cli doesn't like...
Do you care enough to share an example of your Observation Data so I can reproduce on my side ?
I think RINEX FILE SPLICE is the special (this is not standard) marker that the teqc program places inside a RINEX that was either merged or truncated, at the instant it did that operation
Actually, looks like even the data from the reference station just shows a single point at the apriori position... I must definitely be doing something wrong
My recommendation would be to take advantage of the logger ( $RUST_LOG), the application is pretty verbose and will point out what step is failling in the solving process. You can directly copy and paste its output here, or on Discord, I will rapidly understand what issues we're facing
The rx-geo parameter expects lat/lon in degrees, but the geodetic2ecef function wants them in radians. This leads to positions being wildly incorrect. This commit switches to calling the GroundPosition::from_geodetic function instead, which is happy to directly recieve the lat/lon/alt tuple as-is without conversion.