Using the D-RTK 2 Mobile Base with the new P4P RTK, one needs to enter the known coordinates of the base station for best results. Is there a place in the DJI GS RTK app to enter the antenna height, or must it be added to the Z value for the base? Most survey-grade RTK software has a place to enter antenna height separately from the benchmark location to accommodate various antenna and tripod types and remove the chance of arithmetic errors, but I can't find a place to enter it in the GS RTK app RTK settings. If it is not accounted for somewhere, all resulting altitudes (and derived products) will be too low by that amount.

And what is the correct D-RTK 2 antenna height value using the supplied range pole and tripod, with the pointy end of the pole touching the benchmark? It is approximately 1.8m, and the antenna shows some dimensions for what looks to be the antenna base-to-phase center heights for L1 & L2, but the total height using the standard pole should be a published value.

Incidentally the practice suggested in the D-RTK 2 User Guide "Lift the extension rod in the tripod to adjust the D-RTK 2 Mobile Station to the desired height, and then tighten the sleeve." (after centering and leveling the tripod over the benchmark) is contrary to best practices in that it makes the antenna height unknown as well as introducing the potential for loss of benchmark alignment. Without the pointy end of the pole resting on the benchmark, there is no way to visually verify if the antenna is centered over it.

I'm interested in what DJI and other users have to say about all this. Sorry if it has been answered previously in the forums, I searched and did not find anything.

A previous workflow by a surveyor in TX stated to add 5.83 ft or 1.776984m to the benchmark z value that you are set up over to account for the antenna height.  I am still working towards getting a reliable consistent workflow from the DRTK2 and P4RTK when set up over a known point.

HTA_RP-1 Posted at 2-13 11:22
A previous workflow by a surveyor in TX stated to add 5.83 ft or 1.776984m to the benchmark z value that you are set up over to account for the antenna height.  I am still working towards getting a reliable consistent workflow from the DRTK2 and P4RTK when set up over a known point.

Thanks HTA_RP-1!

That's certainly in the ballpark. DJI should really break that out as a separate parameter input and have the correct value for the DRTK2 pole be the default.

We've used the P4RTK with the DRTK2 as well as NTRIP via a mobile phone wireless hotspot with good success, but the results from the former confirmed our suspicion that the antenna height was not being accounted for.

Any links to workflows by the guy in TX or anywhere else (including yours) would be greatly appreciated. Let's share notes!

Anyone else using the P4RTK want to chime in?

(bump)

patiam Posted at 2-13 11:35
Thanks HTA_RP-1!

That's certainly in the ballpark. DJI should really break that out as a separate parameter input and have the correct value for the DRTK2 pole be the default.

