Think we may find a improvement for the Mavic 3 gps issues tried it today and it works went from 6 min to 1min 20sec after firmware refresh

[GadgetGuy]

I Refreshed the aircraft FW and RC-Pro FW tonight through the DJI Assistant 2 (Consumer Drones Series), and immediately got more satellites indoors after, than before the Refresh, after 10 minutes outdoors. This is likely just a warm boot effect. However I will try a cold boot tomorrow from another location and report back, but I am hopeful, and very desperate!

 

[GadgetGuy]

I can confirm @01siver4 's results, after refreshing both FW on the M3 and RC-Pro.
Homepoint and 13 satellites acquired on a cold boot at a new location after 2:20 instead of well over 5 minutes before the Refresh. If you are having satellite acquisition issues after the December and January updates, try a FW Refresh. Worked for me, too!

 

[GadgetGuy]

A second flight later in the day required 6 minutes to acquire enough satellites to set the Home Point! However, when I got back home, 10 miles away, it set the home point indoors within 30 seconds! Go figure!

 

[BlairAir]

It would also help if each person experiencing the issue would report whether they are using the RC-Pro or the RC-N1 RC, and if the latter, whether an iOS or Android device, and how they updated the FW of the aircraft and the controller. It could be an Android issue, or it could be just limited to the RC-Pro. I'm experiencing the problem with the RC-Pro, and I did all updates through the RC-Pro, over Wifi, rather than hardwired with Assistant 2. It could be that the static data referred to above wasn't properly flushed with the update over the RC-Pro. It apparently isn't affecting all users, just a subset. The more we can learn about what this subset has in common, the quicker we can find a resolution.

ALSO RC Pro, 5-6 minutes and have had it since V01.00.0400, not V01.00.0500. Refreshed FW with DJI Assistant and no difference.

 

[BlairAir]

A second flight later in the day required 6 minutes to acquire enough satellites to set the Home Point! However, when I got back home, 10 miles away, it set the home point indoors within 30 seconds! Go figure!

The time it took to "get back home"? I can fly multiple locations all within an hour or do with fast aquisition and lock. Once I go charge batteries an fly again it's back to square 1.

 

[GadgetGuy]

ALSO RC Pro, 5-6 minutes and have had it since V01.00.0400, not V01.00.0500. Refreshed FW with DJI Assistant and no difference.

Yes, it seems the Refresh of the FW also locks onto the satellites during the update, resulting in immediate Home Point setting afterwards, creating the illusion of a fix (no pun intended!). Best workaround is swapping batteries after the lock to a fresh battery, or immediately flying to 96 feet and letting the Home Point be set from the higher elevation in the air, and descending to swap batteries, or sallying forth on the mission.

 

[GadgetGuy]

The time it took to "get back home"? I can fly multiple locations all within an hour or do with fast aquisition and lock. Once I go charge batteries an fly again it's back to square 1.

It was less than 30 minutes later that I tested 10 miles away, and it locked quickly. it It makes sense that an acquired lock has around a 2 hour expiration for all nearby locations, say within 10 miles. The satellites' future locations from nearby an original lock can be reliably predicted, but after two hours, doing so appears beyond the capability of the GPS device, requiring a cold boot to lock. The warm boot parameters appear to be within 10 miles and within 2 hours. In rare cases, the two hours may be able to be exceeded, especially if the location is the same as the last lock.

 

[beermat]

It was less than 30 minutes later that I tested 10 miles away, and it locked quickly. it It makes sense that an acquired lock has around a 2 hour expiration for all nearby locations, say within 10 miles. The satellites' future locations from nearby an original lock can be reliably predicted, but after two hours, doing so appears beyond the capability of the GPS device, requiring a cold boot to lock. The warm boot parameters appear to be within 10 miles and within 2 hours. In rare cases, the two hours may be able to be exceeded, especially if the location is the same as the last lock.

