Problem stations

From GeodesyLab
Revision as of 01:20, 28 November 2007 by Lissy (Talk | contribs) (→‎assignments of problems)

Jump to: navigation, search

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).

assignments of problems

Here should be an overview/short description about the problems the following stations have/had.

LOGC is historically noisy (bad sky view) PETP has episodic problems with severe RF interference
ZECK has a history of being a bad station from time to time

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

week 1433, day 29

Final assessment of ZECK data from this day: it is junk. I'll elaborate on my assessment so that you can learn how I approached it. Part of what contributes to that is that I know ZECK has a history of being a bad station from time to time, although not every day by any means. Maybe it has some intermittent RF interference? I went back to the original file, and it had some enormous pseudorange residuals for GPS37. These would have caused autoclean to mess up the file, and I am pretty sure that these bad pseudorange points would have still been obvious in the point positioning solution left after autoclean. If so, the first thing you should have done was go back to the original file, rerun pppsolve., and then deleted the bad pseudorange for GPS37 using del_pcode_arc.

Then I reran it and got something that looked a lot like what you had in your file after more cleaning, just not quite as bad. I'll leave those files there for now so you can look at them and then delete the files (also move the qm file to a bad subdirectory). What I saw was that some satellites looked OK, but several of them had excursions of up to 20-30 cm magnitude. If you look at some of the worst ones (see list below), they do not look normal at all. The later part of ZECK-GPS41, for example, looks like a staircase going down to the right. That might be a sign of several small cycle slips in the data. Looking at other satellites, I can see 5-10 cm jumps all over the place. 

maxi 07jun29zeck____a0.postlog | head
         -25.06  ZECK  GPS29 29-JUN-2007 17:04:46.0000 120
         -24.61  ZECK  GPS29 29-JUN-2007 17:09:46.0000 120
          20.00  ZECK  GPS41 29-JUN-2007 17:49:46.0000 120
          19.29  ZECK  GPS56 29-JUN-2007 10:49:46.0000 120
         -18.87  ZECK  GPS40 29-JUN-2007 10:39:46.0000 120
          17.94  ZECK  GPS46 29-JUN-2007 08:14:46.0000 120
          17.90  ZECK  GPS27 29-JUN-2007 08:39:46.0000 120
         -17.86  ZECK  GPS34 29-JUN-2007 07:54:46.0000 120
         -17.26  ZECK  GPS40 29-JUN-2007 10:44:46.0000 120
         -17.26  ZECK  GPS32 29-JUN-2007 08:39:46.0000 120

What this means is that maybe, after a LOT of work, you might be able to rescue this file. And unfortunately the problem is nto confined to just one small length of time, but is spread out over most of the day. When I see this with a station that has a history of periods of bad data, it is usually a sign that it is time to throw it out. Or perhaps to try once or twice and see if it gets better, and throw it out if it does not. I'm guessing that you went several iterations and didn't get anything that looked right, so certainly you will be justified in moving this file to the bad/ subdirectory. Be sure to create the qm/bad subdirectory if it does not already exist before you do a mv *29zeck* bad, otherwise you will just rename the file.

Retrieved from "http://gps.alaska.edu/internal/index.php?title=Problem_stations&oldid=388"