ARRGHH PM2's PDOP-20 at 6 miles in rain

One place to start might be an "out of service" SV that is dirtying up the pudding. If you've got Ashtech Solutions, get in there and look at the pdops (I think you can look at each SV) and turn the off the bad ones. Then reprocess.

Also, hopefully you had a good almanac.

When did you run this?

I ran some long occupations last Saturday (I had about 7 hours in common with 5 GPSs). Topcon Tools happily processed everything local with great results. OPUS came back with issues. My TPS files were rejected, so I converted one to RINEX. It was accepted by the Vertical was way out. I have it on my list to reprocess; perhaps one of the CORS was sad last Saturday. Would that make it a Sadurday?

PDOP 20 sounds awful.

a PDOP of 20 isn't just bad ...

I wonder if a PDOP, is actually a very specific number meaning NOTHING'S GOOD ABOUT THIS FILE ... NO WAY ... NO HOW.

Seriously, I have never heard of a PDOP of 20 and I wonder if a PDOP of 20 doesn't even exist ... kinda like a sailboat in 200' of water being 100' from the bottom of the lake, but still sinking ... in retrospect a PDOP of 20 is probably like the boat sinking and matters can't get worse.

Does a PDOP of 21 even compute or is 20 like crossing from positive numbers to negative?

In all seriousness, I wonder if something ... some once familiar step in using the CORS RINEX file has been missed ... after all, with the PDOP of 20, the numbers of sats used in the computation indicates "N/A" ... what!

a PDOP of 20 isn't just bad ...

I have had a few customers lately who have had trouble processing files in Ashtech Solutions that I was able to get results that appeared to be usable out of GNSS Solutions.

It's free for the L1 version and in my opinion has better refinement tools than Ashtech Solutions.

I would be willing to look at the files...

[email protected]

a PDOP of 20 isn't just bad ...

GNSS solutions won't even compute it ... well kinda ... it indicates wild ridiculous point coordinates and NO VECTORS to even look at.

I must be doing something wrong while getting the CORS data.

If I remember right even GNSS wouldn't download the file correctly.

If there's anything than things changing ... like new steps or something, it's when things have changed while I was asleep like Rumplstiltskin.

BTW who took care of Mrs Rumplestiltskin when Mr Rumpstiltskin was away ... Bing Crosby & Al Jolsen.

PDOP Is Only Part Of The Information You Have

Besides PDOP Ashtech Solutions tells you how many satellites that PDOP is derived from. It does not matter how many satellites your receiver sees and what raw PDOP it gives you, vectors are calculated receiver to receiver and it is only the common satellites that count.

I would like to know exactly where and when you id this observation and for how long. I want to see if Planning could foresee such a result.

I will reference a recent project I consider a failure. Another professional engaged me to do GPS for an EC. He listens to too much hype and expected to get good results in a wooded valley area. I set up where he wanted and expected a single L1/L2 receiver to give good results. I being the eternal optimist then walked off the site and set a second L1/L2 receiver in a nearby cul-de-sac. While they were doing the best they could, we drove 3/4 mile to a 29 flood benchmark and did a level run up the road through both GPS points and back down to the benchmark. He then left me on the job alone half expecting a failure so he would not have to pay me. Having been through this with the gentleman before I was prepared. I broke down the L1/L2 receivers and set up my 3 PM2s, on the site, at the cul-de-sac and on the benchmark. I occupied the benchmark for 42 minutes and used a 20° mask. I was only 4.5 miles from a CORS.

CORS to benchmark, 7 satellites, PDOP 1.8. I'll take that any day of the week L1 only and 20° mask.

Benchmark to site, 5 satellites, PDOP 6.4.

Benchmark to cul-de-sac, 3 satellites, PDOP 7.1.

Cul-de-sac to site, 2 hr 45 min, 4 satellites, PDOP 6.4.

BTW, my benchmark to cul-de-sac was 0.01' off the level run. High satellites are good for elevation, less so on position.

Paul in PA

PDOP Is Only Part Of The Information You Have

hi Paul...

this was between 1:30(or so) to 2:45(or so), on day 135(May 15th), 6 miles SSE of Logan Ohio.

The point was a GPS point established by Ohio ODOT VRS by another surveyor, off/on rain which was "usually", the kind of rain(surveying), could/might stand in.

Ashtech solutions gave results(memory), that appeared to be correct, or near so.

I was never given the VRS elevation and my friend said he never got the SPC data, but Ohio's LIDAR put me a few feet in the ballpark ... maybe.

Some trees south that view blocked below about 45 degrees and only covered the SSE & SSW, good view around the rest.

