tomojitakasu/rtklib

rtklib's Issues

NVS conversion error (floating point overflow)

When converting Navis binr tracks with rtkconv somewhere in the middle of conversion I get the following error using rtklib 2.4.2_p3:

When using rtkconv from rtklib navis version by Michele Bavaro:

when using convbin it simply hangs with no error message:

Generated rinex files are truncated, so only part of the track is available for post-processing. Tracks were recorded with strsvr with the following settings:
!NVS CFG-BINR d7 02 0A
!WAIT 500
!NVS CFG-BINR f4 01
!WAIT 500

@
!NVS CFG-BINR 0e

Here is the track file (rover.nvs) with the results of conversion:
https://www.dropbox.com/s/pm7h9yflohzufcb/rover.zip

If necessary I can provide more tracks and test more rtklib versions.

Binex output support

Is there a plan to support binex outputs?

no common satellite

Dear all, I'm running rtklib between 1 GNSS permanent sites and a VRS generated by our network software, more or less as described at:
#35

After some patches and some suggestions I have been able to get a fix. Since a few days, even if I haven't changed the previous working configuration, I've again some problems.
What I notice is:
a) inside the RTK monitor - Error/Warning a continuos "no common satellite" message
b) inside the main RTKNAVI window the satellite maps for both Rover and Base continuosly appear and disappear: when they came up the satellite configuration change for a moment then they disapperar and so on.
c) getting a fix is almost impossible. The solution is for most of the time "SINGLE" and sometimes it's "FLOAT"

I've made different tests and I've got some results.

TEST1: inside rtklib I've disabled the GPS constellation (just GLONASS). With this configuration:
a) I get a fix very quickly but the left pannel of the main RTKNAVI window remains gray (even if the FIX flag is showed). Sometimes the FIX falg becomes green but just for less than a second.
b) inside the RTK monitor - Error/Warning a continuos "point pos error (no observatin data)" message is running.

TEST2: this is the most stable result. On the CASTER side I've disabled the GLONASS constellation and the RTCM TYPE 14 which has been cited also at:
#37
That issue is closed and to me that solution worked up some days ago.
In that way the RTCM streams from the Rover and from the Base do not include TYPE 14 nor GLONASS satellites. With this configuration:
a) I get a stable FIX in a few seconds. The FIX flag on the left pannel stays continuosly green

I'm not sure at all but probably the issue is still cuased by the RTCM TYPE 14 and the leap second issue.

convbin segfault in expath() at rtkcmn.c:2945 on MacOS 10.8.5

When compiled for MacOS 10.8.5, convbin segfaults in routine expath() [rtkcmn.c:2945]

This bug first appeared after the rtklib_4.2.2_p10 commit.

mojo:pct-2014 jeff$ gdb ~/projects/rtklib_2.4.2_p10/app/convbin/gcc/convbin
GNU gdb (GDB) 7.6.2
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin12.5.0".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /Users/jeff/projects/rtklib_2.4.2_p10/app/convbin/gcc/convbin...done.
(gdb) run -ts "2014/01/01" -od -os -oi -ol -d rinex ubx/06-00031.ubx
Starting program: /Users/jeff/projects/rtklib_2.4.2_p10/app/convbin/gcc/convbin -ts "2014/01/01" -od -os -oi -ol -d rinex ubx/06-00031.ubx

Program received signal SIGSEGV, Segmentation fault.
0x00007fff88949557 in strstr () from /usr/lib/system/libsystem_c.dylib
(gdb) bt
#0  0x00007fff88949557 in strstr () from /usr/lib/system/libsystem_c.dylib
#1  0x0000000100012872 in expath (path=0x7fff5fbffbce "ubx/06-00031.ubx", paths=0x7fff5fbfe968, nmax=1) at ../../../src/rtkcmn.c:2945
#2  0x0000000100003654 in cmdopts (argc=10, argv=0x7fff5fbff9c0, opt=0x7fff5fbfeb40, ifile=0x7fff5fbfeb28, ofile=0x7fff5fbfeaf0,
    dir=0x7fff5fbfeae8, trace=0x7fff5fbfeb38) at ../convbin.c:441
#3  0x000000010000119e in main (argc=10, argv=0x7fff5fbff9c0) at ../convbin.c:467
(gdb) up
#1  0x0000000100012872 in expath (path=0x7fff5fbffbce "ubx/06-00031.ubx", paths=0x7fff5fbfe968, nmax=1) at ../../../src/rtkcmn.c:2945
2945                if ((p=strstr(p,q))) p+=strlen(q); else break;
(gdb) l
2940            sprintf(s2,"^%s$",file);
2941            for (p=s1;*p;p++) *p=(char)tolower((int)*p);
2942            for (p=s2;*p;p++) *p=(char)tolower((int)*p);
2943
2944            for (p=s1,q=strtok_r(s2,"*",&r);q;q=strtok_r(NULL,"*",&r)) {
2945                if ((p=strstr(p,q))) p+=strlen(q); else break;
2946            }
2947            if (p&&n<nmax) sprintf(paths[n++],"%s%s",dir,d->d_name);
2948        }
2949        closedir(dp);
(gdb) print s2
$1 = "^06-00031.ubx$", '\000' <repeats 690 times>...
(gdb) print p
$2 = 0x7fff5fbfd370 "^01-00028.ubx$"
(gdb) print s1
$3 = "^01-00028.ubx$", '\000' <repeats 43 times>, "`\221\205\377\177", '\000' <repeats 630 times>...
(gdb) print q
$4 = 0x5fbfcf70 <Address 0x5fbfcf70 out of bounds>
(gdb) print r
$5 = 0x0

Using RTKNAVI with NV08C-CSM and Galileo SVs

Dear group

Is it possible to use a NV08C-CSM hardware revision 4.1 with a Galileo enabled firmware (binary output for PRNs 11, 12, 19, 20) with RTKNAVI (RTKLIB v2.4.2_p9)? I tried several different configurations but to no avail. If yes, will the Galileo SV also be used in kinematic mode? Any input is highly appreciated!

Setup: NV08C-CSM HW Rev. 4.1, Tallysman 2710, RTKLIB v2.4.2_p9

Best regards
Gunnar

Satellite Ephemeris/Clock

Dear all,
I'm running a real-time experiment with rtklib which involves 2 GNSS permanent sites. Both sites are well monumented and their coordinates have been calculated by a post-processing software using 24h of data, both of them are issued by a NTRIP Caster ( (from a regional ntrip caster).
My aim is to use the 1st site as a Master (M) and the 2nd one as a rover (R), the rtklib should produce a fix solution for R which is close to the post-processed solution (mentioned above).

To summarize the experiment is set as:

• Kinematic Positioning with L1+L2 (GPS+GLONASS),
• 15deg of el. mask
• IONO=Estimate STEC
• TROPO=Saastamoinen
• Sat ephem=broadcast.
• rtklib takes its input from NTRIP servers:
  -- ROVER: RTCM2.3 (from a regional ntrip caster)
  -- BASE:RTCM2.3 (froma a regional ntrip caster)
  -- EPHEM/CLOCK:RTCM3.0 (from igs)

