> After doing a bit of research, I see that Trimble Business Center (what a Donald-Trump-sounding name) comes in two versions, the Standard, which will only process L1 GPS vectors, and the Advanced, which handles multi-frequency processing. The price I was quoted was about three grand, but I didn't know to ask which version was being quoted.
I got a quote from my local dealer in March: $2,995 for Advanced.
Cool. 🙂
I like GNSS Solutions but I haven't used it in a long time. Even TGO only processes the L1 only on shorter static vectors.
Kent
could you post your method for entering multiple OPUS solutions into Star*Net V6, please?
I am working on a project with my co-worker which has 4 primary control points, each of which has multiple 5+ hour static observations on different days. So far it is all GPS to aerial target panels but ultimately there will probably be some conventional ties to boundary monuments. My co-worker is doing the processing in Topcon Tools so far but eventually I will put it all into a Star*Net so we can keep adding observations in over time. It would be nice to use all of the OPUS solutions.
Kent
While you're waiting for Kent to chime in, you might want to look at Peter Lazio's excellent article on A Hybrid Covariance Matrix for Use with OPUS Solutions. I've never used it, but I keep it bookmarked for the day I finally have to wrap my brain around the concepts and put them to use.
Kent
> could you post your method for entering multiple OPUS solutions into Star*Net V6, please?
It is really just a cut-n-paste job with the xyz covariance matrix to create a GPS vector of nominal length = 0 (DX=0 DY=0 DZ=0) with the elements of the upper triangle of the covariance matrix that OPUS supplies used to fill in the covariances of the GPS vector.
That is, the standard covariance-weighted GPS vector in Star*Net looks like this:
.GPS WEIGHT COVARIANCE
.GPS FACTOR 2.5 VERT 5.0
.UNITS METERS
# BASE STATIONS USED in 11Day190a
#PID DESIGNATION LATITUDE LONGITUDE DISTANCE(m)
#DE6248 SGI1 SCHULTZ GROUP COOP CORS ARP N294315.169 W0980851.693 37050.1
#DJ7872 TXSE SEGUIN CORS ARP N293527.013 W0975951.834 44721.4
#DG5767 TXSM SAN MARCOS CORS ARP N295240.525 W0975409.649 12302.3
PH 10Day190a 29-59-17.34185 97-55-02.88662 182.398 ! ! !
G0 'V1 Day190a
G1 10Day190a-10 0 0 0
G2 0.0000031156 0.0000125200 0.0000103000
G3 0.0000003031 0.0000002430 -0.0000001044
The "#" comment lines are just to remind me of which reference stations were used in the solution. They aren't really necessary.
The blue GPS WEIGHT line is needed if you are mixing covariance-weighted vectors with other types in the adjustment. You don't need it if all the vectors are covariance-wieghted, but it doesn't hurt to throw it in.
The red line is just the NAD83 OPUS estimate of the position. If the mark is designated as, say, "10", I add a "DayNo" suffix if multiple OPUS solutions on the same point are to be used in the adjustment. The form of the adjustment is to treat the actual position of "10" as being tethered to the OPUS estimate "10Day190a" (in this case). Where there are multiple OPUS estimates on various days, the suffixes group them together in the output listing.
The orange line is is a zero-length vector, i.e. "10Day190a" is the same point as "10", but the coordinates of "10" are subject to adjustment. Those of "10Day190a" are merely one estimate of the coordinates of "10".
The green lines were extracted from the following covariance matrix that OPUS supplied:
Covariance Matrix for the xyz OPUS Position (meters^2).
0.0000031156 0.0000003031 0.0000002430
0.0000003031 0.0000125200 -0.0000001044
0.0000002430 -0.0000001044 0.0000103000
which is in the general form of variances and covariances:
XX XY XZ
YX YY YZ
ZX ZY ZZ
with the G2 and G3 lines being formed as follows
G2 XX YY ZZ
G3 YX YZ YZ
You can derive an appropriate scalar to apply to the OPUS-derived weights. The values of "GPS FACTOR" of 2.5 for horizontal components and 5.0 for vertical are empirically derived from summertime work in Central Texas. Elsewhere, your mileage may vary.
Kent
Thanks.
It looks like you have:
G2 XX YY ZZ
G3 YX XZ ZY
The Star*Net Manual should have the format too. I just don't have it here.
So you get a list of different positions for the same point? What do you tie your baselines to if you have more than one point 10?
Kent
> Thanks.
>
> It looks like you have:
> G2 XX YY ZZ
> G3 YX XZ ZY
Sorry for the typo. Make that:
G2 XX YY ZZ
G3 XY XZ YZ
> The Star*Net Manual should have the format too. I just don't have it here.
> So you get a list of different positions for the same point? What do you tie your baselines to if you have more than one point 10?
If you have more than one OPUS solution on Pt. 10, then you assign the different OPUS solutions names other than "10". I use related point names like "10a", "10b", "10c" or, better yet, names connected with the OPUS solution such as "10Day120" for the OPUS solution from Day 120. The position returned by OPUS is given the related point name and its coordinates are treated as fixed, i.e. weighted "! ! !" in the adjustment.
The floating point "10" (in this example) is connected to fixed OPUS points. Just as an example, let's call the three different OPUS solutions for Pt.10 "10Day120", "10Day121", and "10Day125". Each of them is supposedly Pt.10, so the vector from each to 10 is DX=0, DY=0, DZ=0, but with uncertainties described by the covariances.
So, if you generate three different GPS vectors from "10Day120", "10Day121", and "10Day125" to "10", the adjustment will estimate the position of "10" that is the least squares solution of "10". On the network plot, you'll see the adjusted vectors from each of the three OPUS solutions to "10" will have a length that represents the residual from the adjustment. Here is an example showing three different OPUS solutions on a Pt. 11. in the diagram below.
The baselines from Pt.11 connect to it, the adjusted point, not the fixed values of OPUS solutions, so the uncertainties in Pt.11 propagate to all points connected to it.
TGO ! Cheating allowed?
Just thinking out loud ...
I have no experience with the data format of rinex files ... but it's ascii.
Is it possible to change the time stamps in the Rinex files so they keep synchronised but with a valid time stamp that TGO will process??
chr.
TGO ! Cheating allowed?
Good thought. I don't work with RINEX files very much but Loyal Olsen does so maybe he can shed so light? I talked with my favorite Trimble Trainer and he assured me that Trimble was working on a solution. Let's hope they post a fix soon.
TGO ! Cheating allowed?
> I have no experience with the data format of rinex files ... but it's ascii.
> Is it possible to change the time stamps in the Rinex files so they keep synchronised but with a valid time stamp that TGO will process??
I don't know enough about the way carrier phase data is handled in a baseline processor to offer a definitive comment, but I believe that any workaround that alters observation times would be awfully complicated. You'd not only have to manipulate the observation files, but the orbit file(s) as well. My seat-of-the-pants assessment is that it's not a practical solution.
I see said the blind man
Thanks Kent, that makes sense.
I didn't notice before that you had a vector from Pt 10 to Pt 10day190. I saw the 0,0,0 part I just didn't see the vector which is obvious now that I see it. I see you have !!! for the fixed OPUS solution.
As a test of the reported problem, this afternoon I downloaded 24 hr dual frequency data sets in RINEX 2.11 format from Canadian Active Control points in Penticton (DRAO), Priddis (PRDS), and Saskatoon (SASK) observed yesterday (Friday September 16th).
I imported them into a TGO 1.63 project - note that TGO converts the RINEX files into DAT format during import.
I used the default GPS processing parameters to compute baselines. No problems. The processing worked flawlessly.
I have the software running on a Windows 7 Pro 64-bit system.
Seems like something else is going on here...
Can you try a second processing session? I processed two points from the 15th and it worked fine. Then after reading all the posts I tried to process a second set today (the data was also from the 15). It did not work. Each time I tried, the processor started working and would hang up and give me an error message. I also downloaded and ran all the latest "fix" programs from Trimble for v1.63 and that didn't help.
I tried again with 24-hour data from CORS LNC1 and P271 from the 15th. The WAVE processor hung and, when I checked a couple hours later, was still hung. I had to shut it down.
I'll try the Canadian data to see if I get different results.
Jim I'll try CORS data from the 15th and 16th.
I wonder if this is related to the recent NGS changes in the CORS data?
I always knew that Trimble was arrogant, I just never realized that they would be this arrogant. To think of all the money I've poured into Trimble all these years.
> I wonder if this is related to the recent NGS changes in the CORS data?
I'm going to guess not, Scott. I hit similar problems processing .dat files that I'd collected in the field. The problems began with the data from Day 257. Files from Day 256 and before processed just fine (using the WAVE 2.35a processor in GPSurvey), but nothing other than code phase solutions was possible with sessions from 257 or after.
The error logs indicated that the problem was with certain modules in the software. It wasn't the data.
I downloaded files for DRAO, PRDS and SASK for JD258, and all processed without incident.
The plot thickens...
I had data from the 15th, wouldn't process a L1 PPK session. Crap. If Trimble doesn't provide a free patch, bye bye Trimble. Ashtech, Leica, Topcon here I come.
Thanks, Jim. Looks like I'll be plugging away at learning Ashtech tomorrow. The field work on the 15th is due Monday. Helloooo Ashtech, Goodbye Trimble.