There are no specific parameters like that, but the net effect of how GNSS works has a similar effect. To simplify (and assuming a valid almanac is in place), then downloading position data from a satellite is what causes the "delay" in acquiring a lock - you first need to know where the visible satellites are to calculate where you are, and that satellite location data download (ephemeris data) from the satellite can take 30 seconds or more. This is a "warm start" if this happens. Ephemeris data is regenerated approximately every four hours, so depending on when it was generated and when you receive it, it could be valid to you for less than that. This data can be cached once downloaded, however, and when the receiver starts up later, it can check to see if it has valid cached ephemeris data for all the satellites it sees. If it does, then it can provide a lock "instantly", called a "hot start".

So, what changes this ability to do a "hot start"? On starting the receiver, if the same satellites are visible, but enough time has passed such that the cached data is no longer valid, it needs to re-download this data, pushing you into "warm start" timeframes.

Additionally, satellites are orbiting, and rise and set approximately twice a day for a given location. When starting the receiver, even if the timeframe is within the valid cached data timeframe, one of the previously-seen satellites may have orbited beyond visibility, and a different satellite in that orbital plane is now in view, for which you have no cached data, requiring the download and "warm start". Similarly, if you move a significant distance, that can change which satellites are now visible, especially given the timeframe to move, so when starting the receiver up, the chances of seeing the same satellites, and the cached data being still valid timewise, are significantly reduced.

So, there are no "hard" parameters set for a "hot start", it's basically - do you have valid cached ephemeris data for all the satellites you can see. The passage of time affects the validity of the cached data and the visible satellites as they orbit, and the moving of a significant distance affects the visibility of the same satellites even if you could move instantaneously; but as they also orbit in the time taken to move a significant distance, this increases the odds of the visible satellites changing.

Here's a dump of data of the GPS satellites seen by a uBlox M8 chip on my desktop right now (it's the GNSS chip used in just about every DJI drone from the P4Pro to the Air2S), to give you an idea of what the GNSS system "sees":



You can see that satellites G8, G16, G26, G27 and G31 are visible and the current ephemeris data is good for another 2.5 hours. G9 is visible, but no ephemeris download yet. G25 is no longer visible, and the cached data is good for 0.5 hours. G31 is in visible state of "EL", which means it's elevation is low to the horizon and it will soon orbit out of view. If I were to restart the GNSS chip within 10 mins, I may or may not get a "hot start", depending if G31 orbits away. If I restarted it 3 hours later, I would not get a "hot start" as none of the cached data is valid for that long. If I teleported to the opposite side of the planet instantly, none of those sats would be visible and it'd be a "warm start" while I wonder how the hell I just teleported to the other side of the world

 

[mobilehomer]

There are no specific parameters like that, but the net effect of how GNSS works has a similar effect. To simplify (and assuming a valid almanac is in place), then downloading position data from a satellite is what causes the "delay" in acquiring a lock - you first need to know where the visible satellites are to calculate where you are, and that satellite location data download (ephemeris data) from the satellite can take 30 seconds or more. This is a "warm start" if this happens. Ephemeris data is regenerated approximately every four hours, so depending on when it was generated and when you receive it, it could be valid to you for less than that. This data can be cached once downloaded, however, and when the receiver starts up later, it can check to see if it has valid cached ephemeris data for all the satellites it sees. If it does, then it can provide a lock "instantly", called a "hot start".

So, what changes this ability to do a "hot start"? On starting the receiver, if the same satellites are visible, but enough time has passed such that the cached data is no longer valid, it needs to re-download this data, pushing you into "warm start" timeframes.

Additionally, satellites are orbiting, and rise and set approximately twice a day for a given location. When starting the receiver, even if the timeframe is within the valid cached data timeframe, one of the previously-seen satellites may have orbited beyond visibility, and a different satellite in that orbital plane is now in view, for which you have no cached data, requiring the download and "warm start". Similarly, if you move a significant distance, that can change which satellites are now visible, especially given the timeframe to move, so when starting the receiver up, the chances of seeing the same satellites, and the cached data being still valid timewise, are significantly reduced.

