F9P Surveying In

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

hi,
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

So it is normal to have 50cm diffrence between PPP and SVIN ?
I will put PPP coordinates in base.

I have lots of small fields. Big use of AOG would be year to year field boundry accuracy and AB line repeatability. Will field coordinates drift with tectonic plates and other methods and do i need to PPP base every year to account for it, or use thoese forever and over years fields will not move?

1 Like

Surveying in can be good and notoriously bad all depending on the day, I would not be surprised if the “survey in average” would be out by over a meter in all directions, 50cm off absolute position is pretty decent for a single receiver with no corrections.

Thankfully there are a lot of surveying professionals dedicated to tracking and logging the monuments on long standing ground control points, to quantify long term shifts in measurement.

I will ask the Surveyors on Emlid forum how often a PPP is needed. I doubt its very often, but a very valid question.

1 Like

So after doing the long survey and then getting the data post-processed, how does the final result compare to Google Earth coordinates? With my 10 minute survey in base station coordinate, I find everything is about 3 metres off of Google Earth. Would be nice to be lined up with google earth more closely for mapping purposes. But I’d setting for being lined up more closely with Trimble’s RTX in terms of position.


its about 4.3m apart on current map
PPP_SVIN_ACTUAL2
but on 2016 map its only 1.5m apart too large difference not usable in my area.

Google maps removes precision from cordinates to 1m accuracy its better to use google earth pro.

I want to try getting coordinates of fields with app on android with F9P and ANN-MB-00 antenna and NTRIP (same RTK setup as AOG) and export KML of finished fields from app to AOG.

One way to get your coordinates to more or less line up with Google Earth is to mark the base station location on Google Earth as best you can, then use those lat and lon coordinates to set the base station position in u-center. That should align everything. Of course I’m not sure if Google is consistent over any distance (seems to be consistent on my farm).

1 Like

GE’s coords also seem to change slightly from image update to another.

1 Like

Thats exactly what i wanted to show

This is good only in current map and when next update come it will move coordinates (map behind them).
And what happens if you connect to different base if that base is PPP and yours is GE coordinates.
How would sharing coordinates work someone who uses
government correction service and us with PPP base we should end up on same spot with same coordinates,
and base coordinates based on GE map will be off by difference in GE to PPP coordinates?

Is there a video for this, I have no idea how to do it. I am using u-center 20.10.

Ok so the world is now more magical. Turns out surveyors are more than just flashy vests and big sticks

Local datums like NAD83 are bound to control points that move with the tectonic plate they are on. Those control points coordinates are basically etched in stone. So if you PPP and use coordinates for a local datum for your base, all movement on the plate is relative to the plate and cancels out. Time mostly does not matter. So unless you have a field that is on two separate plates, for all intent and purposes there is basically no drift.

If you PPP to WGS84 and never change your base coordinates your measurements will stay relative to themselves forever, much like creating your own local datum. But your absolute position in WGS84 is forever drifting, because the only control points for ECEF measurements are the center of the earth, the new prime meridian at the equator, and the fixed north pole. So if you PPP at a later date you will be able to see how much you have moved from the earths geology shifting.

WGS84 is a global datum useful for measuring the earth and its changes over time, Local datums like NAD83 are useful for measuring who owns a small piece of it for all time. With the magic of computers we can transform between them. Syncing to the datum them helps the GNSS match your position to the ideal model of the measurement.

Google maps uses WGS84. I recently did a survey with a base set to WGS84 and rover set to ESPG:4326 WGS84. Using these settings to collect data with an Emlid RS2 and Reachview3. Once the data was merged in QGIS the points lined up automatically with the google maps data, but not exactly.

But this is a sample size of one so i may have got lucky

1 Like

It wouldn’t obviously. Sharing is not the high on the priority list for me. I am, however, interested in methods for somehow getting Google Earth to line up such that I can review things like field boundaries. But as @PotatoFarmer says, it’s very complicated!

Found out i did the survey in the wrong projection, will have to redo some points with Googles ESPG.

North is good, but the photo is about one meter too far west. QGIS is an open source project too, possibly the “google map importer” code could be ctrl v’d?