I can't understand how Satellite Ephemeries/Clock types (Boradcast, Precise, Brodcast+SBAS,...) are related to the Input Streams Correction (from the rtklib Input Streams panel).
I.e. the above configuration is working but:
a) can broadcast Satellite Ephemeris/Clock be RINEX navigational files?
b) what can I use to work with precise broadcast Satellite Ephemeris/Clock? Just sp3 files or also real time service such igs IGS01/IGC01 IGS02 IGS03? Remember that in my experimnent just TYPES 3 18/19 are issued for both M and R so no orbits infos are included inside their streams.
c) Broadcast+SSR APC and Broadcast+SSR CoM where they come from? Again I know IGS01/IGC01, IGS02 and IGS03 but using them I can't fix the solution anymore.

Thanks in advance

David

Cannot get FIX Position using Ublox LEA-6T recievers

I'm testing this Ublox LEA-6T GPS receiver with RTKLIB, using positioning mode Single, i cannot get FIX Position even after more than 45min of observation. but with u-center v8.12 it give me a fix position in less than 2 min.
this is the RTKLIB log of 46 minutes of observation without fix position.
https://drive.google.com/file/d/0BwyGQjPp56zjY25wVjZoU1U1OUk/view

i've tested the version 2.4.2_p9 , 2.4.1 , 2.4.2 . none of them works .

i'm available to help you with any other information to fix this bug.

Thanks in advance.

patch 2.4.2p8 broke uBlox parsing

Dear Tomoji,

I use your library for my own project. I've just merged the 2.4.2p8 into my fork. I've seen that it breaks the uBlox (lea-6t) parsing. I suppressed the case of a misuse of the lib or a miscompilation because I confirmed with your provided rtknavi_mkl binary under windows 8.1.
I replayed a captured UBX trace via your STRSVR.exe (2.4.2p8).

the ublox trace is here
On the top of the screen you can see the 2.4.2p7 binary, on the bottom the 2.4.2p8.

If I use your 2.4.2p8 version with ublox.c from 2.4.2p7 it works like a charm.

NMEA GGA FIX FLAG

Dear all, I'm running rtklib between 1 GNSS permanent sites and a VRS generated by our network software, more or less as described at:
#35
I've solved some of the problems using the patch described at:
#37

now I get a fix very quickly but I've noticed that the GGA sentence generated by the rover is not correctly parsed by rtklib. Looking at the Input Streams menù of rtklib I found the "Transmit NMEA GPGGA to base station" popup and I set it to "Single Solution". That string is generated by the rover and usually used but most of the VRS casters to yeld a correct solution for the requesting rover. Further more the GPGGA Fix Quality field is used by the caster to understand if the rover has been able to fix the solution. What I think is that rtklib just handles/parses the coordinate fields avoiding the "Fix Quality" flag which remains 1=GPS SPS mode even if the rover has a FIX 4=RTK with fixed ambiguities.

Is it possible to implement the Fix Quality feature inside the GPGGA sentence? My be I've miss a patch about it. Can you help me?

Bye David

The need to define DLL is not documented

At the top of src/rtklib.h there is documentation for a bunch of defines.

However DLL is not defined, despite it being required for src/rtkcmn.c to compile as a library.

Small typo in rtkrcv.c: "skytreq"

diff --git a/app/rtkrcv/rtkrcv.c b/app/rtkrcv/rtkrcv.c
index dbe7fbd..843d55d 100644
--- a/app/rtkrcv/rtkrcv.c
+++ b/app/rtkrcv/rtkrcv.c
@@ -1205,7 +1205,7 @@ static void prstream(vt_t *vt)
const char *type[]={
"-","serial","file","tcpsvr","tcpcli","udp","ntrips","ntripc","ftp","http"
};

• const char *fmt[]={"rtcm2","rtcm3","oem4","oem3","ubx","ss2","hemis","skytreq",
• const char *fmt[]={"rtcm2","rtcm3","oem4","oem3","ubx","ss2","hemis","skytraq",
  "gw10","javad","lexr","","","","","sp3","","",""};
  const char *sol[]={"llh","xyz","enu","nmea"};
  stream_t stream[9];

Missing MINPRNQZS_S/MAXPRNQZS_S when ENAQZS is not defined

When building with ENAQZS not defines the symbols MINPRNQZS_S and MAXPRNQZS_S are not defined.

This causes a build error in src/rcv/novatel.c

The fix is to add:

define MINPRNQZS_S 0

define MAXPRNQZS_S 0

To src/rtklib.h on line 155.

Issue reading combined broadcast ephemeris products

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

UPDATE: I neglected to mention that I am working with the rtklib_2.4.3 branch.

High processor load when started in background

When the rtkrcv tool is started with a non-interactice stdin, then it constantly prints the prompt in output which causes 100% CPU usage. rtkrcv should detect closed input and not prompt for user interaction (i.e. check for EOF).

Missing } in src/rcv/rcvlex.c

In src/rcv/rcvlex.c on line 239-242 there is a missing }:
if (raw->outtype) {
sprintf(raw->msgtype,"LEXR 0x%04X (%4d): stat=%08X week=%d tow=%10.3f",
type,raw->len,stat,week,tow/1000.0);

A } needs to be inserted on line 242.

IONEX TEC with real time streams

Dear all,
Is it possible to use IONEX TEC grid data for Kinematic positioning mode? Rover and Base stations are both real time streams coming from a NTRIP server.
Thanks

David

rt17.c code change

Thank you very much for making certain needed code changes in rt17.c. I was hoping you would. :-)

However, the following code change which you made in rt17.c/get_time() causes the week to be set to a negative value when raw->time is zero. I suspect that is not what you intended to have happen with that particular change.

Background: Unlike everyone else, Trimble does not give us the gps week number. That's why raw->time is zero there. When we don't know what the gps week number is, we just have to do the best we can. I went to considerable lengths in rt17.c to determine the correct gps week number whenever possible. When all else fails and we still don't know the gps week number when we need it, most of the time the current gps week number based on the current gps time is the correct choice. When it is not, such as when processing an old file, the user can use the -WEEK=n receiver dependent option. Please note that UNAVCO TEQC handles this the same way.

The rt17.c/get_time() code change in question:

if (week == 0)
{

if 0

    time2gpst(timeget(), &week);

else

    /* add to get week number (by TTAKA 2014/08/26) */
    time2gpst(raw->time, &week);

endif

    raw->week = week;

    trace( 2, "RT17: Initial GPS WEEK number unknown; "
              "WEEK number %d assumed.\n", week );
}

I suggest instead perhaps something similar to the following code:

if (week == 0)
{
    if ((raw->time.time == 0) && (raw->time.sec == 0.0))
        raw->time = timeget();

    time2gpst(raw->time, &week);
    raw->week = week;

    trace( 2, "RT17: Initial GPS WEEK number unknown; "
              "WEEK number %d assumed.\n", week );
}

Error converting NVS BINR format with rtkconv

I get an error when converting raw data in NVS BINR format, see attached image. Some of the obs-file is written, but no nav data. The data file is available at http://fluffyelephant.com/rtklib-failing-file/output.raw and produced with strsvr.exe

Conflict between src/rtkcmn.c and src/rcv/rcvlex.c

When compiling without EXTLEX defined some functions are defined in both src/rtkcmn.c and src/rcv/rcvlex.c casuing a link error.

I suggest that src/rcv/rcvlex.c include a #ifdef to remove these conflicts when EXTLEX is not defined.

Ordering of ephemerides : RINEX vs RTCM

Hi Tomoji

I've managed to load NAV data from combined RINEX 3.02 broadcast ephemerides (using pull request #65). My goal is to package the NAV data into RTCM3 type 1019 and 1020 messages over TCP. I have noticed however that readrnx() appears to order the nav.eph array by the order given in the RINEX file (all satellites, all times). However, encode_type1019() expects the nav.eph array to be ordered such that the ephemeride for satellite with id n is located at nav.eph[n-1]. Is there a way to preprocess the nav.eph array for use by the RTCM3 NAV encoders?