The readings(memory) on the vector screen gave sats=N/A and PDOP 20 ... not 20.1 or 19.1 ... 20 or 20.0

The sats= "N/A" is really bothering me.

GNSS refuses to give me a vector and the points it gives me coincide with reality ... if one used an atom bomb ... well, maybe a small one. NO DATA whatsoever in GNSS's vector screen.

I feel confident of the PM2 data and that I should've gotten, at the least, a poor computat5ion which would've stated the number of sats and a more reasonable, even if still poor PDOP ...

I really wonder if a PDOPof 20 is even possible. Maybe a checck of my very old Earthmate postprocessed data might bear this out.

This was my first CORS visit for data for about 3 years.

Even GNSS, which I thought I remembered was very good at getting the CORS data in full time coincidental coverage, was now given me the first half of my needed CORS data. Eventually I had to force it to ask for enought time.

In any case, if I ever felt frustrated with GNSS's interface in the past(which I certanly did), my frustration with this program's inflexibility forced me back to A.S. and I stopped spilling my coffee ... as much.

I know I did something wrong, or CORS data has changed ... or something.

I'm at a loss ... especially with software that indicates sats used as being N/A.

thanks

John, Send Me Your Ashtech Files And The RINEX

Reply to the email I am sending you.

I raised the mask to 30° on my project and got a worst solution of 2 satellites and PDOP 20.0. PDOP 20 appears to be the default highest value. I assume that your 20 without satellites used raw position only, not differencing from receiver to receiver.

At 35° I got a 3 satellite PDOP 19.8 and the 2/20.0 vectors.

At 40° I got a 3/20.0 and a 2/20.0.

At 45°, I got four 3/20.0s and a 2/20.0, 95% confidence of 19.187'.

At 50°, I got four 3/20.0s and two 2/20.0s worst confidence of 109.697'

This tells me that as the mask climbs some of the lower observations for a satellite are being removed.

At 55°, I got two 3/20.0s, three 2/20.0s and three N/A PDOP 20.0s, worst confidence 122.174'.

Interesting exercise.

Paul in PA

John, This Appears To Be The Problem

I used the Ashtech files you sent me, your PM2 RINEX file was unreadable. I brought the data into Ashtech Solutions and set up a project. I created a new RINEX file and your data looked good. I grabbed a 2 hour file from OHHO CORS and tried a solution. Got an N/A and PDOP 20.0, same as you.

I took both files into GNSS Solutions and got results, 9 satellites, PDOP 1.6.

So I then I took a look at the OHHO CORS RINEX file. It is of the latest format with 11 observables. A few months ago even OPUS was having trouble with Ohio DOT CORS data.

I used TEQC to reduce the OHIO CORS RINEX file to 4 observables, C1, L1, L2 and P2. Ashtech Solutions used that file and results were 10 satellites used, PDOP of 1.8. I do not know where the 10 comes from the PM2 file only had 9 satellites.

I take it that Ashtech Solutions will have more troubles as we get more and newer observables.

Paul in PA

John, This Appears To Be The Problem

Hmmm ... I forgot that I made a PM2 Rinex file.

Now that I think about it, it was because GNSS was giving me no solution with the native file(PM2).

Actually Paul, this is my fourth post-back to you. Sometimes ... ON THE BOAT ... the "inter"net gets "inter"mittent ... each time I tried to post, I lost connection and the typed out message ... so I went to sleep instead.

From what you said, I wonder if L1 only users, or maybe only L1 users in Ohio now need to use the software you mentioned to massage the CORS data?

BTW, did GNSS also import the phase-center data into the program?

I will shortly download that software and see if I can realize a good computation.

Thanks

John

Okay Paul

I went to the TEQC site ... and looked ... and looked ...

I downloaded the PDF tutorial ... it loaded fast(good?), and I downloaded the program.

Now, I let my license go last year, but if I catch up with my continuing education I could still renew ... not likely, but I digress ...

back to the TEQC
THEN ... I looked at the online directory and thought ... hmmm, maybe about a year's worth of CEU's to learn how to use this software.

I smell a potential seminar/program here ... Paul

John

Google "WinTEQC" By Silkwerks

On Line version, you can figure it out in a few minutes.

Heard about it here a few months ago, John.

You should stop by more often.

Yes, GNSS Solutions can read all the data from the PM2.

If you keep using Ashtech Solutions make sure you get the latest RINEX converter.

Another problem I have had with Ashtech Solutions is that it does not like the new Rapid orbit .spc files. I get around it by using the UltraRapid _18.spc instead.

Paul in PAS