Tornado12
lvl.4
Flight distance : 356391 ft
United States
Offline
|
I just read through this for the first time today, and there is a LOT wrong with this from a technical standpoint. Several elements of this doesn't even make sense from a technical stance. Because of that I would say this is most likely not true. For one, the UBX M8 GNSS chip is basically the same across all 3 variants. Flash memory would not be inside the chip, but external, and connected to the chip through IO. The chip could have some internal ROM but it would not be used how you describe here with all the other features of the drone. This just isn't how things work. I am NOT an expert or an electrical engineer, but I know a little about these things, enough to know this doesn't make a lot of sense. You also make the following statement:
"...Every time the drone had a cold start, it had to go through the process of downloading the ephemeris data, slowly, on a limited bandwidth, to a small pipeline..."
The drone does download this data, but I don't understand the language of "on limited bandwidth and to a small pipeline" We are talking about an ASCII text file here, that is extremely small. You talk about this thing as if the drone is having to move large amounts of data around and seem to suggest some kind of bottleneck. This just makes no sense. We are talking about miniscule amounts of data.
The summary of the issue suggested here is that the KA Variant of the UBX M8 chip doesnt have the memory to function properly versus the KT Variant of the chip, and because of this memory bottleneck, we are seeing manifestation of issues, most notably in the gps acquisition time. I just find this a little bit ridiculous. It just doesnt make a lot of logical sense. First of all, all my reading of the 3 variants, even the indepth product specification papers suggest they are essentially the same product. The M8 gnss chip is simply a single chip - it is not an entire pcb. This is a very tiny 5mm x 5mm chip. It has IO for external Flash memory, but as I said that would be external. So before we even get to the technical questions themselves we have to believe that DJI's entire Engineering team designed an inadequate gnss pcb module that was wholly inefficient, and didn't realize that they had made this mistake. If you can bring yourself to believe that, then you have to buy into this scenario that doesnt make a whole lot of technical sense....
I just cant buy this. It is too illogical. I still feel the most likely culprit here is firmware, or perhaps some integration with the Beidou constellation, but I still feel it has to be firmware. I am very puzzled that they haven't been able to fix it though. I wont rule out hardware problems, but so far there is just no evidence to go on to suggest that. All of the evidence still points to firmware, though I will admit if it is firmware it is puzzling that they didn't get it 100% fixed in this last update. The explanation here though makes even less sense though. Ill continue to follow the evidence. The above explanation feels like it was very made up by someone with very limited technical knowledge. |
|