So, there are no "hard" parameters set for a "hot start", it's basically - do you have valid cached ephemeris data for all the satellites you can see. The passage of time affects the validity of the cached data and the visible satellites as they orbit, and the moving of a significant distance affects the visibility of the same satellites even if you could move instantaneously; but as they also orbit in the time taken to move a significant distance, this increases the odds of the visible satellites changing.

Here's a dump of data of the GPS satellites seen by a uBlox M8 chip on my desktop right now (it's the GNSS chip used in just about every DJI drone from the P4Pro to the Air2S), to give you an idea of what the GNSS system "sees":

View attachment 143951

You can see that satellites G8, G16, G26, G27 and G31 are visible and the current ephemeris data is good for another 2.5 hours. G25 is no longer visible, and the cached data is good for 0.5 hours. G31 is in visible state of "EL", which means it's elevation is low to the horizon and it will soon orbit out of view. If I were to restart the GNSS chip within 10 mins, I may or may not get a "hot start", depending if G31 orbits away. If I restarted it 3 hours later, I would not get a "hot start" as none of the cached data is valid for that long. If I teleported to the opposite side of the planet instantly, none of those sats would be visible and it'd be a "warm start" while I wonder how the hell I just teleported to the other side of the world

How many BeiDou sats do you see? My S21 Ultra and RC Pro see zero. Just north of Nashville, TN if that makes any difference.

 

[beermat]

How many BeiDou sats do you see? My S21 Ultra and RC Pro see zero. Just north of Nashville, TN if that makes any difference.

Not all S21s have the capability to show BeiDou sats; depends on the market they were manufactured for, they have different internal chipsets. It's either a hardware or software restriction. My S21 in Chicago reports 0 BeiDou sats via GPSTest, but it also reports to GPSTest that it isn't equipped to show BeiDou. However, a GNSS chip I'm playing with reports 2-4 BeiDou sats when I'm indoors with the antenna smushed to my window.

Note that the RC Pro doesn't use/have the capability for BeiDou for it's own GNSS lock, it uses GPS, Galileo and GLONASS.

 

[GadgetGuy]

There are no specific parameters like that, but the net effect of how GNSS works has a similar effect. To simplify (and assuming a valid almanac is in place), then downloading position data from a satellite is what causes the "delay" in acquiring a lock - you first need to know where the visible satellites are to calculate where you are, and that satellite location data download (ephemeris data) from the satellite can take 30 seconds or more. This is a "warm start" if this happens. Ephemeris data is regenerated approximately every four hours, so depending on when it was generated and when you receive it, it could be valid to you for less than that. This data can be cached once downloaded, however, and when the receiver starts up later, it can check to see if it has valid cached ephemeris data for all the satellites it sees. If it does, then it can provide a lock "instantly", called a "hot start".

So, what changes this ability to do a "hot start"? On starting the receiver, if the same satellites are visible, but enough time has passed such that the cached data is no longer valid, it needs to re-download this data, pushing you into "warm start" timeframes.

Additionally, satellites are orbiting, and rise and set approximately twice a day for a given location. When starting the receiver, even if the timeframe is within the valid cached data timeframe, one of the previously-seen satellites may have orbited beyond visibility, and a different satellite in that orbital plane is now in view, for which you have no cached data, requiring the download and "warm start". Similarly, if you move a significant distance, that can change which satellites are now visible, especially given the timeframe to move, so when starting the receiver up, the chances of seeing the same satellites, and the cached data being still valid timewise, are significantly reduced.

So, there are no "hard" parameters set for a "hot start", it's basically - do you have valid cached ephemeris data for all the satellites you can see. The passage of time affects the validity of the cached data and the visible satellites as they orbit, and the moving of a significant distance affects the visibility of the same satellites even if you could move instantaneously; but as they also orbit in the time taken to move a significant distance, this increases the odds of the visible satellites changing.

