Does anyone have a workflow or tutorial to postprocess a rtk survey made with a RS2 BASE and ROVER setup on CHC Geomatics Office 2?
I can process my base against a Cors base, my rover against the same Cors but cannot get any solution between the base and Rover.
Thanks in advance.
I have a copy, bought the software about a year ago. I’ve played around with it on a couple of occasions, although I haven’t lately.
We bought “Javad Justin” software about 3 years ago, it’s a good workhorse for PP. I upgraded to “Javad Justin 3”. This is what I use about 3 times a week verifying RTK and PP static observations. It’s got a pretty steep learning curve, but in my opinion it’s a top of the line processor and better than OPUS PAGES software as well as Trimble office… I’ve PP 1 minute @ 1sec intervals in high multi-path area (oak woods in summertime) just as a test on various projects… It’s amazing how the software can pick out the good signals with 1 minute of data. It literally used about 75% of the 1 minute observation for a “fix” solution with baseline residual of 3cm horizontal, 2cm vertical. Verified the computed position using terrestrial traverse loop, < 3cm difference, both in horizontal/vertical. Of course the baselines to the M2 bases were approx 500m away. Loop closure exceeded 1: 200 000. Pretty good software.
CHC seems to have a fairly good processor, however experimenting with it I’m having issues understanding exactly how the geoids are used. Computing a 30 minute observation on a passive NGS station, horizontal fit well (<5 cm) however elevation was off about a foot; nearest CORS was about 30km away. I was also using/learning “Javad Justin” at the same time. I had small project to verify with both processors, never could get CHC computed elevations to agree even with ties to passive control . I had to drop using CHC in favor of Justin software for the time being.
I need to get back in CHC to figure the problem out, but haven’t the time due to work. The cost was about $600 if I remember correctly, bought from IGAGE. I bought it to have a backup processor and to also process native .UBX files, it imports them fine… I think it’s a good processor but i just need time to resolve the vertical issue.
1 Like
Apparently there is a problem with processing u-blox files (Emlid) with CHC Geomatics Office 2 according to Mark Silver with iGage.com I just learned tonight when I was going to link to Mark’s training videos on CHC GO2. The notice was not there as of a couple of days ago.
From his website:
"CHCNav CGO2 (CHC Geomatics Office Version 2.0)
Important note regarding the processing observation files collected using u-blox based receivers:
While CGO2 directly supports importing and processing u-blox sourced observation files (*.ubx), we have found that results are nearly always disappointing. While you are welcome to purchase and use CGO2, from iGage, for use with u-blox files, we will not support this application. If you contact us requesting support for u-blox files that do not work, we will not help you.
Additionally, we will not accept CGO2 product returns related to CGO2’s use with u-blox receivers or derived files."
1 Like
I’ll try and find time this week to look into this further. I’m convinced now by your comments that there may be something wrong using native .UBX. Mark Silver could have at least emailed all his customers who bought it. I won’t buy anything from him again.
If Ublox would just develope their own converter to rinex like all the rest major GNSS manufacturers there wouldn’t be any issues. I bet no one there probably can’t understand their own proprietary format. Oh, that’s right. … Ublox is made for consumer devices, not professional Geodesist/Land Surveyors. I think Ublox dropped the ball on this one.
This reminds me about Astech’s GNSS Solutions software. There was an issue applying instrument heights to each point, elevation issue also. There was a workaround, but you had to physically apply the instrument heights to each point before processing. I believe it had to do with the “0” antenna heights using CORS when importing/processing. It was a pain if you had 20+ stations to process.
Trimble Office is just too damn expensive to use for what we do. There are other alternatives. We used Trimble Geomatics in the early days and it was free with equipment purchase with free updates. It was an excellent processor. However, their “planned” ending of the software was it for me. No more Trimble products.
We were all about Trimble until we jumped ship and went to Javad about 6 years ago. Now we are all Javad and glad for it. Light years ahead of any GNSS manufacturers. Read the history of Javad, he designed the algorithms, receivers and software at the beginning days of Trimble; one of the true GNSS geniuses we can all be thankful to.
2 Likes
Bryan, I agree that it is puzzling that U-blox didn’t produce a native .ubx to Rinex convertor. Though, from Mark’s statements, it sounds like CGO2 would have had problems even with the .ubx file converted to a Rinex File.
Unfortunately, I just purchased this software this past Monday, before this notice came out. I did download the software and asked for the 30-day demo, but I ran out of time to do much testing on the program before the 30-day expiration occurred over the holidays. I did run a test solution, but it was with a Javad LS receiver and that worked fine. Hopefully, CHC will find a solution for their software to be compatible with U-blox files in the future. I was trying to find a less costly solution for post processing multiple baselines. I will look into the Javad Justin 3 software later this year. EZSurv GNSS Post-Processing software looks to be quite capable, but at $6,130.00 for the EZSurv L1/L2 open license that would be too expensive for me vs Javad’s cost of $2,490.00.
I have read the Javad history, which is quite impressive, and the man was quite the GNSS genius, too bad about his early passing.
Regards, Mark
1 Like
This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.