New release of demo5 B29e RTKLIB code

With the recent upgrades to the SwiftNav firmware and the upcoming release of the u-blox F9 receiver the last couple months have been an exciting time in the world of low-cost precision GNSS.!  It has kept me very busy, both making necessary updates to the demo5 version of the RTKLIB code and with consulting work related to the new receivers.  Unfortunately, this has meant I haven’t got a blog post out in over two months.

I have, however, just recently released a new version (b29e) of the demo5 RTKLIB code with some fairly significant changes from the previous version.  These changes have been much more of a group effort than my previous releases, so I first want to thank everyone who helped with the new features.

Here’s a list of the most important changes:

1)  U-blox F9 support:  Support for the new dual-frequency u-blox raw binary messages.  The updated code will now run real-time and post-processed solutions for the F9 receiver using all available raw binary observations and navigation messages.

2) Swiftnav F/W 2.0 support:  Support for the new Galileo and Bediou Swiftnav binary messages.  The updated code will now run real-time and post-processed solutions for the Piksi Multi receiver using all available raw binary observations and navigation messages.

3) Galileo E5b frequency support:  Both the u-blox F9 and the Swiftnav receiver are using the E5b frequency for the second Galileo frequency.  It was difficult to set the option for this frequency in the RTKLIB solutions and including it caused the solutions to run quite slowly.  Since the demo5 code is focused on low-cost receivers, and both SwiftNav and u-blox, the two most popular low-cost dual frequency receivers, are both using E5b, I have re-ordered the frequency tables in RTKLIB so that a three frequency solution now includes L1, L2, and E5b.  Previously, you would need to run what was effectively a five frequency solution to include E5b which caused RTKLIB to run noticeably slower.

4)  Event logging and event position logging:  This is a nice feature that has been available in the Emlid version of RTKLIB for a long time.  I have ported the code over from their open-source code base and have extended support to the Swiftnav receivers as well as the u-blox receivers.  Any events recorded by the receivers (e.g. camera triggers) are decoded from the binary messages and added to the rinex files.  Post-processing the rinex files will now generate two position logs.  The first is unchanged from before, with a solution position for every rover time stamp.  The second, only includes positions for the logged events which are interpolated from the time stamp positions.

5) Fix for using time-tag files to emulate real-time RTKNAVI solutions with file inputs:  This is a really useful feature that was broken by changes ported from the official 2.4.3 code quite a while ago, so it is really nice to have it working again.  Thanks to Christophe for figuring this one out and giving me the necessary code fixes!

6) Reduce unnecessary NTRIP connection requests:  RTKLIB was behaving quite badly on both server and client side whenever a receiver was disconnected without shutting down an NTRIP caster connection and was hammering the caster with nearly continuous connection requests.  This was causing bandwidth issues for the NTRIP casters, and was causing some users (including me) to get temporarily banned for misuse.   Thanks to David from SNIP for helping resolve this one and also for helping me to test the code.

7)  Improve cycle-slip handling for non-u-blox receivers:  RTKLIB was ignoring cycle-slips in cases where the carrier-phase was not set or set to zero.  This was causing it in some cases to ignore valid cycle-slips which can significantly degrade the solution.  The u-blox receiver code already had a fix for this so this change primarily affects non-ublox receivers

Several of these changes were written specifically for clients that needed the features or fixes for their own use but were willing to share them with the larger community.  I appreciate their willingness to share and hope I can continue to bring more changes this way into the open-source code in the future.

I’ve had a chance to run real-time and post-processed solutions with this code with raw observations from both the u-blox F9 receivers and with the SwiftNav receivers with F/W 2.0 and am getting great results with both of them.  I hope to share more results in the near future, but just wanted to say that the quality and number of raw observations I am seeing from both receivers is excellent.

If you’d like to try the new code, Windows executables can be downloaded here and the source code is available here.








