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.

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

  1. Hello tim,
    first of all thank you for the excellent version of rtklib especially for low-cost receivers.
    I discovered a small bug in the demo5 b34b code: with RTKPLOT the export of AZ/EL/SNR/MP only returns an empty file when raw data is read in.
    however in older versions (e.g. demo5 b33c) the export works as expected.
    maybe you don’t know the error yet and you could fix it in the next version.
    best regards,
    Jan

    Like

  2. Hi,
    I have problems using Galileo in rtk postprocessing since version b34a.
    b33f is working correctly.

    The virtual base station file is from AxioNet and using the C1X, L1X, S1X, … obs types for Galileo.
    There are 48 obs types for GAL in the rinex header but most of them are not used and the data colums are empty (e.g. C1C, L1C,…)
    In the trace file I can see that the obs data is not read correctly:

    3 rtkpos : time=2019/11/21 09:41:34.900 n=37
    4 obs=

    (24) 2019/11/21 09:41:25.000 E04 rcv2 0.000 0.000 0.000 0.000 0 0 0 0 0 0 0.0 0.0
    (25) 2019/11/21 09:41:25.000 E05 rcv2 0.000 0.000 0.000 0.000 0 0 0 0 0 0 0.0 0.0
    (26) 2019/11/21 09:41:25.000 E09 rcv2 0.000 0.000 0.000 0.000 0 0 0 0 0 0 0.0 0.0
    (27) 2019/11/21 09:41:25.000 E36 rcv2 0.000 0.000 0.000 0.000 0 0 0 0 0 0 0.0 0.0

    Any idea how to fix this?

    Thanks!
    Phil

    Like

    1. Hi Phil. RTKLIB has a table of code priorities for each constellation frequency. It will use the highest priority code in the obs file header for each constellation frequency, even if these observations are intermittently or completely empty in the observation data below. If this is the issue, then the easiest way to deal with it is to run the obs file through RTKCONV or CONVBIN with the input format set to “RINEX” and the “Mask” options set to eliminate all but the signals that are present. If this does not fix the issue then please send the rover and base observation files to me at rtklibexplorer@gmail.com and I can take a closer look.

      Like

  3. Demo5 b34b shows incorrect values after enabling option show statistics in plot. And is it possible to copy the statistics to clipboard ?

    Like

    1. Hi g01. If you can be more specific about the issue you are seeing I would be happy to take a look. If you could email me an example solution file that demonstrates the problem that would be even better. I just did a quick comparison of the statistics for the demo5 b34b, the demo5 b33f, and the 2.4.3 b34 versions of RTKPLOT and do not see any differences between them. As far as I know, there is no way to copy the statistics as text to the clipboard.

      Like

      1. Sorry, my fault. I did not notice that default option for Coordinate Origin is Base Station. It took me a long time to find it. Statistics are correct. Once again I apologize for my mistake.

        Like

      1. Hi M1essam. The “msc” folders were removed as part of the official RTKLIB 2.4.3 b34 update, probably to reduce the effort needed to support multiple compilers. The demo5 code inherited these changes when I merged them in. My guess is that the “msc” folders from the b33 code should still work fine with maybe just minor updates with the b34 code.

        Like

  4. Hi, do you know if it is possible to generate C2X / L2X RINEX GPS codes with version B34 of RTKCONV? I am collecting data with a ZED-F9P and if I use RTKCONV version B33 I can successfully generate C2X / L2X observable codes from my raw UBX data – list of codes generated is:
    C1C L1C D1C S1C C2X L2X D2X S2X

    However if I use RTKCONV version B34 I can only generate the following:
    C1C L1C D1C S1C C2L L2L D2L S2L C2S L2S D2S S2S

    The reason I ask is that I want to post-process data through the AUSPOS service. This requires GPS dual-frequency obs but does not support C2L / L2L / S2L / C2S / L2S / S2S. It does however support C2x / L2X on the L2 band (and L1 band data is fine for this receiver).

    So essentially I can create an AUSPOS compatible RINEX file with RTKCONV version B33 but not B34. B34 is able to correct for quarter cycle phase offsets on the L2 band data so would be the preferred choice. Any ideas on B34 emulating the B33 behaviour in regard to C2X / L2X?

    Thanks.

    Like

    1. Hi Lee. This is a good question and something I have been struggling with how to handle in the B34 demo5 code. The L2L/L2S codes are the actual codes that the F9P is decoding and so technically they are the correct answer. Labelling both codes as L2X was a work-around I borrowed from the Emlid code since RTKLIB was not able to properly handle multiple codes from the same frequency. Some of the changes merged in from the 2.4.3 b34 version of RTKLIB were aimed at improving the handling of multiple codes including specifically the C2L and C2S codes for the F9P but I believe this feature is still not fully functional. I was not aware of the issue you are running into but I was already leaning towards returning to the L2X work-around and will most likely do that in the next release. I think I will add a receiver option to enable the C2L/C2S reporting for those who may need the correct codes.

      Like

      1. Thanks for the prompt reply. I’ll take a good look through the change-logs for any upcoming releases. Thanks again for all your work on this project -it’s great! Cheers.

        Like

        1. Hi Lee. The newly released demo5 b34a code defaults to the b33 behavior with combined codes for the F9P (e.g L2L and L2S -> L2x). For anyone who prefers the separate codes, you can use the new “-MULTICODE” receiver option to record them instead of the combined codes.

          Like

  5. 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

  6. 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

  7. 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

  8. 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 comment

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