Trimble 4000sse - Enable cross correlation?

From the Trimble 4000 Series Reference:

About cross-correlation. The 4000SSE receiver supports cross-correlation, and the 4000SSi utilizes a proprietary Super-trak
technique. These techniques make use of encrypted P-code during periods when Anri-Spoofin8 is active. Although P-code is encrypted,
cross-correlation and Super-trak techniques allow the receiver to obtain satellite measurements and derive the L2 ranges.

Receivers that support cross-correlation or Super-trak activate it automatically when required. When the receiver detects encrypted
P-code on a channel, it automatically enables encrypted P-code tracking on that channel. That is, for the 4000SSi it changes the
channel's tracking mode from "L1 P-code and CA-code, L2 P-code and E-code" (the default) to "Ll C/A-code only, L2 E-code only".

The receiver switches the channel back to the default tracking mode if encryption is turned off, or if the channel is assigned to a different
(unencrypted) satellite or to no satellite. The L2 TRACKING softkey's E-CODE (or X-CODE) setting forces the receiver to disable L2 P-code on all channels. lt is not a normal mode of operation, and should only be used when suggested by the Trimble Assistance Center.

So you use P,X Code until it doesn't work and then switch to Cross Correlation?

It sounds like the receiver handles this automatically. I've never messed with those settings.

Jim Frame, post: 412949, member: 10 wrote: From the Trimble 4000 Series Reference:

Good info. On this issue you may find https://www.nrl.navy.mil/ssdd/sites/www.nrl.navy.mil.ssdd/files/files/cc2noncc.f of interest. Using this utility allows you to have both versions available for analysis...

Some more details on this issue see: ftp://igscb.jpl.nasa.gov/pub/resource/pubs/06_darmstadt/IGS%20Presentations%20PDF/2_2_Schaer.pdf

Dr Jim Ray of the NGS developed the cc2noncc tool which addresses a bias introduced when mixing CC and non-CC receiver data.

The variety of GPS processing algorithms and their complexity boggles my mind. I had hoped that Van Sickle (3rd edition, not latest) would sort out some of it, but it has been less helpful than I hoped. There is a huge gap between the readily available elementary explanations, and the detailed papers for experts that DMM links. That middle ground was what I worked in as a signal processing engineer on comm gear, but it seems not to be easy to dig up for GPS.

Howdy,

I was not trying to be unhelpful. The issue of cc v noncc is of interest to specialist users. I do not expect there to be much available in that "middle ground" level of detail.

I provide the following extracts from this site http://www.dtic.mil/get-tr-doc/pdf?AD=ADA390474 that reveal the "insignificance" of the issue to most persons processing GPS data.

BTW, as a signals engineer I imagine you are aware that there is an interface control document for NAVSTAR GPS (as well as another for GLONASS and probably for GALILEO) that details many of the signal characteristics of interest to you. These documents are readily found via search engines.

HTH,

DMM

GeeOddMike, post: 413628, member: 677 wrote: I was not trying to be unhelpful.

I wasn't complaining about you. I do learn bits and pieces from the links you've posted.

I'm just frustrated with how big a job it is to put it together and how scattered among the sources the information seems to be. Maybe what I'm wanting about how the processing is done is at least partly proprietary and thus not dissected in public.

FWIW,

I am more familiar with the non-commercial packages. As you indicate the commercial (proprietary) packages have become more "black box" and less interactive; probably a good decision on their part given the propensity of many to change parameters because they can not because they understand what they are doing.

The academic package GAMIT is widely used and in support of its users there have been a number of workshops given on its use. These workshops cover not only GAMIT but also GLOBK and their kinematic tool. The 2016 workshop's materials are available here:

http://web.mit.edu/mfloyd/www/courses/gg/201605_KIGAM/

The GAMIT materials detail what goes on in a a rigorous processing session.

The NGS software package used by contractors for their FAA work, PAGE-NT, has a good walk-through of its processing steps. I don't have the PDF on this iPad but the guide is included in the program files on their public ftp site.

Lest anyone think they can save a few bucks by using these tools (GAMIT or PAGE-NT) remember that time is money and both have steep learning curves. In the case of GAMIT, MIT licenses the software to other academic institutions, researchers and government groups.

Bill93, post: 413617, member: 87 wrote: That middle ground was what I worked in as a signal processing engineer on comm gear, but it seems not to be easy to dig up for GPS.

