F9P Surveying In

Sorry clod.fr but I have not done the survey with a u-blox F9P.

A manufacturer specific raw log file is typically needed first. The file is then converted to RINEX format. I have done it with my Novatel dual constellation receiver with the following raw log commands:
RANGEB ontime 30
IONUTCB onchanged
RAWEPHEMB onchanged

Novatel provides a tool that converts the binary log file to rinex format. This converted file can then be uploaded directly for on-line analysis.

At a quick glance I did not find instructions from u-blox to perform the raw log but google points to some success cases. Here an example that might show one way forward:

I’m sure the u-blox support site would be able to help if you ask there.

1 Like

This is what i did few weeks ago.
I have a f9p with ardusimple xbee wifi ntrip master.
First of all update firware of f9p, then i use the config file for base from ardusimple. I connect the f9p to a windows computer and connect it to u center. In the msg view you have to disable all the msg (right click on the black and disable) and enable rmx-rawx and rmx-sfrbx. Then disconnect u center and open strsvr from rtklib and you could configure what you need to store.

Hope this help


I did that for post processing to know the position of my base station and to compare i did the survey in (10h) and there was a meter between the two position and in geoportail (google earth for france!) the post processing position match exactly with the satelite photo.


Well, not very accurate at all from what I can find out . I have been struggling a bit with my caster choice’s too so checking hasn’t even been possible yet.

1 Like

Managed to get my esp32 to talk to rtk2go so later in the week I might try the local trig points, out of interest.

Failing miserably to run my own caster! Neither snip, RpiNtripBase or WifiNtripMaster want to talk to the outside world, despite snip managing to produce an outwardly visible caster table.

these are the the steps i followed hopefully it saves the next guy some time.
i’m using the simpleRTK2B

Quote from Natural Resources Canada

  • FINAL (+/- 2 cm): combined weekly and available 13 -15 days after the end of the week
  • RAPID (+/- 5 cm): available the next day
  • ULTRA RAPID (+/- 15 cm): available every 90 minutes (not available to download)

It is preferable to compute the base station’s coordinates before starting the Real Time Kinematic (RTK) work. You could setup the base station ahead of time and collect raw GNSS data (anywhere from 2hrs to 24 hrs depending on the accuracy required). Leave the base station in place. Transform the raw data to RINEX and submit it for Static CSRS-PPP processing. CSRS-PPP can process the data approximately 90 minutes after data collection.

what you need to do.

  1. Survey in your base station using u-center. i surveyed for 12 hours until my accuracy was not getting any better.
  2. switch timemode3 to fix mode from survey in. enter static coordinates you just surveyed in.
  3. right click on UBX->RXM->RAWX and enable messages.
  4. change your usb port to only output UBX. UBX->CFG->PRT change taget to the port youare using. you only need to set the output to UBX
  5. Disconnect u-center from the ZED-F9P
  6. downloaded RTKLIB from this site. it was suppose to have support for the newer ZED-F9P.
  7. un-zip rtk Lib
  8. run strsvr. input will be the serial pot you are connected to. use the same connection setting u-center was using. set the output to a text file.(you are taking a serial strean that is UBX and saving it to a text file. you defined UBX in ucenter)
  9. collect data as long as you want to. 1 week = 2cm, 1 day = 5cm 90min = 15cm. longer the better. Government of Canada website has a max upload of 300mbyte. i collected data for the first 24 hours. submitted my result. then i ran it again for 1 week.
  10. open rtkconv.exe select the file you just created. change format to u-blox. set the location to save the output files.
  11. click convert. this should create a .obs file(this is what you can upload to the Canadian government site.)
  12. go to Precise Point Positioning
    create an account if needed.
  13. select a epoch data to use and select the .obs file you created to upload. if there are multiple files. you can zip them together. zipping will also create a smaller file to upload.
    14.click “summit to PPP”
  14. wait about 90 min to receive an email with the results. my new coordinates were in “out_pitfile_test.sum”
  15. enter the new coordinates in timemode3 in ucenter UBX->CFG->TMMODE3

i’m just running this now. i ran a small test that did not improve my accuracy because it was only 5 min. ill update this afternoon with my results. current accuracy is .5 meters. Also my antenna is not on a metel plate yet.


A quick and dirty way without resorting to offline post processing is to use ucenter to provide an NTRIP feed from the nearest base station and run the f9p in RTK mode. You should get within a centimeter or two quite quickly, but accuracy depends on the accuracy of that base station position plus/minus 10 mm plus/minus 1mm/km baseline. Post processing won’t necessarily get any more accurate unless it’s via a more accurate or nearer reference station.


i set up NTRIP and was able to survey my antenna to .08 meters. this worked OK. but after i submitted 24 hours of RINEX observation data to natural resources canada. i was able to get .013 meters of accuracy. the quick and dirty way worked but it was defiantly worth the time to record 24 hours of data and submit it.


Has anyone submitted data from a Swift Piksi Multi base to Natural Resources Canada? I’m trying to figure out what data to output to the file.

google swift binary protocol to Rinex. see this link.

1 Like

