search

rtklibexplorer / RTKLIB

A version of RTKLIB optimized for low cost GNSS receivers, especially u-blox receivers. It is based on RTKLIB 2.4.3 and is kept reasonably closely synced to that branch. This software is provided “AS IS” without any warranties of any kind so please be careful, especially if using it in any kind of real-time application.
http://rtkexplorer.com/
Other
675 stars 263 forks source link

When was tadj (time adjust) added to gen_obs_glo() call? #45

Closed DavidKelleySCSC closed 5 years ago

DavidKelleySCSC commented 5 years ago

Not an issue, just trying to keep one of our clone copies aligned. Trying to get a feel for how far back the two diverged, so I can seek for related changes. Can anyone recall when this was added?

What first brought this issue up was a failure in the b31a release (using the strsrv tool) to translate GLO MT1012 to MT1010 where it appears that the carrier frequency is always getting set to -1 (err), The codes fail for the translation is MT1012->MT1012 as well. The old code also has an issue where lambda is not always computed that seems to be dealt with as well in the new.

Running this with b33a, and the same settings, the translate of RTCM3 to RTCM3, GLO MT1012 to 1010/1011/1012 is working fine.

rtklibexplorer commented 5 years ago

Tadj was added to gen_obs_glo() on 2/2/17 and first appeared in version b26a but I don't believe this is related to the issues you describe. I believe these were fixed by the commit on 9/17/19 which first appeared in the current b33a release.

DavidKelleySCSC commented 5 years ago

Thanks of this and the quick reply. It gives me an anchor in time to be looking for other changes. I managed to merge the current rtcm3e.c into my project without too many issues. And it is correctly encoding MT1009~1012 now. There is a new 'freq' term added to the obs struct I will need to look over carefully as part of this, our branch is quite old. We have heavily modded rtklib.h with our own elements so this sort of thing so there is always a fear of introduced conflicts at out end.

DavidKelleySCSC commented 5 years ago

Spent the last week updating everything in sight from the past 5 years, a good investment but painful to undertake. The more comprehensive treatment of time is much to the better, but causes problems with patches we have to now work through here. In our work we also make provisions for all the RTCM messages to be handled, and that might be somethings to bring into the common code base now (PM me for a copy you can use). I am still trying to unwind issues with GLO freq treatment in all this that seem to be the root issue with my original issue.