Question about Tropospheric Corrections
Closed this issue · 7 comments
One thing I've just learnt is that tropospheric corrections are actually computed using a model.
But also I've discovered that they seem to be highly dependent on the clock error.
That's especially true in the case of coarse time navigation, with the local clock error in the order of seconds or even minutes.
So I've put a cap on those computed tropospheric corrections, so that they wouldn't screw the system (I've also noticed that those corrections are excluded when computing an a priori position).
It's curious that they seem to minimize around the true time. How's that happening?
Also: what maximum correction should one expect?
Ciao Emanuele!
Normally the correlation between troposphere and clock error is present,
but just when you actually estimate both troposphere and receiver clock
(e.g. for PPP). goGPS at the moment does not estimate tropospheric delays;
it just applies the Saastamoinen model, that is simply dependent on the
elevation of the satellite and height of the receiver (as well as on
atmospheric parameters, i.e. pressure and temperature, which in goGPS are
modelled as well). So the tropospheric correction is computed independently
from the positioning estimate: it is simply computed and applied to
observations.
In your case, with coarse time navigation, I suppose that it might be a
little trickier in the sense they the two variables in input (i.e.
satellite elevation and receiver antenna height) might be significantly
different from the "true" value, due to the high error of the receiver
clock (?) To understand why they minimize around the true time, I would
check the behaviour of satellite elevation and receiver height as well... I
guess that they also converge to their "true" value around the same time?
About the maximum expected correlation, it depends on which elevation
cutoff you use, and which height you consider, on average... I will send
you a plot I have here, by email.
2015-11-05 22:56 GMT+01:00 Emanuele Ziglioli notifications@github.com:
One thing I've just learnt is that tropospheric corrections are actually
computed using a model.
But also I've discovered that they seem to be highly dependent on the
clock error.
That's especially true in the case of coarse time navigation, with the
local clock error in the order of seconds or even minutes.
So I've put a cap on those computed tropospheric corrections, so that they
wouldn't screw the system (I've also noticed that those corrections are
excluded when computing an a priori position).
It's curious that they seem to minimize around the true time. How's that
happening?
Also: what maximum correction should one expect?—
Reply to this email directly or view it on GitHub
#18.
Thank you very much Eugenio, there's a lot to digest.
I'll get back to you when I do more tests
@ege010 I've just noticed you've created a Troposhere branch, were you planning on porting more Matlab code there?
Yes, my plan was to port the code needed to perform tropospheric delay estimation by PPP. So basically it would become a PPP implementation branch, like this one: https://github.com/goGPS-Project/goGPS_MATLAB/tree/troposphere
Did not have time to work on that though... however, from discussions with @nro2dai on the goGPS slack channel (BTW @ZiglioNZ, you have not joined yet!! ;) ) I gathered that activity on that branch should start soon at his lab.
Thank you @ege010
I'm glad there are long term plans for this project. Obviously someone other than ourselves is still using it, have you looked at all the clones? I was surprised.
With regards to Slack, I haven't tried it yet. I've never been on IRC either.
I'd like to keep discussions in one place, i.e. here, if possible.
For example: are we targeting a release? should goGPS/Java go together with Matlab or each one on its own? Those sort of questions.
I've got plans for Java, mainly simplifying the code, eliminating redundancies. Also I'd like to add Android support but that could be happening in a separate project.
Could you, and/or @nro2dai, please test my latest changes and see if it still works for you?
When you have time, no rush
I've tested your changes last week, and everything seemed to run just fine. But I have run just a couple of examples... unit testing would be nice to have!
Great to know. I was hoping to hear that. The only problem I suspect is in case and Ephmeris is not found.
A unit test would be great here, you're right.
I don't really like the approach I've taken (returning a singleton to signal that the ephemeris couldn't be found) but it was the only practical thing I could think of at the time without changing the API, ie throwing exceptions. There's one type of exception though in Java that doesn't require API changes (RuntimeException), so that'd be another option to consider.
Let me know if you have any preference.