Problem stations
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
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.