acceptable values of mp_win

Nacho Romero nacho at
Wed Jun 17 15:25:16 UTC 2020

Dear Sir,

mp_win in TEQC defines the window of epochs to use for the MP removal of 
a common bias .. MP is biased and should always be zero-meaned by 
removing a common bias over the observation pass. In theory the entire 
satellite pass would have the same bias but TEQC was implemented with a 
50 epoch MP window (mp_win) … we consider this window too short actually 
so increasing it gives more realistic values and decreasing it 
introduces many more degrees of freedom to the calculation. Therefore 
while a value of 2 may ‘improve’ the values they are not reliable since 
one cannot know the MP based on just 2 epochs, this allows too much 
flexibility in the MP estimation and the common bias would absorb the MP 
signal , especially at low elevation.

Selecting mp_win depends on the Rinex observation epochs, 50 was 
selected as reasonable for 30 second files (common in the data from IGS, 
EPN, etc) , for 1Hz data the equivalent would be an mp_win of 1500!

If MP changes at are site using reasonable settings (50, 100, etc) from 
one day to the next then something may be the matter with the data  or 
the physical conditions around the antenna, the cable, the connectors, 
etc, its worth investigating the physical conditions . If the problems 
come and go then it could be a tracking issue at certain elevations .

This was helpful tip of week 1895 explaining the issue better than me!


[teqc] helpful tip of week 1895 Lou Estey lou at

Wed May 4 08:52:00 MDT 2016

Previous message: [teqc] AUTO: Mark van Kints is out of the office 
(returning 09/05/2016) Next message: [teqc] helpful tip of week 1896
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

This week's tip is about using teqc to quality check (qc) "high-rate" data.

The original UNAVCO QC algorithms were developed by Chris Rocken, Jim 
Johnson, and a few others in the early '90s back when the usual sample 
interval for GPS observables was 30 seconds. Those algorithms still form 
the core of teqc's qc and certain default parameters are still "tuned" 
to a sample interval of order 10 or more seconds. For example, these 
parameters are fine for the now normal sample interval of 15 seconds 
used in the PBO, COCONet, TLALOCNet, and other networks. However, when 
you start to collect and qc

GNSS data with a sample interval of 5 seconds or less, especially 1 
second or less, you need to start making a couple of parameter adjustments.

One of these involves the multipath '-mp_win' parameter, which has a 
default value of 50. And what does this mean? To get an estimate of the 
multipath rms about the multipath mean, one needs some idea of what the 
mean is. To do this, as was done in the original QC program, teqc uses a 
default moving average window of N points, N = 50. At 30 second sampling 
this amounts to the last

25 minutes of data that can be combined into a multipath combination 
(i.e. any single multipath combination requires a code pseudorange value 
and two different phase values all at the same epoch). The time 
variation of multipath typically has cycles that are on the order of 
several minutes in length, so that the default 50-point 25-minute window 
for 30-second data averages over a number of multipath cycles. It also 
works well enough for 15-second data.

For intervals much smaller than that, though, especially when one gets 
down to intervals of 1 second or less, you need to increase that 
multipath moving average window length. This is done with '-mp_win' 
option. The "rule-of-thumb" that we use here at UNAVCO is to use a 
window size that is 900 divided by the sample interval in seconds. So 
for 1-Hz data, you would want '-mp_win 900'; for 5-Hz data, '-mp_win 
4500'; for 10-Hz data, '-mp_win 9000'; etc. Since 1996 when this part of 
teqc was written, this window size has an upper limit of N = 65536 
points, which means this adjustment will work as is to 50-Hz data (well, 
up to 73-Hz data), so for intervals less than 0.02 seconds, just use 
'-mp_win 65536' which should be fine for intervals down to 0.01 seconds, 
i.e. 100-Hz data. (I guess I'll have to redefine the storage of this 
parameter in teqc when users start collecting and qc-ing 200-Hz or even 
higher rate data.)

Is that all? Not quite. For high-rate data you will probably also need 
to change the parameters for detecting ionospheric slips. Going back 
again to the early QC parameters, the slip detection threshold for 
time-rate of change of the GPS L1 - L2 combination for the ionosphere 
was set to be 400 cm/minute, i.e. the default '-iod_jump' option value. 
Again, this works pretty well for intervals greater than about 1 second, 
but for intervals around 1 second or less, you start to see the 
ionospheric scintillations -- and, in fact, special receivers are 
developed for ionospheric scintillation monitoring which are run at, 
say, 10-Hz to perhaps as high as 50-Hz. At these rates, the "smoothed" 
time rate of change threshold of 400 cm/minute becomes far too sensitive 
(i.e. normal scintillations will incorrectly be detected as "slips"), so 
you want

to set 'iod_jump' to something huge, say, '-iod_jump 1e38'. But, you 
still want to detect ionospheric slips and this is now done by 
introducing a realistic

jump size, in centimeters, using the '-ion_jump' option. A good value to 
start with is 8 centimeters. So:

interval > 1 second: '-iod_jump 400 -ion_jump 1e38' (teqc's defaults)

interval <= 1 second: '-iod_jump 1e39 -ion_jump 8' ... although you 
might want to play around with the '-ion_jump' value a bit

These are the two major issues I've run into when qc-ing high-rate data, 
based largely on GPS and some GLONASS data. There could be other issues 
as users start to qc more complex GNSS high-rate datasets, so this is 
probably not the end of the story ...

cheers, --lou


Louis H. Estey, Ph.D. UNAVCO, 6350 Nautilus Drive Boulder, CO 80301-5554

office: [+001] 303-381-7456 FAX: [+001] 303-381-7451

e-mail: lou WWW:

"If the universe is the answer, what is the question?" -- Leon Lederman


Previous message: [teqc] AUTO: Mark van Kints is out of the office 
(returning 09/05/2016) Next message: [teqc] helpful tip of week 1896
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

More information about the teqc mailing list



Best regards,

Ignacio (Nacho) Romero
Aerospace Engineer, PhD
Satellite Navigation Engineer @ ESOC Navigation Support Office
IGS Infrastructure Committee Chair
This message including any attachments may contain confidential
information, according to our Information Security Management System,
  and intended solely for a specific individual to whom they are addressed.
  Any unauthorised copy, disclosure or distribution of this message
  is strictly forbidden. If you have received this transmission in error,
  please notify the sender immediately and delete it.

On 17/06/2020 13:44, Павел Шарый wrote:
> *Dear Sir
> *
> Some day before I got very high and atypical values of mp12 and mp21 
> on data from a wide set of stations by some unkown reason.
> Then, I used mp_win 2 instead of the default (50) in order to decrease 
> mp12 ad mp21 values for teqc reports.
> Empirically I found out that that value (2) in contrast to others 
> gives low values of mp12 and mp21.
> Is the value of 2 correct for moovig average ? And why it works so 
> good as compared to the others ?
> What value or range of values of mp_win should I use if the default 
> value works badly ?
> Yours faithfully
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the teqc mailing list