All right, I think it’s a good time to summarize the survey results. At this point I’ve had just over 100 completed survey responses and new responses have slowed to just a trickle. As with all my posts, I make no attempt to follow rigorous scientific methods, this is just a summary of the data and some informal observations.
First of all it’s interesting to see where people are using RTKLIB.
For what country or countries are you processing RTKLIB solutions?
Europe: 57% of total users (Oct blog views: 44%)
6 users: Germany, France
5 users : UK, Finland, Italy, Sweden
4 users: Switzerland
3 users: Russia
2 users: Poland, Slovakia, Austria, Ukraine, Spain
1 user: Czech Rep, Croatia, Slovenia, Ireland, Belarus, Turkey, Hungary
North America: 17% (Oct blog views: 21%)
15 users: USA
2 users: Canada
Asia: 8% (Oct blog views: 23%)
4 users: Japan
3 users: China
1 user: Taiwan
Oceania: 8% (Oct blog views: 4%)
6 users: Australia
2 users: New Zealand
South America: 6% (Oct blog views: 5%)
3 users: Brazil
1 user: Chile, Argentina, Columbia
Other (Africa/ Mideast): 4% (Oct blog views: 2%)
1 user: Uganda, Iran, GCC, Africa
It’s great to see such an international response! I’ve also included blog view statistics for comparison. I suspect less familiarity with English at least partially explains the comparatively low response rate from Asian countries relative to their blog views.
Here’s a summary of the remaining questions with a few comments and observations from me. Many of the questions allowed for multiple answers and some respondents didn’t answer all the questions, so both the total answers and total percentages vary from question to question.
It looks like users are fairly evenly split between business (48%), academic (38%), and personal applications (48%) but lean more towards post-processing solutions (67%) over real-time solutions (47%) and RTK/PPK solutions (67%) over PPP solutions (21%). Dual frequency solutions (71%) are most popular but many people are still using single frequency solutions (44%). I think the most surprising thing I saw here was that the percent of real-time solutions was as high as 47%, I would have expected lower.
Pretty evenly split here between beginner/intermediate and advanced/expert.
It’s great to see responses that span the range from new users to long time experts, although it can make it challenging some times to find the right balance for everyone when writing the posts.
It looks like just over 2/3 of respondents are using the Demo5 version of RTKLIB, at least some of the time. For those not using the Demo5 code, that’s fine, there should still be lots of useful information in the blog, but be aware that a good number of the features and results described in my posts apply only to the Demo5 version of the code.
I was surprised how few respondents are using RNX2RTKP, the CUI alternative to RTKPOST. RTKPOST is better for interactive experimentation, but RNX2RTKP is much better for processing large amounts of data. Maybe it’s time for another post about RNX2RTKP?
Again, it looks like there is a full range of answers here, all the way from daily use to never tried it.
A majority of Window users, which isn’t surprising given that the GUI apps are only fully supported in Windows. I’m still hoping someone from the linux world will step up to better support the linux GUIs.
It’s great to see that quite a few respondents are customizing the code themselves, that is one of the big advantages of open source code. One thing I’d like to explore more in my blogs is using RTKLIB as a library instead of a set of apps, as well as making some changes to the code to make this easier to do.
I’m always amazed at how many different applications that people have found for RTKLIB! Still, I was surprised that ground based surveying (64%) dominated the results as much as it did.
It looks like most people are working with a single receiver or pair of receivers but there are still a significant percent of respondents (31.4%) who are working on a bigger project involving at least five receivers.
These numbers suggest to me that more than half of the respondents are using local receivers or VRS as base rather than a CORS station.
I was surprised here how many respondents are looking for horizontal accuracies better than 5 cm given that there seems to be a shift in the industry to easier-to-use, more scalable solutions (PPP, PPP-RTK) that often offer decimeter accuracies rather than centimeter accuracies.
What brand /model of receivers do you typically use for the rover?
I’ve grouped the answers as best as I can to make them easier to summarize.
U-blox: (78 users total)
—F9P: 35 users
—M8T: 17 users
—M8N/M8P/M9: 4 users
—model not specified: 22 users
Emlid: 13 users
Novatel: 9 users
Trimble: 7 users
Leica: 4 users
3 users: Septentrio, Topcon
2 users: Hemisphere, Android, Sokkia, NVS
1 user: Swiftnav, Stonex, Allystar, DJI, South, Spectra, Ashtech, SIRF, Unicore, Sinan, NTLab, CHC, Span, Skytraq, Topodrone, SingoGNSS, Huawey, Hiro
Clearly dominated by u-blox and u-blox based receivers (mostly Emlid). I guess I was a little surprised that Swiftnav didn’t appear more frequently in the responses as either rover or base.
What brand/model or type (CORS, VRS, etc) of receiver do you typically use for the base in RTK/PPK solutions?
Again, I’ve grouped the actual answers to make them easier to summarize.
Reference Stations: (36% of total users)
—CORS: 37 users
—VRS: 7 users
U-blox: (28% of total users)
—F9P: 15 users
—M8T: 8 users
—M8N: 1 user
—model not specified: 11 users
Trimble: 11 users
Emlid: 7 users
Lecia: 6 users
Novatel: 4 users
Septentrio: 3 users
2 users: Topcon, Centipede
1 user: Drotek, Unicore, Sinan, NTlab, Skytraq, SinoGNSS, Hiro, NVS, Stonex
A more evenly distributed set of answers for the base than for the rover, but still dominated by u-blox receivers for those using dedicated receivers.
What is your largest frustration when using RTKLIB?
I tried to combine these and I’ve listed all the resulting categories that had at least two occurrences.
None: 31
Cryptic options/ Config file too complex / Too difficult to configure: 17
Solution not good enough/ not as good as internal F9P: 9
Lack of support for linux GUIs/MacOS: 6
Frustrations unrelated to demo5 version of RTKLIB: 5
Cryptic or missing error messages: 4
Lack of complete documentation in one place: 4
Non-intuitive/old-style GUIs: 4
Poor coding style/organization: 3
Too slow/ too much memory use: 3
False fixes: 2
Not compatible with other survey tools: 2
Limitations in RINEX/RTCM conversions: 2
Limited import/export options: 2
Differences between different versions of RTKLIB: 2
I think it’s a good list. I wouldn’t disagree with very much of it. Definitely some good suggestions for things that can be improved. Not surprisingly, the largest frustration was with the difficulty of configuring the solution. There were lots of other more specific frustrations that only got mentioned once that I didn’t have space to include here, but also made good feedback.
What features or fixes (up to 3) would you most like to see added to RTKLIB?
At first, I tried to consolidate this list as well but gave up because there were so many specific requests. I’ve just listed them below with some slight editing. Lots of good ideas. The suggestions that were the most common were IMU integration, better support for Linux GUIs, improved GUI interfaces, and automatic download of ephemeris/clock files required for a solution.
Brief description of your RTKLIB application:
Lots of interesting uses! Again I’ve just listed them all below with some slight editing.
Thank you everyone who responded to the survey! It’s great to hear what everyone is doing with RTKLIB. It’s also all great feedback and will be very helpful for choosing future blog post subjects and code features. The survey is still open so if you haven’t responded yet, you still can.
Listed responses:
New Feature Requests:
-Better multipath rejection
-Nrtk, nppk
-Support NTRIP caster
-linux gui
-port of demo5 to android
-Así está bien
-Better fix 😉
-Import Leica raw format
-multipath mitigation
-advanced algorithms for ambiguity resolution
-The possibility of using SP3 files containing GNSS precise ephemerides for more than 99 satellites
-included explanation for parameters (show them on hovering for example)
-Iono-free for dual frequeny receivers
-A more clear interface
-When used in post-processing, the Analyze the obs file to exclude satellites with low signal quality.
-Return error status appropriately
-Drawing kinematic profile. Non much report choise
-IMU integration (loosely and tightly)
-working gui for Linux
-multi station processing
-“I don’t understand most of the views in rtknavi, and they’re all unlabeled which is frustrating
-Documentation on file formats
-The buttons that are just an unlabeled box with no tooltip are very frustrating, especially when they don’t seem to do anything”
-Funcionalidad Stop and Go con rtk mas simple.
-automatic PPP all necessary files are downloaded from the Internet themselves.
-Simultaneous calculation forward – backward.
-full ntrip caster feature in str2str
-Better Linux support (for GUI)
-Simplified GUI like Emlid Studio,
-more useful diagnostic reporting
-tightly coupled processing with IMU data.
-CASTER option would be a great addition
-Plot in google earth.
-Install files with native apps rather than a folder with ini files – ie ini files stored in app data etc.
-A easy way to combine rinex data together, Often have to merge 1hz data with 15 min files.
-better work with multifrequency measurements, both in PLOT and POST
-Ability to copy/paste the ORI results in RTKPLOT. Fix tabbing behavior in TIME Select in RTKPLOT.
-option for str2str to compress base data or extract absolutely necessary data for long range low bitrate (14kbps) radio links between base and rover.
-I know rtklib benefit from static start but it would be absolutely fantastic if rtklib could support hybrid navigation with additional gyro,accelerometer, odometry data to help rtk processing and provide position in case gps signal is degraded or temporarily unavailable
-Better RAIM-like detection and rejection of interference and multipath. Support for using all available signal types (eg L1C, L1P, L1CA, L1M, L1Y) and frequencies (L1, L2, L5) in the nav solution simultaneously.
-help; tutorials;
-Fixed solutions criteria;
-CLI versions better usability (parameter selection)
-More tutorials, better interface
-Specific support for the L1+L5 GNSS chips that are coming out in the newest android phones
-Q= should report real accuracy
-A solid version for network and PPP static/kinematic solution,
-Multipath analysis
-Bigger UI window.
-More up to date/user friendly gui
-Tightly coupled gnss/ins soluions
-multi rover observations
-better and more robust kinematic solutions
-an automatically takeover of the internal q5 sol
-Linux GUI support
-rtkpost auto populate rinex nav/clock files if available based on base station file root name to make less steps when adding the additional files. feature
– add teqc like interface/functionality into rtkconv for help with rinex 3.02 conversions submitted to OPUS that return with errors.
-automatic download of sp3 and clk &etc. files
-taking advantage of wide lane combination
-more tightly integrated multi frequency solution
-faster processing
-Better import (offline) or interfaces (online) for correction data
-UI via a web application (using WebSocket and modern HTML5 etc). Should be platform neutral.
-VRS
-for stop and go i would like to be able to tell rtkpost the time frames when i am stopped
-Clear reasons why RTKPost fails
-selection or ability to change the reference satellite (potentially multiple times in a session)
-any improvements to the moving-baseline tool for compassing
-Moving baseline support
-I think it’s quite feature complete and does everything I need.
-macOS support.
-Filenames not being reset in RTKCONV when changes are made.
-An active forum. Your blog is fantastic, I imagine you’ll be getting an email from me eventually, but have a StackExchange RTKLIB would be amazing.
-Sensor fusion module taking advantage of IMU/INU including in the ublox receiver
-Better integration between the apps
-reduce complexity in settings
-F9P msm translation to legacy messages to be received in my olds hemisphere receivers
-static baseline support.
-an “if this then that” guide (for example: if you want to include SP3 for ephemeris ans SBAS for correction then you must use navsys …. and ephopt … )
-the GUI for Linux
-fully nmea 0183 output sentences
-extended options referring to atmospheric models
-the possibility of placing own models inside
-I wish RTKlib indicated reasons why “fix” was unstable.
-Possibility to access/output filter internals (covariances, etc.)
-I want the vectors AND weighting in the form of covariances
RTKLIB User Applications:
-using it internaly in RTKBase (https://github.com/Stefal/rtkbase) and for PPK.
-Robotic Lawn Mower, it navigates without boundaries. But has “issues” when near walls or other objects that interfere with reception of GPS signals.
-PPK system for drones
-Ground survey for gcp, mapping in marine application
-Improving the quality of GPS position data recorded during marine surveys.
-Quality monitoring of network solution RTK service
-Research and development within the scope of the work done in Rokubun
-research
-precise location of caves entrances with post process
-Post-processing of land survey
-Teaching and education
-vehicle navigation, AHRS, autonomous agriculture machine
-Teaching undergrad students to process real time/post-mission GNSS data in static, kinematic, PPP, and DGNSS modes
-Main use is for PPK solution for UAV applications but moving towards local NTRIP based RTK android applications as receivers become more available and price drops.
-Motorcycle sports riding trajectory visualization.
-https://twitter.com/s1cb400sb/status/1402450986325528587
-Static and kinematic for surveying by land surveyor and drones
-Near real time land monitoring
-amateur survey and mapping
-diverse – from RTK to PPP
-Tracking how far off the ublox M8U sensor fusion solutions are to determine if that is acceptable for our V2X application
-Proyecto propio de construccion GNSS, homologacion de equipos GNSS en el trabajo
-drone flight trajectory calculation
-monitoring landslide with rtk and expirement of real time ppp
-Survey
-accurately record archaeological features and to establish ground control points for aerial survey.
-Topographic and bathymetric survey
-Unmanned fixed-wings for aerial survey
-Post processing for Drone PPk photogrametry
-I run country wide CORS network but would love to aggregate my streams into a caster using RTKLIB and as well provide VRS solutions to rover users.
-Real time positioning of various sports
-Processing data in aid of finding errors.
-Low-cost equipment (cell phone, F9P etc.), short-observation-time static and RTK measurements in forests. Surveying, navigation (staking out), and combination with other methods (photogrammetry, laser scanning)
-GCPs for Aerial Surveys
-automatic mower that uses rtk gps position to mow according to map
-trying to pp poor data (float to fix hopefully)
-Rovers
-Forestry, surveying, boating
-Survey Ground Control Points for Photogrammetry with RTK, UAS picture geotagging with PPK.
-Processing for PPP, PPK
-Frustrating, confusing, and fun. It would help if I knew what I was doing.
-open pit mine and stock volume calculation
-Tested for PPP, some student projects (Smart phones, multipath, static baseline processing, etc)
-we develop gnss devices for agriculture
-Calcualtiom of drone positions
-single Freq dynamic RTK
-use it in a university context for education and projects. i also work privately with kinematic applications in the sports sector.
-Navigation validation
-Converting UBX to RINEX for OPUS etc, RTKPost to process static and kinematic solutions.
-UAS photogrammetry survey
-Precise measurements of reference points
-Agriculture: hedgerow scanning to measure sequestered carbon.
-we use it to for rinex convertion and str2str in our embedded app for streams
-woodland fish passage obstruction issues and habitat qualification
-collect observable satellite data on the ground using ublox F9P as a rover, then post-process against a base station
-Realtime drone positioning and simple ground based mapping
-high-resolution measurements of glacier motion in the Canadian Arctic.
-Post processing aerial photogrammetry
-My base is connected to RTK2GO by STSVR. RTKGPS+ used as rover for collect data (Android app). RTCONV and RTKPOST used for post prosessing.
-PPK for aerial drone surveying. We’re just starting out. Mostly surveying and construction applications so far. Hopefully move into digital agriculture soon.
-academic, leveling for tidal inundation gauges
-Double checking official survey point
-a survey robot which takes georeferenced picture inside crops and establish a map of diseases, weeds over the crops.
-UAV SfM
-Pre-processing for loosely coupled multi-sensor integration.
-Lawnmower
-control, boundary, topography
rtklibexplorer 