There are (at least) 2 sets of coords data that exist in the .DAT. There is the GPS coords that come directly from the GPS receiver. That's the raw GPS data that can be found in the GPS record - DatCon labels these fields GPS(0):Long and GPS(0):Lat. Then there are the latitude and longitude values that can be found in the IMU record, labelled IMU(0):Latitude and IMU(0):Longitude). These are actually computed values that come from fusing the GPS data with IMU data (accelerometers, gyros), and magnetometer data. The .kml that DatCon produces is based on the computed latitude/longitude values, not the raw GPS data.I tried to create kml files for Google Earth and csv files for spreadsheets with several 'DAT' files from my Spark flight records
(using DatCon to convert DAT to either csv or kml)
but
the approach did not produce Google Earth drone paths from the kml and the DatCom csv did not produce spreadsheet columns containing GPS data.
However, the corresponding FlightRecord 'text' files:
do produce Google Earth path traces with PhantomHelp website uploads
and
the csv in the spreadsheet has GPS data.
Computing the IMU latitude/longitude values isn't always possible. If not, then DatCon can't create a .kml. NavHealth (formerly known as gpsHealth) is a measure of the confidence that the FC has in the computed latitude/longitude values. It ranges from 0 (no confidence) to 5 (full confidence). There are several reasons that will cause the FC to lower the navHealth value. Insufficient satellites is one reason but low confidence can also be caused by a compass error.
Maybe you could provide a .DAT that we could look at. It might also help if you provided the corresponding .txt.