I mean "free" when I say "open source". 🙂
Curious what you are using to post process the data.
?ÿ
@dmyhill - Good question and I hope you'll share what you like to use too, open source or otherwise ???
I think I mentioned to you earlier that I'm not expecting these HiPers will be good for RTK, though I haven't ruled out efforts for proving it through future tests, and that I'm hoping to use them for science experiments and other static applications. In answer to your question, lately the 2 primary processing applications that I'm using are OPUS and DPOS. Sometimes I use Justin (v2.124.164.28), but I expect to be using using OPUS Projects for baseline processing in the coming months after having recently completed OP manager training.
I assume you're already well acquainted with OPUS. DPOS is JAVAD's online processing service for their customers. They both end up producing similar looking solution reports, and both use available CORS for their adjustment, but that's where the similarities end.
As it stands presently, OPUS-S (static) requires 2-hour minimum observation files. Its 'PAGES' software currently still only uses DoD's constellation; i.e., GPS, and has never processed GLONASS, or for that matter any other GNSS data. That is expected to change in the new year at some point as M-PAGES leaves in-house beta testing, but I've heard no real word on its arrival date to us mortal surveyors beyond the conversational "sometime next year".
DPOS already is multi-constellation and truly a GNSS adjustment service for JAVAD customers using its own 'Justin' software and has no such minimum time span for processing submissions. This sometimes makes for an interesting situation when OPUS simply can't handle the noise of the neighborhood and produces a dubious solution while DPOS adeptly handles those scenarios without issue. Trying to discuss things with NGS, the matter gets dismissed as being caused by 'garbage in garbage out' and poor judgement by the user. Here's a recent case in point, noting in particular the distant station 2309N1 and the tree that's to the east (to the right) of it which had fewer leaves on it on November 13th than on the 7th. Also note the 1.5 meters OPUS disagreed with itself between these dates.
?ÿ
?ÿ
@kelly That metal sculpture could cause multipath for your antenna. Perhaps the 1.5' difference is the result of multipath and not an inherent error by OPUS.
@kelly That metal sculpture could cause multipath for your antenna. Perhaps the 1.5' difference is the result of multipath and not an inherent error by OPUS.
That is an interesting perspective, given that the same data set worked with DPOS.?ÿ It could be technically correct, and it this is exactly the kind of "black box" that gives us pause at times. We must assume that the NGS made certain decisions in the development of OPUS.
Curious how often OPUS is upgraded, and brought forward into "state of the art"?
And lurker is correct, the Hypers are not the best at beating multi-path. It would be interesting to see if it worked better on a Cinderella day, with all options turned on (including multi-path rejection).
(And yes, we should all have a discussion why we ever bought from a company that chose to make you pay extra for multi-path rejection.)
@lurker - You're correct that the metal sculpture is not helping things (most particularly with the compass!), but isn't related to the mentioned issue of 1.5 meters.
The metal sculpture is 4' distant from 2309S1, the southern monument. The 1.5 meters between OPUS 20211107 and OPUS 20211113 is at 2309N1, the northern monument.