For the users of Trimble (who's business plan includes Trimble products for many years to come) TBC is a very good choice. It is a nice software. The feel is fresh and there are new and very useful features. And yes, the processor is probably better than the one in TGO.
And, I just found out from my rep that the TBC program is available to me for $1500, as an upgrade from TSO, until the end of the year. Sounds like a pretty good deal, considering what I've reviewed thusfar. It should be compatible with all of my existing equipment.
>who's business plan includes Trimble products for many years to come
Yes, that's the catch, as I see it. I'm not necessarily committed to Trimble, and don't want to be forced into future upgrades, or to be forced to buy Trimble equipment down the road.
One item of interest that came out when I attended the OPUS Projects class a couple of months ago was that NGS is working to make the OPUS suite of tools a replacement if you will for PP software. I don't know how true it is, BUT the NGS is under the impression that the various vendors would rather sell hardware and get out of the software business. The only reason they got into the GPS PP business to start with is the alternatives were limited with the exception of a few standalone products such as GrafNav. If the free OPUS suite goes mainstream we may see more hardware vendors get out of the software business. I think there are a few "newcomers" to the hardware game that don't even provide a PP solution so who knows, maybe in a few years we will all use OPUS Projects or buy GravNav, etc. from a 3rd party because the hardware vendors all stop software sales.
SHG
Don't forget GeoLab; it's been around since the TRANSIT days of WGS72. Still being upgraded, still supported.
John
I am curious. I ran a session in my backyard last weekend with a 4000ssi and 2 4400 receivers coupled to 2 TDC1's. Because of some trees some of the satellites had cycle slips. I used a method that Dario taught me to edit the rinex files so I could process the data in TGO even though it was after Sept 14, the day TGO died. One of the baselines had bad results but I was able to edit out the offending data and reprocess to get a good baseline. I then took the raw data and processed in TBC. TBC was able to process to a good baseline without removing the poor data. Out of curiosity I removed the same data I had removed in TGO then reprocessed. This time the TBC processor gave me a float solution rather than a good baseline. After reverting back to good baselines in TBC and comparing results with TGO I find a significant difference in coordinates of the points. Both TGO and TBC started processing at the same point with the same starting coordinates. Have you done any comparison processing between TGO and TBC? If you have what kind of differences are you seeing? The difference I found was about 1.3ft in N and E. I'm new to TBC so right now I'm assuming 1. I don't know what I'm doing in TBC or 2. My rinex editing is causing problems even though I get good baselines in TGO or 3. Both 1. and 2. are true.
John
Without knowing more about what you did, I can say that it is possible to edit out so much data that TGO doesn't know that the data is bad. For example, if you have a LONG baseline, and say 10 minutes of data, TGO will probably return a line with good stats, but actually off by one or more wavelengths (0.19 m). If it doesn't have enough satellites, something similar can occur. That is the only time I have known TGO to give a "false positive". So, I always go by the rule of a minimum of 15 minutes plus 1 minute for each km over 15.
Also, I never edit the data outside of TGO. If I want to remove a satellite or portions, I use the timeline in TGO to disable the noisy SV(s). I try to do that as little as possible. I prefer to raise the mask to 18 degrees.
I do not have enough experience yet with TBC to know if it has any possibility of false positives. That is one thing I liked about TGO, as long as you avoided the pitfall I describe above, the chances of a false positive were nearly zero. TGO did give more false negatives, but they could usually be fixed by editing or raising the mask. Worse case was to re-observe, which is better than giving out data that is bad that you think is good (which could result from a false positive if there wasn't enough redundancy in the network to detect it.
Geolab is not post processing software, it is a least squares adjustment package. And very good, I have been using it since 1986.
But, they do need to release a new version, the last was 2001. It has a few small bugs, nothing that affects the results, just some annoyances that can be expected with 10 year old software. For example, I can no longer view a network map since switching to Win7.
I have tried switching, to Star*Net, Columbus, and most recently to MOVE3. None of them are as rigorous, in my opinion. I thought Move3 was going to tip me, but it failed to impress me, after paying something like $150 for a limited time demo.
John
Thanks for the quick reply. The baselines were about 300ft and the dataset was 30 minutes. There were 7 SV to start with but I edited out 2 SV because of cycle slips. I used the timeline in TGO to edit the data. I might have given the impression that I edited the SV out of the rinex file. The only thing I edited in the rinex file had to do with date fields. If you recall a few weeks ago Dario posted how to do this.
I'm sure that it is something I am doing because I can't imagine there would be a 1.3ft diff between TGO and TBC.
Interesting on the various LS packages experience, I have always thought that both Move3 and Columbus to be more rigorous than Star*Net, although I think it is more widely used.
As mentioned, I use an OEM version of Move3 in LGO and am generally happy with that.
Of the three, I would be inclined to buy Columbus due to pricing and very good local support based here in Oregon.
I used to use GeoLab in the mid 1990's, but haven't touched it in years, sounds like it might still be about the same!
SHG
