Activity Feed › Discussion Forums › Strictly Surveying › Geomax Zenith25 Pro Static obs help
Geomax Zenith25 Pro Static obs help
Posted by dtmmaps18 on June 9, 2020 at 2:48 pmI recently picked up a pair of Geomax GNSS receivers and am running them with Field Genius software. I am having trouble configuring them for static sessions. I can’t seem to find an easy solution. Please let me know if you have experience with these receivers.
The following is my continued testing:
Logging “GNSS Raw Data” in RINEX format from the FieldGenius menu did result in a Rinex v 3.02 file but OPUS is unable to process it. I tried a lot of file manipulations using Teqc and GFZRNX that included: ripping out all extra observations, reverting to Rinex 2.11, decimating to 30 seconds, and repairing, still no love from OPUS. Unfortunately, TrimbleRTX doesn’t support any Geomax receivers (I tried anyway). I seemed to be able to get a PPP solution from MagicGNSS, but it was my first time using the tool and I don’t have a lot of time to verify what is going on “under the hood”.
My GSM sim cards come in this week so I am hoping that the network will be easier to configure.
Thanks for looking.
bill93 replied 3 years, 10 months ago 6 Members · 16 Replies- 16 Replies
Interesting.
Could you post your RINEX file? (maybe before & after modification).
I really believe NGS (the programmer) is being lazy with their error reporting. They could give much better error messages with a little bit of coding.
I had to chop off the end (and changed the end of observation time in the header) of the original to get under the 5mb limit for RPLS upload. Otherwise, it is the same.
And yes @john-hamilton, OPUS error codes have always been either cryptic or vague, or both.
Not surprised that OPUS choked on this, although the C1 & L1 looks solid, there is NOWHERE near enough L2 data to process the file as dual frequency. The file would probably run fine in a single frequency processor.
Just my quick take on it.
Loyal
Does OPUS look at the approximate XYZ line in the RINEX file? It doesn’t seem to be anywhere near the US, so if it is used as a starting point there won’t be any CORS in range.
Where approximately was this?
.@john-hamilton. They have 2 basic messages- ??thy excrement is weak.? ??Thy is excrement is dubious.? You know, budgets and all….
As others have noted, the APPROX POSITION XYZ value is not written correctly. NRCAN’s Precise Point Positioning (PPP) service does process the data and arrives at a position:
- Lat 44?ø 46′ 27.5…”
- Long-122?ø 57′ 36.4…”
- Ellipsoid Height 138.584m
Another thing of potential concern is that there is no antenna height recorded in the file.
I would start with checking your versions of field software and antenna firmware. Generally I would expect if the field software was released AFTER the firmware, and the firmware is the latest/current release then we might be looking at a bug somewhere in either the firmware or field software.
Is there a native format option to log? Not sure what that might be for a Geomax Zentih25 and would require a conversion to RINEX but SHOULD be more reliable from a firmware point of view.
What happens if you edit the RINEX file and change the approx position to the values below, does OPUS process?
-2467501.9121 -3805414.8601 4469677.0211 APPROX POSITION XYZ
Jacob Wall- Posted by: @jacob-wall
-2467501.9121 -3805414.8601 4469677.0211 APPROX POSITION XYZ
OPUS processed it with that change. I had no idea what antenna type or antenna height to pick. Here it is in Dropbox.
The percent used and percent ambiguities fixed don’t look good at all.
FILE: Forum20200609.20o OP1591761659916
1009 WARNING! No antenna type was selected. No antenna offsets or
1009 pattern will be applied. Coordinates with reduced accuracy
1009 will be returned for the antenna phase center.
1009
NGS OPUS SOLUTION REPORT
========================
All computed coordinate accuracies are listed as peak-to-peak values.
For additional information: https://www.ngs.noaa.gov/OPUS/about.jsp#accuracy
USER: [email protected] DATE: June 10, 2020
RINEX FILE: foru159p.20o TIME: 04:02:30 UTC
SOFTWARE: page5 1801.18 master57.pl 160321 START: 2020/06/07 15:56:00
EPHEMERIS: igr21090.eph [rapid] STOP: 2020/06/07 20:42:00
NAV FILE: brdc1590.20n OBS USED: 727 / 998 : 73%
ANT NAME: NONE NONE # FIXED AMB: 3 / 7 : 43%
ARP HEIGHT: 0.001 OVERALL RMS: 0.014(m)
REF FRAME: NAD_83(2011)(EPOCH:2010.0000) ITRF2014 (EPOCH:2020.4336)
X: -2467501.681(m) 0.329(m) -2467502.601(m) 0.329(m)
Y: -3805414.484(m) 3.477(m) -3805413.256(m) 3.477(m)
Z: 4469677.032(m) 0.756(m) 4469677.036(m) 0.756(m)
LAT: 44 46 27.55898 1.932(m) 44 46 27.57115 1.932(m)
E LON: 237 2 23.54240 2.164(m) 237 2 23.47692 2.164(m)
W LON: 122 57 36.45760 2.164(m) 122 57 36.52308 2.164(m)
EL HGT: 138.278(m) 1.944(m) 137.905(m) 1.944(m)
ORTHO HGT: 161.377(m) 2.242(m) [NAVD88 (Computed using GEOID18)]
UTM COORDINATES STATE PLANE COORDINATES
UTM (Zone 10) SPC (3601 OR N)
Northing (Y) [meters] 4957881.699 126048.836
Easting (X) [meters] 503154.906 2305312.851
Convergence [degrees] 0.02808333 -1.74468889
Point Scale 0.99960012 0.99991814
Combined Factor 0.99957845 0.99989646
BASE STATIONS USED
PID DESIGNATION LATITUDE LONGITUDE DISTANCE(m)
DE6236 LPSB LANE CNTY COOP CORS ARP N440304.409 W1230524.248 81015.0
DH4503 P376 EOLARESVR_OR2004 CORS ARP N445628.315 W1230608.099 21682.9
DN2111 JIME JIM ELAM CORS ARP N453123.214 W1225925.841 83250.7. Thanks @Bill93 @jacob-wall @loyal !
This helps with this file. I have no idea why the receiver thought it was in Austria. I think I found some alternate collection methods after playing with the software more last night. Be safe out there.
I’m surprised that OPUS could (would) process a file with such limited L2 data, but NOT surprised by the lousy results. This is IMO a great example for the need to closely review the OPUS Report, and NOT to ASSUME that if OPUS can (will) process it, then it must be OKAY.
I’m somewhat at a lose to explain why the C1 L1 data looks solid, while the L2 data is so sporadic. I seem to recall (maybe erroneously) that the L2 signal is somewhat weaker than the L1 signal, but there is probably other factors involved in this observation/data set.
Loyal
- Posted by: @dtmmaps18
This helps with this file. I have no idea why the receiver thought it was in Austria.
Had the receiver not been on and hooked to an antenna for months, and then started recording the data as soon as it found satellites? If it had an almanac very seriously out of date, perhaps the approximate position was computed before updating the almanac.
The update takes at least 12.5 minutes of reception to complete (as much as 25 if the receiver can’t deal with starting midway through the list). Since the satellites orbit closer to a sidereal day than a solar day, that would mean their positions could be way off before update.
.
Log in to reply.