I think that, like several of us are, @ianwood is just trying to understand the GNSS system and the components that impact or influence it's performance, or could potentially impact or influence that, in both hardware and software. This knowledge could then drive testing out certain things, not just the obvious ones, leading to potentially figuring out a workaround (like "ascend 20 feet"), because DJI remain silent on everything to do with this. The proximity of other radio signals to the GNSS antenna *could* impact it's performance, sure; unlikely to be the issue, but possible.What is the significance? Could that be the problem?
The GPS daughter board appears to have two raised contacts in the same layout/location. Roughly looks like they would connect?
View attachment 143167
Ian is very good at this stuff, he spearheaded diagnosis of the now famous toilet bowl effect and dji listened.
Hahaha, for a hot and crazy minute, I did contemplate if I could open one up and tap into the GNSS chip I/O with the rest of the system, be it SPI or I2C or UART, link to a microcontroller and log some meaningful low level info in the field I ain't touching mine either, but hopefully a "friend" can "find" one for me, per a different thread
Hahaha, yeah The problem is, that chipset is configurable for a number of key parameters, initialization data, etc. and what DJI use for that is unknown, so we would be unable to recreate what is going on, to understand it better, with just the module. Additionally, it's performance "in situ", amongst all the other signals flying around inside the Mavic 3 (ADB, Occusync, etc, as well as potential signal interference from the different internal data buses running past and around it) could be the issue, so having the module separate from that wouldn't give the same results, either. Sort of like being told your kid misbehaves at school with all the other kids, so you observe them at home alone in their bedroom to see what their bad behavior is....Or buy one instead of opening your aircraft!
View attachment 143260
There's a tendency to think that GPS Health simply depends on the number of satellites, but it doesn't.
For good location data, the receiver needs a suitable number of sats and a suitable spread of sats in different parts of the sky.
It's based on number of satellites locked, not any of the DOP calculations.
It needs further clarification. @Meta4 is quite correct that the accuracy of a GNSS solution depends on both number of satellites and their distribution in the sky. A dilution of precision estimate for just the satellites currently locked is a reasonable way to estimate that accuracy but that's not what the DJI GPS health value represents. GPS health is calculated from the correlation between the GPS and the IMU solutions for position. In other words it is more a measure of confidence in the fusion position solution than a measure of GPS accuracy.While we're waiting for more news... Here's a debate we can solve:
It IS NOT based only on the number of satellites.
It IS based only on the number of satellites.
So... Who's right? Evidence preferred over opinion. It ought to be verifiable using log data.
That looks like GPSTest....If you hit the "share" function and choose "device" on that popup, it'll upload some inner details on the RC Pro device capabilities. If you whizz on over immediately to the linked spreadsheet, the last row in there should be yours, if you're interested.In other news, it looks like the RC Pro is still using GLONASS and not Beidou.
View attachment 143332
View attachment 143331
Ignore the TTFF as I opened it up indoors and then took it outside. It was pretty quick once outside and probably used A-GPS. Looking for Android apps that provide detailed information about A-GPS use.
That looks like GPSTest....If you hit the "share" function and choose "device" on that popup, it'll upload some inner details on the RC Pro device capabilities. If you whizz on over immediately to the linked spreadsheet, the last row in there should be yours, if you're interested.
Also, as an aside, I went down a whole rabbit hole with this - my S21 didn't show BeiDou, despite a spec sheet that said it could. In researching why, I stumbled upon a blog by the GPSTest author who detailed a story of a user travelling from Europe to the USA, monitoring GPSTest, and suddenly seeing all the Galileo satellites disappear from the list once over the USA. Long story short, it's actually illegal in the US to receive foreign GNSS signals without a license! It appears that receiver manufacturers generally hadn't applied for the Galileo licenses. There is a waiver process for this for the GNSS, and the EU applied and ultimately got a waiver from requiring receivers to be licensed to use Galileo. On the FCC website for waivers, there is only the EU waiver; nothing for GLONASS (guessing because it pre-dated the ruling) and nothing for BeiDou. Part of me wonders if the lack of BeiDou is a chipset limitation or a license limitation.
BeiDou is a two-way communication system, allowing it to identify the locations of receivers. BeiDou-compatible devices can transmit data back to the satellites, even in text messages of up to 1,200 Chinese characters.
I still think some with knowledge should check out if the agps data is transfered correctly.
There is a status message that returns the agps data from the drone.
DataFlycGetPushAgpsStatus, DataFlycSendAgpsData
Could also be nice to check that the gps har the correct time.
Good question. I don't think so, not sure though.Are these status messages that appear in log files? If so, I can pull some from cold and warm starts to analyze.
We use essential cookies to make this site work, and optional cookies to enhance your experience.