Don,
Well, I set up this tripod myself, so if anyone has been straddling it, it would be me. But, generally in answer to your question - NO. Of course I was around tripod when I set it up, and maybe for a moment, just checking to see that everything still looked good, but aside from these relatively insignificant periods, I left it alone to do its thing.
Why do you ask?
Al
> To your knowledge, has anyone been straddling the tripod?
>
> Don
"Why do you ask?"
Just being silly, sorry
Don
Sorry, I didn't get that. Cheers!
Al, if I remember correctly, the column of 1's hold some important information. I don't remember what each number represents but I do remember that 1 and 5 are bad. When we wrote our in-house GPS editing tools, we added a step that asks if you want to delete these observations. I think it is loss of lock.
From the OPUS website:
OPUS Processor down OPUS processor is under maintenance.
OPUS website is functional. Your submissions will be queued.
They are processed once OPUS processor back running.
Thank you David. I tried to figure out what the observation values mean, but couldn't figure out the details from the explanation given in the RINEX format specification.
In the example which I submitted, the first line lists the year, month, day, hour, minute, and second of the observation set. Then the epoch flag (0, indicating OK). Then, in the same line, the total number of satellites observed, and their identification (corresponding to each of the observations - one line per satellite).
Still, the code for the observations is bewildering. Maybe the column of "1"'s is Loss of Lock Indicator? Maybe Signal Strength. What is the meaning of m(F14.3,I1,I1)? There appear to be four records expressing a measured value. Do these correspond to Phase L1, Code L1, Phase L2, and Code L2?
Al
+-------------+-------------------------------------------------+------------+
|OBSERVATIONS | - Observation | rep. within record for | m(F14.3, |
| | - LLI | each obs.type (same seq | I1, |
| | - Signal strength | as given in header) | I1) |
| | | |
| | If more than 5 observation types (=80 char): | |
| | continue observations in next record. | |
| | | |
| | This record is (these records are) repeated for | |
| | each satellite given in EPOCH/SAT - record. | |
| | | |
| | Observations: | |
| | Phase : Units in whole cycles of carrier | |
| | Code : Units in meters | |
| | Missing observations are written as 0.0 | |
| | or blanks. | |
| | | |
| | Phase values overflowing the fixed format F14.3 | |
| | have to be clipped into the valid interval (e.g.| |
| | add or subtract 10**9), set LLI indicator. | |
| | | |
| | Loss of lock indicator (LLI). Range: 0-7 | |
| | 0 or blank: OK or not known | |
| | Bit 0 set : Lost lock between previous and | |
| | current observation: cycle slip | |
| | possible | |
| | Bit 1 set : Opposite wavelength factor to the | |
| | one defined for the satellite by a | |
| | previous WAVELENGTH FACT L1/2 line.| |
| | Valid for the current epoch only. | |
| | Bit 2 set : Observation under Antispoofing | |
| | (may suffer from increased noise) | |
| | | |
| | Bits 0 and 1 for phase only. | |
| | | |
| | Signal strength projected into interval 1-9: | |
| | 1: minimum possible signal strength | |
| | 5: threshold for good S/N ratio | |
| | 9: maximum possible signal strength | |
| | 0 or blank: not known, don't care | |
+-------------+-------------------------------------------------+------------+
The RINEX header shows the order in which the observables appear.
In your file the order from left side is -
C1 - pseudorange using C/A on L1
L1 - phase measurement on L1
L2 - phase measurement on L2
P2 - pseudorange using P-Code on L2
One tip - pseudoranges will never be negative AFAIK.
The loss-of-lock indicator (LLI) is the integer in the fourth column to the right of the decimal point. For the epoch you showed, this column is blank for the L1 data so there was no loss of lock on L1 in this epoch. The "4" (bit 2 set - binary 100) in that column for L2 data indicates antispoofing is on, which is normal.
The signal-strength indicator is the integer in the fifth column to the right of the decimal point, but since it is simply the range from minimum possible to maximum possible it is not worth much at this point.
I reviewed a few other RINEX files and they do not have consistent 1s (indicating lowest possible signal strength) in the L1 signal-strength column. The other RINEX files (none from 4000-series receivers) I looked at all had consistent values of 5 or higher in that column except when a satellite was just coming into the set. This is a receiver-reported value so it may or may not indicate a problem. It would be interesting to see what a file from your other receiver shows.
Offhand I cannot remember actually seeing signal-to-noise ratio (SNR) in any postprocessing results.
SNR is calculated by the receiver on an epoch-by-epoch basis and is displayed by the Survey Controller data-collector software and other programs. I am sure Kent McMillan or Jim Frame knows if an older version of GPS Configurator or another free-for-download Trimble utility will show the SNR from a 4000-series receiver.
Where I saw SNR most often from the 4000-series receivers was on the screens of reference-station software such as Trimble Reference Station and GPSBase. Some of the very low SNRs in those cases may have been due to excessively long GPS-antenna cables with lossy lightning protectors in the circuits.
GB
Al
Christof sent me this link a short time ago when we were dealing with Rinex files. It might help you.
http://gage14.upc.es/gLAB/HTML/GPS_Navigation_Rinex_v2.11.html
I've got some study ahead of me. Thank you for that link!
FWIW, I loaded the DAT file into TBC 2.60 and processed it against NYHS, a CORS that's about 27 km northwest of the occupied station. The vector processed normally, with the exception of an antenna model problem unrelated to the DAT file (see related post). I got a fixed solution with stated accuracies (take with a grain of salt) of 0.007 m horizontal and 0.029 vertical. The session was a little over 2.5 hours long.
Glenn,
Thank you very much for your post. The explanatory information is very helpful to me in understanding the RINEX file format.
I see what you mean about the number and types of observations being in the header
4 C1 L1 L2 P2 # / TYPES OF OBSERV
and how that corresponds to the observation values that follow.
I also see how the fourth column after the decimal is blank on the L1 data, and that the fifth column after the decimal consistently contains a "1" associated with the L1 data. I have not performed any observations yet with my other SSi receiver, but when I do, I will evaluate whether that receiver also consistently generates a "1" in the fifth column for the L1 data.
Is it correct to state that all four of the observation values are proportional to distance, and that when the the magnitude of the value (to the left of the decimal point) is small, the satellite is closer, and that when the magnitude of the value is large, the satellite is farther away? If that is correct, is it also generally true (assuming no obstructions) that the strength of the signal is inversely proportional to the distance between the satellite and the antenna?
Thanks again, Glenn!
Sounds like a pretty good solution....
Just submitted again to OPUS. This time, it seems the data went through!
But, got an error message, below.
Do I need to strip out the few observations that include values for L1 only, like at the beginning of the observation set? What other sorts of pre-processing might I need to do in order to achieve a file which is acceptable for OPUS?
Al
FILE: 86462740.11o 000323966
1007 The RINEX dataset submitted to OPUS failed to pass an initial
1007 test for one or more of the following reasons.
1007 1. The data only contained values for a single frequency.
1007 2. RINEX file not formatted correctly.
1007 3. One of the lines in the RINEX file is over 80 characters
1007 in length.
1007
Now it's time for TEQC
Go over to the UNAVCO web site and download TEQC.
From a command prompt, run TEQC's "verify" command on your RINEX file as follows:
[inlinecode]teqc +v {filename}[/inlinecode]
There's a good chance the information that appears will point you right to the line where the (first) problem exists. It can be something as small as a line starting one column off, a missing (or extra) carriage return/linefeed at the end of the file, or the like.
You're getting a good education - hang in there!
GB
The signal-to-noise-ratio information is in the DAT file
The SNR data for each satellite at each epoch is in your DAT file and TEQC can extract it.
For instance, to make a RINEX observations file with only the SNRs just for inspection (no pseudorange or phase observables so such a file cannot produce a position) you could open a command line and execute -
[inlinecode]teqc -tr d -O.obs S1+S2 86462740.dat > SNR.11o[/inlinecode]
Or, if you would like a more usable RINEX observations file that could actually go to OPUS as well as display the SNR information, you could execute -
[inlinecode]teqc -tr d -O.obs C1+L1+L2+P2+S1+S2 86462740.dat > 86462740.11o[/inlinecode]
The output-file names were more for convenience than anything - assign your own as appropriate.
GB
Now it's time for TEQC
Glenn:
I figured out how to install TEQC. I guess it is assumed at UNAVCO that someone who is used to the Windows GUI would know to install the teqc.exe file at c:WINDOWSsystem32 so that the program can be called from any directory at the DOS command line. I looked for some time before I figured this out, ultimately through the following web page:
After figuring that out, it was pretty easy to run the program as you described, though its going to take some time for me to understand how to create the more complex commands like that on my own...
My RINEX file appears to be OK. I get the message "teqc: '86462740.11o' readable as RINEX V.2.11 format". No other message is displayed.
I also created the SNR.11o file as you described. I see from the RINEX format that S1 and S2 correspond to the raw signal strength or SNR for L1 and L2. I note that the values for S1 and S2 range from about 2 to about 32, and I assume that the values in the single digits reflect observations where signal strength was not good. However, there is no indication from review of this resulting file that the signal strengths are any worse for L1 than for L2.
By the way, I got a response back from OPUS on a submission that I had made earlier today.
"OPUS aborting: 86462740.dat"
"OPUS could not process the data file that was submitted. The data was either very noisy or it was collected in kinematic mode."
And another response, this one resulting from a submission to OPUS-Rapid Static:
"OPUS-RS aborting: 86462740.11o"
"The RINEX dataset submitted to OPUS failed to pass an initial test for one or more of the following reasons.
1. The data only contained values for a single frequency.
2. RINEX file not formatted correctly.
3. One of the lines in the RINEX file is over 80 characters in length."
I've been thinking about those columns of 1s for the L1 signal, how it never varies for any of the observations, whereas for the L2 observations, the magnitude of this fifth column past the decimal point varies according to signal strength. Putting aside the apparent fact that OPUS was down over the weekend, it appears to be up and running again, but I'm still having trouble. Could it be that the lack of signal strength information for L1 in the RINEX file is causing these error messages?
Thanks for your encouragement!
Al
OPUS_RS Solution
I just now got a solution from the OPUS_RS submission that I made sometime yesterday. It doesn't look too bad to me, but I don't know squat about OPUS_RS.
SOFTWARE: rsgps 1.35.1 RS40.prl 1.71 START: 2011/10/01 19:22:15
EPHEMERIS: igr16556.eph [rapid] STOP: 2011/10/01 20:24:00
NAV FILE: brdc2740.11n OBS USED: 5121 / 5706 : 90%
ANT NAME: TRM22020.02 TCWD QUALITY IND. 21.37/ 40.27
ARP HEIGHT: 1.356 NORMALIZED RMS: 0.278
REF FRAME: NAD_83(CORS96)(EPOCH:2002.0000) ITRF00 (EPOCH:2011.75022)
X: 1348632.892(m) 0.007(m) 1348632.109(m) 0.007(m)
Y: -4539264.158(m) 0.022(m) -4539262.734(m) 0.022(m)
Z: 4258795.888(m) 0.018(m) 4258795.817(m) 0.018(m)
LAT: 42 9 29.91730 0.004(m) 42 9 29.95014 0.004(m)
E LON: 286 32 48.79540 0.003(m) 286 32 48.78037 0.003(m)
W LON: 73 27 11.20460 0.003(m) 73 27 11.21963 0.003(m)
EL HGT: 209.550(m) 0.029(m) 208.325(m) 0.029(m)
ORTHO HGT: 239.982(m) 0.031(m) [NAVD88 (Computed using GEOID09)]
UTM COORDINATES STATE PLANE COORDINATES
UTM (Zone 18) SPC (2001 MA M)
Northing (Y) [meters] 4668511.488 880500.900
Easting (X) [meters] 627793.093 38604.638
Convergence [degrees] 1.03838235 -1.31196160
Point Scale 0.99980095 0.99996482
Combined Factor 0.99976809 0.99993196
US NATIONAL GRID DESIGNATOR: 18TXM2779368511(NAD 83)
BASE STATIONS USED
PID DESIGNATION LATITUDE LONGITUDE DISTANCE(m)
DI0466 NYHS HUDSON CORS ARP N421508.359 W0734527.160 27224.8
DH5839 CTWI WINCHESTER CORS ARP N415351.907 W0730410.968 42962.9
DI0468 NYKT KINGSTON NY CORS ARP N415612.971 W0740152.218 53805.3
DH5829 CTEG EAST GRANBY CORS ARP N415524.347 W0724155.881 67682.0
DH5825 CTBR BROOKFIELD CORS ARP N412949.864 W0732505.674 73489.6
DI0470 NYLC LAKE CARMEL CORS ARP N412851.876 W0733905.369 77006.7
DH7113 CTNE PAQUETTE CORS ARP N414024.717 W0724252.252 81571.3
DK7181 NYNB NEWBURGH CORS ARP N412942.806 W0740131.973 87668.5
DK7175 NYCS COBLESKILL CORS ARP N424002.836 W0742910.948 102140.1
It uses the first hour (or so) of "clean data" in the file.
I also got a crappy OPUS_Static result today, I will have to find it though.
Loyal
OPUS_Static Solution
Well...here it is. About as skanky as I have seen in a while.
SOFTWARE: page5 1108.09 master4.pl 0825113 START: 2011/10/01 19:22:00
EPHEMERIS: igr16556.eph [rapid] STOP: 2011/10/01 23:58:00
NAV FILE: brdc2740.11n OBS USED: 7469 / 7823 : 95%
ANT NAME: TRM22020.02 TCWD # FIXED AMB: 30 / 48 : 63%
ARP HEIGHT: 1.356 OVERALL RMS: 0.015(m)
REF FRAME: NAD_83(2011)(EPOCH:2010.0000) IGS08 (EPOCH:2011.7504)
X: 1348632.933(m) 0.054(m) 1348632.133(m) 0.054(m)
Y: -4539264.152(m) 0.040(m) -4539262.722(m) 0.040(m)
Z: 4258795.893(m) 0.052(m) 4258795.855(m) 0.052(m)
LAT: 42 9 29.91730 0.067(m) 42 9 29.95116 0.067(m)
E LON: 286 32 48.79719 0.048(m) 286 32 48.78152 0.048(m)
W LON: 73 27 11.20281 0.048(m) 73 27 11.21848 0.048(m)
EL HGT: 209.558(m) 0.009(m) 208.347(m) 0.009(m)
ORTHO HGT: [Geoid Model Not Yet Available w/ NAD83 (2011).]
UTM COORDINATES STATE PLANE COORDINATES
UTM (Zone 18) SPC (2001 MA M)
Northing (Y) [meters] 4668511.488 880500.898
Easting (X) [meters] 627793.134 38604.679
Convergence [degrees] 1.03838268 -1.31196126
Point Scale 0.99980095 0.99996482
Combined Factor 0.99976809 0.99993196
US NATIONAL GRID DESIGNATOR: 18TXM2779368511(NAD 83)
BASE STATIONS USED
PID DESIGNATION LATITUDE LONGITUDE DISTANCE(m)
DI0440 NYAB ALBANY CORS ARP N424248.873 W0734858.501 68537.5
DH5829 CTEG EAST GRANBY CORS ARP N415524.347 W0724155.881 67682.0
DI0468 NYKT KINGSTON NY CORS ARP N415612.971 W0740152.218 53805.3
Why this is so bad beats me, but further analysis is in order.
BTW, the OPUS_Static solution is NAD83(2011) whereas the OPUS_RS solution is NAD(CORS96).
Loyal
OPUS_Static Solution
Thanks Loyal. I agree. Pretty bad for a 4 hour session without obstructions. Did you submit at DAT file or a .11o file? If the latter, does your file contain 1's in the fifth column after the decimal point for the L1 observables? I couldn't get as far as you did.
OPUS_Static Solution
Big Al,
All that I did was decimate the RINEX to 30 seconds, and trim out the first few minutes of "incomplete" data.
If I have some time tomorrow, I'll get an extended output solution, and that "might" tell us a little more.
Loyal
