Dual-frequency PPK solutions with RTKLIB and the u-blox F9P

With previous generations of u-blox receivers there has been a lower priced option available without an internal RTK engine, such as the popular M8T in the generation 8 modules. This does not appear to be the case with the new dual-frequency generation 9 modules, as the F9T, without internal RTK solution, is currently priced higher than the F9P with internal solution.

As the u-blox internal RTK solution in the F9P appears to be very robust, there is probably no good reason to ever use RTKLIB for real-time solutions with the F9P. However, it often still makes sense to use RTKLIB to post-process raw data previously collected by the F9P since the F9P is not capable of post-processing solutions.

Post-processed (PPK) solutions have several advantages over real-time solutions. The rover hardware is simpler, less expensive, lighter, and lower power since post-processing does not require a real-time data link between base and rover. Post-processed solutions also tend to be more robust than real-time solutions, both because they are not subject to data dropouts in the base data link and because they allow for solution techniques that take advantage of both past and future observations, not just past observations. When the solution is not required in real-time, it often makes more sense to collect the data first and then process it later.

Collecting data and processing RTK solutions for the dual-frquency F9P with RTKLIB is not very different for doing this for the single-frequency u-blox M8T, and if you are already familiar with doing that, you will probably not have much trouble adapting to the F9P. However, since it’s been a long time since I did a post on this subject, I thought it would be worth going over again with some updated tips for the new receiver.

Step 1: Configuring the receiver:

To process an RTKLIB solution, we will need raw observation messages from both rover and base receivers and navigation data messages from one of the receivers. The receivers do not output these messages by default so we will need to configure them to do this. With the u-blox M8T it was possible to do this directly with RTKLIB using a command file but this is not an option with the F9P as RTKLIB does not currently support the new F9P configuration messages.

Instead we will download the u-blox u-center app and use this to configure the receivers, then save the results to the on-board flash. There are detailed instructions on how to do this in the F9P documentation available on the u-blox website but here’s a quick summary of the process.

  1. Plug the receiver into a Windows PC using a USB cable if the board supports USB or with an FTDI serial/USB converter if the receiver only has a UART port.
  2. Start the “u-center” app and connect to the receiver with the “Connection” command on the “Receiver” tab. If it is a USB connection, baud rate won’t matter, but if it is a UART->USB connection through FTDI, then you will have to set the correct baud rate from the “Receiver” tab. If all is well, you should see the green connection indicator flashing at the bottom of the screen
  3. From the “View” tab, open the “Messages”, Configure”, “Gen 9 Configure”, and “Packet Console” windows
  4. If using the UART port, click on “PRT (Ports)” from the “Configure” window, set the Target to “1-UART1” and “Baudrate” to the desired baud rate, and click on “Send”. I typically set this to 115200 baud. You will then need to change the baud rate in u-center to the new baud rate. If you are using the USB port directly, you can skip this step.
  5. From the “Configure” window, click on “RATE”, and set “Measurement Period” to the desired time between observation samples, then click on “Send”. I typically set this to 200 ms which gives a 5 Hz sample rate.
  6. From the “Gen 9 Configure” window, select “GNSS Configuration”, enable the desired constellations and signals, select “RAM” and “Flash” under “Layer Selection”, then click on “Send Configuration”. The F9P supports GPS L1C/A and L2C, Glonass L1 and L2, Galileo E1 and E5b, BediDou B1 and B2, and QZSS L1C/A.
  7. From the “Messages” window, right click on “NMEA” and then click on “Disable Child Messages” to disable all the NMEA messages. None of these are needed for an RTK solution but if you want any of the messages for other reasons you can then individually enable the ones you need.
  8. From the “Messages” window, double click on “UBX” then “RXM”. Right click and enable “RAWX” to enable raw observation messages and “SFRBX” to enable navigation messages. Alternatively, you can enable the RTCM3 messages from the “Gen 9 Configure” window. In this case you will want to enable the 1077,1087,1097,and 1127 messages. I have occasionally had trouble enabling the RTCM3 messages on the F9P and have had to use the “Revert to default configuration” option under the “CFG” command first to get this working.
  9. If an antenna is connected to the receiver and is not completely blocked, verify that you see RAWX and SFRBX messages appear in the “Packet” window.
  10. From the “Configure” window, select “CFG”, then “Save current configuration” then “Send” to save these settings to the flash on-board the F9P module.
  11. Repeat this procedure for the base receiver except set the “Measurement Period” under “RATE” to “1000 ms” for a 1 Hz sample rate. You will only need one set of navigation data so you can choose not to enable the SFRBX messages on the base. I tend to leave them enabled just because it makes plotting slightly easier later if each set of observations has its own navigation data.

If you have any trouble with the above summary, you might find this YouTube video from Robo Roby useful. It is intended for setting up the F9P for real-time solutions, not post-processing, but there is a lot of overlap between the two.

In the descriptions below STRSVR, RTKCONV, RTKPLOT, and RTKPOST are all RTKLIB GUI apps. They can be opened individually or you can start by opening RTKLAUNCH and run the individual apps from there. I do not believe the official 2.4.2 or 2.4.3 versions of RTKLIB fully support the F9P receiver yet so I would recommend using the demo5 version of RTKLIB available here.

RTKLAUNCH used to open the different RTKLIB apps

Step 2: Collecting the data:

  1. For this exercise I will connect both base and rover directly to a Windows PC through the USB port. You can connect both receivers to one PC or each to a separate PC.
  2. Launch two instances of STRSVR, one for each receiver
  3. Set the input stream to “Serial”, click on the input “Opt” button and set the port and baud rate. Set the output stream to file and click on the output “Opt” to set the file name. Click on the “?” to get a list of keyword replacements for the file name. I like to add “_%h%M” to the end of the file name which will append the hour and minute of the data to the file name. If you are collecting long data sets you might want to set the “Swap Intv” to break up the data into manageable file sizes. Note that you will need to use the keywords in this case to avoid overwriting the same file repeatedly. Give the file name a “.ubx” extension to let RTKLIB know that it is u-blox binary data.
  4. Click “Start” to start collecting data.
STRSVR used to collect the raw data

