J.D. and I have discussed the issue of "solution type" in the vectors tab. According to the manual, we should have either "fixed", "float" or "partial". I have seen "partial", but even with good data and acceptable residuals, have not seen them tagged as "fixed". Any comments about this?
Also, the new antenna parameters; we now know the Locus antenna as type "800372", while Locus Processor gave us "unkown". Discussing the issue of using older projects with Richard Phelan, and the fact that Solutions 2.4 gives us type 800372 with new data, yet retains type "unknown" with old data, are we going to see a problem? Should we change all the data to the one type?
And last but certainly not least, with these new antenna parameters, what would be considered the vertical height of a locus receiver on a 2 meter pole. Will it be 2.00 maters or 2.00 meters + the offset of the receiver itself (0.125 meters) for a vertical height of 2.125 meters?
TIA!
Dave

I think I've seen "float", "partial" and "fail". I've never seen "fixed", either, but I think if nothing appears in the QA section, it is "fixed".

We often get "failed" vectors, but in networks with enough redundancy, it is obvious that many of the reported "failed" vectors are actually OK. I'd assume it's the same with vectors reported as "partial", although, I would not trust them unless there were some redundant vectors.

-Greg

Dave,

As far as your 2 meter pole goes, I think I can answer that one. It's very similar to my "base station post". In Solutions you can use "vertical" instead of "slant", but "vertical" is expecting the H.I. to be from the "point" to the ARP. With the proper antenna type listed, Solutions automatically accounts for the antenna phase center offset. So, if your pole, from the point of the pole to the base of the receiver is 2 meters, that's the HI to input, and set for Vertical.

Someone can correct my if I'm wrong.

J.D.


p.s. The SV tweeking in 2.4 works. Reduced my error estimates in adjusted data from 0.11 to <.06 on some 7 mile lines, just by turning off a few random SV's. Can't wait to run the 15 miles in from the next PAC to "scrunch" my post in a bit closer. Then the third one.

Modified By J.D. Billings on 8/16/2001 at 1:03 AM

I'd be careful about removing SV's from the solution. It's rare, but I have seen cases where you can remove a few, get good statistics on the solution, but poor geometry, causing a solution that is poor (even though the stats are good).

Brian,

I'm fairly confident in the final results on this one. I only turned off one or two sv's for each vector. After processing I looked at the residuals and compared to the previous processed residuals. In some cases the residuals didn't seem to change, but after adjustment, the error estimates on the sites themselves dropped substantially. You're right for sure about turning off too many satellites. I played with that to see the processed residuals drop, and after adjustment see the error estimates zoom up. Am I correct in using the adjusted data error estimates as a basis for final adjustment? I also left at least 6 sv's in the vector solutions on this project. On this project I do have previous coordinates to check into, so I do at least have a target to shoot at for comparison.

Thanks, J.D.

J.D.,

Sounds like you're OK. A bogus solution will definitely show in the network adjustment. I usually try raising the mask angle a little before dropping individual SV's, but it's not too unusual for one SV to degrade a solution.

Regards,
Brian

Brian,

Yeah, I did raise the mask angle to 15°, then 20°, then 30°, just to check things out. Seems that 15° mask and turning off a couple of sv's here and there (based on the sv vector residual graph) made a tremendous difference in the final data error estimates. It's a bit more work with 2.4, but I see it's also only a matter of an additional small learning curve.

Thank's,

J.D.