The L2 techniques do seem to have a long and interesting history. There's a paper summarizing the signal processing for cross-correlation (Trimble, others) and Z-tracking (Ashtech):

http://www.bmotion.com/navcom/images/tech_archiv/L2_Phase_Tracking.pdf

For a more general treatment of receivers and how they derive observables from waveforms, there's a book on software receivers by Pany. Are you interested mostly in receiver techniques or in positioning and modeling at the application layer (e.g. PPP or RTK)? Maybe the book by Leick for the latter.

Cheers,
Peter

Thanks to both of you for some very interesting links. I'll be doing some more reading.

To satisfy my need to complete things, I provide the following...

Having returned home and with access to my computers, I dug up the two resources I mentioned. They were copied to my web site and are the top two links on the following site:

http://geodesyattamucc.pbworks.com/w/page/37089695/Links (N.B. I have not been maintaining this page and some are no longer valid).

They are the NAVSTAR GPS Interface Control Document and the processing guide for the NGS vector reduction package PAGE-NT.

The PAGE-NT document, if read carefully, describes in detail the steps the program follows to solve baselines. The other package mentioned, GAMIT, uses scripts to set up processing.

DMM

Would anyone happen to know whether source code is available for PAGE-NT, and if so, what its license might be? The one processor I know of that is open source, GPSTk's DDBase, is not designed for long baselines.

Cheers,
Peter

Why would you want to mess with the source instead of using the executables?

Jim Frame, post: 413944, member: 10 wrote: Why would you want to mess with the source instead of using the executables?

- educational value, to see how the workflow is structured, how independent and modular the models are, etc.

- my preferred platform is Linux, so it would be nice to compile for that OS rather than resorting to a VM or Wine

- ability to extend the code to handle L2C, L5, or other GNSS, though of course this would not be trivial

PAGE-NT is an interface for a large set of individual programs. Many of these programs were written to implement IGS conventions, implement various functions like troop mapping, etc.

Some source code for aspects of GPS processing is available here: https://www.ngs.noaa.gov/gps-toolbox/exist.htm

FWIW, Professor Kai Borre of Aalborg University has a large set of Matlab scripts developed in conjunction with the texts he wrote with Prof. Strang of MIT.. The books are excellent. See: https://www.ngs.noaa.gov/gps-toolbox/Borre.htm

To the best of my knowledge NGS does NOT license its software. Contact them for a definitive answer.

BTW, another excellent resource to modeling and conventions used in GNSS processing are IERS Conventions available here: https://www.iers.org/IERS/EN/Publications/TechnicalNotes/TechnicalNotes.html ( see No. 32)

GeeOddMike, post: 413595, member: 677 wrote: Some more details on this issue see: ftp://igscb.jpl.nasa.gov/pub/resource/pubs/06_darmstadt/IGS%20Presentations%20PDF/2_2_Schaer.pdf

Dr Jim Ray of the NGS developed the cc2noncc tool which addresses a bias introduced when mixing CC and non-CC receiver data.

See also https://igscb.jpl.nasa.gov/pipermail/igsmail/2002/003811.html :

"As noted previously, cc2noncc will create an output file only when an input
RINEX file indicates that the receiver is one of the types to be modified,
so it is vital that the RINEX headers be reliable and that the IGS standard
names are used <ftp://igscb.jpl.nasa.gov/igscb/station/general/rcvr_ant.tab>."

I wonder if Opus uses cc2noncc internally to take care of applying the correct differential code biases?

Digging a bit, I could only find this in the FAQ:
http://ftp://www.ngs.noaa.gov/pub/corbin/CORS_OPUS%20Advanced%20Webinar/Advanced%20CORS%20and%20OPUS%20Questions.pdf&apos ;">ftp://www.ngs.noaa.gov/pub/corbin/CORS_OPUS%20Advanced%20Webinar/Advanced%20CORS%20and%20OPUS%20Questions.pdf
"Q: Does NGS use the cc2noncc code when mixing receiver types?
A: Answer pending"

If Opus supported rinex version 3, it'd be possible to force the correct interpretation of the tracking mode, as that version offers separable observable codes, e.g., L2W for modern civilian receivers, L2D for the old Trimbles, etc.:
Table 4 in the Rinex 3 spec:
http://ftp://igs.org/pub/data/format/rinex303.pdf&apos ;">ftp://igs.org/pub/data/format/rinex303.pdf