DPOS

Kelly Bellis

ME PLS 2099
5PLS
VKB_DPOS_configuration_20150505-03.39.45.png


Don,

In addition to proper DPOS settings, what makes good practice, begins with always completing the download of the base file file from the T2 to the LS. From that point, it's really up to you and how you want to go about submissions.

For example, I've done a couple of tests in my search for answers to some questions:

DPOS is waiting on NGS, IGS, and maybe something else(?) before it can complete requests being made directly online via the browser interface and requests being made directly via the Triumph-LS. The user has been loosely informed to wait overnight before expecting to see their returned results. But do we have enough information to answer replies to our users' questions with a little more exactness? Can we tell them a little bit more as to why we wait?

For example, and in regard to Glonass, when is IGS data typically expected; e.g., at the top of the hour for the previous hour's ephemeris, midnight for the previous day's , etc. Same goes for NGS's routine schedule for disseminating GPS data.

The tests I've done involved timing and reviewing LS-DPOS using short Base/Rover sessions, generally under 20 minutes. In the first test, my initial submission to DPOS was about 4:00 PM EDT. The second test was initially submitted to DPOS about 4:00 AM EDT. In both tests, subsequent submissions continued automatically every 5 minutes until the results were returned and the automatic adjustments were made.

The results in both tests were returned at very nearly the time same: 8:20 PM EDT ± 5 minutes. So at this point, one might conclude that midnight (UTC) for the previous day's data + 20 minutes is more likely the time as to when to expect an answer back from DPOS to the LS. And then with that in mind, at least for myself, I'll use the settings shown at the top of this post.

These tests involved only the LS-DPOS scenario and did not involve the T2-PC to DPOS via the web browser.
 
Top