Difference between revisions of "Problem stations"

From GeodesyLab
Jump to: navigation, search
Line 42: Line 42:
 
  pppclean 07oct08gmas____u0
 
  pppclean 07oct08gmas____u0
 
It is perfectly OK to do this, because this is what autoclean would have done if it had  not been messed up by a few bad points. But if there are small cycle slips or a few outliers left, pppclean will not find them (it uses a 10 cm tolerance for jumps in the residuals).
 
It is perfectly OK to do this, because this is what autoclean would have done if it had  not been messed up by a few bad points. But if there are small cycle slips or a few outliers left, pppclean will not find them (it uses a 10 cm tolerance for jumps in the residuals).
 +
 +
=== AC16 ===
  
 
=== LOGC ===
 
=== LOGC ===

Revision as of 00:54, 28 November 2007

special cleaning solution

The cleaning solution just uses a small subset of sites including the Denali sites and sites that are often messy. Run it like the line below or see the make-clean file.

Alaska_cleaning_solution 07aug12

more commands

del_pt

If only a few points have bad pseudorange you can use

del_pt

to delete those points. Because there are so few of them I (Jeff) think it is better to remove both phase and pseudorange data for these points, as opposed to removing all pseudorange data for GPS37 using del_pcode_arc. Also, in my experience when there is a few points like this, often the phase data are bad also. So I would go back to the qm directory and use del_pt by hand to remove the points.

An example:

1448/flt> allbadp
07oct08gmas____u0.postlog
  -119496000.00  GMAS  GPS37  8-OCT-2007 15:44:46.0000 110
  -119495000.00  GMAS  GPS37  8-OCT-2007 15:49:46.0000 110
  -119494000.00  GMAS  GPS37  8-OCT-2007 16:14:46.0000 110
  -119494000.00  GMAS  GPS37  8-OCT-2007 16:09:46.0000 110
  -119494000.00  GMAS  GPS37  8-OCT-2007 16:04:46.0000 110
  -119494000.00  GMAS  GPS37  8-OCT-2007 15:59:46.0000 110
  -119494000.00  GMAS  GPS37  8-OCT-2007 15:54:46.0000 110
      447900.00  GMAS  GPS30  8-OCT-2007 15:44:46.0000 110
      435303.00  GMAS  GPS54  8-OCT-2007 16:09:46.0000 110
      434522.00  GMAS  GPS24  8-OCT-2007 16:14:46.0000 110
      433306.00  GMAS  GPS24  8-OCT-2007 16:09:46.0000 110
      433262.00  GMAS  GPS24  8-OCT-2007 16:04:46.0000 110
      432806.00  GMAS  GPS36  8-OCT-2007 16:04:46.0000 110
      432401.00  GMAS  GPS36  8-OCT-2007 16:14:46.0000 110
      432376.00  GMAS  GPS36  8-OCT-2007 15:59:46.0000 110
> cd ../qm
> gunzip *08gmas*
> del_pt *08gmas* GMAS GPS37 "8-OCT-2007 15:45"
#  and repeat del_pt for the other 6 points

pppclean

If a station solution seems to have quite a few cycle slips, then I (Jeff) would run

pppclean

on the command line to let it do its work automatically. You might have to repeat pppclean again.

An example:

pppclean 07oct08gmas____u0

It is perfectly OK to do this, because this is what autoclean would have done if it had not been messed up by a few bad points. But if there are small cycle slips or a few outliers left, pppclean will not find them (it uses a 10 cm tolerance for jumps in the residuals).

AC16

LOGC

LOGC is historically noisy, which is easy to understand if you have ever seen it (bad sky view). Also, once it starts to snow, the noise level at LOGC rises. So expect to see more bad points then -- we might see some of its effect at the very end of the data we currently have. I have not seen any solution to the problem of LOGC other than deleting all the outliers. It's a pain.

PETP

The site PETP has episodic problems with severe RF interference. A good example is 07oct23 in week 1450 (files also copied over to the /gps/data/bad_examples/flt/ directory).

postplot PETP ALL *23petp*fit

If you look at this plot you will see a period of significantly elevated residuals from about hour 26 to hour 34. Then the residuals get small again and go back to normal. I have tried many times before to fix up PETP files that look like this, and the best solution is to remove all the data from this window. If you add -xel to the postplot line, you can see that there is almost no elevation dependence of the residuals, and if you add -xaz instead you can see that the largest residuals are concentrated in a certain range of azimuths.

There is a later period of large residuals, but you can see that the residuals for GPS35 form a stair-step pattern. I count 4 small cycle slips on that satellite over about a 3 hour span. I would figure out the times and run add_amb manually to add ambiguities at those three points (short_hand will not handle this well because the times of the slips do not line up with times of large residuals, so do it by hand), and then after doing that and removing the first bad window I would run the point position again and see what is left).

It is possible that PETP will be like this most days for a month or so, then will suddenly stop and go back to normal. You will not see these problems at the same time of day -- it depends on when they turn on whatever powerful transmitter is causing the interference.

ZECK