Thanks
Andrew

rtkrcv.exe

Is it possible to release the console app rtkrcv as windows executable?

I wasn't able to compile it myself with VS2013 express, or crosscompile it on Ubuntu.
Or maybe someone can give me a hint how to crosscompile it?

Compilling error

Hello Sir,

i am trying to compile rtklib on ubuntu desktop as well as beagle bone black, when i run "makeall.sh" it completes with warning and after that i run "makefile" which is under rtkrcv \ gcc folder giving below errors i am getting same error on desktop as well as beaglebone black. i am very newbie into linux. any suggestion ?

mahesh@WZ7:/rtklib/app/rtkrcv/gcc$ ls
? ephemeris.c javad.o options.c ppp.c rcvraw.o rtcm3e.o rtkpos.c rtkrcv.o sbas.o stec.o ublox.o
binex.o ephemeris.o lambda.c options.o ppp.o rinex.c rtcm3.o rtkpos_gsi.c rtkrcv.trace skytraq.o stream.c
convkml.c geoid.c lambda.o pntpos.c preceph.c rinex.o rtcm.c rtkpos_gsi.o rtkshut.sh solution.c stream.o
convrnx.c geoid.o makefile pntpos.o preceph.o rtcm2.c rtcm.o rtkpos.o rtkstart.sh solution.o streamsvr.c
crescent.o gw10.o makefile postpos.c qzslex.c rtcm2.o rtkcmn.c rtkrcv rtksvr.c src temp
datum.c ionex.c novatel.o ppp_ar.c rcv rtcm3.c rtkcmn.o rtkrcv.conf rtksvr.o ss2.o tle.c
download.c ionex.o nvs.o ppp_ar.o rcvraw.c rtcm3e.c rtklib.h rtkrcv.nav sbas.c stec.c todo
mahesh@WZ7:/rtklib/app/rtkrcv/gcc$ bash makefil
bash: makefil: No such file or directory
mahesh@WZ7:/rtklib/app/rtkrcv/gcc$ bash makefile
makefile: line 2: $'\r': command not found
makefile: line 3: BINDIR: command not found
makefile: line 4: SRC: command not found
makefile: line 5: $'\r': command not found
makefile: line 8: -DENAGLO: command not found
makefile: line 9: $'\r': command not found
makefile: line 10: SRC: command not found
makefile: line 10: CTARGET: command not found
makefile: line 10: CFLAGS: command not found
makefile: line 11: LDLIBS: command not found
makefile: line 12: $'\r': command not found
makefile: line 13: all: command not found
makefile: line 14: rtkrcv: command not found
makefile: line 15: rtkrcv: command not found
makefile: line 16: rtkrcv: command not found
makefile: line 17: rtkrcv: command not found
makefile: line 18: $'\r': command not found
makefile: line 19: rtkrcv.o: command not found
makefile: line 20: CC: command not found
makefile: line 20: CFLAGS: command not found
makefile: line 20: -c: command not found
makefile: line 21: SRC: command not found
makefile: line 21: rtkcmn.o: command not found
makefile: line 22: CC: command not found
makefile: line 22: CFLAGS: command not found
makefile: line 22: SRC: command not found
makefile: line 22: -c: command not found
makefile: line 23: SRC: command not found
makefile: line 23: rtksvr.o: command not found
makefile: line 24: CC: command not found
makefile: line 24: CFLAGS: command not found
makefile: line 24: SRC: command not found
makefile: line 24: -c: command not found
makefile: line 25: SRC: command not found
makefile: line 25: rtkpos.o: command not found
makefile: line 26: CC: command not found
makefile: line 26: CFLAGS: command not found
makefile: line 26: SRC: command not found
makefile: line 26: -c: command not found
makefile: line 27: SRC: command not found
makefile: line 27: geoid.o: command not found
makefile: line 28: CC: command not found
makefile: line 28: CFLAGS: command not found
makefile: line 28: SRC: command not found
makefile: line 28: -c: command not found
makefile: line 29: SRC: command not found
makefile: line 29: solution.o: command not found
makefile: line 30: CC: command not found
makefile: line 30: CFLAGS: command not found
makefile: line 30: SRC: command not found
makefile: line 30: -c: command not found
makefile: line 31: SRC: command not found
makefile: line 31: lambda.o: command not found
makefile: line 32: CC: command not found
makefile: line 32: CFLAGS: command not found
makefile: line 32: SRC: command not found
makefile: line 32: -c: command not found
makefile: line 33: SRC: command not found
makefile: line 33: sbas.o: command not found
makefile: line 34: CC: command not found
makefile: line 34: CFLAGS: command not found
makefile: line 34: SRC: command not found
makefile: line 34: -c: command not found
makefile: line 35: SRC: command not found
makefile: line 35: stream.o: command not found
makefile: line 36: CC: command not found
makefile: line 36: CFLAGS: command not found
makefile: line 36: SRC: command not found
makefile: line 36: -c: command not found
makefile: line 37: SRC: command not found
makefile: line 37: rcvraw.o: command not found
makefile: line 38: CC: command not found
makefile: line 38: CFLAGS: command not found
makefile: line 38: SRC: command not found
makefile: line 38: -c: command not found
makefile: line 39: SRC: command not found
makefile: line 39: rtcm.o: command not found
makefile: line 40: CC: command not found
makefile: line 40: CFLAGS: command not found
makefile: line 40: SRC: command not found
makefile: line 40: -c: command not found
makefile: line 41: SRC: command not found
makefile: line 41: rtcm2.o: command not found
makefile: line 42: CC: command not found
makefile: line 42: CFLAGS: command not found
makefile: line 42: SRC: command not found
makefile: line 42: -c: command not found
makefile: line 43: SRC: command not found
makefile: line 43: rtcm3.o: command not found
makefile: line 44: CC: command not found
makefile: line 44: CFLAGS: command not found
makefile: line 44: SRC: command not found
makefile: line 44: -c: command not found
makefile: line 45: SRC: command not found
makefile: line 45: rtcm3e.o: command not found
makefile: line 46: CC: command not found
makefile: line 46: CFLAGS: command not found
makefile: line 46: SRC: command not found
makefile: line 46: -c: command not found
makefile: line 47: SRC: command not found
makefile: line 47: preceph.o: command not found
makefile: line 48: CC: command not found
makefile: line 48: CFLAGS: command not found
makefile: line 48: SRC: command not found
makefile: line 48: -c: command not found
makefile: line 49: SRC: command not found
makefile: line 49: options.o: command not found
makefile: line 50: CC: command not found
makefile: line 50: CFLAGS: command not found
makefile: line 50: SRC: command not found
makefile: line 50: -c: command not found
makefile: line 51: SRC: command not found
makefile: line 51: pntpos.o: command not found
makefile: line 52: CC: command not found
makefile: line 52: CFLAGS: command not found
makefile: line 52: SRC: command not found
makefile: line 52: -c: command not found
makefile: line 53: SRC: command not found
makefile: line 53: ppp.o: command not found
makefile: line 54: CC: command not found
makefile: line 54: CFLAGS: command not found
makefile: line 54: SRC: command not found
makefile: line 54: -c: command not found
makefile: line 55: SRC: command not found
makefile: line 55: ppp_ar.o: command not found
makefile: line 56: CC: command not found
makefile: line 56: CFLAGS: command not found
makefile: line 56: SRC: command not found
makefile: line 56: -c: command not found
makefile: line 57: SRC: command not found
makefile: line 57: novatel.o: command not found
makefile: line 58: CC: command not found
makefile: line 58: CFLAGS: command not found
makefile: line 58: SRC: command not found
makefile: line 58: -c: command not found
makefile: line 59: SRC: command not found
makefile: line 59: ublox.o: command not found
makefile: line 60: CC: command not found
makefile: line 60: CFLAGS: command not found
makefile: line 60: SRC: command not found
makefile: line 60: -c: command not found
makefile: line 61: SRC: command not found
makefile: line 61: ss2.o: command not found
makefile: line 62: CC: command not found
makefile: line 62: CFLAGS: command not found
makefile: line 62: SRC: command not found
makefile: line 62: -c: command not found
makefile: line 63: SRC: command not found
makefile: line 63: crescent.o: command not found
makefile: line 64: CC: command not found
makefile: line 64: CFLAGS: command not found
makefile: line 64: SRC: command not found
makefile: line 64: -c: command not found
makefile: line 65: SRC: command not found
makefile: line 65: skytraq.o: command not found
makefile: line 66: CC: command not found
makefile: line 66: CFLAGS: command not found
makefile: line 66: SRC: command not found
makefile: line 66: -c: command not found
makefile: line 67: SRC: command not found
makefile: line 67: gw10.o: command not found
makefile: line 68: CC: command not found
makefile: line 68: CFLAGS: command not found
makefile: line 68: SRC: command not found
makefile: line 68: -c: command not found
makefile: line 69: SRC: command not found
makefile: line 69: javad.o: command not found
makefile: line 70: CC: command not found
makefile: line 70: CFLAGS: command not found
makefile: line 70: SRC: command not found
makefile: line 70: -c: command not found
makefile: line 71: SRC: command not found
makefile: line 71: nvs.o: command not found
makefile: line 72: CC: command not found
makefile: line 72: CFLAGS: command not found
makefile: line 72: SRC: command not found
makefile: line 72: -c: command not found
makefile: line 73: SRC: command not found
makefile: line 73: binex.o: command not found
makefile: line 74: CC: command not found
makefile: line 74: CFLAGS: command not found
makefile: line 74: SRC: command not found
makefile: line 74: -c: command not found
makefile: line 75: SRC: command not found
makefile: line 75: ephemeris.o:: command not found
makefile: line 76: CC: command not found
makefile: line 76: CFLAGS: command not found
makefile: line 76: SRC: command not found
makefile: line 76: -c: command not found
makefile: line 77: SRC: command not found
makefile: line 77: rinex.o: command not found
makefile: line 78: CC: command not found
makefile: line 78: CFLAGS: command not found
makefile: line 78: SRC: command not found
makefile: line 78: -c: command not found
makefile: line 79: SRC: command not found
makefile: line 79: ionex.o: command not found
makefile: line 80: CC: command not found
makefile: line 80: CFLAGS: command not found
makefile: line 80: SRC: command not found
makefile: line 80: -c: command not found
makefile: line 81: SRC: command not found
makefile: line 81: stec.o: command not found
makefile: line 82: CC: command not found
makefile: line 82: CFLAGS: command not found
makefile: line 82: SRC: command not found
makefile: line 82: -c: command not found
makefile: line 83: SRC: command not found
makefile: line 83: rtkpos_gsi.o:: command not found
makefile: line 84: CC: command not found
makefile: line 84: CFLAGS: command not found
makefile: line 84: SRC: command not found
makefile: line 84: -c: command not found
makefile: line 85: $'\r': command not found
makefile: line 86: SRC: command not found
makefile: line 86: rtkrcv.o: command not found
makefile: line 87: SRC: command not found
makefile: line 87: rtkcmn.o: command not found
makefile: line 88: SRC: command not found
makefile: line 88: rtksvr.o: command not found
makefile: line 89: SRC: command not found
makefile: line 89: rtkpos.o: command not found
makefile: line 90: SRC: command not found
makefile: line 90: geoid.o: command not found
makefile: line 91: SRC: command not found
makefile: line 91: solution.o: command not found
makefile: line 92: SRC: command not found
makefile: line 92: lambda.o: command not found
makefile: line 93: SRC: command not found
makefile: line 93: sbas.o: command not found
makefile: line 94: SRC: command not found
makefile: line 94: rcvraw.o: command not found
makefile: line 95: SRC: command not found
makefile: line 95: rtcm.o: command not found
makefile: line 96: SRC: command not found
makefile: line 96: rtcm2.o: command not found
makefile: line 97: SRC: command not found
makefile: line 97: rtcm3.o: command not found
makefile: line 98: SRC: command not found
makefile: line 98: rtcm3e.o: command not found
makefile: line 99: SRC: command not found
makefile: line 99: preceph.o: command not found
makefile: line 100: SRC: command not found
makefile: line 100: options.o: command not found
makefile: line 101: SRC: command not found
makefile: line 101: pntpos.o: command not found
makefile: line 102: SRC: command not found
makefile: line 102: ppp.o: command not found
makefile: line 103: SRC: command not found
makefile: line 103: novatel.o: command not found
makefile: line 104: SRC: command not found
makefile: line 104: ublox.o: command not found
makefile: line 105: SRC: command not found
makefile: line 105: ss2.o: command not found
makefile: line 106: SRC: command not found
makefile: line 106: crescent.o: command not found
makefile: line 107: SRC: command not found
makefile: line 107: skytraq.o: command not found
makefile: line 108: SRC: command not found
makefile: line 108: gw10.o: command not found
makefile: line 109: SRC: command not found
makefile: line 109: javad.o: command not found
makefile: line 110: SRC: command not found
makefile: line 110: nvs.o: command not found
makefile: line 111: SRC: command not found
makefile: line 111: binex.o: command not found
makefile: line 112: SRC: command not found
makefile: line 112: ephemeris.o:: command not found
makefile: line 113: SRC: command not found
makefile: line 113: rinex.o: command not found
makefile: line 114: SRC: command not found
makefile: line 114: ionex.o: command not found
makefile: line 115: SRC: command not found
makefile: line 115: stec.o: command not found
makefile: line 116: SRC: command not found
makefile: line 116: rtkpos_gsi.o:: command not found
makefile: line 117: $'\r': command not found
makefile: line 118: $'install:\r': command not found
makefile: line 119: BINDIR: command not found
makefile: line 120: $'\r': command not found
makefile: line 121: $'test1:\r': command not found
invalid option value pos1-snrmask (./rtkrcv.conf:46)
** rtkrcv ver.2.4.2 b11 console (h:help) **
rtkrcv>