I also took some time to get the precise position of my base station. I think I can complete your guide.

What you suggest here is to perform a PPP (Precise Point Positionning) calculation to post process the observation. In short, you have a raw file in RINEX format, and the NRCAN compensates each position according to the data they have about orbit errors, atmospheric perturbation, etc. That’s why you have to wait before using the service, and the more you wait, the more their correction data is precise. It should work well. Take note that the position of your base station will be expressed in the system coordinates you chose (ITRF or NAD83). It may not be the system used in your country ! (for example in France, the official system is RFGF93).

There is at least one other post processing method you can use, which is differential GNSS. It’s quite like the RTK solution suggested by arwoodridge, but it’s not in real time. Basically, you chose a local base station (they are called CORS station in the USA for example). In general, they are operated by the state, and you can trust their position down to a few millimeters. You should be able to get their RINEX observation one way or another. Choose a file according to your own observation window. Then, use RTKPOST with both observation files in static mode to get your base station position. Its coordinates will be expressed in the same system as the position of your local reference station (probably the official system for your country).

A good idea is to compare results from both methods to make sure you have a reliable position.

I discussed more about it for the specific case of France here : Service PPP gratuit en France (in french of course)

1 Like

Also, if you want a base station easy to install ant that can give you RINEX files automatically (no more messing with STRSVR), you can give look at RTKBase (Releases · CentipedeRTK/pi-gen_RTKbase · GitHub). The software is flashable on a micro SD card and lets you build your base station with a ZED-F9P module connected in USB to a Raspberry Pi. The GUI is in english, and you can find an installation guide here : GitHub - Stefal/rtkbase: Software for your own GNSS base station for RTK localization. For a guide in french, it’s here : https://jancelin.github.io/docs-centipedeRTK/docs/base/Materiels.html.

I’m currently using this setup, and if you want a NTRIP base station with no hassle, I think it’s worth a look.

So I submitted 24hrs of data, we’ll see if I did it correctly. I saved 24hrs of sbp with the message types listed in the Swift doc you linked. Then I used sbp2rinex to convert it, zipped it so that it was <300MB and uploaded it with the options (Static, Epoch->2010.0, Vertical datum->CGVD28(HT2_0)).

Did it work for you?

I think so. I received the full_output.zip back from Natural Resources Canada with the following email text. The corrected position was very close to my auto surveyed position.

200804 piksi base.obs
||Warning : No approximate position RINEX header record was found. A priori position initialized using a pseudo-range only solution.|
||Warning : No antenna type RINEX header record was found. Phase Centre Offsets and Variation could not be applied. Estimated height should be used with caution.|
||Warning : Your combined GPS, GLONASS RINEX observation file has been processed with the available GLONASS products.|
||Warning : Ocean loading coefficients (OTL) not applied. To apply OTL we need either valid approximate coordinates in the RINEX header or a user-supplied OTL coefficients file.|

Nothing unusual here, I had similar warnings. What you might want to check :

  • Dual frequency was used for the calculation
  • Few data was rejected
  • The error ellipse at 95% is less than 1 cm wide in both directions
  • The altitude uncertainty is no more than a few cm
  • The satellites distribution on the sky map doesn’t show strange behavior which could indicate a bad sky view for your antenna. For example on my report, there are lots of points missing westwards, because of the roof of my house :
    Distribution spatiale satellites
    Good idea to compare position calculated through various techniques (survey in, PPP, differential GNSS with CORS station). Ideally, positions should be a few mm apart

i found the Canadian equivalent Geodetic tools and data

I did survey in for 24h and get accuracy of 0.041m (3D acc.) 0.03m (2D acc.)

Then i did steps from @redalert11 post
and i received full_output.zip (it is NRCan Ultra-rapid)
error ellipse

with error just 3mm is it even possible to have such small error?
Main problem is that these coordinates have difference of ~30cm in X and ~50cm in Y with survey in coordinates
should i trust PPP coordinates more and go with them ?
I tried comparing in google earth pro but maps are not precise.

Is it worth it to get FINAL (+/- 2 cm) do i need to record for a week or record for 24h and wait 3 weeks and than upload to CSRS-PPP ?
and if so why in report coordinates have ± 0.005 m ± 0.003 m(95%) and not ULTRA RAPID (+/- 15 cm): ± 0.15 m ?

1 Like

Nrcan only works with gps and glonass. 24Hr recording is 12Hr too much, lol. But I still did 24Hr too, the last 12Hr is deciding +/- 1mm. But you can never be too accurate especially when you own the equipment.

The final and rapid will be slightly different, mostly in the vertical. have to fix the snip tool in win 11 then I can show you.

Run the rapid right away, its way better than averaging. Whenever you get the final use it forever, but really your tractors wheels wont know the difference. Your getting down to the bleeding edge of the current available tech at this point, without buying a javad reciever.

PPP increases your stability and accuracy on long baselines. You will actually get the stated accuracy of your equipment now. The other big benefit is fix time, the rover fixes faster off the PPP base, than average coordinates seconds of improvement but worth it.

1 Like

A small difference East and North, but 10cm difference vertical