Changeset 11066 in ntrip for trunk/BNC/src/bnchelp.html
- Timestamp:
- Oct 5, 2026, 12:31:32 PM (25 hours ago)
- File:
-
- 1 edited
-
trunk/BNC/src/bnchelp.html (modified) (8 diffs)
Legend:
- Unmodified
- Added
- Removed
-
trunk/BNC/src/bnchelp.html
r11064 r11066 147 147 2.8.2 <a href="#corrint">Interval</a><br> 148 148 2.8.3 <a href="#corrport">Port</a><br> 149 2.8.4 <a href="#ssrqc">QC Logfile, QC Interval</a><br> 149 150 2.8.4 <a href="#corrwait">Wait for Full Corr Epoch</a><br> 150 151 2.9 <a href="#syncout"><b>Feed Engine</b></a><br> … … 4997 4998 falls back to using ANTEX-based satellite antenna corrections instead. 4998 4999 </p> 5000 <p> 5001 <b>SSR epoch times:</b> In IGS-SSR, the SSR Epoch Time (IDF003) of all GNSS is given in GPS seconds of week. In 5002 RTCM-SSR, the GLONASS epoch time (DF386) is given in GLONASS time (UTC+3h) as seconds of day, the BDS epoch time 5003 (DF465) in BDT. Some encoders use other conventions for IGS-SSR. BNC recognises them by comparison with the GPS or 5004 Galileo epoch of the same stream, converts the epochs and writes a warning to the logfile at most once per hour 5005 per stream and system: 5006 </p> 5007 <ul> 5008 <li>'IGS-SSR GLONASS epoch time in outdated convention (UTC seconds of day ...)': the convention of older BNC 5009 versions; the SSR encoder should be updated.</li> 5010 <li>'IGS-SSR GLONASS epoch time erroneously encoded (UTC seconds of week ...)': UTC instead of GPS time; the SSR 5011 encoder should be corrected.</li> 5012 <li>'IGS-SSR BDS epoch time in outdated convention (BDT ...)': BDT instead of GPS time; the SSR encoder should be 5013 updated.</li> 5014 </ul> 5015 <p> 5016 In addition, the orbit and clock epochs of all systems of a stream, converted to GPS time, are compared with the 5017 latest GPS orbit and clock epoch of the same stream. A difference of more than 120 seconds points to another 5018 erroneous encoding and is reported as 'X SSR epoch time ... differs by ... s from the GPS SSR epoch time of the 5019 stream - erroneously encoded?'. Such epochs are not converted. Code and phase biases are not checked, as they may 5020 be sent with the epoch of their last update. 5021 </p> 4999 5022 5000 5023 <p> … … 5032 5055 <p><img src="IMG/Figure17.png" width=1000 /></p> 5033 5056 <p>Figure 17: Example for pulling, saving and output of Broadcast Corrections using BNC</p> 5057 5058 <p> 5059 <h4 id="ssrqc">2.8.4 QC Logfile, QC Interval - optional</h4> 5060 </p> 5061 <p> 5062 BNC can check the quality of all Broadcast Correction streams it decodes, in real time or when reading a raw file 5063 ('--file'). Specify the full path to a 'QC Logfile' to activate this function, and select the 'QC Interval' for 5064 the reports (default: 1 hour). At the end of each interval and at the end of the program, a report is written per 5065 stream and system. Broadcast ephemerides must be received as well, e.g. via stream 'BCEP00BKG0'. 5066 </p> 5067 <p> 5068 A table lists per system and message type (ORBIT, CLOCK, CODE_BIAS, PHASE_BIAS): 5069 </p> 5070 <ul> 5071 <li>the number of epochs,</li> 5072 <li>the update interval as declared in the messages (SSR Update Interval), the median and the maximum of the 5073 actual intervals,</li> 5074 <li>the number of gaps, i.e. intervals longer than twice the larger of declared and median interval,</li> 5075 <li>the number of epochs older than the previous one (out of order),</li> 5076 <li>the latency, median and maximum, i.e. the time of the decoded output minus the epoch time. Note that BNC 5077 passes on the corrections of an epoch when the next epoch arrives; the latency therefore includes one update 5078 interval. When reading a raw file, the times of the file are used,</li> 5079 <li>the number of satellites.</li> 5080 </ul> 5081 <p> 5082 It is followed by the findings per system, only lines with findings are listed: 5083 </p> 5084 <ul> 5085 <li>a declared update interval differing from the actual one (BNC uses it e.g. to detect outdated 5086 corrections),</li> 5087 <li>satellites with a healthy, current broadcast ephemeris without orbit corrections, clock corrections, code 5088 biases or phase biases (the latter two only if the stream provides them for the system),</li> 5089 <li>orbit and clock corrections referring to an IOD of no received broadcast ephemeris, to an unhealthy 5090 broadcast ephemeris, or to a satellite without broadcast ephemeris (number of corrections in brackets),</li> 5091 <li>the code bias signals provided, satellites without code biases of the reference signals (GPS C1W/C2W, GLONASS 5092 C1P/C2P, Galileo C1C/C5Q, BDS C2I/C6I, QZSS C1C/C2L), and the standard deviation and maximum of the 5093 ionosphere-free combination B_IF of the reference signal biases. A B_IF varying between the satellites is 5094 legitimate if the clocks are estimated with other signals, but must then be consistent with the clocks 5095 (see section 'Combination'),</li> 5096 <li>clock jumps, i.e. clock changes between consecutive epochs (same IOD) beyond the clock rate of more than 5097 0.5 m,</li> 5098 <li>the largest radial and along-/cross-track orbit corrections. Their size mainly reflects the quality of the 5099 broadcast ephemerides; a value differing from that of other streams for the same satellite points to a 5100 problem of the stream.</li> 5101 </ul> 5102 <p> 5103 Example: 5104 </p> 5105 <pre> 5106 Stream SSRA00GMV0 5107 Sys Type Epochs Interval nom/med/max [s] Gaps Out-of-order Latency med/max [s] Sats 5108 G ORBIT 47 1 / 5.0 / 5.0 0 0 11.0 / 12.0 32 5109 ... 5110 G ORBIT: declared update interval 1 s, actual 5.0 s 5111 G corrections referring to an IOD of no received broadcast ephemeris: G10(94) G22(94) G29(94) 5112 G code bias signals: 1C 1P 1W 2L 2P 2S 2W 5Q 5113 G ionosphere-free combination B_IF of the reference signal biases: std. dev. 0.586 m, max |B_IF| 2.058 m (32 satellites) 5114 G largest orbit corrections: radial 1.06 m (G11), along/cross 2.05 m (G11) 5115 </pre> 5116 <p> 5117 Errors in the encoding of the SSR epoch times are reported by the decoder itself in the BNC logfile (see section 5118 'Broadcast Corrections'). 5119 </p> 5034 5120 5035 5121 <p> … … 6173 6259 Default value for 'ANTEX file' is an empty option field, meaning that you do not want to correct observations for 6174 6260 Antenna Phase Center offsets and variations. 6261 </p> 6262 <p> 6263 A satellite PRN is reassigned to new satellites over time, therefore an ANTEX file contains several entries per 6264 PRN with their validity ('VALID FROM' / 'VALID UNTIL'). BNC uses the entry valid at the epoch processed, so that 6265 the same ANTEX file can be used for current and for older data. At startup, BNC logs the ANTEX file name, the 6266 number of receiver and satellite antenna entries and the latest satellite entry, e.g. 6267 </p> 6268 <pre> 6269 ANTEX file Input/igs20.atx: 515 receiver and 405 satellite antenna entries, latest satellite entry R26 valid from 2026-09-26 6270 </pre> 6271 <p> 6272 The date of the latest satellite entry identifies the version of the file. Use the current IGS ANTEX file and update 6273 it promptly when new satellites are announced, ideally at the same time as the providers of the corrections, as 6274 their orbits and clocks refer to the antenna offsets of their own ANTEX file. 6275 If there is no satellite antenna entry valid at the epoch for a satellite, e.g. a new satellite in an outdated 6276 ANTEX file, its observations are not corrected for the satellite antenna offset and the message 6277 'ANTEX: no satellite antenna entry valid at ... - ANTEX file outdated?' is written to the PPP logfile, at most once 6278 per hour and satellite. 6175 6279 </p> 6176 6280 <p> … … 7916 8020 Hence, the ionosphere-free linear combination of code biases for the IGS reference signals is determined 7917 8021 from the supplied code biases and subtracted from the clocks before combination. 8022 This requires the code biases of both reference signals of a system. If an AC provides none or only one of them 8023 for a satellite, its clock cannot be referred to the reference signals. It is still combined, but, as long as 8024 other ACs provide referred clocks for this satellite, it is excluded from the clock datum like the clocks of an AC 8025 with inconsistent biases (see below): its satellite offset absorbs the difference, and the combined clock is 8026 defined by the referred clocks only. The message '... provides no code biases for the ... reference signal(s) 8027 ...' naming the missing signal(s) is written to the logfile at most once per hour per AC and system. 7918 8028 The combined satellite clocks are consistent to IGS clocks, which means ionosphere-free clocks based on the defined 7919 8029 reference signals … … 7931 8041 </p> 7932 8042 <p> 7933 In the combination (method 'Filter') such errors are absorbed by the satellite-specific clock offsets estimated 7934 for each AC, which consequently follow B_IF of that AC from satellite to satellite. BNC uses this to check the 7935 consistency, separately for each AC and system: 8043 In the combination (method 'Filter') such errors show up in the satellite-specific clock offsets estimated for 8044 each AC, which consequently follow B_IF of that AC from satellite to satellite. As the offsets of all ACs of a 8045 satellite are constrained to sum up to zero, they absorb only part of the error: with N ACs, the offset of the 8046 inconsistent AC takes up about (N-1)/N of it, while about 1/N goes into the combined clock. BNC uses the offsets 8047 to check the consistency, separately for each AC and system: 7936 8048 </p> 7937 8049 <ul> … … 7952 8064 <pre> 7953 8065 bncComb: BKG E code biases (C1C/C5Q) seem inconsistent with its clocks: satellite offsets follow the bias 7954 combination B_IF (27 satellites, B_IF spread 0.084 m, slope 0.60, correlation 0.88) 8066 combination B_IF (27 satellites, B_IF spread 0.084 m, slope 0.60, correlation 0.88), AC excluded from the clock datum 7955 8067 </pre> 7956 8068 <p> 7957 The AC is still used in the combination, its offsets absorb most of the error. Nevertheless, the code biases 7958 sent out by this AC should be corrected by its provider: either biases estimated together with the clocks 7959 should be used, or the external biases have to be aligned to the clocks per satellite (b' = b - B_IF of the 7960 reference signals, SSR sign convention). The check is not applied with the 'Single-Epoch' method. 7961 </p> 8069 Such an AC is therefore excluded from the clock datum of the respective system: its satellite offsets are no 8070 longer part of the zero-sum conditions (their own sum is constrained to zero instead), and the satellite offsets 8071 of all ACs of this system are re-initialized. The combined clocks are then defined by the consistent ACs only, 8072 while the offsets of the excluded AC take up its error completely (a regression slope of about 1 at the 8073 following checks). The AC is still used in the combination: it contributes its epoch-wise clock variations and 8074 is counted for the minimum of 2 ACs per satellite. A satellite observed by excluded ACs only is combined with 8075 the zero-sum condition of all its ACs as before, and if no consistent AC provides corrections for a system, the 8076 exclusion is not applied. The checks continue: as soon as a check finds no inconsistency any more (or B_IF no 8077 longer varies noticeably between the satellites, e.g. after the provider has aligned its biases), the AC is 8078 used for the clock datum again, which is reported in both logfiles. A smaller weight factor of the AC would not 8079 help instead: the weights act on the epoch-wise clock variations, while the satellite-specific constant part is 8080 fixed by the zero-sum conditions, independent of the weights. 8081 </p> 8082 <p> 8083 Nevertheless, the code biases sent out by this AC should be corrected by its provider: either biases estimated 8084 together with the clocks should be used, or the external biases have to be aligned to the clocks per satellite 8085 (b' = b - B_IF of the reference signals, SSR sign convention). The check is not applied with the 'Single-Epoch' method. 8086 </p> 8087 <p> 8088 <b>Persistent outliers:</b> 8089 A clock correction whose residual exceeds 'Maximal Residuum' is rejected as outlier. If an AC's clock for a single 8090 satellite differs persistently from those of the other ACs, its satellite offset cannot absorb the difference, since 8091 the offsets of all ACs of a satellite sum up to zero, and the correction is rejected again in every epoch. This 8092 protects the combined clock, but it is worth to be reported to the AC. Therefore, once per hour and system, BNC 8093 reports all AC satellites rejected in at least half of their epochs of the last hour (minimum 10 epochs), in the 8094 combination logfile and in the BNC logfile, e.g. 8095 </p> 8096 <pre> 8097 bncComb: SHA G26 rejected as outlier in 99% of 720 epochs in the last hour (median residual 1.08 m) 8098 </pre> 7962 8099 <p> 7963 8100 This convention allows the ionosphere-free linear combination of the two OSBs of the reference signals to be set to … … 9267 9404 If you do not specify an ANTEX file, the SP3 file will contain orbit information which is referred to Antenna Phase 9268 9405 Center (APC) instead of CoM. 9406 </p> 9407 <p> 9408 A satellite PRN is reassigned to new satellites over time, therefore an ANTEX file contains several entries per 9409 PRN with their validity ('VALID FROM' / 'VALID UNTIL'). BNC uses the entry valid at the epoch processed, so that 9410 the same ANTEX file can be used for current and for older data. At startup, BNC logs the ANTEX file name, the 9411 number of receiver and satellite antenna entries and the latest satellite entry, e.g. 9412 </p> 9413 <pre> 9414 ANTEX file Input/igs20.atx: 515 receiver and 405 satellite antenna entries, latest satellite entry R26 valid from 2026-09-26 9415 </pre> 9416 <p> 9417 The date of the latest satellite entry identifies the version of the file. Use the current IGS ANTEX file and update 9418 it promptly when new satellites are announced, ideally at the same time as the providers of the corrections, as 9419 their orbits and clocks refer to the antenna offsets of their own ANTEX file. 9420 If there is no satellite antenna entry valid at the epoch for a satellite, its orbit cannot be referred to CoM; 9421 the satellite is then not part of the combined product, and the message 9422 'bncComb: no satellite antenna entry valid at ... - ANTEX file outdated? Satellite not combined' is written to the 9423 logfile, at most once per hour and satellite. 9269 9424 </p> 9270 9425 <p>
Note:
See TracChangeset
for help on using the changeset viewer.
