EDIT: No doubt,
@beermat made some very interesting evaluations on the GNSS board. I really appreciate him doing that. But I think he would also agree, we have not discovered a smoking gun with respect to the slow boot times on the
Mavic 3 and why they're so different and got worse in Dec.
Correct. I resisted the urge to speculate, even then, tempting as it was
In my testing (via u-center and my own code) of the
M3 GPS module I received, even with the unpopulated chip, it functioned exactly the same as the Mavic Air chip did, and functioned as expected and documented, through power cycles, warm starts, cold starts, even with A-GNSS via uBlox AssistNow.
There is one simple thing I always throw into the mix as I agonize on theories on what causes this, and it's important in the context of the latest "theory" passed off as fact, and that is - hot swapping the battery after the home point has been established. The
M3 can only be using persistent storage (flash, battery-backed RAM, etc) for ephemeris data at this point, and it works fine in this case in "instantly" establishing a home point, even for those experiencing long initial acquisition times. Removing the main battery power will clear all data stored in volatile RAM and leave only persistent storage available. Whether power is removed for 30 seconds or 12 hours, that is still true so how can it have space to retain that data when powered up 30 seconds later but not 12 hours later? That doesn't make sense.
Acquire a home point, fly a Hyperlapse mission and use any of the other new features introduced in the Dec firmware, and then remove the battery for 45 seconds, re-insert, and it will lock the home point in seconds. How does that fit with the newly proposed theory?
Also, with the
M3 uBlox GPS module (which I identified in that thread a while ago as being a different variant of the typical chip used by DJI), I downloaded almanacs and ephemeris data for *every* GNSS system and *every* satellite, regardless of current visibility, via the AssistNow service, stored it in the battery backed RAM, and power-cycled it, and it retained it. It has enough memory on-chip. I don't recall the uBlox M8 specifications giving any way for an end-user to use the BBR storage independently as a generic data store, either.
The other thing is, in this age of reliable high-speed internet, people tend to have the viewpoint that a long download time is indicative of size of the download, and thus the ephemeris and almanac data must require a lot of storage, and that's why this latest "theory" makes sense, squeezing it into memory is an issue. In fact, it's just that satellites have incredibly low bandwidth that makes it slow - the full set of almanac and ephemeris data for all GNSS systems and all satellites is around 10Kb. That's less than the "Google" image that downloads when you go to the deliberately-minimal ww.google.com page. It's a tiny amount of data.
So, as you ultimately said - who knows? The latest theory is hard to take as it doesn't make technical sense, knowing how the uBlox chip functions and can be used, and also the behavior of the OP in subsequent follow-ups makes it hard to believe. He claimed to only be passing on information, but he wasn't - he was presenting a theory backed with information that was secretly only available to him (red flag as that is unverifiable, classic conspiracy tactic) and information that he claimed was on other forum posts, which turned out to be false or non-existent/misunderstood.