Issue reading combined broadcast ephemeris products about rtklib HOT 6 CLOSED

Dear Andrew,

You need gzip or cnx2rnx in the command search
path to uncompress files.

regards,

Tomoji TAKASU
Tokyo University of Marine Science and Technology
2-1-6 Etchujima Kohtoh-ku, Tokyo, Japan, 135-0044
Email: [email protected], Tel/Fax: 03-5245-7365
WWW: http://gpspp.sakura.ne.jp

From: "Andrew Symington" [email protected]
Sent: Sunday, December 14, 2014 1:24 AM
To: "tomojitakasu/RTKLIB" [email protected]
Subject: [RTKLIB] Issue reading combined broadcast ephemeris products (#63)

Hi Tomoji

I'm working on a simulator for multi-constellation GNSS. I've been trying
to open combined broadcast ephemerides in RINEX 3.02 format. Here's an
example of one such file:

ftp://cddis.gsfc.nasa.gov/gnss/data/campaign/mgex/daily/rinex3/2014/brdm/brdm2830.14p.Z

I've been trying to use the readrnx function in src/rinex.c to
do this. I noticed that this function was returning 0 each time, so I
printed out a level 5 trace and found this error.

2 rinex file uncompact error: /path/to/brdm2830.14p

This error occurs if both the uncompressed and compressed files are used.
I also tried to use the rtconv.exe app to load and extract the NAV
data for just GPS. I noticed that no file was produced, and so I expect
the issue lies somewhere in the format of the file not being compatible
with RTKLIB.

Are there known issues with the RINEX 3.02 parser?

Thanks
Andrew

---

Reply to this email directly or view it on GitHub:
#63

from rtklib.

Dear Tomoji

I agree that it is definitely an issue with the uncompress function in src/rtkcmn.c. The gzip binary is definitely in my search path (by default in Ubuntu 14.04). For example, the command below executes correctly and results in a decompressed file in the correct directory.

execcmd("gzip -f -d -c \"/path/to/brdm2830.14p.Z\" > \"/path/to/brdm2830.14p\"");

I don't believe that I need cnx2rnx in the search path, as the data file that I am using does not make use of Hatanaka compression.

Furthermore, if I manually decompress the file and then modify the readrnxfile function as below to bypass the decompression step, the ephemerides are read.

/* uncompress and read rinex file --------------------------------------------*/
static int readrnxfile(const char *file, gtime_t ts, gtime_t te, double tint,
                       const char *opt, int flag, int index, char *type,
                       obs_t *obs, nav_t *nav, sta_t *sta)
{
    FILE *fp;
    int cstat,stat;
    char tmpfile[1024];

    trace(3,"readrnxfile: file=%s flag=%d index=%d\n",file,flag,index);

    if (sta) init_sta(sta);

    /* uncompress file */
    //if ((cstat=uncompress(file,tmpfile))<0) {
    //    trace(2,"rinex file uncompact error: %s\n",file);
    //    return 0;
    //}
    if (!(fp=fopen(file,"r"))) {
        trace(2,"rinex file open error: %s\n",file);
        return 0;
    }
    /* read rinex file */
    stat=readrnxfp(fp,ts,te,tint,opt,flag,index,type,obs,nav,sta);

    fclose(fp);

    /* delete temporary file */
    if (cstat) remove(tmpfile);

    return stat;
}

from rtklib.

I wrote a small test case below to illustrate the problem, which actually worked correctly. This suggests that there is some issue with my code. I'll need to debug a bit further. For this reason I am going to close the issue until I am sure it is not a problem on my side.

#include <iostream>
extern "C"
{
    #include <rtklib.h>
}

int main(int argc, char* argv[])
{
    rtcm_t rtcm;
    traceopen("rtklib.trace");
    tracelevel(5);
    init_rtcm(&rtcm);
    if (!readrnx("/path/to/brdm2830.14p.Z", 1, "", &(rtcm.obs), &(rtcm.nav), &(rtcm.sta)))
        std::cout << "Problem" << std::endl;
    else
        std::cout << "OK" << std::endl;
    free_rtcm(&rtcm);
    traceclose();
    return 0;
}

from rtklib.

I worked out that the reason for the error had to do with readrnx() being called from a library that was dynamically loaded at runtime by a plugin architecture. Perhaps, for security reasons, a system() call (required to unzip the file) is not allowed from a runtime library.

UPDATE 1: I still have not managed to solve the issue. Curiously, it appears as if the RTKLIB uncompress() function never actually gets called called by readrnxfile() when the calling application is dynamically loaded at runtime by dlopen().

For example, here is a debug trace:

3 init_rtcm:
3 readrnx : file=/path/to/brdm2830.14p rcv=1
3 readrnxt: file=/path/to/brdm2830.14p rcv=1
3 expath  : path=/path/to/brdm2830.14p nmax=100
3 expath  : file=/path/to/brdm2830.14p
3 readrnxfile: file=/path/to/brdm2830.14p flag=0 index=1
2 rinex file uncompact error: /path/to/brdm2830.14p

From line 3679 of src/rtkcmn.c I see that there should by a trace error trace(3,"uncompress: file=%s\n",file); which never appears in the log. It's almost as if there is a naming conflict with another function that is not found at compile time. This issue appears to only present itself when RTKLIB is being called from a Gazebo plugin, but not as a standalone C++ application. Weird.

UPDATE 2: I renamed all instances of uncompress() to decompress() in the RTKLIB sources and this completely solved the problem. I can now open RINEX files within a Gazebo plugin. I haven't yet managed to determine the guilty library with a name conflict on uncompress but I suspect it may be zlib.

from rtklib.

I am fairly certain at this point that there is a naming conflict with the RTKLIB uncompress() function and an Ubuntu system library linked to by the Gazebo project (http://gazebosim.org). A quick solution is to rename all uncompress() instances to decompress() in RTKLIB. A longer term solution is to identify the offending library, which I have been unable to do thus far.

See pull request #65

from rtklib.

It is fixed in rtklib 2.4.3 b15.

from rtklib.