Question

I'm using DiscFix^? to count cycle slips by examining the df.out files and looking for "BD" commands.

While processing RINEX data from Continuously Operating Reference Stations (CORS) using DiscFix^? in its default configuration, I encountered several days in which the output file (df.out) was empty and the message was "Insufficient Data".

The RINEX files appear to be complete - is DiscFix^? failing because the data gaps/slips were perhaps too large? Is there a way to know if slips were identified using df.log?

I'm trying not to under-count the slips.

Thanks, Rob

-- RobertSteenburgh - 31 Jan 2011

Rob, I can't tell what's happening without seeing the RINEX file, but most likely there is some problem there. I think DiscFix^? outputs that message right after reading the file and looking at how much raw data it has. Perhaps you would upload some example RINEX files, with any options you are giving to DiscFix^?.

-- BrianTolman - 01 Feb 2011

Hello Brian and thank you for your response. I have attached the output logs from DiscFix^? showing the configuration and error messages. I've also attached the Hatakana compressed RINEX files and TEQC summaries for the two Continuously Operating Reference Staitons (CORS), GNAA and CENA. I chose the first day of 2003, but the behavior was consistent for the entire year - df.out was empty. Thanks, Rob

-- RobertSteenburgh - 02 Feb 2011

Rob,

Thanks for responding. These RINEX files have P1 in the header, but all the P1 values are zero (blank). DiscFix^? wants to use P1 if it can, but will fall back to C1 if P1 is not available. The RINEX header tells DiscFix^? that P1 is there, but then all the values are zero; hence it concludes "no data found."

This is a common occurrence in RINEX files, particularly from teqc converters. The gpstk tool RinSum^? will quickly give you a summary of the contents of a RINEX file; for these files it issues a warning - "P1 should be removed from the header." This tells you that P1 data is actually not there, despite what the header says, and so P1 should be removed from the header.

The fix is either to remove P1 from the file using EditRinex^?, or simply add the option --forceCA to the DiscFix^? configuration, this will force it to use C1 and ignore P1.

(And when I go to test the --forceCA fix, I find it doesn't work! How embarrassing. I have now fixed the code and committed the change, so if you will download the latest version and recompile, it should work.)

Let me know if you find any other problems. I'll add to my todo list an item to make DiscFix^? not be fooled by this 'feature.'

Regards, Brian

-- BrianTolman - 01 Feb 2011

Answer

If you answer a question - or have a question you asked answered by someone - please remember to edit the page and set the status to answered. The status is in a drop-down list below the edit box.

Thanks Brian! I really appreciate your prompt diagnosis and response. Thank you also for taking the time to test the solution and to fix the broken bit.

Cheers, Rob

-- RobertSteenburgh - 03 Feb 2011

• df_cena.log: DiscFix^? Log File for CORS site CENA on 2003001

• df_gnaa.log: DiscFix^? Log File for CORS site GNAA on 2003001

• cena0010.03d: Compressed RINEX file for CENA 2003001

• gnaa0010.03d: Compressed RINEX file for GNAA 2003001

• cena0010.03S: TEQC Summary file for CENA 2003001 from National Geodetic Survey

• gnaa0010.03S: TEQC Summary file for GNAA 2003001 from National Geodetic Survey