I have not worked with uBlox at an I2C or UART level in quite some time but I know enough to know what he has written across myriad posts doesn't make much sense. I can highlight plenty of things he says that are not at all accurate.
A "chip teardown" in this forum that highlights differences in memory architecture. This does not exist. He then says he was wrong and got the information from DJI engineers. As if they're having detail integration discussions with end users.
View attachment 145869
He also claims to have "blueprints" of the chip variants. Like uBlox hands those out like candy. Not to mention irrelevant and mostly useless. He has also been referring to an unpopulated chip location on the PCB as if DJI forgot to put something there. He doesn't know what he is talking about. I can go on but it's really not worth it. His explanation morphs and gets sketchier with each additional post he makes.
My uBlox NDA has expired and would need to be renewed to access the current M8030 documentation. Nonetheless, no one seems to be able to point to any uBlox doc, discussion, etc. that highlights a fundamental difference in "memory architecture" between variants that impacts ephemeris. I have found no reference in any sources I do have access to. Doesn't mean it doesn't exist but
it seems highly implausible that uBlox would design a series variant with such a significant difference in its critical function without making this abundantly clear. This is my biggest issue with his claim.
There may very well be memory issues somewhere in the overall design of the Mavic 3 but I highly doubt it relates to the use of the KA variant M8030. Maybe the FC doesn't have enough memory of its own but that is unrelated to GNSS. Even if THAT were true (just described incredibly inaccurately), it still does not explain the long duration of cold starts where there is no current ephemeris. If there isn't enough memory for ephemeris, you're not getting off the ground. If there is, there is. No issue.
I suppose there could be excessive paging or use of swap on the FC but that would likely slow everything down and manifest itself in many unpleasant ways beyond slow GNSS. Maybe there are initialization routines that consume memory temporarily. That still does not explain the seemingly random distribution of time-to-first-homepoint we have seen. I still don't see how adding mastershots or hyperlapse functions would impact usable memory if those functions are not in use. They may occupy storage but not active memory until they are in use.
What we DO know from DJI is they are using new sensor fusion algorithms for their AHRS functions on the FC which has improved overall positioning accuracy. My best guess as to the cause of the slow time-to-first-homrepoint is active filtering of SVs based on HDOP to improve overall positioning accuracy. I bet if you plugged into the UART on the GNSS you would find a pretty normal TTFF but the FC is discarding low quality SVs. I have no evidence to support this theory. It is mere speculation. But at least it is consistent with what people have experienced which is more than can be said of the theory we are debating.
Another possibility would be an issue with SDR or overall RF design between different functions like Airsense, Occusync, etc. Which again would be a far more consistent and plausible explanation of what has been observed.
www.techinasia.com