Bug in novatel.c - decode_rawwaasframeb()

In the file src/rcv/novatel.c on line 503 is:
if (MINPRNQZS_S<=prn&&prn<=MINPRNQZS_S) {

This appears to be a bug, it should be:
if (MINPRNQZS_S<=prn&&prn<=MAXPRNQZS_S) {

rinex header and gz

Please ignore this issue

rtknavi: Input Streams Correction

Dear colleagues

I'm a little bit confused about the Correction field of the "Input Streams" pannel inside rtknavi. What is it used for? I can access different NTRIP IGS services reffering to RTCM SSR such IGS01 IGS02 IGS03
used for orbits and clocks. Can I use one of them inside that filed or is it better to use RTCM3EPH01 or RTCM3EPH (which are broadcast ephemeries)?

Bye and thanks in advance

rtklib between 2 GNSS permanent sites

Dear group
currently I'm running an experiment with rtklib which involves 2 GNSS permanent sites.
Both sites are well monumented, they belong to a network devoted to cadastrial RTK services so their coordinates are well known (ad published inside official logsheets).
To summarize the experiment is set as Kinematic Positioning with L1+L2 (GPS+GLONASS), 15deg of el. mask, IONO=Estimate STEC, TROPO=Saastamoinen, Sat ephem=broadcast.
rtklib takes its input from NTRIP servers:
ROVER: RTCM2.3 (from a regional ntrip caster)
BASE:RTCM2.3 (froma a regional ntrip caster)
EPHEM/CLOCK:RTCM3.0 (from igs)
As both Rover and Base are permanent sites I except that when the FIX status is reached the Rover coordinates will fit the coordinates written inside the offcial logsheet.

Well,... having a fix with Min Ratio to Fix Ambiguity=3.0 (default) for me is impossible. I've changed that value to 1.8 and sometimes I get a FIX but usually the ratio is very close to 1 (between 1.1 and 1.2), the naseline is more ore less 25Km. Probably I can get a sable FIX because of the baseline (the saastamoinen tropo modue should be good up to 20Km), but I need some support to this idea. What do you think?

When the FIX is reached the solution is very close to the logsheets values (some cm of difference as expected). Anyway, in this kind of experiment, I can't understand what are the differences among the Positioning Modes: Kinematic, static and fixed. Furthermore I've a problem to chose the right Integer Ambiguity Res. What is the best among the various options (Fix and Hold, Continuous and Istantaneous). Probably for this kind of experiment Fix and Hold will be good but I need some support. Can you help me?

Finally using an Estimate STEC for the Iono correction lead me usually to a more stable FIX state than using Iono-Free LC (which should be the best with L1 and L2 receivers).
What do you think?

Thanks in advance

David

Build fails if CLOCK_MONOTONIC_RAW is not supported by libc

If compiling on a version of libc without CLOCK_MONOTONIC_RAW the build will fail.

I suggest adding a #ifdef CLOCK_MONOTONIC_RAW around lines 1511 and 1514 of src/rtkcmn.c

SP3 precise ephemeris not used for correction when provided as "file"

Hi Tomaji,
Thanks for your work.
it seems that providing a sp3 file for correction does not work in rtkrcv

first test OK:
pos1-posmode =ppp-static
pos1-sateph =precise
file-tempdir =./temp/
inpstr3-type =ftp
inpstr3-path =anonymous:none@[email protected]/gps/products/%W/igu%W%D_%hb.sp3.Z::T=-21600,21600,0,0

second test not working (igu18003_06.sp3 is the file automatically downloaded and uncompressed in step 1)
pos1-posmode =ppp-static
pos1-sateph =precise
inpstr3-type =file
inpstr3-path =./temp/igu18003_06.sp3

in the second test I get the error "xxxx: point pos error (lack of valid sats ns=XX)

rtkrcv can not get FLOAT or FIX solution after rtkrcv be running and start

i was used rtkrcv in the arm board with ublox m8n gps module and the NTRIP base server, i found an issue that rtkrcv can not got the FLOAT or FIX solution int rtkrcv first running the start. It's always in SINGLE state, but it will quickly change the solution status to FLOAT or FIX when i running the ' restart' command int the console to restart the rtk server.

RTKLIB and leap second

Dear group,
can you help me to understand how rtklib handles the leap second issue? Currently most GNSS networks provide RTK streams with RTCM TYPE 14 enabled. That type helps with the GPS time. Is rtklib able to recognize that type?
Bye
David

RTKLIB on raspberry PI

Dear all,
I'm trying to compile rtklib CUIs (rtklib_2.4.2.zip) on my raspberry PI.
Currently I've the following working moudules (so the compile procedure went Ok for them):
RTKRCV, STR2STR, CONVBIN.
When I try to compile RNX2RTKP it seems both stec.c and rtkpos_gsi.c are missing from
the src directory. Do I need to download something else to make it work? Do I need to change the makefile?

Broadcast Ephemeris

Dear group

is there a way to feed rtklib with broadcast ephemeries form a ntrip provider if both the Rover and the Base station do not collect brdc ephemeries?

Thanks

David

RTCM msgs with strange date: 1994

Dear all
I’m the manager of FReDNet that is a permanent GNNS receivers network located in Friuli (N-E of Italy).
I’ve just started to use RTKLIB but I’ve some difficulties. I don’t now if you have time to support me but I’m trying RTKNAVI to yeld a kinematic solution starting from two mountpoints belonging to FReDNet. The experiment involves:

1. Rover taken from the FReDNet ntrip caster (RTCM 2.3)
2. Base Station taken from the FReDNet ntrip caster (RTCM 2.3)
3. Correction: real time orbits (GPS+GLONASS) coming from trip server at products.igs-ip.net mount point RTCM3EPH
   Settings1
   a) Positioning Mode: Kinematic
   b) Ionosphere Correction: Iono-Free LC
   c) Troposphere Correction: Saastamoinen
   b) Frequency: L1+L2
   c) Satellite Ephemeris/ Clock : broadcast

