A look at the recently released RTKLIB b34 code

In January 2021, after a fairly long gap of 17 months without code updates, Tomoji Takasu released a b34 update to the 2.4.3 RTKLIB code. He and his team apparently were very busy over that time as, according to Github, the new release has 1064 changed files, 279,767 additions and 312,550 deletions! While some of these numbers come from reorganizing the file structure, this still constitutes a major rewrite of the codebase and a significant challenge to merging the updates into the demo5 version of RTKLIB.

After a fair bit of effort I have completed a first pass at this merge. Given the magnitude of the changes, I have decided to keep this update on a separate branch in the demo5 repository until it is better tested and more stable. It is now on the demo5_b34_dev branch and the beta executables, along with the more stable b33f version, are available here. All of the Windows GUI and CUI apps appear to run as well as all the linux CUI apps. I have done a very limited amount of testing and am not aware of any major issues in any of the apps at the moment but expect that with more testing, issues will be found. Unfortunately the linux GUI Qt apps have not been updated and given the amount of work involved to do this they will most likely be dropped from both the 2.4.3 and the demo5 code.

At this point I am looking for feedback from regular (or new) users of the demo5 version of RTKLIB. In particular, I would like to focus on finding and fixing features or capabilities that are functional in either the demo5 b33 code or the 2.4.3 b34 code but that are not functional in the demo5 b34 code. Ideally, if you find an issue of this sort, if you can send me an email with your data set, config file, and results with both the good code and the bad code, and a detailed description of the problems, it will make it easier for me to track them down. I will also be monitoring issues reported to the demo5 Github repository, so you can use that mechanism as well, it may just be harder to share data that way.

One thing I should mention is that at this point, the Swiftnav, Comnav, and Tersus receivers are not supported by the demo5 b34 code since they are not supported in the 2.4.3 code but I hope to eventually bring these receivers back into the demo5 code. In the meantime you can still convert files from these receivers to RINEX using the b33 code and run post-processed solutions with the b34 code.

In my limited testing I did not find significant differences in the results between the b33 and b34 code but I believe the emphasis of the changes was on basic structural improvements as well as improvements for the newer constellations and signals which for the most part were not included in my testing. I ran a data set collected from a u-blox F9P moving rover with a PPK solution using a CORS reference as base as well as a kinematic PPP solution. The PPK solution was virtually identical between the two codes but the b34 code did run about 30% faster which is a nice improvement. The PPP results were similar but the b34 results were no better and maybe a little worse than the b33 results so there may still be some room for improvement there. I do think that many of the structural changes will be valuable in the long term even if they do not have an immediate payoff.

There are also some new features in the code that I am looking forward to exploring after I’m more comfortable that the basic functionality is there.

So give it a try and let me know what you find!

I will try to update the beta source code and executables fairly frequently as I make fixes and will eventually move them to the main branch of Github but will probably keep the b33 code around on a separate branch for the foreseeable future.

12 thoughts on “A look at the recently released RTKLIB b34 code”

  1. Hi! I’ve just recently moved from b33c to b33f and have yet to try this version, so thank you for reporting your experience.

    On another note, I’m curious about the output for Static mode works on RTKLib. I noticed it has the options “all” and “single”. Any idea if on “single output” one solution is randomly chosen or if rtkpost averages all the fix solutions to present one result?

    Like

    1. Hi Heloisa. The single output in Static mode is the last solution point from the kalman filter which is effectively a best estimate or weighted average of all the previous solution points.

      Like

  2. Recently, I have to compile the GUI app in Linux to analyze some data. Could please tell me how to complie RTKPLOT and RTKPOST in Ubuntu16.04?

    Like

    1. Hi Amos. Only the RTKLIB CUI apps can be directly compiled from Linux. The Qt versions will compile but are not well supported. If you want to use these, your best bet is to use the Emlid version of RTKLIB. If you don’t need to make custom changes to the code, other users have had success using WINE to run the Window executables.

      Like

  3. I fond one BUG in the b34 code:
    in function detslp_gf()
    {
    if ((g1=gfobs(obs,i,j,k,nav))==0.0) return;
    should be this:
    if ((g1=gfobs(obs,i,j,k,nav))==0.0) continue;
    }

    reason:
    if no L2 data,then L1+L3 jump detecter will not be enabled

    Like

    1. another BUG in the b34 code:
      in function save_msm_obs()
      {
      lossoflock(rtcm,sat,ind[k],lock[j])+(half[j]?3:0);
      should be this:
      lossoflock(rtcm,sat,ind[k],lock[j])+(half[j]?2:0);
      }

      Like

    2. another BUG in the b34 code:
      in function ddidx()
      {
      if (rtk->ssat[j-k].lock[f]>=0&&!(rtk->ssat[j-k].slip[f]&2)&&
      rtk->ssat[i-k].vsat[f]&&
      rtk->ssat[j-k].azel[1]>=rtk->opt.elmaskar&&!nofix)
      }
      should be this
      {
      if (rtk->ssat[j-k].lock[f]>=0&&!(rtk->ssat[j-k].slip[f]&2)&&
      rtk->ssat[j-k].vsat[f]&&
      rtk->ssat[j-k].azel[1]>=rtk->opt.elmaskar&&!nofix)
      }

      index i must be changed to j

      Like

  4. Hi Tim,

    Thanks for the update, and this valuable service!

    I would like to mention a behavior in rtknavi … I don’t know this can be corrected.

    Sometimes I use the rtknavi for log data from a GNSS network in my country (Brazil), using the options to redirect the streamings to files (“Log Streams” button)

    But I noticed that the rtknavi flush the content of the file to disk just when I press the “stop” button.

    It’s is not a big problem, but, for a reason where the PC running the rtknavi gets some problem with energy/power supply/hardware problem/disconnection … several hours of logging can be lost

    It’s possible to insert an update in code in order to flush the file contents some times while the rtknavi still running?

    I’ll download this new version to test with some data sets (from PPK in drones). If I notice something, I’ll notify you.

    Thanks again!

    Thiago Tiedtke dos Reis

    Liked by 1 person

    1. Hi Thiago. The “Output Streams” menu in RTKNAVI has a “Swap Intrv” option which will save the file at the selected interval and then start a new output file which, in addition to forcing periodic file writes, will keep your data in more manageable size chunks for processing. If you need a single file you can always combine the multiple files later. Just be sure to use appropriate keywords in the file name so that it changes on every iteration or it will overwrite the previous one. You can get a list of keywords by clicking on the “?” next to the “Swap Intrvl” box. The other RTKLIB apps in general have the same capability.

      Liked by 1 person

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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.