[url=https://hoyletanner-my.sharepoint.com/:w:/p/emcdougal/EcUNqCOMUc5HqNvf7N1CtdYBr0GYcjAUCkWfG1FJRiGgrg?e=hvtWTY][/url]

Try this or pm and we can exchange workflows

Hi I have been having similar problems as you two have. I tired to set up over a known point but the software rejected my coordinates stating it was more the 50m away.

What coordinate system does the D-RTK 2 base station use?  My understating was that I could enter my Lat / Long and elevation of the known point, including the height of the rod, and be good to go.

What did I miss?

HTA_RP-1 Posted at 2-15 04:24
[/url]

Try this or pm and we can exchange workflows

Thanks HTA_RP1! Very helpful.

Will take a look and be in touch...

abaugh Posted at 2-15 09:07
Hi I have been having similar problems as you two have. I tired to set up over a known point but the software rejected my coordinates stating it was more the 50m away.

What coordinate system does the D-RTK 2 base station use?  My understating was that I could enter my Lat / Long and elevation of the known point, including the height of the rod, and be good to go.

In our experience, although one is supposed to be able to enter base coords in their system of choice, it wants Lat/Lon (I believe in DD, don't recall for sure). As noted, an antenna offset needs to be added to the Z, as there is nowhere else to introduce this. We use HAE rather than Ortho height for the Z. Our processing workflow in Pix4D involves bringing images in as HAE and applying Geoid12B height to make all output products UTM/NAVD88 Ortho.

Note that in order to make the base station coord entries "stick", you have to press the "Settings" button, which should more properly be labeled "Save". Sometimes you have to press it a couple times. If there were values present in the coord box previously (and they were more than 50 m away from your current position), that could be why the software is timing out after a bit and rejecting the coords it has as too far away- the coords you just entered have not been saved to replace the old (bad) ones. It should acknowledge when the coords are saved.
Otherwise, check your coords, or perhaps your D-RTK 2 is broken, or you have too much electromagnetic/radio interference at your site.
HTH.

patiam Posted at 2-15 09:39
In our experience, although one is supposed to be able to enter base coords in their system of choice, it wants Lat/Lon (I believe in DD, don't recall for sure). As noted, an antenna offset needs to be added to the Z, as there is nowhere else to introduce this. We use HAE rather than Ortho height for the Z. Our processing workflow in Pix4D involves bringing images in as HAE and applying Geoid12B height to make all output products UTM/NAVD88 Ortho.

Note that in order to make the base station coord entries "stick", you have to press the "Settings" button, which should more properly be labeled "Save". Sometimes you have to press it a couple times. If there were values present in the coord box previously (and they were more than 50 m away from your current position), that could be why the software is timing out after a bit and rejecting the coords it has as too far away- the coords you just entered have not been saved to replace the old (bad) ones. It should acknowledge when the coords are saved.

HAE = Height above Earth?
I tried zeroing the GNSS coordinates input today and inserting the surveyed benchmark in decimal degress that I set my DRTK 2 over and it would not take it. 7902E009-080206AHC.pdf (16.72 KB, Down times: 272)

2019-2-15 Upload

Click on the file name to download attach   When i plugged the "current D-RTK 2 mobile station location information" values in that were just above the "settings " button and hit settings it was confirmed.
I need to see a complete workflow as I am not a surveyor and applying Geiod12B to make all output products UTM/NAVD88 Ortho is greek to me.  I need outputs to be in local state plane coordinates ao that I can measure tree heights above runway ends at airports.  All worked well when using P4Pro/Pix4D Capture/ and GCP's captured with a Leica20.  And I know the RTK can do this is I get the coordinates and workflow figured out.   Any help geetting me ther is appreciated.

HTA_RP-1 Posted at 2-15 13:49
HAE = Height above Earth?
I tried zeroing the GNSS coordinates input today and inserting the surveyed benchmark in decimal degress that I set my DRTK 2 over and it would not take it.  When i plugged the "current D-RTK 2 mobile station location information" values in that were just above the "settings " button and hit settings it was confirmed.
I need to see a complete workflow as I am not a surveyor and applying Geiod12B to make all output products UTM/NAVD88 Ortho is greek to me.  I need outputs to be in local state plane coordinates ao that I can measure tree heights above runway ends at airports.  All worked well when using P4Pro/Pix4D Capture/ and GCP's captured with a Leica20.  And I know the RTK can do this is I get the coordinates and workflow figured out.   Any help geetting me ther is appreciated.

Sorry, HAE = Height Above Ellipsoid, which is the Z value all GPS positions are calculated & reported in (at least initially, unless adjusted to MSL or the Geoid or some other vertical datum).

For example, here is a OPUS Solution Report for one of the benchmarks we use here for testing and calibration:

---

FILE: 43651100correctedAnt.18o OP1524512619526

                              NGS OPUS-RS SOLUTION REPORT
                              ========================



All computed coordinate accuracies are listed as 1-sigma RMS values.
For additional information: https://www.ngs.noaa.gov/OPUS/about.jsp#accuracy

      USER: xxxxxxx@xxxx.edu                       DATE: April 23, 2018
RINEX FILE: 4365110p.18o                            TIME: 19:45:47 UTC


  SOFTWARE: rsgps  1.38 RS57.prl 1.99.3            START: 2018/04/20 15:44:15
EPHEMERIS: igr19975.eph [rapid]                    STOP: 2018/04/20 16:30:30
  NAV FILE: brdc1100.18n                        OBS USED:  4662 /  4743   :  98%
  ANT NAME: TRM57971.00     NONE             QUALITY IND.  26.89/ 50.58
ARP HEIGHT: 2.000                         NORMALIZED RMS:        0.237


REF FRAME: NAD_83(2011)(EPOCH:2010.0000)              IGS08 (EPOCH:2018.30047)

         X:     -2698742.154(m)   0.007(m)          -2698743.148(m)   0.007(m)
         Y:     -4354619.539(m)   0.005(m)          -4354617.986(m)   0.005(m)
         Z:      3786643.212(m)   0.009(m)           3786643.346(m)   0.009(m)

       LAT:   36 39 12.67445      0.006(m)        36 39 12.69335      0.006(m)
     E LON:  238 12 42.30583      0.007(m)       238 12 42.23887      0.007(m)
     W LON:  121 47 17.69417      0.007(m)       121 47 17.76113      0.007(m)
    EL HGT:           46.288(m)   0.009(m)                45.729(m)   0.009(m)
ORTHO HGT:           80.474(m)   0.024(m) [NAVD88 (Computed using GEOID12B)]

                        UTM COORDINATES    STATE PLANE COORDINATES
                         UTM (Zone 10)         SPC (0404 CA 4)
Northing (Y) [meters]     4057121.184           650108.450
Easting (X)  [meters]      608306.462          1750741.548
Convergence  [degrees]     0.72345519          -1.66343315
Point Scale                0.99974452           0.99994088
Combined Factor            0.99973726           0.99993362

---

The highlighted elevations are Ellipsoid Height (HAE), and NAVD88 Ortho Height, and the difference between them is the Ellispoid-Geoid separation defined by the GEOID12B model as indicated.

The station report you uploaded for 7902E009 lists both HAE and an NAVD88 Ortho height for the station.

We enter the Lat Lon & HAE (with the antenna height added) in the P4RTK base station coordinates. That makes (keeps) all the image geotags in HAE, which is what we tell Pix4D when we import them into a new project.

Then we specify our output coordinate system as UTM and add in the Geoid12B value to shift it to NAVD88 Ortho Height.

There's a workflow describing the Pix4D rpoject setup on their support site. If you're using Pix4D, you would do the same except choose SPC instead of UTM for your output coords.

Back to the D-RTK 2 setup- as I mentioned before, supposedly you can enter your base station coords in your system of choice, but I have had no luck figuring out how to do so. That's why we are sticking with Lat/Lon and HAE, becuase that's themost native system and datum available for GPS. I haven't tested throroughly what happens when you enter Ortho height rather than HAE.

Also, be sure you're entering Lat/Lon properly; Degrees Minutes Seconds 36° 39' 12.67445' = 36° 39.211240833333' (Degrees Decimal Minutes) = 36.65352068° (Decimal Degrees).

Hope this helps!

patiam Posted at 2-15 15:08
Sorry, HAE = Height Above Ellipsoid, which is the Z value all GPS positions are calculated & reported in (at least initially, unless adjusted to MSL or the Geoid or some other vertical datum).

For example, here is a OPUS Solution Report for one of the benchmarks we use here for testing and calibration:

Very helpful -  thanks !

HTA_RP-1 Posted at 2-15 15:41
Very helpful -  thanks !

YW-
and I forgot to add- W longitude is generally entered as negative! (DD for the BM in my example is 36.65352068, -121.7882484). The station you listed seems to be in FL, and you mentioned using SPC, so that would apply.

patiam Posted at 2-15 16:01
YW-
and I forgot to add- W longitude is generally entered as negative! (DD for the BM in my example is 36.65352068, -121.7882484). The station you listed seems to be in FL, and you mentioned using SPC, so that would apply.

The station report you uploaded for 7902E009 lists both HAE and an NAVD88 Ortho height for the station.

We enter the Lat Lon & HAE (with the antenna height added) in the P4RTK base station coordinates. That makes (keeps) all the image geotags in HAE, which is what we tell Pix4D when we import them into a new project.  ....What do you tell Pix4D? ... exactly the workflow Blaz from Pix4D provided?  WGS 84, meter, known coordinate system [m], WGS 84, Geiod Ht above WGS ellipsoid [m]  (leave at 0.000 or put in the difference between ellipsoid and ortho elevation that you mention? )

Then we specify our output coordinate system as UTM (which dropdown on Pix4D has UTM? is it called UTM or something else?)  and add in the Geoid12B value to shift it to NAVD88 Ortho Height.  (so add the difference between ellipsoid and ortho height here?

There's a workflow describing the Pix4D project setup on their support site. If you're using Pix4D, you would do the same except choose SPC (State Plane Coordinate) instead of UTM for your output coords.  If I can get the photos accurately georeferenced to one known point and then adjust the resulting point cloud to a State Plane so that we can provide the client with MSL elevations of trees.

sorry for the questions but I appreciate the help nailing down the workflow.

HTA_RP-1 Posted at 2-17 16:53
The station report you uploaded for 7902E009 lists both HAE and an NAVD88 Ortho height for the station.

We enter the Lat Lon & HAE (with the antenna height added) in the P4RTK base station coordinates. That makes (keeps) all the image geotags in HAE, which is what we tell Pix4D when we import them into a new project.  ....What do you tell Pix4D? ... exactly the workflow Blaz from Pix4D provided?  WGS 84, meter, known coordinate system [m], WGS 84, Geiod Ht above WGS ellipsoid [m]  (leave at 0.000 or put in the difference between ellipsoid and ortho elevation that you mention? )

Sorry if it was unclear.

In RTK setup you enter the sum of benchmark Ellipsoid height (HAE) + antenna height for the base station Z.

Then in Pix4D, in image input coordinate system info you choose Geographic WGS 84, and for vertical choose WGS84, Height above ellisposid 0.00 exactly as in that thread by Blaz.

Then in the next panel where you choose output coordinate system, choose your desired state plane flavor and for vertical replace the 0.00 height you used before with the difference between ellipsoid and desired ortho height. This will probably be a negative number.

If this doesn't make sense PM me and we can take it to email if needed.

Good luck, have fun, and safe flying!

patiam Posted at 2-17 17:16
Sorry if it was unclear.

In RTK setup you enter the sum of benchmark Ellipsoid height (HAE) + antenna height for the base station Z.

Perfect -  I will run another test hopefully tomorrow and advise!  Thanks!

patiam Posted at 2-17 17:16
Sorry if it was unclear.

In RTK setup you enter the sum of benchmark Ellipsoid height (HAE) + antenna height for the base station Z.

When calculating the Geoid12B shift value do you take the differnence between the values circled in red or blue, as seen in the image below? Also, can you only obtain the values from an OPUS report?
For clarification, is it "EL HGT - ORTHO HGT = ANSWER"
In this case:  "46.288- 80.474= -34.459" or

                   "0.009- 0.024= -0.015"

?

Thanks

fans9ab7b0f9 Posted at 2-18 08:49
When calculating the Geoid12B shift value do you take the differnence between the values circled in red or blue, as seen in the image below? Also, can you only obtain the values from an OPUS report?
[view_image]For clarification, is it "EL HGT - ORTHO HGT = ANSWER"
In this case:  "46.288- 80.474= -34.459" or

Hi fans9ab7b0f9-

You're on the money in that the difference between Ellipsoid & NAVD88 Orthometric Height defined by GEOID12B (or any other Geoid Model) varies over space. This is because the geoid surface is irregular, unlike the reference ellipsoid.  So you need to find the value that is appropriate for your site (and if your site is quite large, and you want the highest accuracy possible, you should not apply a single correction but one that varies across the area mapped - that can be accomplished a number of ways).
You can get the value for your base station location from a number of sources, and perhaps the National Geodetic Survey (NGS- part of  NOAA, they run OPUS as well) is the best one-stop shop:

• If you're using a known published benchmark the Ellipsoid and Orthometric Height should be in the published station info (as in HTA_RP-1's example). If it's a CORS station, NGS will have it (as well as data from the station if needed for PPK processing, etc.)
• The easiest way to get the value for an known but unpublished location is also at NGS, where they have an interactive tool into which you can enter Lat/Lon for a single site or a file of multiple sites, which will return the GEOID12B height. While the GEOID12B height varies over space as noted above, it does so on a scale that even the error associated with a decent autonomous GPS Lat/Lon position (3-5m) will still give you an accurate value in most locations. They also have software tools that run in Windows or Unix that you can download and run locally (with downloaded data for your area)
• If you need the value for an unknown location, and you are going to use your RTK GPS to site it in as a new benchmark, you can record data  for at least 15min but not more than 24hrs in a RINEX file, and upload it to OPUS (Online Positioning User Service) for processing. You'll need to enter the antenna model and height there when you upload the file. OPUS will either rapid-static or static process the data using a network of nearby CORS stations and send you a report like the one I pasted in my post (I left off the section lising all the stations used and their info). The report will have your previously unknown benchmark coords in earth-centric (XYZ) coordinates for both the NAD83 and IGS08 datums, as well as Lat/Lon in DMS and the Ellipsoid height for both those datums, as well as the NAVD88 Ortho height for NAD 83.
  

Lots of info on how OPUS works and how to interpret the report is here. Your blue square indicates the Ellipsoid and Ortho Heights in m. The red square shows the error of those values (standard deviation for rapid-static, peak-to-peak for static); this is the case for the Lat/Lon's listed above and all XYZ & LAT/Lon positions in the report. Next to every position is it's associated error and the units of the error (yes, the EL HGT error is just 9mm, and while the ORTHO HGT is a bit worse at 24mm, due to the uncertainty in the GEOID12B model, but still... That's pretty dead nutz!).

• If you need to apply the GEOID12B model over a larger area you can download it for different areas and in various formats from the main GEOID12b page, CONUS is here. The model can be applied in some processing software (not yet in Pix4D unfortunately), or you can leave your Pix4D DSM/DEM/XYZ outputs in HAE and apply the GEOID12B model in GIS or elsewhere. Note that the resolution of the downloaded file is 1 arc-minute (about 31 m or 101 ft at the equator), so you won't see any variarion of the model at scales smaller than this. If you need finer resolution then you need to use the interactive tool on the website or the downloadable one to generate heights at dicrete locations, which you can then apply
  

Lots more info on GEOID12B here


Finally, regarding the math: you nailed it.

For clarification, is it "EL HGT - ORTHO HGT = ANSWER"
In this case:  "46.288- 80.474= -34.459"


Since Ellipsoid Height - GEOID12B = Ortho Height,
GEOID 12B = Ellipsoid Height - Ortho Height.

The Geoid correction in CONUS is a negative number.

Lots more about Geodesy if you're interested here.

I realize much of this may be way more than you wanted to know. Use what you can

Have fun, be safe, and happy flying!

Hey Patiam,

We are having an issue with the Phantom 4 RTK hand controller not recognizing our ZTE MF833V 4G dongle. We have a working SIM card in it and even tested the dongle on a PC to make sure it was working. I was wondering if you had an idea on how to fix this issue or if you just use a different internet source.

AerialSurveyor Posted at 2-20 11:50
Hey Patiam,

We are having an issue with the Phantom 4 RTK hand controller not recognizing our ZTE MF833V 4G dongle. We have a working SIM card in it and even tested the dongle on a PC to make sure it was working. I was wondering if you had an idea on how to fix this issue or if you just use a different internet source.

Hi AerialSurveyor-

Sorry, I have no experience with that as I haven't tried the dongle approach. I just create a hotspot on my phone and connect the remote to that. Then I can connect to an NTRIP source for corrections and don't even need the D-RTK 2.

Have fun, and safe flying!

Okay that's what I was wondering. We are using the D-RTK 2 Setup but in the event that we wanted to use a NTRIP source we had ordered the ZTE dongles because DJI had specifically requested only the MF833V model. DJI hasn't been able to help us either so it seems we ordered them for no reason. Thanks for your reply!

AerialSurveyor Posted at 2-20 12:13
Okay that's what I was wondering. We are using the D-RTK 2 Setup but in the event that we wanted to use a NTRIP source we had ordered the ZTE dongles because DJI had specifically requested only the MF833V model. DJI hasn't been able to help us either so it seems we ordered them for no reason. Thanks for your reply!

DJI support is next to non-existent on this kit. I can't say I'm surprised but it's still inexcusable.

We're on our own, so let's all help each other figure this stuff out!

patiam Posted at 2-20 12:28
DJI support is next to non-existent on this kit. I can't say I'm surprised but it's still inexcusable.

We're on our own, so let's all help each other figure this stuff out!

Yeah that's what we have found. I joined this forum just for any information regarding this setup so I will always be looking for any helpful information and will also share anything we have found out. Glad to know we have our own support! Thanks for everything Patiam!

First thing I did was ditch the 80's tripod and ridiculous rod and mount and put the base on a 2m rover pole with a tripod attachment. A static dimensions and move on. I think it hilarious the lack of info and the manual even says setup to the "desired height", but that's all you get. I really hope people know to measure. Otherwise there are allot of accurately incorrect maps out there.

CHASCOADMIN Posted at 2-20 19:58
First thing I did was ditch the 80's tripod and ridiculous rod and mount and put the base on a 2m rover pole with a tripod attachment. A static dimensions and move on. I think it hilarious the lack of info and the manual even says setup to the "desired height", but that's all you get. I really hope people know to measure. Otherwise there are allot of accurately incorrect maps out there.

Haha CHASCOADMIN my thoughts exactly. I rolled my eyes and shook my head as well at the instructions that were both lacking most important details while at the same time encouraging inadvisable practices.

And you're right, the supplied tripod is a joke to anyone that's used real gear.

It's really ironic that DJI chose to bring their first "real" RTK survey solution to market at the toy/consumer grade (Phantom) rather than commercial/enterprise (Matrice).

It's cheaper, but in quality not just price.

You know the saying.... "Pick two".

Has anyone complied a decent guide on setting this up? I recently bought my unit and I am trying to determine the best method for setting everything up. I am in Ohio and I have the ODOT VRS network I would like to use instead of using the GPS they provide (is that possible?)

Jason Heyman Posted at 2-21 02:34
Has anyone complied a decent guide on setting this up? I recently bought my unit and I am trying to determine the best method for setting everything up. I am in Ohio and I have the ODOT VRS network I would like to use instead of using the GPS they provide (is that possible?)

I don't have one that's fit to share yet, but I'll try to clean it up and post it for others to use.

Here's a so-so tutorial/pitch video from a vendor (not me).



Yes, you can use an NTRIP source for your RTK corrections and completely forgo the D-RTK2 base station that came with the P4RTK. To do so your remote needs an internet connection, either by using a dongle with a sim card, or by simply using a wireless connection to a network that is range (such as a hotspot created on your phone).

The other way you can skip using the D-RTK2 is by using PPK (Post-Processed Kinnematic) instead of RTK. To do this, you turn off RTK on the aircraft (it still logs all the required data for post-processing), and then when you get the logged files off after the flight you need to process them using data from a CORS station or VRS. This approach does not get you real-time accuracy and the post-processing involves a lot of steps, but the results can be quite good (from what I've heard- I have not tried this myself).

So far, we've done RTK w/ the D-RTK2 over a known benchmark (our own, very well surveyed in using RTK & OPUS processing) as well as using only NTRIP corrections form our own network-connected community GPS base station.

Good luck, have fun, and safe flying!

patiam Posted at 2-21 09:24
I don't have one that's fit to share yet, but I'll try to clean it up and post it for others to use.

Here's a so-so tutorial/pitch video from a vendor (not me).

Thanks Patiam

I also found this video that explains how to setup/configure VRS/RTK Phantom 4 RTK - VRS setup

Jason Heyman Posted at 2-21 11:31
Thanks Patiam

I also found this video that explains how to setup/configure VRS/RTK Phantom 4 RTK - VRS setup

Good find, that covers the basic NTRIP setup pretty well.

Another good tool to have in your kit is the Lefebure NTRIP Client (windows version there, also on Play for Android). There's at least one iOS one called DigiFarm NTRIP Client as well, but I haven't used it.
These are like the BNC client in the video, they let you connect to an NTRIP caster to test connection settings, see available mountpoints, etc. Hopefully DJI will update the GUI in the app to behave as it should, which is to connect to the caster without you having to specify the mountpoint, and then give you a list of mountpoints from which to choose. If they had done even a passing review of current existing RTK receiver and associated apps they would have known that requiring the user to type in the mountpoint a priori is just wrong.

Anyway good luck & keep sharing info here!

Jason Heyman Posted at 2-21 02:34
Has anyone complied a decent guide on setting this up? I recently bought my unit and I am trying to determine the best method for setting everything up. I am in Ohio and I have the ODOT VRS network I would like to use instead of using the GPS they provide (is that possible?)

Another component.

https://forum.dronedeploy.com/t/phantom-4-rtk/11244/23?u=michaell

I have been using pix4d for the past two years for the controller software in the field and it has been good. I am leaning towards using the dji software for field collection, then processing with pix4d back in the office. Before I go down that road, any issues that I should be concerned about?

Jason Heyman Posted at 2-21 15:45
I have been using pix4d for the past two years for the controller software in the field and it has been good. I am leaning towards using the dji software for field collection, then processing with pix4d back in the office. Before I go down that road, any issues that I should be concerned about?

That has been and is our workflow now too (used to use Pix4D Capture but using the DJI software for autonomous flight mapping now w/ the P4RTK, and Pix4D for processing). No know issues with that workflow yet. We've flown both NTRIP and D-RTK2.

Still figuring out a vertical discrepancy- flew without entering the antenna height on the D-RTK2, but the point cloud and DSM are off by more than that height (by about 20 cm). Need to do more testing.

patiam Posted at 2-21 16:08
That has been and is our workflow now too (used to use Pix4D Capture but using the DJI software for autonomous flight mapping now w/ the P4RTK, and Pix4D for processing). No know issues with that workflow yet. We've flown both NTRIP and D-RTK2.

Still figuring out a vertical discrepancy- flew without entering the antenna height on the D-RTK2, but the point cloud and DSM are off by more than that height (by about 20 cm). Need to do more testing.

What vertical accuracy are averaging using the NTRIP basestation method?

Jason Heyman Posted at 2-22 06:17
What vertical accuracy are averaging using the NTRIP basestation method?

Very early for any real results yet.

Still trying to figure out a systematic offset, but when that is applied, about ±0.10m RMSE.

Hoping for better, and to suss out where that offset is coming from. XY is closer to 0.02m.

patiam Posted at 2-22 13:15
Very early for any real results yet.

Still trying to figure out a systematic offset, but when that is applied, about ±0.10m RMSE.

Tony Anderson in TX finally got an answer from DJI ref the height of the DRTK-2 base station.  I attached it.  

HTA_RP-1 Posted at 2-25 12:24
Tony Anderson in TX finally got an answer from DJI ref the height of the DRTK-2 base station.  I attached it.[view_image]  [view_image]

Yup, that's what we figured. Pretty lame that DJI does not provide the height of B using their supplied pole with the tip on the ground. No "survey grade" equipment manufacturer would even think of selling such poorly documented gear.

Thanks for relaying the news.

Jason Heyman Posted at 2-22 06:17
What vertical accuracy are averaging using the NTRIP basestation method?

After re-processing to account for an unexplained ~0.85m systematic offset in Z when we apply only the GEOID12B correction for our test site, the Z accuracy using our NTRIP station for corrections is much better (RMSE = 0.034m).
The points below were used in Pix4D as CheckPoints only - no GCPs were used to process the imagery.

So we're getting ~2cm XY and ~3cm Z accuarcy. Not bad.

Still not sure where that offset is coming from, or whether it will be consistent across flights/locations...

HTA_RP-1 Posted at 2-25 12:24
Tony Anderson in TX finally got an answer from DJI ref the height of the DRTK-2 base station.  I attached it.[view_image]  [view_image]

So when we measure the stock pole provided by DJI we get 1.660m from the pointy end to the base of the antenna. Adding 0.1419m to get to the antenna phase center as specified on the diagram and by DJI gives us 1.802m for our antenna height to be added to the BM elevation in RTK setup.

That's a few cm different than the value reported earlier by the surveyor in TX.

We'll try this value on our next flights (probably Friday).

This thread is packed with some really good information! Just wanted to say thank you to @patiam and everyone else that has contributed.

@patiam Looking forward to hearing your results from the test flights using the new offset value.  

You're welcome, BEO, and welcome to the fray!

If we all share our experiences and ideas, hopefully we can help make up for the dismal lack of documentation provided by DJI for this kit. Not to beat a dead horse, but I think DJI took the whole "survey grade" and RTK implementation a bit lightly, and it shows in the design of and how robust the gear is, the way the interface is set up, and the lack of docs.

That all being said, I think we've shown the system is capable of some pretty decent results, at least so far. More testing is needed, to be sure. But we're already getting much better accuracy than was possible with a "normal" P4, without usings GCPs. As I believe CHASCOADMIN said in the other thread, if we want to quantify our accuracy we'll never get away from GCPs or at least check points entirely...

patiam Posted at 2-26 10:03
After re-processing to account for an unexplained ~0.85m systematic offset in Z when we apply only the GEOID12B correction for our test site, the Z accuracy using our NTRIP station for corrections is much better (RMSE = 0.034m).
The points below were used in Pix4D as CheckPoints only - no GCPs were used to process the imagery.

Update on the NTRIP-corrected flight accuracy reported earlier:

I added about 35 Total Station shots to the accuracy assessment of our Jan 28 calibration flight. In GIS I compared the Z from the shots vs that of the DSM produced by Pix4D.

RMSE from these independent checkpoints is also about 3 cm.