29 thoughts on “New release of demo5 B29e RTKLIB code”

  1. Hello Tim,
    Thank you for the excellent blog and all the great work you are putting in on RTKLIB. I have a reasonably simple application which involves setting up ground control points for drone surveys. RTK functionality is not needed and I am quite happy with PPP services (like NRCan’s) to get the x,y,z coordinates of painted points on the ground. We do need centimetre level accuracy however without having to spend too much data collection time at each ground control point (say not more than 30-40 minutes).
    I am thinking of getting the ZED-F9P evaluation board since it is a dual-frequency product and should allow for cm accuracy with shorter measurement times. Will RTKLIB generate the RINEX file which will take advantage of the dual frequency raw data from the F9P?
    Do I need a special dual frequency antenna (they can get quite expensive) or will the simple 20 dollar unit which usual comes with the M8T receiver be adequate?
    Thanks again for your advice.


    1. Hi Sundar. The most recent versions of the 2.4.3 or demo5 versions of RTKLIB will translate the F9P binary files to RINEX files with dual frequency observations. You will need a dual frequency antenna, the antenna that came with the M8T will only receive the L1 signals. Low cost dual frequency antennas are hard to find but Ardusimple is advertising two models, one for 61 euros and one for 79 euros, although they are not available until next month.


  2. Hi Tim,

    Once again, great job! I’ve been using this last release for a couple of days and I’m quite impressed of my results. I just found an error and don’t know if it’s my fault or there is a bug. When trying to save both the solution data or the output log into a file, I get a segmentation fault. I used the same configuration files you uploaded and just changed the output. Did this happen to you?

    Thanks in advance,


    1. Hi Paul. I’ll take a look to see if I can duplicate the problem. Can you tell me which application you were using (e.g. STRSVR,RTKNAVI,RTKRCV), whether it was the demo5 b29e or b30 version and whether you were using the executables that I compiled or you compiled your own. If you run the same configuration with the demo5 b29d, is that OK?


      1. Hi Tim,

        Sorry for not being clear enough. I’m using demo3 b30’s RTKRCV after compiling it myself. I only found this problem when trying to log the data into a file with RTKRCV. If I output both the raw data or the solution data to a tcp server, everything works perfectly. I haven’t tried RTKRCV from the demo5 before, so I don’t know whether if it happens in demo5 b29. I will have a look to it this next monday when I get to work. By the way, I didn’t find this problem with demo5 b30’s RTKNAVI.



          1. Hi Tim,

            The official 2.4.3 code doesn’t have this segmentation fault, but the demo5 b29d code does. I hope it helps.


          2. Hi Paul. I compiled and ran RTKRCV under Ubuntu linux on my PC and was not able to duplicate the problem. If you can get it to fail on this platform and send me the config file you used I can look further but otherwise I don’t know how to do more. Has anyone else seen this problem? On thing I might suggest is running rtkrcv with sudo in case it is an access rights issue of some sort.


          3. Hello Tim,

            I think I found the problem.
            In the file rtkrcv.c, the function startsvr is called with passed argument as NULL (vt struck). The segment fault will occur at the line of code (309) vt->state. vt at this time is NULL.

            Tu Nguyen


          4. Hi Tim,

            Follow the link you provided that is same issue, however official version 2.4.3 now they passes vt to the function startsvr(vt). I used dbg to trace the error, it stopped at the line I mentioned in the previous post.
            So I tried to pass vt like startsvr(con[0]->vt), then I use -s in command line. It worked without crash. However, I need to confirm overwrite always return true on my raspberry pi every time it is powered on . So user should not use -s for auto start anyway but need to modify the function confwrite return 1 all of the time.

            I hope I can give some hints to solve the problem.
            Tu Nguyen


          5. Hi Tim,

            I checked the issue you commented to Tu, but I’m afraid this isn’t my problem. It doesn’t matter whether if I run RTKRCV with the autostart or not, the segmentation fault remains there. If I run the the script with the tracing option (and adding more traces), the last point before crashing is in line 309, as Tu commented.



          6. Hi Paul. If you can send me an email with a config file that you can confirm will duplicate the problem either on a PC running Ubuntu or on a Raspberry Pi, I will take a closer look. Otherwise, if I can’t duplicate the problem, it is very difficult for me to help.


  3. Great work, really impressive!!! Congratulations!

    One question about even marks, have you seen any suspicious behaviour with even interpolation like the one I described to Emlid:

    I think they fixed it, but just to make sure: the Rinex (and ubx) file contains raw receiver clock values for measurement epochs, but GPST (requiring the PVT solution) for the events, so interpolation should be done with the GPST time vector.


  4. Hi friend, congratulations, this is a great work!
    How implement “Event logging and event position logging” with str2str or rtkrcv?


    1. Hi Neilon. Both str2str and rtkrcv will log the binary event messages from the receiver if they are enabled. The event positions are normally calculated in post-processing with rtkpost or rnx2rtkp.


      1. Hi friend, the timemark is this in section 19 “u-blox 8 (M8) Receiver Description Including Protocol Specification.pdf”.

        The UBX-TIM-TM2 messages include time of the last timemark, new rising/falling edge indicator, time source,
        validity, number of marks and a quantization error. The timemark is triggered continuously.



  5. Great improvement.. super cool
    Please informasi more detail about event Mark
    1. How can ublox sending and event Mark. Via pps ??
    2. How accurate the time tag event Mark?
    3. Step by step to be able to make event Mark working for ublox.. I mean the wiring diagram or others else
    Thank you in advance


    1. Hi Catur. Sounds like a good topic for one of my next posts. In the meantime, you can refer to the “Timemark” section in the u-blox M8 Receiver Description and to Emlid documentation on event logging.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.