SP3 Parser Crash

Orekit usage
1

Hi,

I am a OREKEIT newbie, therefore sorry if my question is stupid.
I am trying to parse a SP3 ephemeris file using the class SP3Parser.
Unfortunately, the method “parse” crashes for each file I used.

My code is very very simple:

        SP3Parser tSP3Pars = new SP3Parser();
        try {
            SP3File pFp = tSP3Pars.parse("C:\\Tmp\\esa20056.sp3");
        } catch (IOException ex) {
            Logger.getLogger(ConvertorMainFrame.class.getName()).log(Level.SEVERE, null, ex);
        } catch (OrekitException ex) {
            Logger.getLogger(ConvertorMainFrame.class.getName()).log(Level.SEVERE, null, ex);
        }

I have downloaded a SP3-c file on standard website and i have checked the consistency of the file.

Thanks for your support.

2

Could you tell us the exception message you get during the crash and if possible
join the SP3 file (if its content is not confidential, of course)?

3

Thanks for your prompt message.
Sorry, but i don’t know how to send you the file. I tried to copy/paste it here, but the message size is limited…
Actually, i have tested many sp3 files from the website: ftp://cddis.gsfc.nasa.gov/gnss/products and the error is always returned.

I have also tested the method SP3File parse​(InputStream stream) → same result.

And here is the returned error:

image
image1366×834 54.8 KB

4

Hi gmoura,

To avoid spam, Discourse (the forum engine) gradually grants rights to users. According to this policy, new users are not allowed to attach files to their messages. I just upgraded your « trust level » to grant you this right. So, you should be able now to attach the log file to your message.

Regards,

Sébastien

5

Sorry, but it stiil does not show any icon to upload files. I tried to upload the file as an image but as it is not an image it does not work… Here is my editor:

image
image1853×350 36.1 KB

6

It was the content of the exception ex) in your code that would be more helpful. The code to catch it does
not really bring much information. As I read it, you log the exception somewhere, so it probably ends up in
some log file.

First possible problem is that on the cddis ftp site, despite the directory for week 20056 already exists,
there are no files there yet, which is expected since week 20056 will be in year 2364 (and even week
2056 is in the future, at beginning of June 2019). So I could not file the exact same file that triggered
the error.

I tried to download one of the file with a similar name, but for available data. I used esa19986.sp3.Z, which contains data from April 2018.

Another possible problem is that as the file is compressed as a .Z file, it should be uncompressed before
reading it. Orekit can help there with something like:

  NamedData raw = new NamedData(fileName, () -> new FileInputStream(fileName));
  NamedData uncompressed = new UnixCompressFilter().filter(raw);
  SP3File file = parser.parse(uncompressed.getStreamOpener().openStream());

However, I don’t think this is your problem since your initial post does not have a .Z so it
seems you already uncompressed it before attempting to load it.

After having done this, I tried to directly load the esa19986.sp3.Z and got a parsing error.
The error message related to an unknown orbit type.

Looking at the uncompressed file content, I saw the orbit type near the end of the
first line was set to BHN. There are only four predefined orbit types in the SP3 file
formats (even in the newer version d of the format): FIT (fitted), EXT (extrapolated
or predicted), BCT (broadcast), and HLM (fitted after applying a Helmert
transformation). Other types could potentially be added. It seemed ESOC did that
and defined a new BHN type. I don’t know what BHN stands for.

Adding just a new entry for BHN in the enumerate SP3OrbitType at https://gitlab.orekit.org/orekit/orekit/blob/develop/src/main/java/org/orekit/files/sp3/SP3File.java#L65 allowed Orekit to
parse the file successfully.

Could you:

  1. try to add the BHN entry and check if this fixes the problem for your files?
  2. find the definition of this BHN type?
7

You are right. Only images were allowed. I just modified the Discourse configuration to allow upload of any type of file.

Sébastien

8

First possible problem is that on the cddis ftp site, despite the directory for week 20056 already exists,
there are no files there yet, which is expected since week 20056 will be in year 2364 (and even week
2056 is in the future, at beginning of June 2019). So I could not file the exact same file that triggered
the error.

Sorry, I forgot that the last digit was the day number, so esa20056.sp3 is day 6 of week 2005, i.e. 2018-06-15. This file parses correctly when adding the BHN entry. Note that if BHN is another way to describe an already supported type (like BCT for example), then we could also ensure we parse it
as the existing type. We already do this for some sp3 files that use “EST” (for estimated) instead of “FIT”.

If adding this support to the BHN key in the file solves the problem for you, I suggest that you
open an issue on the forge at Issues · Orekit / Orekit · GitLab.

9

Dear Luc,

First of all, thank you very much for your very quick reply.

  1. I did unzip the sp3 and i only play with the unzipped version.
  2. Sorry for the lack of information regarding the exception, but my code does not catch anything and crashes immediatly. I think that i would be able to get more information but I am very very poor in Java (and i just want to read a SP3 file without learning the beauty of this langage :-)) so i sent you what i got without long investigation.
  3. The solution you suggested does fix the problem. However, I did not follow strictly your advice. Because I only use the jar file (without the sources) and i don’t want to recompile the solution, I just change in my file “BHN” by “FIT” and it seems to work. You suggest to add “BHN” in the enumerate of the class, therefore i assume that there is no specific “BHN” part in the content of the file.
  4. I will ask my ESA colleagues what BHN means and i will contact you afterwards.
  5. I am going to raise the bug in your system.

Thank you very much !
Best regards,
Grégory

10

Thanks, it works now !

11

@gmoura, Could you please let us know about,

  1. The meaning of BHN?
  2. If there is any other issue with overwriting BHN files with FIT orbit type (i.e.) Does the parser wrongly interpret any other field?

I am trying to move from “igv.sp3” files to “esa*.sp3” files as I need Glonass Satellite Clock Bias. I am curious about your experiment here.

12

I got some information about this name from ESOC navigation team.
BHN stands for Bahn, which is the name of their orbit determination tool. They use this key when the SP3 file is produced by Bahn. In Orekit, we map the BHN key to FIT as it seems the most appropriate.
They also use another key: PRO which stands for Propag which they use when the SP3 file is produced by Propag. In Orekit, we map the PRO key to EXT as it seems the most appropriate.

They told me they have been using these keys for years and we were the first one to have a problem with them, I guess everyone else just ignore the key and don’t distinguished between fit and extrapolated ephemerides.

In order to avoid future problems of this kind, in Orekit we also added an OTHER key in case some agency produces files with yet another key.

During parsing, this field has no effect at all on other fields. It is simply stored and provided to the use who calls sp3File.getOrbitType().

13

Thank you Luc for your helpful and quick response. I will proceed with the update.

If I may, I have another question - not related to OREkit but I think this is as good a forum there is:

Is there a source for Ultra-rapid Glonass Satellite Clock bias? This paper lists multiple sources of Glonass Clock bias but they are all Rapids with a latency of up to 24 hours. I am looking for real-time use of GLO Satellite Clock bias and I have not found any so far.

Thank you again.

14

For real time analysis, you will have to look at NTRIP casters, see IGS real time services at http://www.igs.org/rts. Glonass support is announced as experimental there, but if you look at the
NTRIP sourcetable that you get when you access URL http://products.igs-ip.net/ using a simple web browser (no need for an ntrip program for this sourcetable), you will see some casters provide clock for non-GPS systems.

15

Thank you Luc.

I read about NTRIP. My existing framework digests orbit SP3 files (using OREkit) from IGS FTP servers and corrects Pseudoranges for our location filters. NTRIP seems to be different.

For SP3 files, from my research, there seems like there is no realtime GLO Satellite Bias.