Here's a dump of data of the GPS satellites seen by a uBlox M8 chip on my desktop right now (it's the GNSS chip used in just about every DJI drone from the P4Pro to the Air2S), to give you an idea of what the GNSS system "sees":

View attachment 143951

You can see that satellites G8, G16, G26, G27 and G31 are visible and the current ephemeris data is good for another 2.5 hours. G9 is visible, but no ephemeris download yet. G25 is no longer visible, and the cached data is good for 0.5 hours. G31 is in visible state of "EL", which means it's elevation is low to the horizon and it will soon orbit out of view. If I were to restart the GNSS chip within 10 mins, I may or may not get a "hot start", depending if G31 orbits away. If I restarted it 3 hours later, I would not get a "hot start" as none of the cached data is valid for that long. If I teleported to the opposite side of the planet instantly, none of those sats would be visible and it'd be a "warm start" while I wonder how the hell I just teleported to the other side of the world

Thank you! That's really helpful!

 

[kesteloo]

This works for me went from 6min to 1min 20sec to lock on to 13 satellites after firmware refresh

We just received an official statement from DJI in which the drone maker acknowledges the DJI Mavic 3 GPS issue and promises us that it will be addressed with a firmware update soon. Read more about it here: DJI Mavic 3 GPS Issue - Fix With Firmware Update Coming Soon

 

[370Z2017]

It's not exactly clear from your explanation, but it sounds like you are just referring to the difference between a cold boot and warm boot, which is quite normal for GPS receivers.

 

[370Z2017]

After a cold boot, how long is considered enough time to pass before performing another cold boot? Maybe I'm doing something wrong... Thanks

 

[Dale D]

RE: GPS lo k with the Mavic 3- after the new update of the drone and the app, I didn't time it today but I tried it today and it captured GPS lock well within a minute or less for a cold boot. It was much longer before the update. I am encouraged.

 

[Meta4]

After a cold boot, how long is considered enough time to pass before performing another cold boot? Maybe I'm doing something wrong...

After the recent firmware update, the Mavic 3 picks up 20+ sats very quickly and records a home point as it should.
Before the update, it would take minutes and still be looking at low numbers without haveing recorded a home point.

 

[BlairAir]

After the recent firmware update, the Mavic 3 picks up 20+ sats very quickly and records a home point as it should.
Before the update, it would take minutes and still be looking at low numbers without haveing recorded a home point.

This IS encouraging. Too bad they dropped V01.00.0700 AS I WAS OUT AT UPS shipping it in for what is now constant disconnects on RC Pro. Started with V01.00.0600 or I should say v03.01.600 on RC Pro. Could be coincidence, but I never had a single disconnect all the way back to when I recieved it last November. Mostly video transmission, and only in dual band (Auto) not in 5.8 ghz. Sometimes complete controller loss, and RTH ensues with no control at all. So I gave up waiting for FW that might fix it. That and the complete absence of Airsense operation. My Air 2 and 2S have functioning Airsense. Mavic 3? Nothing. I mainly shipped it back to stop arguing that never seeing a single aircraft (when I live in a high air traffic area) is not "Airsense working to keep me safe" or "Tuned to avoid excess alerts" unless excess means "all" and I didn't get the memo.

Really like some of these updates, and anxious to try them. Too bad warranty service is nothing like Care Refresh Express. I shipped it Tuesday. It won't even arrive at support until NEXT WEDNESDAY.


Anyone checked Airsense?

 

[GadgetGuy]

After a cold boot, how long is considered enough time to pass before performing another cold boot? Maybe I'm doing something wrong... Thanks

24 hours is a safe bet.

 

[370Z2017]

24 hours is a safe bet.

Thank you Sir!

 

[370Z2017]

Thank you Meta 4 and Dale D!