teqc operations

[gwbres]

teqc operations we'd like to see integrated in a V1.0.

[gwbres]

Hello @larsnaesbye

do you happen to know what the "raw" receiver data that teqc handles when performing a "translation" operation, look like ?

[larsnaesbye]

Doesn't it depend on the manufacturer?
Usually, when we talk of RAW data, it is observations sent in a proprietary format where e.g. Trimble and Septentrio use their own formats. Septentrio describe their SBF 'raw' format in Chapter 4 of the reference guide.

[gwbres]

@larsnaesbye

so if I understand correctly,
teqc is knowledgeable about many formats, some even proprietary, and one of its basic usage is to convert all of this into RINEX.

I haven't looked into your SBF crate in detail yet but it is something I will do in the future.
I assume when you're connected to a device, you want stream based interfaces, to generate content as bytes come in.
Maybe if i can provide a streaming interface, and not only a static file interface, that would help such use cases ?

[larsnaesbye]

so if I understand correctly, teqc is knowledgeable about many formats, some even proprietary, and one of its basic usage is to convert all of this into RINEX.

That is my understanding too - teqc has many import features, some of them from proprietary formats. This is also why the source code to teqc is not open source, as some of the manufacturers have donated closed information and code to teqc.

I haven't looked into your SBF crate in detail yet but it is something I will do in the future.

Please don't - it doesn't work at all yet 😄 and it is low priority because converting from SBF to RINEX is not the heavy part of our processing.

[larsnaesbye]

Maybe if i can provide a streaming interface, and not only a static file interface, that would help such use cases ?

You mean something like receiving an NTRIP stream?

[gwbres]

Hello @larsnaesbye,

could you confirm with your team mates that my understanding of the following fields, contained in a QC report, are correct?

1. |qc - header| position : xxx meters
2. and the qc position offsets: xx vertical meters, yy vertical meters

According to the teqc manual:

The first primary goal of the a qc full run is to find the pseudorange point position of the antenna

I assume the calculation is an RMS average accross all epochs.
BTW, that means we're only dealing with laboratory / stationary data.
So, my understanding of 1 and 2 is that they are the residual error, between the result of this calculation, and what the Header tells you

[larsnaesbye]

The short message from my colleagues is that the inner workings of teqc are black magic written in the 1980's but there is another method through a Canadian PPP service which provides a much more accurate algorithm. I will elaborate on this tomorrow.

[gwbres]

Hello @larsnaesbye,

currently I am only copying /emulating the teqc -qc report. Do you think this is a good idea?
I stopped my progression to avoid going too far and need to redevelop something smarter.

are you familiar with other softwares (like "anubis" ?) and what people use them for?
Because if we could fulfill several requirements in a single tool, that would be valuable to the end user.

So far, our only differences with "teqc" will be

• "smaller" reports on a "per constellation" basis
• not limited to GPS + GLO
• not limited to L1 + L2

at some point, some algorithms like CS detection and possibly compensation require the ability to fine tune their parameters.
I think the UNAVCO tools use configuration files, and it's totally fine; I'm thinking doing the same.
These usecases are advanced usage, it is not a problem for the advanced user to fine tune some parameters

[larsnaesbye]

Simple gap analysis/report would be very nice, e.g.

Gaps: 1
 #1: 04:35:52 -> 05:00:00 (1448s)"

[larsnaesbye]

The information contained in the ‘teqc’ SUM line would suffice for our purposes:

“The first IOD line shows the limiting value for the Ionospheric delay observable rate; more than this is regarded as an ionospheric slip. If teqc computed the derivative of the ionospheric delay observable (+iod) or multipath (+mp), a count of the number of IOD and/or multipath (MP) slips is given. If qc­full, this is further broken down according to elevation mask. In order to qualify as a count here, both MP1 and MP2 must slip (though not necessarily by the same amount) at the same epoch for a particular SV.”

first epoch last epoch hrs dt #expt #have % mp1 mp2 o/slps
SUM 10 4 30 00:00 23:59 24.00 30 41538 41293 99 0.39 0.49 41293

[gwbres]

The information contained in the ‘teqc’ SUM line would suffice for our purposes:

“The first IOD line shows the limiting value for the Ionospheric delay observable rate; more than this is regarded as an ionospheric slip. If teqc computed the derivative of the ionospheric delay observable (+iod) or multipath (+mp), a count of the number of IOD and/or multipath (MP) slips is given. If qc­full, this is further broken down according to elevation mask. In order to qualify as a count here, both MP1 and MP2 must slip (though not necessarily by the same amount) at the same epoch for a particular SV.”

first epoch last epoch hrs dt #expt #have % mp1 mp2 o/slps
SUM 10 4 30 00:00 23:59 24.00 30 41538 41293 99 0.39 0.49 41293

Hello Lars,

you can visualize this estimator with the --iono flag in the command line, try this for example

export RUST_TRACE=log
rinex-cli --fp test_resources/CRNX/V3/ESBCDNK_2020.gz --retain-sv G08 --iono --gf --qc 

The more filters you apply, the quicker the processing execution.
Compare for example the execution time of --retain-sv G08,G31,E10,E13,E10 to --retain-constell GPS.

I'm thinking about providing an option to split the report per constellation. This would help the visualization when very few filters were applied.

The way I built the GNSS combinations method is such as, we form all possible (unique) combinations.
That already proves convenient in some existing operations: for example we have all the --iono combinations, you can easily form the L1/L2 and L2/L1 cross comparison as mentionned above.

What i'm interested in, is the apparently ultimate CS detection method, where you combine a L1/L2 anlysis to a third one (L5), probably unknown to teqc and explained in the ESA handbook (vol 1).

Keep in mind I'll be working on the --qc report for the next few days. Mainly: conclude and clean up the summary we have.

--mp did not work correctly due to data scaling / handling. But I think I got it figured out, I will try to solve it today.

[larsnaesbye]

Great! This means that when I get back from vacation tomorrow I can try to rewrite most of our workflow using the main build of rinex-cli.

[gwbres]

(i'm working in the rinex-qc branch but expect me to regularly merge its content).

Rinex.observation_code_multipath still does not work.

As opposed to the other combinations, physics get cross-mixed in this one: PR - Phase.
The problem is solely due to non correctly scaled / formatted input data.
I tried to align the phase origins. I tried to remove the DC offset as some documentations online led me to have a doubt about that.
I looked for all the formulas I could find online, I think I found 3 variations of them, same results.
By incorrect results, I mean I'm expecting tiny residuals, like the ones we have with other residuals (--dcb, --gf, --iono etc..). The values we're getting are way off at the moment.

I'll try looking for other source of information, I'll focus on correcting the satellite elevation angle calculations that is also highly required for the rest of this project