Anytime I need to pause a mapping mission and do a battery swap with my M3E, the altitude EXIF readings in the photos are vastly different after I continue the mission I paused. This causes extreme tilt of the point cloud after initial processing. I have no idea what is causing this, because I am simply continuing the flight I had paused. The controller shows ~150' AGL during all flights, before and after all battery swaps. I have mapped with several DJI drones and never experienced this. Also, this is without RTK. I do plan on going RTK soon.

I've attached some photos of the point cloud on Pix4D, this is a test flight I did with a couple mission pauses and battery swaps to demonstrate the issue. I also attached photos of the exact same mission being flown with no battery changes, where the "tilt" and orientation of the point cloud is more or less correct and true to real-world conditions. Both projects processed in Pix4D with identical settings.

My MRK files for flight 1 show an ellipsoidal height of ~1755 meters, flight 2 ~1761 meters, and flight 3 ~1825 meters. Screenshots of those attached as well. What's with the huge change? Everything was flown at 150' AGL from the same launch spot.

Granted, this is before using GCPs to correct the positioning and orientation. However, I feel like relying on my GCPs to correct an issue this extreme is not best practice and could cause distortion or inaccuracies elsewhere in the mapped area. I would like my mapped areas to not have glaring issues like this before I correct them with GCPs, if that makes sense. Any idea what may be causing this or how to fix it?

There is clearly a problem with altitude, this has already been reported several times with DJI drones.  
A crazy story of GNSS receiver and baro.  

Using RTK should completely solve the problem.  In the meantime, I recommend that you deactivate the altitude reading in your photogrammetry software and set everything manually to the same value.  Also it is necessary to adjust the precision to +/-10m.  And finally you correct with the GCP.  

You need a lot of GCP, especially at the periphery, otherwise there is guaranteed distortion.

LV_Forestry Posted at 11-11 00:29
There is clearly a problem with altitude, this has already been reported several times with DJI drones.  
A crazy story of GNSS receiver and baro.  

Yes GCPs are absolutely necessary, whenever I map an area for client I always use them. This flight was more of a test case; I had noticed that every Mavic 3E mission I flew with a battery change had this crazy tilt, and wildly varying GPS heights.

I'm starting to wonder if even after the controller indicates a 10 or 11 satellite GPS lock and says "home point recorded", it still doesn't actually have a substantial enough GPS lock. I'm going to leave the drone on the ground for a couple extra minutes after it claims to have a GPS lock, and see if that helps. I also think I'll be purchasing the RTK module sooner than expected.

Drone_on_and_on Posted at 11-13 09:47
Yes GCPs are absolutely necessary, whenever I map an area for client I always use them. This flight was more of a test case; I had noticed that every Mavic 3E mission I flew with a battery change had this crazy tilt, and wildly varying GPS heights.

I'm starting to wonder if even after the controller indicates a 10 or 11 satellite GPS lock and says "home point recorded", it still doesn't actually have a substantial enough GPS lock. I'm going to leave the drone on the ground for a couple extra minutes after it claims to have a GPS lock, and see if that helps. I also think I'll be purchasing the RTK module sooner than expected.

The tilt comes from PiX4D. It is the software which decides to prioritize the exif data rather than the photogrammetric data. In Metashape we can overcome this easily. No clue if this is possible in PiX4D.

There's no point in waiting any longer GNSS lock. if the solution is lock then there is nothing else to do. But the difference in altitude is still worrying.

I invite you to write to enterprise@dji.com explaining the problem to them. Don’t hesitate to share the answer with us.

Drone_on_and_on Posted at 11-13 09:47
Yes GCPs are absolutely necessary, whenever I map an area for client I always use them. This flight was more of a test case; I had noticed that every Mavic 3E mission I flew with a battery change had this crazy tilt, and wildly varying GPS heights.

I'm starting to wonder if even after the controller indicates a 10 or 11 satellite GPS lock and says "home point recorded", it still doesn't actually have a substantial enough GPS lock. I'm going to leave the drone on the ground for a couple extra minutes after it claims to have a GPS lock, and see if that helps. I also think I'll be purchasing the RTK module sooner than expected.

Remember that with non-precision gnss flight, the exif is tagged with the height above take-off, not MSL.  When you attach an RTK module, your exif will indicate MSL height, not height above take-off, and this problem will be solved.  
With non- precision gnss work, do what @LV_Forestry suggests for workflow.
I agree, it is odd that you are getting such difference from one flight to the next.  I have never flown a mission with the M3E without the RTK module, so I don't know if mine would do the same or not.  My P4P, or M2P never showed that tendancy.

Drone_on_and_on Posted at 11-13 09:47
Yes GCPs are absolutely necessary, whenever I map an area for client I always use them. This flight was more of a test case; I had noticed that every Mavic 3E mission I flew with a battery change had this crazy tilt, and wildly varying GPS heights.

I'm starting to wonder if even after the controller indicates a 10 or 11 satellite GPS lock and says "home point recorded", it still doesn't actually have a substantial enough GPS lock. I'm going to leave the drone on the ground for a couple extra minutes after it claims to have a GPS lock, and see if that helps. I also think I'll be purchasing the RTK module sooner than expected.

Hello, there. May we know if you contacted our support for help?