Step 3: Convert the observation data to rinex format:

  1. Start the RTKCONV app
  2. Click on the “…” button to the right of the “RTCM, RCV RAW or RINEX OBS” field and select the observation file created in the previous step.
  3. If the file extension is not “.ubx” set the “Format” to “u-blox”, otherwise leave as “Auto”
  4. Click on the “Options” button and select “L1”, “L2/E5b”, and all GNSS constellations collected (usually “GPS”,”GLO”,”GAL”, and possibly “BDS” (Bediou) depending on your location. Then close the options menu.
  5. Click on “Convert” to convert from binary to rinex format.
RTKCONV used to convert the raw data from binary format to rinex text format

Step 4: Review the observation data:

  1. Before processing the solution, it is a good idea to look at the data first and make sure it is complete, of reasonable quality, and at the right sample rate.
  2. From the RTKCONV main window, click on “Plot” to plot the observations you just converted.
  3. Verify there are observations from all constellations. Green indicates dual frequency measurements, yellow is single frequency. The GPS observations will be a mix of single and dual frequency since only about half of the satellites currently support L2C used by the F9P, but the other constellations should be nearly all dual frequency.
  4. Red ticks indicate cycle slips. Too many of these will make it difficult to get a decent solution. Gaps in the data usually indicate the receiver lost lock and these are not good unless they are in the low elevation satellites.
  5. If all the satellites are in gray, this usually indicates you are missing the navigation data. The previous step should have generated a “.nav” file as well as a “.obs” file. If just a few satellites are in gray, this normally indicates that they are below the elevation threshold which can be adjusted in the options menu selected in the top right corner with the star-like icon.
  6. Check both rover and base observations.
  7. In some cases you may only have one set of navigation data and so not have a matching “.nav” file for one of your observation files. In that case you can manually specify the navigation data with the “Open Nav Data…” option in the “File” tab.
Plot of raw observations

Step 5: Generate the position solution

  1. Open RTKPOST
  2. From the “…” buttons on the right hand side of the GUI, select the rover observation file, the base observation file, and the navigation file as shown in the example below.
  3. Click on the “Options” button and then the “Load” button. Select the “demo5_m8t_5hz.conf” file from the same folder as the demo5 RTKLIB executables, and then click on “Open”
  4. From the “Setting1” tab in the “Options” menu, enable “Galileo” and if applicable “Bediou”. “GPS” and “GLO” should already be enabled.
  5. From the “Setting2” tab in the “Options” menu, set “Integer Ambiguity Res (GLO)” to “On”. We are able to use the “On” setting in this case because the receivers are identical and so the Glonass hardware biases cancel. If you are not using an F9P receiver for base, then leave this field set to “Fix-and-Hold” which will automatically calibrate out the biases.
  6. From the “Setting1” tab in the “Options” menu, change the “Frequencies” from “L1” to “L1+L2”. This is the only change you should need to make to switch from processing single-frequency data to dual-frequency data for the F9P. The Galileo second frequency for the F9P is actually E5b not L2 but to simplify and improve the processing speed, I have modified the demo5 code to include “E5b” processing as Galileo’s second frequency. This won’t be the case for the 2.4.2 or 2.4.3 code. I don’t believe it’s currently possible to include the E5b data with these versions of RTKLIB but if I’m wrong please let me know
  7. Click on “OK” to close the Options menu.
  8. Click on “Execute” to run the solution. The bar at the bottom of the GUI will show the solution status as it runs and will report any errors. You should see a mix of Q=1 and Q=2 as the solution runs. If you see only Q=0, something is wrong. In this case, open the “Options” window, select the “Output” tab and set “Output Debug Trace” to “Level3”, exit the Options menu, and rerun the solution. Then open the “.trace” file in the solution folder for additional information on what went wrong.
  9. Click on “Plot” to plot the solution with RTKPLOT
RTKPOST used to generate a PPK solution
Plot RTKPOST generated PPK solution

This was just meant to be a quick summary of the process. For more details please see the references below.

References:

  1. u-center User Guide
  2. u-blox F9P Interface Description
  3. RTKLIB manual
  4. Updated guide to the RTKLIB configuration file

117 thoughts on “Dual-frequency PPK solutions with RTKLIB and the u-blox F9P”

  1. Hi Eric!
    After successfully using a pair of u-blox C099-F9P boards setup as a base and rover I decided to try the NTRIP Client built into u-center which I was also able to get working. Now I want to use an NTRIP client other than u-center and I have tried using STRSVR.exe from Demo5_b34a but I have obviously not set things up correctly. I have tried this with my own Windows App and with u-center but I cannot get it to work. I created a diagram to show some of the specifics of the setup (see link below). Please note that I am using the same NTRIP client details with the U-Center NTRIP Client which is working correctly. Any pointers would be much appreciated.

    Like

    1. Hi Ross. Use the Input Stream Monitor Window in STRSVR (click on the small square above the Stop button) to verify the incoming RTCM stream. If that looks OK then I suspect you have a communication issue on the serial port between STRSVR and the F9P. If you really want to test the same configuration between u-center and RTKLIB you should either use two serial ports in both cases or just one serial port. You can use try with two instances of u-center if you want to use two ports or use the “Output Received Stream to TCP Port” option in the STRSVR serial port output config to use a single port with STRSVR. In this case the incoming stream from the F9P will be piped to a TCP port which can be monitored by u-center.

      Like

      1. Hi Eric,
        Thank you for your reply. Unfortunately, I am such a noob that you have completely lost me. I am not sure if what I am seeing in the Input Stream Monitor is OK or not. I am attaching a screenshot in case it helps. I am trying to use u-center as a way to verify fixed or float etc. on the F9P board. I am able to connect my own Windows App to the ‘Serial Device’ on the F9P board and at the same time u-center to the ZED-F9P port on the F9P board. By turning on the NTRIP client in u-center it is able to send RTCM3 messages to the F9P and my App sees the board go into Fixed mode. I am not able to get the same result connecting STRSVR to the ZED-F9P port. I guess I am trying to figure out the simplest way to verify I am setting up STRSVR correctly?

        Like

        1. Hi Ross. If u-center is working for you then it may be easiest to just use that. The point I was trying to make in my earlier reply was that your u-center setup is using one F9P serial port and your STRSVR setup is using two F9P serial ports so they are not equivalent. The F9P has some constraints on the second serial port so that may explain why you are seeing different results between the two cases. If setup correctly though, STRSVR is definitely capable of providing NTRIP corrections to the F9P. All of the RTKLIB apps have options to log the inputs and outputs so I would use these to debug your issue. STRSVR is just a stream server to pipe a data stream from one port to another, so if the output log of STRSVR matches the input log, then STRSVR is working fine.

          Like

          1. Hi,
            I was able to get the NTRIP client at http://lefebure.com/ working with the F9P. If I find the time I will try some more experimentation with STRSVR. The Lefebure NTRIP client can also be run in a batch mode so it should work OK for me. I am not sure if U-center can be run in a batch mode though I doubt it was ever intended for that. Thanks again for your help. I think my next big challenge is trying to get a pair of F9P rovers to produce an accurate heading. I would love to hear any thoughts you have on using RTK to produce highly accurate headings.
            Ross

            Like

  2. Thank you for the tutorial.
    Is there a way to log raw data for PPK at the same time as using the realtime solution offered by the F9P ? A comparison between both would be interesting !

    Like

    1. Yes. You can include NMEA sequences in the UBX files, so you will have both the real time solution and raw data for post-processing.

      Like

    2. Hi Web Van. I actually did the comparison you describe in this post. There is a summary comparison table at the end of the post between the internal F9P RTK solution and the RTKLIB PPK solution. I found that the F9P internal solution is very good and roughly equivalent to a combined forwards/backwards PPK solution with the demo5 RTKLIB. I have made some improvements to RTKLIB since then but I suspect the two are still fairly equivalent. This comparison was done with reasonably good quality raw observations. As the quality of the observations gets worse, the internal F9P solution will hold up better as it will automatically switch to more robust but less precise solution modes while RTKLIB will not.

      Like

      1. Thank you for the link that was a very interesting read. I’m impressed by your results with the M8T as I find it hard to get a fix while driving around, the local base probably helps as I use a distant Ntrip stream. I’m waiting for a second Mi8 receiver.
        I’m also thinking of getting a DF SkyTraq based Polaris Alpha+ receiver as they are a lot cheaper than the uBlox receivers. Have you ever used one?

        Like

          1. Sure, I’m still debating getting the Ardusimple “RTK Portable Bluetooth Kit” ZED-F9P https://www.ardusimple.com/product/simplertk2blite-bt-case-kit/ or the SkyTraq Alpha+. More or less the same price but the F9P is probably the safer bet. However it doesn’t seem like the Bluetooth output can have both the raw UBX and NMEA streams while the Alpha+ has a built-in SD car reader for standalone operation.

            Like

          2. Hi Web Van. I am not familiar with the Skytraq Alpha+ receiver. I am a big fan of both the F9P receiver and the Ardusimple boards. However, there are some issues with the Ardusimple bluetooth solution. I don’t know the details for the SimpleRTK2BLite board, but if you are trying to log the raw UBX messages RAWX and SFRBX through bluetooth, it is not possible to do this with the SimpleRTK2B V1 board. This is because the F9P will only output these messages on UART1 and the Ardusimple board will only allow the bluetooth to be connected to UART2. This is fixed with the V3 board but I was unable to change the bluetooth baudrate on the V3 board. Fortunately I had a V1 board and was able to change the baudrate with this and then move it back to the V3 board. This is not ideal and would not be possible if you did not have both boards. I prefer to use a bluetooth HC05 module rather than the Arudsimple bluetooth board. It is much less expensive and can be connected directly to the UART1 pins on the Ardusimple board. It may be that they have fixed all this on the SimpleRTKBlite board, but it would be worth verifying before you bought it. As long as you are using UART1 and set the baud rate high enough, it is possible to output both raw UBX and NMEA on bluetooth with the Ardusimple boards and I have done this.

            Like

          3. Thanks for this detailed information, I did find out in the meantime that the SimpleRTKBlite “all in one” solution could only output NMEA data at this time. They are working on a firmware release for the summer that would allow both ubx and NMEA via Bluetooth. I’ll look at the other options you mention but I like it because it’s “all-in-one” although not as much as the Sparkfun module as it lacks a a battery 😉 It’s too bad there’s never been a uBlox 8 or 9 standalone Bluetooth GPS receiver with an external antenna connector. Probably not much of a market I suppose…

            Like

          4. Once upon a time there was this https://www.amazon.com/Bluetooth-NEO-M8N-Compass-STM32F103T8-Antenna/dp/B01M1H7TAW

            The ZED-F9P can output RTCM3 via UART2, people have used that to recover RINEX observation files.
            The newer ArduSimple board has more routing options, personally I’ve been using data from the shield side. I’d have to contrive a logging system to record solution and observation data concurrently and try some F9P, F9R and F9K implementations. I’m half tempted to put it on an STM32 DISCO board with a screen and microSD card, and plot the outputs from the spectrum analyzer too. I have a LoRa XBee radio solution coded now so can in-board the RTCM3 data from the existing infrastructure.

            In terms of wandering off I’ve seen people with issues of signal loss (GNSS side), and loss of observation messages resulting in a decay of accuracy as in fails over into DGPS/SBAS territory. One needs to watch the reported Position Accuracy (pAcc). The antennas are very sensitive to electrical noise (cables, switching noise, GPIO signals/clocks), and the receivers to brezzes and drafts.

            Like

          5. I just found an interesting RT comparison between F9P+RTK and Internal F9P in a challenging environment (urban motorway) https://youtu.be/UMk6ROFWl68
            I’m not sure if the plot on the right is the RTK or the Internal solution. Having both would have been great but the errors are shown in separate graphs.

            Like

      2. While driving in mountain under tree cover, I was quite impressed by the smoothness of the instantaneous solution (without RTK) provided by the F9P. In parallel, RTKLib post-processing of raw data was rougher. There should some magic with Kalman filters in the F9P.
        I’m considering using the instantaneous solution to smooth the RTKLib solution when fix is not obtained.

        Like

        1. Hi Eric. The internal RTK solution of the F9P is very good and will be more robust than the RTKLIB post-processing solution to lower quality observations, in part because it is able to switch to more robust but less accurate solution modes to adjust for the observation quality. The standard precision (no RTK) mode in the F9P is the most robust and may be the best choice when in very challenging conditions. I like to collect both raw observation messages and NMEA position messages when using the F9P so that I have the option to switch to the F9P solution when the observation quality is too poor for a PPK solution.

          Like

          1. Even more, this week-end, I started using real time RTK through the centipede network (https://centipede.fr/). I made a first test on a motorway. I had fix nearly all the time. When driving under bridges, you have 1 or 2 s of DGPS, 2 or 3 s of FloatRTK before being back to RTK with a very smooth track. So, when network is available, post-processing seems to be useless. I will still make a comparison with RTKLib. And I need to make comparison on mountain roads.

            Like

          2. Hi Eric. I would recommend using the F9P internal RTK solution whenever you have continuous good cellphone or internet coverage and an easy way to link this to the rover. Otherwise post-processing can often be the easiest and most robust solution since it doesn’t rely on a continuous data link to the rover.

            Like

          3. Well, I want to combine the best of the two. It is indeed trivial when there is fix on one side. It is more complicated when there is no fix on both. I will explore more carefully on sample data and see what can I do.

            Like

          4. Hi Eric. Each solution point has an estimated accuracy associated with it, so I would suggest a weighted average between the two float points based on the estimated accuracies and have used this technique myself.

            Like

          5. @Tim, I’d need to engineer something, but I think collecting and analyzing this sort of thing would be universally helpful and illuminating. I do have some ZED-F9P that can generate two solutions (with/without type thing), and I need to review some of the debug messages to see what I can pull out of those.

            Like

        2. @Eric – Yes even with the M8N the non-corrected internal solution is generally smoother than the post-processed RTKLib solution, likely due to some clever filtering being done, but it can “drift” unlike the RTKLib, even in Float mode. I compared Internal/RTKNavi (w/centipede)/RTKPost and RTKNavi didn’t fare very well compared to RTKPost.
          What’s your F9P setup ?

          Like

          1. I’m using a DIY logger : https://github.com/PaulZC/F9P_RAWX_Logger
            – F9P from sparkfun
            – adafruit feather board M0 adalogger (on uart1)
            – I added a sparkfun BT Smirf silver board (on uart2) for connection with the smartphone

            For the F9P single position, I observed one time a big drift, like 10 m off for 1 km in a quite open area.

            Like

          2. Hi Web Van. I haven’t used the internal F9P solution a lot but have been mostly impressed with it when I have used it, although it is true that I have seen a few more false fixes with the internal solution. I have also seen some other posts on the Emlid forum that suggest the RTKLIB solution can be more accurate than the internal F9P solution. If you (or anyone else) has a data set with both raw observations and F9P solution that demonstrates the difference and would be willing to share it, I would like to explore this further.

            Like

          3. I recently did a static record on a geodetic reference. The antenna was not very precisely positioned over the reference and I didn’t measured the elevation of antenna versus the reference. RTK/RTCM station was 45 km away. I used two reference stations for post-processing : one at 5 km (same elevation, GPS+GLO), the second at 11 km (high in the mountain, GPS+GLO+GAL). Post-processed solutions were closer to official value (2-3 cm) than RTK (~4 cm). They were also less noisy, nearly mm stable over 20 mn, instead of moving about 2-3 cm (F9P was in Automotive mode).
            I will try to make new more careful measurements with a longer session.
            I also did a try on motorway for 60 km (cruise speed of 30 m/s). When having fix on both methods, average horizontal distance was of 4,4 cm. E-W difference average was 4 mm, N-S 32 mm. Big bias in elevation of 17 cm (sigma 4 cm). So, except for Z, this is within error bars.

            Like

          4. Great results ! What tool did you use the measure the average difference for the kinetic test ? On the open road I’d expect the results to be close but in an urban environment the built-in solution should be much better with the built-in smoothing algorithms that RTKLib can’t perform after the fact, AFAIK at least.

            Like

          5. “I just opened booth files in excel.” sound easy !
            Based on your previous I thought you had compared both the live and PPK solution and calculated the distance between the tracks which seemed difficult to do. Still, I can see how you would get the average “calculated” error from the .pos file with RTKPost but I’m not sure how you’d do that from the NMEA stream fed by the F9P ?

            Like

  3. Hi, I have some beginners questions doing PPK using RTKPOST:

    I have a Rover observation file from a drone that took measurements at 0.2 seconds intervals. My base observations file took observations in 1 s intervals. I’m getting a good result, however, I don’t understand why the solution file contains data at 2.2 seconds time intervals. Why am I not getting data at 1 s intervals, as their should always be a point of time matching base and rover at the 1 s interval. Is there a certain setting for the program that I have missed?
    All data points from my solution are getting a fix status (Q = 1), only a single point is in float status (Q =2). Whatever setting I try, doesn’t change anything. Is it possible that there is a problem with the quality of the source data (rover file)? Any ideas what I can do to improve the solution.

    Thanks in advance if somebody can help me out here.

    Like

    1. Hi Markus. In general, RTKLIB should generate a PPK solution point for every rover observation as long as it can find a matching base observation. The most likely reason it would not find a base observation is if you have set the “Max Age of Differential” in the Setting2 options too low. This value is the largest allowed difference between rover observation time stamp and base observation time stamp. If that doesn’t explain your issue, then I would enable the Debug trace at level 2 and look for errors in the debug trace file.

      Like

      1. Thanks a lot for your help!

        I found out that it works, when I reduce the settings for elevation mask, which was originally set to 15°. I’m now getting a solution for every rover observation. I noticed that now the number of satellites (ns) in the solution file went up from 9 to 10 with elevation mask at 15° to 11 satellites even with elevation mask set to 0°. Should that number not be higher, as my rover and base observation file contain observations from around 25 satellites (GPS, Glonass, Galileo)? I activated to use GPS, Glonass and Galileo in Settings 1. I also noticed that the age values for each solution are negative. Is that normal? Also the ‘ratio’ looks weird. Some solutions have ratios of up to 900. I will later try to adjust the “max age of differential” value, as you suggested. It is now set to 30 s which should be sufficient, I guess?

        Like

        1. Hi Markus. It’s possible you are missing navigation data for one or more of your constellations. I would plot both base and rover observations with RTKPLOT, set the elevation threshold in the RTKPLOT options to something greater than zero, then confirm all satellites appear in color, not gray. A gray satellite indicates either it is below the minimum elevation threshold or it’s missing navigation data. Setting the elevation threshold too low will tend to degrade the solution since the low elevation satellites are most affected by multipath and have the longest signal path through the atmosphere.

          Negative age values just indicate that the closest base observation was later in time than the rover observation and are not an issue as long as they are not too large. A max age of differential of 30 seconds should be fine. Large AR ratios are normal when ambiguity resolution is set to Fix-and-Hold.

          Like

  4. Hello, good morning to the community.
    I would like to know if there is any guide on how to add RTCM 3.1 or RTCM 3.2 messages to ZED F9P boards.
    I have an ArdusimpleRTK2B V3 board and my NTRIP provider supplies me with the following messages: 1004, 1012, 1033, 1230, 1008, 1005, 1013 with which I do NOT reach “RTK fix”. On the Ardusimple support page, they told me that the solution was for my provider to enable RTCM 3.3 messages or for me to add older RTCM messages (RTCM 3.1 or 3.2). I lean towards the latter, since I don’t think the NTRIP provider will modify their software just to please me.
    Thank you for your cooperation.

    Like

    1. Hi Cecil. The F9P supports all the legacy RTCM messages you list except 1008 and 1013. Those two messages are not required to achieve RTK fix. The legacy RTCM messages do not contain quite as much information as the newer MSM messages, but still should not cause any issues with achieving RTK fix. The F9P does not need to be configured differently to receive the legacy messages so you should be able to follow the instructions provided by Ardusimple or other online sources to configure the F9P. The most common problem I see users having with NTRIP bases is when they are using virtual reference mount points (VRS). These typically have “VRS” in the mountpoint name and require that the rover be configured to send periodic NMEA GGA messages with the approximate rover location to the base. If you are using a RTKLIB stream server (STRSVR or STR2STR) you will need to specify the base location and enable the NMEA Cycle option as described in the manual. If you are using u-blox u-center you will need to follow the instructions in section 6.1 of the u-center user guide.

      Liked by 1 person

  5. F9P post-processing: meters of inaccuracy
    Hi, I’m using f9p on Sparkfun GPS-RTK2 board for post-processing, I’ve been playing around with it for a few weeks now but can’t seem to get it to work on it’s near-up-to-specification performance.

    Base station: GPS SparkFun GPS-RTK-SMA,
    survey multiband GNSS antenna, AS-ANT2B-SUR-L1L2-25SMA-00

    Rover: GPS SparkFun GPS-RTK2,
    active stacked patch (GPS L1+L2+L5) Abracon antenna, APARC2511X-SGL2L5

    I’m using them as rover and base separately, and I collect data from them and post-process on RTKLIB.

    However I am only able to get Float PPK solution for most of the time (78% of the test).

    Here’s my set-up:

    The base station’s antenna is placed at floor on open space, good sky view.
    The rover is moving at the floor on the same open space when capturing. Both of them are connected to two different windows pcs trough USB cable.

    Base is in TIME fix mode using Survey in mode:

    Minimum Observation Time: 300 [s]
    Requiered Position Accuracy: 1 [m]

    Message:
    Both Rover and Base are collecting UBX-RXM-RAWX and UBX-RXM-SFRBX message data.

    Rover is 1Hz message rate and base is 5Hz message rate.

    Post-processing
    I am post-processing the data using RTKLIB demo5_b33b, provided by rtklibexplorer, which is supposed to have the functionality of processing F9P data.

    The settings in RTKPOST are which give me the best results until now:

    Settings1:
    – Positioning Mode: Kinematic
    – Frequencies: L1+L2
    – Filter Type: Combine
    – Elevation Mask: 15°
    – Iono/Tropo Correction: Broadcast/Saastamoir
    -Satellite Ephemeris/Clock: Broadcast
    -Satellites Constellation activate: GPS – GLO – Galileo

    Settings2:
    -Integer Ambiguity Res (GPS/GLO/BDS): Fix and Hold / ON / OFF
    – The rest of the options are set by default.

    So far I’m not getting post-processing output accuracy. It seems rover’s antenna could be the problem. Below some examples of the rover observation data:

    Images of satellite’ s bands:

    Base: https://drive.google.com/file/d/16zgEQ-c1TfIl2DaDIqaQxGjr1pbAuof_/view?usp=sharing
    Rover: https://drive.google.com/file/d/1oXAWxWNXJvAS1vsegrnuOV3RPIM0TIjB/view?usp=sharing

    ————–<>—————

    Questions I have:
    1. Is the Abracon antenna, APARC2511X-SGL2L5, the reason of the poor performance to get fix solution?
    2. How can I improve to get good result?

    I’m very frustrated but perhaps I might be missing some obvious things all this time. I would really appreciate it if anyone can provide any tip to overcome this situation.

    Thanks in advance,
    Matías.

    Like

    1. Hi Matias. Your rover observations do look much worse than the base, especially the Glonass observations. Your base observations look quite good. I would swap the antennas and see if the results follow the antenna. If so, I would replace the antenna. If not, there could be an electrical noise or EMI issue in the rover. If you want to try and improve the solution results with the current configuration I would experiment with disabling Glonass in the solution, but I would only use this at best as a temporary band-aid until you can fix the root problem.

      Like

  6. I never get a smooth-continue obs data after RINEX convertion process. If I look at the PLOT OBS data.. then Zoom in.. i found the data not continue.. there are always a little GAP.. Is it normal with UBLOX???

    Like

    1. Hi Catur. If you are consistently seeing missing observations in the raw data with u-blox receivers the most likely explanation is that the UART baud rate is set too low for the volume of data the receiver is trying to output. Even if you are not using the UART, if it is enabled within the receiver and set to a low baud rate it can cause missing observations on the USB or other interface ports. You can also see this problem if you try to set the sample rate higher than the receiver can support but you should always be able to go to at least 5 Hz without problem and usually higher provided the baud rate is set to at least 115K.

      Like

      1. Have you ever try to zoom in your data? please check… I’ve try many combination.. (1) with openlog module (2) with USB direct hyperterminal (3) with bluetooth (4) with Wifi Module.. all of the connection with 115200 baudrate. I think the problem is at the Conversion RTKCONV mat be.. not in the logger.. please check.. thank you anyway

        Like

        1. If you get “txbuf alloc” messages the receiver is log-jamming on one or more interfaces. They share a common resource pool, and it is readily exhausted.
          Check UBX-MON-IO / COMMS / TXBUF reporting to understand utilization.
          Cull messages on unused interfaces, and ones you don’t need at high rates, ie GSV, UBX-NAV-SAT / SIG

          Like

          1. Thx Clive1 .. Do you agree the problem is on RTKCONV not in data streaming / log ?? Then how can we get a smooth continue no gap data?

            Like

        2. Hi Catur. Yes I regularly check my observation data and other people’s data for missing observations by zooming in since this is a very common problem. Like Clive, I think this is mostly likely an issue with bottlenecks in the receiver output interface due to incorrect configuration. I would follow his suggestions to try and debug it.

          Like

          1. other issue is the time-record is not integer like other professional geodetic receiver. So sometimes we can not used branded product for best result in post processing. in this case we can use RTKLIB for getting fixed solution

            Like

  7. Good night.
    What does the comment in the simpleRTK2B-F9P V3 description mean: “Selectable UART1 / UART2 connection to the XBee socket, to be able to send UBX protocol over the air”. Does it mean that UBX messages can already be logged to UART2?

    Like

    1. No, there are no UBX messages on UART2, you can record RTCM3
      The V3 board has a switch allowing the radio to connect to UART1 instead of UART2, providing for pushing UBX, NMEA or RTCM3 over the data-link.

      Like

  8. Hi, I am looking for a receiver with raw data output and I always read about the M8T. From your article I understand, that the F9P is also capable to output raw data (further to the internal RTK solution). What about the other series 9 ublox modules? Do they output raw data?

    Actually I do not need internal RTK. Is it a disadvantage to use RTKLIB instead?

    Like

    1. uBlox RTK models generally output raw measurements, this includes F9P, F9T and F9R. I expect the F9K is capable.
      The F9H does not, and the F9R cannot output RTCM3 either.

      I have NEO-M9N’s capable, available on eBay to US buyers. Tim has a couple he evaluated.

      RTKLIB just requires that you have a single board computer capable of running the code, or port thereof, rather than just using a simple embedded MCU, where you just have to deliver RTCM3 data. The NEO-M8P and ZED-F9P can be serviced by a simple MCU in a radio.

      Like

      1. Thanks for the answer.

        I need to verify some static point and have a laptop connected to the receiver.

        Is the Sparkfun M9N able to output raw? These are available in Germany.

        How is the performance compared to the M8T?

        Like

        1. Depends what your criteria are, from a speed perspective the M9N has about 5x the horsepower of the M8T, so can track and output more channels, and can do so a much higher rates.
          Stock M9N parts from SparkFun aren’t going to do what you want.

          Like

          1. Sounds good and a better alternative to the M8T. Would you let me know, what you modified? Since I am from Germany I can not get one of yours and the stock ones are available here.

            Like

  9. Hello good day to every one. I don’t speak English (I use the Google translator) so sorry for any mistake.
    I carry out topographic surveys (stop and go) on plots that are generally in rural areas, without internet access. In a store they offer an RTK kit (Rover only) calibrated to work with NTRIP, based on simpleRTK2Blite (u-blox ZED-F9P) at a really attractive price, but I have the following questions:
    1. When I cannot access the internet, and therefore NTRIP corrections, can I record raw data on the rover and then post-process using Rinex downloaded from government geodetic databases?
    2. If this was possible, what would be the detailed procedure to carry out said configuration in U-Center?

    Like

    1. Hi Cecil. It is possible to log the rover observations and post-process a solution with downloaded base station data using RTKLIB. U-center can be used to configure the receiver for this but not to calculate the solution. I describe post-processing solutions with the F9P in this post . Be aware that the real-time u-blox solution is very very good, and unfortunately RTKLIB is not yet up to the same robustness of solution for dual frequency receivers. You can make up some of this difference by using “combined” solution mode in post-processing but it will probably still not be as robust as the real-time solution, particularly in challenging environments.

      Liked by 1 person

      1. Thank you very much for your prompt response and valuable information.
        1. Looking for information, I found a developer who has implemented a LoRa radio with which to transmit NTRIP corrections to the ZED F9P via Lefebure App, from a distance between 7 and 10 kilometers. I think it is a good option to try to work with NTRIP, because it is difficult not to find within a radius of 7 or 10 kilometers, an area with internet coverage.
        2. As the entity that regulates the production of official cartography in Colombia, yes or yes, requires that the surveys have a post-process, then I see myself in the need to implement what you suggest.
        3. I think I will implement the following working method:
        Build two milestones and capture data in static, go to the office to post-process, and then carry out the survey of the property with Total Station. Do you have any suggestions for taking static data with the F9P and its post process?

        Like

        1. Hi Cecil. One issue I have found with post-processing dual frequency static data sets with RTKLIB is that multipath is more of an issue with static solutions than it is with dynamic solutions and RTKLIB sometimes has trouble converging if multiple satellite signals contain higher levels of multipath. This is because the multipath errors vary much more slowly for a fixed receiver and so don’t average out to zero as quickly as they do for a moving receiver. I suggest increased filtering of the satellites for static solutions with higher elevation and SNR thresholds to try and eliminate some of the higher risk signals from the solution. Also, moving the receiver around before or between static points will help randomize the multipath and make the solution converge more quickly. Once it is converged, it will be more robust to multipath errors.

          Like

          1. Ok Tim, I will consider all your suggestions. Thank you for taking the time to clarify many doubts for us in the Ublox world.

            Like

  10. Hi,
    I get the messages RAWX and SFRBX from u-center. With RTKconv, I transform the ubx file into nav and obs. Then I get the .pos file with RTKPost. But I have the message :
    3 searchpcv: sat= 1 type=
    3 no satellite antenna pcv: G01
    3 searchpcv: sat= 2 type=
    3 no satellite antenna pcv: G02
    3 searchpcv: sat= 3 type=
    3 no satellite antenna pcv: G03
    3 searchpcv: sat= 4 type=
    3 no satellite antenna pcv: G04
    Also in the file pos :
    % antenna1 : ( 0.0000 0.0000 0.0000)
    % antenna2 : ( 0.0000 0.0000 0.0000)

    Cheers,

    jérôme

    Like

    1. Hi Jerome. Both debug messages are normal and don’t indicate any issues. The “no satellite antenna pcv” message indicates that you are not using phase correction values for the satellite antennas which is unnecessary for RTK/PPK solutions. The last messages just indicate zero offsets for the antenna locations.

      Like

      1. Thank you for your reply. I am correcting the nav and obs files with a file from the ign site (20o). I get an empty file .pos with RTKPost. I do not understand why.

        Like

        1. In the file .pos :

          2 18:09:38.39: point pos error (lack of valid sats ns=5)
          3 infunc : revs=0 iobsu=9891 iobsr=9865 isbs=0
          3 rtkpos : time=2020/07/01 18:09:38.588 n=18
          3 pntpos : tobs=2020/07/01 18:09:38.588 n=8
          3 satposs : teph=2020/07/01 18:09:38.588 n=8 ephopt=0
          3 no broadcast ephemeris: 2020/07/01 18:09:39 sat= 1 iode= -1
          3 no broadcast clock 2020/07/01 18:09:38.525 sat= 1
          3 estpos : n=8
          3 resprng : n=8
          3 resprng : n=8

          Like

          1. 2 16:51:04.80: age of differential error (age=82294.8)
            3 outsol :
            3 outsols :
            3 infunc : revs=0 iobsu=11102 iobsr=7107 isbs=0
            3 rtkpos : time=2020/07/03 16:51:05.004 n=22
            3 pntpos : tobs=2020/07/03 16:51:05.004 n=13
            3 satposs : teph=2020/07/03 16:51:05.004 n=13 ephopt=0
            3 no broadcast ephemeris: 2020/07/03 16:51:05 sat= 8 iode= -1
            3 no broadcast clock 2020/07/03 16:51:04.916 sat= 8
            3 no broadcast ephemeris: 2020/07/03 16:51:05 sat=11 iode= -1
            3 no broadcast clock 2020/07/03 16:51:04.926 sat=11
            3 no broadcast ephemeris: 2020/07/03 16:51:05 sat=14 iode= -1
            3 no broadcast clock 2020/07/03 16:51:04.923 sat=14

            Like

  11. Hello again Tim,

    I’m still struggling to get any decent PPK fix with my ZED-F9P hardware using this guide. I have managed to get the data logging working properly by loading RTKLIB onto the Raspi, but I still get very poor results. I’ve tried multiple different configurations, setting, locations, times, etc., but with no luck. I’m hoping it’s just some simple setting that I’m overlooking.

    My current configuration consists of a base and rover, both custom ZED-F9P board (two different revisions), with the only major difference being the voltage regulator, which should not be the problem. Antenna used for both boards is an M7HCT-A-SMA, which gives great GNSS coverage from my experience. All ZED-F9P configurations are set using u-center, and are saved to continues through power lose. Both base and rover are configured to use all constellations possible. Both are set to output the UBX-RAWX and UBX-SFRBX messages via USB. I have attempted using RTCM3 to similar poor results. Base station is configured with a survey-in for ~5 minutes, <10m accuracy, and the results are used to set the base station into fixed mode, sometimes changing the accuracy to <1m. I have also tried no survey, to poor results. Navigation/measurement frequency is 1Hz. Messages are logged using STRSVR on a Windows 10 laptop. Rover is set to a navigation/measurement frequency of 5Hz, while using the Dynamic Airborne 30 seconds. At no point in time is the base station moved from its surveyed location. I have been using the demo5_m8t_5hz.conf file for RTKPOST, following this guide. Most RTKPOST solutions result in a majority of Q=2, followed by Q=5, with very limited Q=1.

    Any input/suggestions you can give would be greatly appreciated, as I feel thoroughly stuck. Hopefully this information gives you an idea of what I might be doing wrong/what is causing my issues. If there’s any additional data/files that might help, I can gladly provide them. Thank you in advance for your time!

    Like

    1. Hi Avery. I would suggest plotting both base and rover observations from the rinex files using RTKPLOT. From the problems you describe, I suspect you are going to see either many missing observations or many cycle slips in either the base or rover or possibly both. Once you have this information, that should help you know where to look. Also, you will need navigation data from either base or rover but not both.

      Like

  12. Hey Tim,

    Very helpful guide, it has helped me quite a lot.

    I’m running into an interesting problem that I’d appreciate some of your input on. I have two custom ZED-F9P boards, whose hardware works as expected. I am using one as a base station, and then other as a rover. I have enabled the RAWX and SRFBX messages to go out the USB port on both boards, saving the configuration to persist after power loss. No other messages are going out this USB port. I am able to successfully record data from both base and rover using RTKLIB STRSVR and save to file. RTKCONV and RTKPOST work as expected. The results from RTKPOST are very promising for my potential integration. Data recorded directly through u-center also converts fine. I am using RTKLIB demo5 b33c.
    The problem is I would like to be able to record data on the move without the need for a laptop/computer. I’ve attempted to log data using a Raspberry Pi 4, but RTKCONV has problems with the resulting files. I am using the command screen -Logfile "filename" /dev/ttyACM0 plus the appropriate command (ctrl+a and shift+h) to enable data logging. This logs all data that’s coming through the USB port to a file, which I later transfer to my computer to process with RTKLIB. RTKCONV fails to properly convert this data, regardless of what format I select (auto, u-blox). Comparing the data logged via the Raspi with the data logged with RTKLIB, they look similar. Enabling debug level 5 in RTKCONV, it appears that I’m getting ubx checksum errors after one successful ubx decode. I’m thinking that my logging method is interpreting the incoming data as ASCII, which is messing with the raw format, making it nonconvertible.
    Do you have any input/thoughts? If there are other methods of data recording that you’d recommend, I’d appreciate it. During the course of writing this I discovered the debug option and developed this theory about my data logging method. This gives me a path to continue with, but thought I’d post anyways. If there’s other info, like data files, that you’d like me to share to help with this issue, let me know and I’ll happily share it.
    I’m not using the UART ports for this method as the custom F9P board I have only has UART2 available off chip, but with a molex connector that I currently don’t have the hardware to connect to. The F9P USB port has a USB connector, which is how I’m able to log all this data. I do have a Sparkfun ZED-F9P board, which I can easily connect to UART2 with. One of my potential solutions is to use a different form of data logging, using a Sparkfun Openlogger, which I’ve heard great things about. Should probably do some research to ensure that it’ll properly record all the data without any of the errors I’ve run into.

    Like

    1. Hi Avery. If you are already using a Pi, one option is to log the data with the STR2STR app in RTKLIB running on the Pi. I describe doing this in this post. The post is a little out of date now but should still be helpful. I also describe using the SparkFun Openlogger to record F9P raw data in this post. If you go this path, I would suggest using RTCM3 messages instead of UBX messages to reduce the chance of missing data due to bandwidth limitations of the Openlogger.

      Like

      1. Guess I didn’t read enough of your other posts, there’s a lot of other good info in there! I’ll definitely look into using RTKLIB on the Pi, that would make stuff easier. Might have to change a few things since I’m using a USB port instead of a serial port. But I think I can figure it out.
        I forgot about the RTCM3 method. I think I’ll try that with my current method and see if it works. I think I initially didn’t use it cause I was only getting grey satellites from RTKPLOT, but that’s cause it doesn’t output a .nav file. I thought a .nav file was critical for PPK, but I just tested without it and seems to still work.
        Thanks!

        Like

      2. Well I spent most of the day trying to get a valid/acceptable PPK solution, but very limited luck. Installing RTKLIB on the Pi was relatively easy, just a little modification to remap to the USB port instead of the serial port. The problem is that my PPK solution is either completely wrong, or with a majority of Q=2, Q=5 for most of the trials I did. I’ve tested the rover with RTCM3 or raw data, both with poor results. Could it possibly be an error between the different versions of RTKLIB? Using demo5_b33c on the laptop to record the base station and the demo5 github tree on the Pi. I don’t think that would be it, but possibly. Tomorrow I might try logging base data with a Pi and then doing the CONV and RTKPOST on the laptop.

        How was your base station setup? Was it just stationary with no additional configuration beyond the raw messages? My system was set up as an RTK base station, so it does a survey-in and then puts itself into fixed mode. Only messages coming out the USB are the raws. Is this a problem for PPK? I’m wondering if my poor results could be due to this. I’m trying to further expand my current RTK system to PPK, as I ran into data rate issues between the base and rover. Expansion into PPK is an attempt to increase accuracy of the rover without a large amount of external hardware when real-time precision isn’t critical.

        Like

    2. UART2 doesn’t support UBX messages. The other consideration with UART1 / UART2 is limiting the amount of messages, especially at high solution rates, as the receiver allocates buffers and then tries to emit to each interface before releasing. It can run out of resources very quickly resulting in $GxTXT txbuf alloc warnings, and significant data loss/corruption. Best to cull all unused messages, and on all unused interfaces.

      For logging on LINUX platforms I’d presume you could cat /dev/ttyACM0 >logfile

      UART2 can output RTCM3, and there are RTCM3 to RINEX converters

      Like

      1. Ah, good catch, thanks! Been a while since I used the ZED-F9P in much depth, so I forgot about that annoying limitation. I have seen the $GxTXT txbuf alloc warnings before when I’ve had way to many messages enabled. I’ll try to remember to disable all unnecessary messages to avoid this problem.

        I’ll try out that logging method and see if I have any luck.

        Might end up having to use RTCM3 messages, as the USB port might not always be available in the field.

        Like

  13. I know this article is about PPK, but it’s also the only place I’ve seen detailed instructions about how to configure an F9P for RTKLIB. I’m actually interested in RTK solutions, but wanted to see if I could get RTKLIB’s solution with an F9P as rover and an ntrip base close enough for testing. I found a usable base station on rtk2go.com and am able to get an RTK fix using u-center.

    Using the instructions in this article I was able to turn on the RAWX and SFRBX messages, as well as the RTCM3 messages. I configured this in u-center. I can see those messages emitting in u-center and I see them streaming into RTKLIB, but I’m not getting an RTKLIB solution. When I set the rover input stream to RTCM3 format, I am seeing satelite bars from both the rover and base, but they are not filled in. I also get gps time.

    When I set the format to ublox, I don’t see any rover satelite bars or time updates. Are there some rover messages that are required for RTK but not for PPK? I’m doing everything over just USB (and NTRIP for the base).

    I am pretty new to surveyor-grade usage of GPS. I have read the rtklib manual as well as many of the articles on your blog. Thanks for contributing – you are helping me get up to speed. I’m a volunteer mentor to a high school robotics team and we are trying to set up some summer projects with back yard RTK navigation.

    Like

    1. Step 7 of Configuring the Receiver says to turn off NMEA messages, so that’s what I did. As a result I had only the 2 UBX-RXM messages and the 4 RTCM3 messages. When I had it configured that way I couldn’t get a solution – not even in u-center. Once I turned NMEA back on I got an RTK fix. So at least something else seems to be needed.

      I’m using two different versions of rtklib. I’m using the most recent download here and I’m also using an Android port. The Android port is unstable so I was hoping to whittle down the output messages to the bare minimum. But at least it also got colored bars once I renabled NMEA output on USB. Though it won’t stay up long enough to get a fix.

      Like

      1. Hi Iron Reign. You need to enable only the RTCM3 messages or the UBX messages (RAWX/SFRBX) not both, but enabling both should not cause a problem assuming you have enough data bandwidth to support both. Be aware if you choose RTCM3 from the F9P then you will get observations only, no navigation data. Only one set of navigation data is needed so as long as one receiver (base or rover) is providing navigation messages, you will be fine. Gray bars in RTKNAVI normally indicates that you are not getting any navigation messages, however that should not be affected by enabling or disabling NMEA messages. If you are using the internal F9P RTK engine then the RTK fix output will be transmitted over NMEA messages so that might explain why you saw an RTK fix in u-center when you enabled them.

        Like

  14. I am trying to follow this post with the new version of u-center 19.11.01 and your new version of RTKLIB demo5 b33b2 with no luck. I am not getting any obs or nav files output when I try to convert the UBX log file. One difference I notice is my log from previous (I believe successful attempts) is coded as such I cannot view in Notepad++ but the new UBX log file is easily readable with $GNRMC $GNVTG $GNGGA messages. Thanks

    Like

    1. Hi Jay. The NMEA text messages and UBX binary messages both go into the same ubx log file, so just because there are NMEA messages in the log file, doesn’t mean there are not any UBX binary messages. IF you see just text messages in the log file, however, and no binary gibberish, then the RXM-RAWX and RXM-SFRBX binary messages were not enabled when you collected the data. You can enable these from u-center.

      Like

      1. Ok. I will try again but I swear I have been enabling them. I always hit the default settings button before I try to reset everything too. Thanks!

        Like

      2. Hello,
        I don’t know English and I use google traslator (sorry).
        I have to ask the following question: how do you enable RXM-RAWX and RXM-SFRBX messages through u-center?
        thanks

        Like

        1. Hi Alberto. You can enable the RXM messages by right clicking on them from the “Messages View” window in u-center and selecting “Enable Message”. If this doesn’t work, then most likely either your connection to the receiver is not valid, or your receiver does not support these messages.

          Like

  15. Hi, I am astonished with my firt postprocessing with this demo5_b33b version of rtklib. To my test I Did everything you said and results are perfect. on 30min not moving (both Zed f9p) Base and Rover, 1.3m apart, I get more than 90% Q=1, with only 3mm difference on Heigth, and 0mm horizontal. Simply amazing
    Then I tried to restrain Time Start and Time End on RTKPOST, and no more Q=1, all were Q=2. Solution was to close and reopen RTKPOST with no changes on options it works fine.
    The only thing not normal about my data is that there is a lapse of 15min of no logging :computer suspended 🙂 in the middle of the file.
    Thank you very much.

    one final note for the inexperienced begginers like me: when I first was changing F9P Base configuration I enabled all RTCM messages to the USB port and the rover stopped making corrections. So I got back and enabled to the USB only those who are enabled to the radio (UART2).
    With current Base and Rover configuration I can do both RTK and Postprocessing without changing any settings. Just have to log the base.

    Like

    1. Hi Paulo. I just released the b33b version a couple of days ago so it is not well tested and it’s possible there is a bug in it. If you are able to email me your base and rover raw files and config file I will take a look and see if I can replicate the issue.

      Regarding different RTCM messages from the u-blox receiver to the USB and UART ports, this can be a problem. The RTCM format includes a flag for the last message of each epoch. The F9P does not set these flags independently for the two ports so both ports must both have the same last message in each epoch.

      Like

  16. Hello Tim. Thank you for your excellent work.
    I have a set of Zed F9Ps and Im wondering whether theres a method of obtaining the raw pseudorange-rates, pseudoranges and carrier-phase measurements in RTKLib. I realise that the rinex obtained from the ubx logs has pseuodorange but im unsure of pseudorange rates and carrier phase, and whether this is readily accessible. Would be grateful if you could point me in the right direction.

    Like

    1. Hi Suraj. The F9P can be configured to output raw pseudorange, carrier-phase, and doppler observations by either enabling the appropriate RTCM3 messages or the UBX-RXM-RAWX messages. The easiest way to enable these messages is using the configuration menus in the u-center app from u-blox. The raw binary or RTCM3 files can then be converted to rinex with the RTKCONV app in RTKLIB. Pseudorange-rate can be derived from the doppler measurement.

      Like

      1. Hello Tim. Thanks for your reply. My apologies, I should have been more specific.
        I’ve already enabled raw messages in UBX-RXM-RAWX plus im converting to RINEX using RTKCONV as mentioned in your blog posts.
        Im simply wondering if theres an option to visualize pseudorange, carrier-phase and doppler in RTKplot, or to export these variables to a text file (similar to how theres an option for exporting carrier to noise and multipath).
        Is this possible in RTKLIB?

        Like

  17. Dear Tim! In the most recent b33a release it seems like you have changed some of the compiler settings, since I got the following error code when calling rnx2rtkp:
    “The code execution cannot proceed because VCRUNTIME140.dll was not found.” I suspect this is related to Visual Studio, on the same computer b33 works just fine. Also I do not find the usual 64 bit rnx2rtkp_win64 executable, so that also supports my suspect that you have changed compiler settings. It would be great to have some sort of fix for this. Thanks, Balint

    Like

    1. Hi Balint. I did make some updates to the Embarcadero compiler project files for the newer version of the Embarcadero compiler for the GUI apps but these should not affect builds with the VS compiler. You can download VCRUNTIM140.dll as part of the MS VS++ Redistributable packages here. Another suggestion that helps in general with VS compiler errors that may or may not help in your particular case is to go to the properties menu in the VS compiler and select the most recent options listed for “Windows SDK Version” and “Platform Toolset” from the “General” tab.

      I don’t think I’ve included the 64 bit version of rnx2rtkp in any of the demo5 releases except for b31 but I will consider adding it to future releases.

      Liked by 1 person

      1. Dear Tim! Thanks for the reply! Actually I copied the VCRUNTIM140.dll file to the folder and it gave me a different error that time “The application was unable to start correctly (0xc000007b)”. On the other hand I built the rnx2rtkp_win64 and rnx2rtkp files with embarcadero and seen a 38% speed increase in processing (64 bit vs 32 bit).

        Like

  18. After running RTKconv on F9P data logging RAWX and SFRBX messages, I end up with nav files for every GNSS system: gnav(GLO), lnav(GAL), and nav(GPS). Is there any reason to splice these together in a combined file for RTKpost? Or put them all into RTKpost?
    I am just curious if the additional nav files can be used with RTKpost, and if they improve anything if used.
    Thanks,
    Adam

    Like

    1. Hi Adam. The options menu in RTKCONV allows you to select different versions of Rinex format. If you select a 2.xx version, the nav files will be separate. If you select a 3.xx version, the nav data will be combined into a single file. I would suggest using version 3.03 and using the single navigation file for RTKPOST. If you stick with the 2.xx version, you will need to provide all the nav files to RTKPOS for the constellations you are using in the solution.

      Like

      1. Thanks for the response!
        As a follow up question, is there a simple way to know which satellite was used as the reference satellite for PPK? I see the documentation states it will use the highest elevation satellite, but there I do not see any indication of what it choose, and I do not see skyplots for the PPK solutions.

        Like

        1. Hi Adam. As you mentioned, RTKLIB will choose the highest elevation satellite from each constellation as reference for the double differencing. You can deduce this from elevations in the skyplot or if you want to see this specified explicitly, you can enable the debug trace to level 3 and look in the trace file. Each double difference will be listed.

          Like

    1. Hi Aleksandr. RTKLIB does not support a single solution from multiple bases. Depending on exactly what you are trying to do, you may be able to add a layer on top of RTKLIB to either call the command line executables and combine the solutions, or use the API to internal function calls as described in the online RTKLIB manual.

      Like

    1. Hi JJ. In RTKPOST, the output format (LLH or ENU) is specified in the Options/Output menu under “Solution Format”. Note that in RTKNAVI this option is grayed out and you need to specify the solution format from the Output menu.

      Like

  19. Hi Tim,

    Great post! It was exactly this kind of information that I had wished was more readily available when first starting to work with RTKLIB.

    For PPK, you’re recording both the UBX-RXM-RAWX and UBX-RXM-SFRBX messages. Can you confirm if these are the only two messages required for PPP as well? Do any of the other messages provide any use when creating a RINEX file from the raw collected data?

    Cheers,
    Adam

    Like

    1. Hi Adam. For online PPP solutions you need only the observation messages (RXM-RAWX). For RTKLIB PPP solutions you will need more precise ephemeris/clock information which I usually get from the SSR correction messages as I describe in this post. For RTK/PPK solutions using surveyed base stations, you might want to collect base position/antenna info messages as well. RTKLIB supports the 1005, 1006, 1007, 1008, and 1033 messages.

      Like

      1. Thanks, Tim!

        I collected some data with the ZED-F9P and submitted a RINEX file to NRCan’s CSRS-PPP tool the other day.
        I receive the message: “Warning : Some or all of the GPS signal(s) in your RINEX file are not currently supported by CSRS-PPP. A dual-frequency GLONASS only solution has been processed. The currently supported signals for GPS are: C1C L1C C2C L2C C1W L1W C2W L2W and for GLONASS: C1C L1C C2C L2C C1P L1P C2P L2P. Other modulations are planned for support once specific code biases become available.”

        Does this mean that PPP tool does not support the L1C/A signal as of yet? I’m curious if you received a similar message.

        Cheers,
        Adam

        Like

        1. Hi Adam. I believe it is the GPS L2C codes (C2L/L2L) that CSRS is complaining about. If you set the options in RTKCONV to use Rinex version 2.11 instead of 3.03 when generating the Rinex observation files, then the codes in the file header are listed as C2/L2 instead of C2L/L2L. In this case, CSRS will include the GPS observations in the PPP solution. The errors in the solution caused by the missing code biases should be very small.

          Like

  20. hi, i have a m8t and im planning to buy a second antenna to make a rover/base rtk rig, what would you reccomend, the base is going to be stationary and the rover goes in a moving tractor, should i buy a second m8t and use rtklib or a z9p? in this case should i use the z9p as a rover or base?

    Like

    1. Hi Diego. A dual-frequency solution will require dual frequency base and rover receivers so if you want to use an existing M8T your only real option is another M8T. A F9P would work but the solution would only be single frequency so there would be no advantage in using the more expensive receiver.

      Like

  21. Do to know if there’s any way to run your demo5 code on an Android tablet?

    I’m also wondering if there’s a way to log position events with the f9p. The aim is to have a single f9p on a pole as a rover connected to an Android tablet via Bluetooth. I want to be able to log the raw observations and also save position events and then post process it against a local CORS station. Is this viable?

    Like

  22. wow how incredibly helpful! Thank you so much for creating this. Your postings related to rtklib have been invaluable in helping me understand how to get the most out of RTKLIB and my ublox 8t.

    I do not own a f9 but have been looking into it. What do you suggest as the best antenna for the f9? one that might produce the best results in a canopy and canyon constrained environment?

    Like

    1. Hi Tlove. There are not a lot of choices for low-cost dual-frequency antennas. However, I have had good results with the ANN-MB-00 dual-frequency antenna from u-blox and would recommend it.

      Like

        1. Hi JJ. For PPP solutions on the OPUS website, you should specify “NONE” for the antenna option when using the ANN-MB-00. I am not aware of any calibration data available for the ANN-MB-00. The adjustments are usually very small in the horizontal axes (a few mms) and a little larger in the vertical axis. If you need more precise solutions than this, you will need to use a survey grade antenna from the dropdown list on the OPUS page.

          Like

          1. Thanks, Do you have a survey grade antenna you can recommend? I see some of them are tough to find and some are not L1 L2/E5b

            Like

          2. Hi JJ. A more complete set of antennas with calibration data than what is in the igs14.atx file is available at https://geodesy.noaa.gov/ANTCAL/#. I would suggest one of the Harxon antennas, either GPS500, GPS600, or GPS1000. SwiftNav has sold GPS500 and GP1000 antennas with their receivers. The GPS1000 antenna is available new from the SwiftNav wibsite for $425 but you may be able to find better prices elsewhere or you can look for used antennas.

            Like

          3. I am also getting an error when trying to rtkpost my obs of no position in rinex header. I’m assuming it is in my obs file not the unavco station file. Can i manually enter the position in the header?

            Like

          4. Hi JJ. The “No position in rinex header” error can be deceptive as it often means that RTKLIB just can’t find the observation file at all. See this post for more details on getting better debug info from RTKLIB. You could manually enter the base location in the rinex file header but normally it should not be missing in files from any kind of CORS reference station. For non-CORS base rinex files, it would usually be simpler to add the location to the config file under the antenna settings than modifying the rinex files.

            Like

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.