remaining options are more or less set to default values.

As I start the solution it guest to the “Single” status with red color, but after
a it turns into a grey color.

Looking at the Error/Warning tab I got:
point pos error (lack of valid sats ns=0)

I’ve also checked:

• Streams: all of the cited streams (Rover, Master and Ephemeris are streaming down data
• Nav GPS: the status is always and for every sat Unknown (the symbol - is used for that)
• Obs data: the Trcv (GPST) is strangely 1994/08/25
• RTCM Msgs for Rover and For Master are wrong: 1994/08/25. The one for the ephemeris is correct 2014/04/11

Can you help me? Thanks in advance.

David

Replace obsolete S_IRUSR in download.c

In the file src/download.c on line 136:
return buff.st_mode&S_IREAD;

The S_IREAD is obsolete (see http://www.gnu.org/savannah-checkouts/gnu/libc/manual/html_node/Permission-Bits.html).

It should be replaced with S_IRUSR.

This was preventing the file from compiling under Android which does not include the obsolete symbol.

Precise clock are not used from SP3 combined orbits/clocks

Dear Tomoji,
I suspect that precise clocks are not use with SP3 IGS predicted ultra rapid orbits and clock.

On RTKNAVI I choose for stream 3 FTP / "cddis.gsfc.nasa.gov/gps/products/%W/igu%W%D_%hb.sp3.Z" / anonymous / [email protected] / offset -6h
Stream 1 is a stream NTRIP / www.euref-ip.net / 2101 / DENT0

Option "precise ephemeris" is set.

No fix can be obtained.

If I look at the debug trace 3, the problem seems to come from the absence of precise clock.
For having a fix, I need to add a stream 2 with broadcast ephemeris (RTCM3EPH) , but after looking at the debug trace precise ephemeris are used but clock are used from the broadcast stream.

misleading error message from postpos.c

I'm using rtkpost/rnx2rktp in batch processing mode. When the wild cards (e.g. %r%n0.13o) does not match any files, then I get the error "no station position: basepositions.pos". In this case the base station file has been assigned rcvno=1 and the sp3 file gets rcvno=2. As a consequence .name is empty.

It would be great if postpos.c gives a "no files found" error if a file pattern does not match any files at all. Ideally this error would happen as early as possible, so that it does waste time reading the huge base station file.

I have been using rtkpost and rnx2rktp.c with these inputs :

rnx2rtkp -k enga.conf -bid "ornc lurc" -rid "tright ttop" -o "output/%r/%r_%b_%n0.pos"
-ts 2013/05/23 00:00:00 -te 2013/08/26 23:59:59 -tu 86400 -ti 60
"%r/%r%n0.13o"
"Base/%b/%b%n0.13o"
"%r/%r%n0.13n"
"Base/%b/%b%n0.13n"
"../GNSS_DATA/product/mgex/%W/com%W%D.sp3"
"../GPS/GNSS_DATA/product/%W/cod%W%D.clk"

Here:
tu is equivalent to "unit" in rtkpost.
bid: list of base station id's
rid: list of rover ids

--- see also this pull request for the meaning of the tu,rid, and bid parameters:
#48

Compilation error on MacOS 10.9.2 with xCode

Due to the lack of separated librt we cannot compile under MacOS X , in fact all the required rt call are built in in standard libraries. So it just need to remove the -lrt
this is a sample diff

diff --git a/app/convbin/gcc/makefile b/app/convbin/gcc/makefile
index 463f529..b3e92ec 100644
--- a/app/convbin/gcc/makefile
+++ b/app/convbin/gcc/makefile
@@ -5,7 +5,7 @@ SRC = ../../../src

OPTS = -DTRACE -DENAGLO -DENAQZS -DENAGAL -DENACMP -DNFREQ=3 -DNEXOBS=3
CFLAGS = -Wall -O3 -ansi -pedantic -I$(SRC) $(OPTS) -g
-LDLIBS = -lm -lrt
+LDLIBS = -lm

convbin : convbin.o rtkcmn.o rinex.o sbas.o preceph.o rcvraw.o convrnx.o
convbin : rtcm.o rtcm2.o rtcm3.o rtcm3e.o pntpos.o ephemeris.o ionex.o
diff --git a/app/pos2kml/gcc/makefile b/app/pos2kml/gcc/makefile
index 08621a7..c511f2d 100644
--- a/app/pos2kml/gcc/makefile
+++ b/app/pos2kml/gcc/makefile
@@ -3,7 +3,7 @@
BINDIR = /usr/local/bin
SRC = ../../../src
CFLAGS = -Wall -O3 -ansi -pedantic -I$(SRC) -DTRACE
-LDLIBS = -lm -lrt
+LDLIBS = -lm

pos2kml : pos2kml.o convkml.o solution.o geoid.o rtkcmn.o preceph.o

diff --git a/app/rnx2rtkp/gcc/makefile b/app/rnx2rtkp/gcc/makefile
index d9b86b7..091eabf 100644
--- a/app/rnx2rtkp/gcc/makefile
+++ b/app/rnx2rtkp/gcc/makefile
@@ -7,7 +7,7 @@ OPTS = -DTRACE -DENAGLO -DENAQZS -DENAGAL -DNFREQ=3

for no lapack

CFLAGS = -Wall -O3 -ansi -pedantic -I$(SRC) $(OPTS)
-LDLIBS = -lm -lrt
+LDLIBS = -lm

#CFLAGS = -Wall -O3 -ansi -pedantic -I$(SRC) -DLAPACK $(OPTS)
#LDLIBS = -lm -lrt -llapack -lblas
diff --git a/app/rtkrcv/gcc/makefile b/app/rtkrcv/gcc/makefile
index 4191fc9..b40a29f 100644
--- a/app/rtkrcv/gcc/makefile
+++ b/app/rtkrcv/gcc/makefile
@@ -8,7 +8,7 @@ SRC = ../../../src
CTARGET= -DENAGLO -DENAGAL -DENAQZS -DNFREQ=3

CFLAGS = -Wall -O3 -ansi -pedantic -I$(SRC) -DTRACE $(CTARGET)
-LDLIBS = -lm -lrt -lpthread
+LDLIBS = -lm -lpthread

all : rtkrcv
rtkrcv : rtkrcv.o rtkcmn.o rtksvr.o rtkpos.o geoid.o solution.o lambda.o
diff --git a/app/str2str/gcc/makefile b/app/str2str/gcc/makefile
index f8bf255..c068122 100644
--- a/app/str2str/gcc/makefile
+++ b/app/str2str/gcc/makefile
@@ -9,7 +9,7 @@ CTARGET=

OPTION = -DENAGLO -DENAGAL -DENAQZS -DENACMP -DTRACE -DNFREQ=3 -DNEXOBS=3
CFLAGS = -Wall -O3 -ansi -pedantic -I$(SRC) $(OPTION) $(CTARGET)
-LDLIBS = -lm -lrt -lpthread
+LDLIBS = -lm -lpthread

all : str2str
str2str : str2str.o stream.o rtkcmn.o solution.o sbas.o geoid.o

RTKPOST Single produces less accurate result than NMEA lat/lon

I am using a ublox NEO 7P chip with an ANN-MS antenna fixed to the exterior roof of a vehicle.

I captured a ubx-formatted file containing NAV_POSLLH, MSG_NAV_POSECEF, MSG_RXM_RAW, and MSG_RXM_SFRB entries using the pyUblox capure_raw script having options: prefered dynamic model=automobile and PPP=off.

The trace I am considering follows urban streets into downtown LA and passes through areas suspected to have poor GPS reception caused by tall buildings and overpasses.

I am running RTKLIB version 2.4.2 in a virtual Win7 instance.

RINEX obs, nav, and sbs are produced using RTKCONV using the default settings except for the RINEX version option.

Executing RTKPOST in single positioning mode, using the default configurations, on the only the obs and nav files, produces pos and kml results for RINEX versions 2.12 and 3.03 (see repo).

Note that converted RINEX versions 2 and 3 files produce drastically different RTKPOST results in the downtown area.

r2.12:

r3.02:

The NMEA lat/lon data from the original ubx file was extracted and converted to kml using a web tool, producing the following results:
5049 NMEA-records could be converted
99.74 % had a GPS fix and contained usable data

By visual inspection of the RTKPOST r212 and r303 results with respect to the NMEA fixes, it’s easy to see that the NMEA-produced route is likely to be far more accurate in the downtown area than the RTK single results.

NMEA:

I find it hard to believe that the raw GPS data in single positioning mode cannot be used to at least match the accuracy of the lat/lon fixes produced by the ublox chip. Surely I am missing a crucial configuration option in the conversion or post processing steps. Can someone please point me toward the most likely candidate settings to tweak?

Is the NVS BINR format being rejected from rtkrcv?

I have two NVS08C-CSM units, which I'm trying to use in a very short baseline kinematic setup. I managed to get it working in Windows with rtknavi, and I'm now trying to get it to work in Linux with rtkrcv. I have generated a *.conf file and modified the input devices from COM to tty. However, rtkrcv seems to reject the NVS file format.

Here's how I ran it...

$ ./rtkrcv -s -o ucl.conf 
invalid option value inpstr1-format (ucl.conf:109)
invalid option value inpstr2-format (ucl.conf:110)
no navigation data: rtkrcv.nav
** rtkrcv ver.2.4.2 console (h:help) **
rtkrcv> shutdown
shutdown rtkrcv process ? (y/n): y

And here are lines 109 and 110 from ucl.conf

inpstr1-format     =10         # (0:rtcm2,1:rtcm3,2:oem4,3:oem3,4:ubx,5:ss2,6:hemis,7:skytraq,8:gw10,9:javad,15:sp3)
inpstr2-format     =10         # (0:rtcm2,1:rtcm3,2:oem4,3:oem3,4:ubx,5:ss2,6:hemis,7:skytraq,8:gw10,9:javad,15:sp3)

I suspect there's a runtime check on the input formats that rejects the nvs type. Possibly, because it was recently added?

Regards
Andrew

TEST ISSUE

This is a test issue.

Antenna type from observation header

RTKLIB cannot recognize the receiver antenna type from the observation header when we are using broadcast ephemeris. I have attached two output files of RTKPOST; only the ephemeris option was changed from precise to broadcast. What could be the problem behind this?

Precise:

% program   : RTKPOST ver.2.4.2
% inp file  : N:\HHRAW\20141126\posd\*_n1.14o
% inp file  : N:\SAPOS\REF\2530330H.14o
% inp file  : N:\HHRAW\20141126\posd\*_n1.14*
% inp file  : N:\HHRAW\20141126\posd\*.sbs
% obs start : 2014/11/26 07:09:39.0 GPST (week1820 284979.0s)
% obs end   : 2014/11/26 07:46:36.0 GPST (week1820 287196.0s)
% pos mode  : static
% freqs     : L1+L2+L5
% solution  : forward
% elev mask : 15.0 deg
% dynamics  : off
% tidecorr  : off
% ionos opt : sbas
% tropo opt : sbas
% ephemeris : precise
% navi sys  : gps glonass galileo qzss sbas
% amb res   : fix and hold
% amb glo   : on
% val thres : 2.0
% antenna1  : TRM55971.00     NONE  ( 0.0000  0.0000  0.0000)
% antenna2  : LEIAR25.R4      LEIT  ( 0.0000  0.0000  0.0780)
% ref pos   :  4033219.8252    554680.2568   4893761.4131
%
% (x/y/z-ecef=WGS84,Q=1:fix,2:float,3:sbas,4:dgps,5:single,6:ppp,ns=# of satellites)
%  GPST              x-ecef(m)      y-ecef(m)      z-ecef(m)   Q  ns   sdx(m)   sdy(m)   sdz(m)  sdxy(m)  sdyz(m)  sdzx(m) age(s)  ratio

Broadcast:

% program   : RTKPOST ver.2.4.2
% inp file  : N:\HHRAW\20141126\posd\*_n1.14o
% inp file  : N:\SAPOS\REF\2530330H.14o
% inp file  : N:\HHRAW\20141126\posd\*_n1.14*
% inp file  : N:\HHRAW\20141126\posd\*.sbs
% obs start : 2014/11/26 07:09:39.0 GPST (week1820 284979.0s)
% obs end   : 2014/11/26 07:46:36.0 GPST (week1820 287196.0s)
% pos mode  : static
% freqs     : L1+L2+L5
% solution  : forward
% elev mask : 15.0 deg
% dynamics  : off
% tidecorr  : off
% ionos opt : sbas
% tropo opt : sbas
% ephemeris : broadcast
% navi sys  : gps glonass galileo qzss sbas
% amb res   : fix and hold
% amb glo   : on
% val thres : 2.0
% antenna1  : *                     ( 0.0000  0.0000  0.0000)
% antenna2  : *                     ( 0.0000  0.0000  0.0000)
% ref pos   :  4033219.8252    554680.2568   4893761.4131
%
% (x/y/z-ecef=WGS84,Q=1:fix,2:float,3:sbas,4:dgps,5:single,6:ppp,ns=# of satellites)
%  GPST              x-ecef(m)      y-ecef(m)      z-ecef(m)   Q  ns   sdx(m)   sdy(m)   sdz(m)  sdxy(m)  sdyz(m)  sdzx(m) age(s)  ratio

Remove binaries from the source tree

Please consider moving Binaries out from the source tree (at /bin) to the GitHub Releases feature.

Having binaries at the source tree is highly disruptive since a "git clone" size will increase significantly at each release.

ublox.c:decode_alm1() return value

Should ublox.c:decode_alm1() return 9 to update server ion/utc parameters in rtksvr.c:updatesvr() ? Are ion/utc parameters otherwise discarded?

Could you explain?

Hello Tomoji

I am exploring your sorce code (latest version) for pnt positioning and can't understand below string in function
double varerr(const prcopt_t *opt, double el, int sys)

varr=SQR(opt->err[0])*(SQR(opt->err[1])+SQR(opt->err[2])/sin(el));

while in rtklib.h
double err[5]; /* measurement error factor /
/ [0]:reserved /
/ [1-3]:error factor a/b/c of phase (m) /
/ [4]:doppler frequency (hz) */

My questions are:
a. Why for range variations estimation reserved value ( /* [0]:reserved */) is used.
b. Why for range variations estimation phase error factors (opt->err[2]+opt->err[1]) are used.

BR Aleksey

Dropping L2 signals in RINEX files with RTKCONV tool

We are using the RTKlib 2.4.2 source code in a project and having problems converting what appears to me me to be valid RTCM 1004 message content into a RINEX file. The call to convrnx() has worked well overall but we seem to be having problems with any C2/P2 content being dropped out and not in the final file. [And an aside, the RTCM binary content has been checked using the commercial Alberding InspectRTCM tool and which confirms it is well formed and decodes]

As is my habit with this wonderful tool, I then used RTKCONV directly to try and convert one RINEX file to another in order to understand some of the control flags.

I am having two problems that seem to be part of the tool itself. First the "Scan Obs Types" seem to damage the output and remove any L2 signal content which is present in any SV which does not also have P2/C2 content. Otherwise it seems to correctly detect there is not any Doppler and remove that signal entry. This may be related to the below.

Second, the RTKCONV tool, when scan obs types is disabled (checked off) and all signal types are enabled (C, L, D, S and L1, L2 are all checked on) also removes any L2 signal content which is present in any SV which does not also have P2/C2 content.

In fact I am not seeing any way to pass the L2 content for those SV that do not have a P2 signal. Very Strange.

[And When we use the same core routines in our own code, we DO get the desired L2 content in the RINEX Obs file output at all times, however we seem unable to get any P2 values - which is what first led to this posting]

Here is a the 1st epoch of a RINEX file that illustrates this problem
Original file is:

 2.10           OBSERVATION DATA    M (MIXED)           RINEX VERSION / TYPE

DCTOOLS DCTOOLS 20130808 000310 UTC PGM / RUN BY / DATE
COMMENT
station ID: GISA COMMENT
COMMENT
gisar30 MARKER NAME
MARKER NUMBER
OBSERVER / AGENCY
TRIMBLE NETR9 REC # / TYPE / VERS
30137282 TRM55971.00 NONE ANT # / TYPE
-2419200.2475 -4703567.0730 3553009.4654 APPROX POSITION XYZ
0.0000 0.0000 0.0000 ANTENNA: DELTA H/E/N
1 1 WAVELENGTH FACT L1/2
10 C1 L1 D1 S1 P1 P2 L2 D2 S2# / TYPES OF OBSERV
C2 # / TYPES OF OBSERV
2013 8 7 23 58 17.0000000 GPS TIME OF FIRST OBS
2013 8 8 0 3 26.0000000 GPS TIME OF LAST OBS
END OF HEADER
13 8 7 23 58 17.0000000 0 9G 2G12G10G29G31G 4G25G24G 5
21185515.060 111330764.192 50.500
21185518.040 86751290.425 39.500
20328459.626 106826846.532 49.750
83241721.081 49.750
22365271.972 117530411.680 47.750
22365278.772 91582172.665 31.250
22755330.950 119580161.255 45.250
93179371.102 42.500
25188280.032 132365310.315 40.250
103141802.997 34.000
23676469.084 124420786.001 41.500
23676474.664 96951288.234 18.250
21069863.760 110722943.173 47.500
86277629.738 48.250
24339685.798 127905879.334 38.250
99666909.523 39.250
21556860.958 113282235.481 45.750
88271914.310 45.500
13 8 7 23 58 18.0000000 0 9G 2G12G10G29G31G 4G25G24G 5

• cut ---
  Note that there is an L2 entry for every SV.
  The returned file from RTKCONV is:

  2.11 OBSERVATION DATA G (GPS) RINEX VERSION / TYPE
  RTKCONV 2.4.2 20131204 181548 UTC PGM / RUN BY / DATE
  log: C:\Users\dck\Desktop\DCToos-625\trunk\QT-Compress\Tes COMMENT
  format: RINEX COMMENT
  gisar30 MARKER NAME
  MARKER NUMBER
  OBSERVER / AGENCY
  TRIMBLE NETR9 REC # / TYPE / VERS
  30137282 TRM55971.00 NONE ANT # / TYPE
  -2419200.2475 -4703567.0730 3553009.4654 APPROX POSITION XYZ
  0.0000 0.0000 0.0000 ANTENNA: DELTA H/E/N
  1 1 WAVELENGTH FACT L1/2
  10 C1 L1 D1 S1 P1 C2 L2 D2 S2# / TYPES OF OBSERV
  P2 # / TYPES OF OBSERV
  2013 8 7 23 58 17.0000000 GPS TIME OF FIRST OBS
  2013 8 8 0 3 26.0000000 GPS TIME OF LAST OBS
  END OF HEADER
  13 8 7 23 58 17.0000000 0 9G 2G12G10G29G31G 4G25G24G 5
  21185515.060 111330764.192 50.500
  86751290.425 39.500 21185518.040
  20328459.626 106826846.532 49.750

  22365271.972 117530411.680 47.750
  91582172.665 31.250 22365278.772
  22755330.950 119580161.255 45.250

  25188280.032 132365310.315 40.250

  23676469.084 124420786.001 41.500
  96951288.234 18.250 23676474.664
  21069863.760 110722943.173 47.500

  24339685.798 127905879.334 38.250

  21556860.958 113282235.481 45.750

  13 8 7 23 58 18.0000000 0 9G 2G12G10G29G31G 4G25G24G 5

Note that that the L2 signal is now only present when there is a P2 signal and for all other SVs have been dropped.
Your assistance with this is sought.

Navigation output file header bug

Fix for navigation output file header bug (unrelated to any other changes)

I accidentally included the code fix for this bug as an update to Pull Request #45, but it should have been completely separate. Oops. In any case, you can see the simple fix there.

When CONVBIN is run with a command line such as the following, the output navigation file header can be incorrectly written.

This occurs because "raw->nav" is never fully initialized before writing the output navigation file header for the first time.

The output navigation file header is written with garbage random memory values, the input data processed, the output file rewound, then its header rewritten with good values. Unfortunately because the header was written with garbage random memory values the first time, this can cause it to have more lines than the rewritten header, creating a bad final header.

This particular example was reproduced on both the Windows platform with Visual Studio Express 2013 and on the Debian Linux platform with gcc.

(RTKLIB rarely if ever fully initializes any of its structures. As a programming practice, that is problematic. Someone with some time on his hands should go through the code and make it fully initialize every structure.)

Command line:

-od -os -oi -ot -ol -r rt17 e:\rtklib\rt17\p478.rt17

The output navigation file header is initially written with garbage memory values and looks like this:

 2.11           N: GPS NAV DATA                         RINEX VERSION / TYPE

CONVBIN 2.4.2 20140908 114827 UTC PGM / RUN BY / DATE
log: e:\rtklib\rt17\p478.rt17 COMMENT
format: Trimble RT17 COMMENT
-6.2774E+066-6.2774E+066-6.2774E+066-6.2774E+066 ION ALPHA
-6.2774E+066-6.2774E+066-6.2774E+066-6.2774E+066 ION BETA
-.627743856220E+67 -.627743856220E+67-6277438562204192500000000000000000000000000000000000000000000000000-6277438562204192500000000000000000000000000000000000000000000000000 DELTA-UTC: A0,A1,T,W
-842150451 LEAP SECONDS
END OF HEADER
After a rewind, the output navigation file header is re-written and the final header ends up looking like this:

 2.11           N: GPS NAV DATA                         RINEX VERSION / TYPE

CONVBIN 2.4.2 20140908 115247 UTC PGM / RUN BY / DATE
log: e:\rtklib\rt17\p478.rt17 COMMENT
format: Trimble RT17 COMMENT
2.0489E-008 2.2352E-008-1.1921E-007-1.1921E-007 ION ALPHA
1.2493E+005 3.2768E+004-2.6214E+005 2.6214E+005 ION BETA
-.186264514923E-08 -.621724893790E-14 319488 1809 DELTA-UTC: A0,A1,T,W
16 LEAP SECONDS
END OF HEADER
LEAP SECONDS
END OF HEADER

Note the junk after the end of the header.

Bug in the file src/rtcm3e.c, Glonass

Dear group
If using str2str input stream NVS and from the output stream RTCM3, I disappear GLONASS satellites. Am I doing something wrong?

Feature request

Hi Takasu,

First, i want to thank you for the great open source tool RTKLIB.
Im a phd student in the GNSS positioning field, i started using it for data acquisition, and error modeling and evaluation. So i used the RTKPLOT statistics about error average and standard deviations for a large amount of log files data.
However it would be great if you could add a feature in the RTKPLOT that show the accuracy error relative to the receiver position as a histograme.
I mean show the percentage of data in a accuracy <10 cm, 50 cm, 1 m, 2m.

In fact i tried to see the code to know where to add this feature but it doesn't work for me.

It would be kind of you if you could add this feature.

Thanks in advance

str2str -p option, which is the correct format for the antenna position?

I am trying to submit the antenna position with str2str -p with rtklib 2.4.2 p11.
Therefore I like to use a position which I get with rtknavi.
In rtknavi there are the following options to display the solution:
Lat/Lon/Height or X/Y/Z-ECEF or E/N/U-Baseline or Pitch/Yaw/Lenght-Baseline.
It doesn't matter which of them I type in after "-p", It is never the same as I get as output on an other computer where I use the str2str output as an input for rtknavi. In rtknavi in the RTK Monitor/ RTCM Msgs/(2) under Base station position.

Does someone has a working example for transmission of the base station position with str2str?

Additionally It seems to me like there are only GPS Satellites Transmitted, no GLONASS Satellites.
Even if I select the messages with -msg "1004, ..."
The curious thing is, that I receive the messages 1009-1012 (GLONASS http://www.geopp.de/rtcm-3-x-message-types/) but in rtknav there are no visible GLONASS Satellites for the rover...

agreement between PPP algorithms?

Hi, I want to use RTKLib for PPP-static analysis of clock offset.
I did a comparison of different algorithms, see:
http://www.anderswallin.net/2013/12/comparing-gps-ppp-solutions/

There is a constant offset of about 4 ns between CSRS-PPP/gLAB and the RTKLib-PPP solution.
Does anyone know what settings should be used with RTKLib to get solutions that are consistent with the other PPP algorithms?
The offset of 4 ns seems to be about half of the ZTD (!?) - but this may be just a coincidence ??