Troposphere selection ignored in Kinematic

[ToppDev]

When selecting the Kinematic positioning mode, the Tropo correction gets ignored.

This makes it hard to analyze simulated data without troposphere.

Can be seen here in the code: https://github.com/rtklibexplorer/RTKLIB/blob/demo5/src/rtkpos.c#L1032 The tropo correction gets always applied

/* adjust range for troposphere delay model (hydrostatic) */
zhd=tropmodel(obs[0].time,pos,zazel,0.0);
mapfh=tropmapf(obs[i].time,pos,azel+i*2,NULL);
r+=mapfh*zhd;

Maybe you can wrap this in an if similar to https://github.com/rtklibexplorer/RTKLIB/blob/demo5/src/pntpos.c#L265

if (tropopt==TROPOPT_SAAS||tropopt==TROPOPT_EST||tropopt==TROPOPT_ESTG) {
    *trp=tropmodel(time,pos,azel,REL_HUMI);
    ...
}

Also a side question to this. Why does the wet delay get ignored?

[ourairquality]

Might it be assumed for RTK that the troposphere delay will cancel out in the differences, but perhaps it is included to remove some first order effects to extend the usable baseline a little? Or would it have just been for the tropo estimation code paths (if that code even works). Can it be improved?

[ToppDev]

I agree that it mostly cancels out. My problem is mainly if you are using simulated data without troposphere simulation. Here this leads to an error of up to 10cm just because troposphere is not there in the observations, but Rtklib is adjusting for it.

It is also confusing, that you can select a model in the GUI, but it has no effect, as the code is not reacting to it.

[ourairquality]

The pntpos solution uses TROPOPT_SAAS except in PMODESINGLE, see function pntpos() `opt.tropopt=TROPOPT_SAAS`, so that might also be an issue for your simulated data.

The wet component appears to be an order of magnitude less than the hydrostatic. Including the wet component using the approximation in tropmodel() appears to degrade the rtk solution and perhaps the more precise mapping function of tropmapf() is more important. Rewriting tropmodel() to separately return the wet component and mapping both components using the more precise tropmapf() did not appear to make much difference to an rtk solution, did not appear to add much.

Avoiding any troposphere delay completely did significantly push an rtk solution off, over 10mm on a 15km baseline, so there does appear to be merit in including a good estimate.

The rtk tropo estimation code does not work in the example datasets that I tried, it just seems unstable, and that is with good data with a lot of signals.

The rtk code currently accounts for the wet component in ddres() but only when it is being estimated.

I'd just hack the rtklib code to disable this if it helps with your simulated data. I doubt it is of general applicability to completely disable the tropo delay estimation in rtk solutions. Perhaps that option should be removed from the apps, except for pmode single.

[ToppDev]

Thanks for the work you put into this. I agree that validating simulation data without troposphere is an edge case and most people wont need it.

I already compiled my own version where I disabled it myself so there is no need to 'hack' it in. I think it's better to think about what benefits the software the most.

And I think most people would expect that when doing kinematic double differences, that the atmosphere model shouldn't matter. So I tend to like your last suggestion of removing/disabling it from the apps. This would simplify the GUI while also making it consistent with the code