Lost my Spark, but have I searched in the right place?

[Templar 74]

Hello.

I've managed to mess things up again..

.I was flying towards a small hill with a steady incline and good visibility.
For some inexplicable reason, I decided to press the 'Return to Home' button to bring the drone back, and that's when the chaos started:The drone wanted to land right there and then.

I tried to abort the landing, but I was bombarded with messages and warnings, and to top it off, the Wi-Fi signal disappeared. Wiser from previous experiences, I took a screenshot of where the drone was on the map in the DJI GO4 app, and that turned out to be a lifesaver!
'Find My Drone' wasn't working, and it seems that the GPS coordinates are missing, making it impossible for me to check the flight log with the map.In the app, I had a clear idea of where the drone was located, so I hoped it would still be in that area.

There was a lot of underbrush and grass, but I had a UV flashlight that makes my Spark shine like, well..., a spark in the dark! . I couldn't find it despite searching in both daylight and darkness.Are any of you experts able to shed more light on where the drone might have gone?


Flight log: DJI Flight Log Viewer - PhantomHelp.com

 

[Meta4]

'Find My Drone' wasn't working, and it seems that the GPS coordinates are missing, making it impossible for me to check the flight log with the map.In the app, I had a clear idea of where the drone was located, so I hoped it would still be in that area.

The flight data you posted is no use, I cannot even tell which continent the flight was made on.
It has no location data at all.

 

[slup]

This flight seems to be far from a normal one... consisting of both plain pilot errors & troublesome warning messages throughout the flight.

You took off without any HP recorded at all, & furthermore no one was ever recorded during the flight either... meaning that if you was to lose the connection the Spark would just land.

The sat count started out on 11 & was at best 15 (blue graph)... this should during normal circumstances mean a good GPS support, but not in this case unfortunately. The GPS level (black graph) that is 5 at best, was mostly at 2 during this flight... & as the HP is only recorded from 4, no HP was recorded. This can mean that the spread of sats in the sky was insufficient or that something is wrong with your Spark, I suspect the later.

Despite this, you took off & started to fly in a mix of Sport & GPS mode & stepwise ascended up to 894ft (red graph)... 344sec into the flight you had your first major disconnect which lasted for approx. 17,7sec. When you regain connection the auto landing is already in progress. After this you again lose connection, this time for approx. 14,6sec, but when the connection returns it's there for just a couple seconds before it gone for good. When the log ends your Spark was up on 706ft with 28% battery remaining... & was landing.

No GPS position from your Spark exists in the .TXT log at all, maybe something is recorded in the mobile device .DAT log which is stored in the same place in your phone but in a sub-folder there called MCDatFlightRecords. Retrieve the one ending with ...FLY0680.DAT & attach it in a new post in this thread.

Here all the relevant data from the log:

(Click on the chart to make it larger)


And here the log message stream... highlighted in red tells you that something is going on with the GPS positional support. It also show various other worrying messages...

 

[Templar 74]

The flight data you posted is no use, I cannot even tell which continent the flight was made on.
It has no location data at all.

Thank you for your reply.
It is very strange. I cannot understand why this happened. I only hope that the screenshot from the app is showing the correct location.
Back to the forest then!

 

[Yorkshire_Pud]

If you are going to be looking for the DAT

SWITCH SYNCING OFF otherwise the DAT will be lost.

 

[Templar 74]

This flight seems to be far from a normal one... consisting of both plain pilot errors & troublesome warning messages throughout the flight.

You took off without any HP recoded at all, & furthermore no one was ever recoded during the flight either... meaning that if you was to lose the connection the Spark would just land.

The sat count started out on 11 & was at best 15 (blue graph)... this should during normal circumstances mean a good GPS support, but not in this case unfortunately. The GPS level (black graph) that is 5 at best, was mostly at 2 during this flight... & as the HP is only recorded from 4, no HP was recorded. This can mean that the spread of sats in the sky was insufficient or that something is wrong with your Spark, I suspect the later.

Despite this, you took off & started to fly in a mix of Sport & GPS mode & stepwise ascended up to 894ft (red graph)... 344sec into the flight you had your first major disconnect which lasted for approx. 17,7sec. When you regain connection the auto landing is already in progress. After this you again lose connection, this time for approx. 14,6sec, but when the connection returns it's there for just a couple seconds before it gone for good. When the log ends your Spark was up on 706ft with 28% battery remaining... & was landing.

No GPS position from your Spark exists in the .TXT log at all, maybe something is recorded in the mobile device .DAT log which is stored in the same place in your phone but in a sub-folder there called MCDatFlightRecords. Retrieve the one ending with ...FLY0680.DAT & attach it in a new post in this thread.

Here all the relevant data from the log:

(Click on the chart to make it larger)
View attachment 169201

And here the log message stream... highlighted in red tells you that something is going on with the GPS positional support. It also show various other worrying messages...

View attachment 169202

This flight seems to be far from a normal one... consisting of both plain pilot errors & troublesome warning messages throughout the flight.

You took off without any HP recoded at all, & furthermore no one was ever recoded during the flight either... meaning that if you was to lose the connection the Spark would just land.

The sat count started out on 11 & was at best 15 (blue graph)... this should during normal circumstances mean a good GPS support, but not in this case unfortunately. The GPS level (black graph) that is 5 at best, was mostly at 2 during this flight... & as the HP is only recorded from 4, no HP was recorded. This can mean that the spread of sats in the sky was insufficient or that something is wrong with your Spark, I suspect the later.

Despite this, you took off & started to fly in a mix of Sport & GPS mode & stepwise ascended up to 894ft (red graph)... 344sec into the flight you had your first major disconnect which lasted for approx. 17,7sec. When you regain connection the auto landing is already in progress. After this you again lose connection, this time for approx. 14,6sec, but when the connection returns it's there for just a couple seconds before it gone for good. When the log ends your Spark was up on 706ft with 28% battery remaining... & was landing.

No GPS position from your Spark exists in the .TXT log at all, maybe something is recorded in the mobile device .DAT log which is stored in the same place in your phone but in a sub-folder there called MCDatFlightRecords. Retrieve the one ending with ...FLY0680.DAT & attach it in a new post in this thread.

Here all the relevant data from the log:

(Click on the chart to make it larger)
View attachment 169201

And here the log message stream... highlighted in red tells you that something is going on with the GPS positional support. It also show various other worrying messages...

View attachment 169202

 

[slup]

If you are going to be looking for the DAT

SWITCH SYNCING OFF otherwise the DAT will be lost.

A Spark uses the DJI Go 4 app ... no such choice exists there, all syncing is manual.

 

[Yorkshire_Pud]

Ahh thanks.

 

[Templar 74]

Hello again. Finally, here's the Dat file. I attempted to send it while I was out in the woods searching, but it seems that attempt wasn't successful. Well, now I've managed to connect to a laptop, and I hope this is the file you requested. I'm grateful for the help I'm receiving, and I'll make another attempt to search before winter arrives.

Is there a way to check if the drone may have drifted with the wind when it landed? I believe the position I took a screenshot of is the correct one, and it should be relatively close to that point. However, I've been on two trips without finding it, so I'm starting to lose hope.

Nevertheless, I want to thank you once again for the help here on the forum.

 

[BudWalker]

Hello again. Finally, here's the Dat file. I attempted to send it while I was out in the woods searching, but it seems that attempt wasn't successful. Well, now I've managed to connect to a laptop, and I hope this is the file you requested. I'm grateful for the help I'm receiving, and I'll make another attempt to search before winter arrives.

Is there a way to check if the drone may have drifted with the wind when it landed? I believe the position I took a screenshot of is the correct one, and it should be relatively close to that point. However, I've been on two trips without finding it, so I'm starting to lose hope.

Nevertheless, I want to thank you once again for the help here on the forum.

Take a look here



Longitude: 12.4625493
Latitude: 60.6757994

These are the last recorded GPS coordinates. The Spark was in auto land mode and should have descended straight down.

 

[Templar 74]

This has probably become a bit of a cliché by now, but I'm really impressed by the smart folks here on this forum! It seems like I've been looking in the wrong place, and all those hours I spent wandering around in the woods and fields have only resulted in my better half having exclusive rights to the TV remote, and the next thinning job won't be quite as extensive for the forestry workers I'm going for another walk tomorrow, and since it's going to be even longer, I'll have plenty of time to ponder the depth of my abysmal drone piloting assessments!
I attached a photo of the moment of realization out there in the forest.

 

[RodPad]

That Picture fits your story!

BTW, your now required..
#1 Take a picture of where you found it.
#2 Hang around on this Forum and tell others why its important to cough up the data.

I watch all of these and learn a lot!

Rod ..

 

[BudWalker]

This has probably become a bit of a cliché by now, but I'm really impressed by the smart folks here on this forum! It seems like I've been looking in the wrong place, and all those hours I spent wandering around in the woods and fields have only resulted in my better half having exclusive rights to the TV remote, and the next thinning job won't be quite as extensive for the forestry workers I'm going for another walk tomorrow, and since it's going to be even longer, I'll have plenty of time to ponder the depth of my abysmal drone piloting assessments!
I attached a photo of the moment of realization out there in the forest.

Hope you find it.

 

[BudWalker]

Some may be asking why the .txt log has no location data but the .DAT log does. The location data recorded in the .txt are actually values computed by the Flight Controller. In addition to GPS data the FC uses accelerometer, gyro and magnetometer data to derive higher resolution location data than available from GPS. In this incident the FC had low confidence in the derived location data and didn't use or record it. I don't know why the FC didn't like its location solution. There weren't any obvious problems with the accelerometer, gyro and magnetometer data.

In addition to the derived location data the .DAT records the GPS data which was then used to determine where the Spark went down.

 

[Yorkshire_Pud]

Some may be asking why the .txt log has no location data but the .DAT log does. The location data recorded in the .txt are actually values computed by the Flight Controller. In addition to GPS data the FC uses accelerometer, gyro and magnetometer data to derive higher resolution location data than available from GPS. In this incident the FC had low confidence in the derived location data and didn't use or record it. I don't know why the FC didn't like its location solution. There weren't any obvious problems with the accelerometer, gyro and magnetometer data.

In addition to the derived location data the .DAT records the GPS data which was then used to determine where the Spark went down.

Just wondering, do "APPGPS.latitude" & "APPGPS.longitude" come from the phone's gps? It suddenly struck me that that is what "APP" might refer to.

 

[BudWalker]

Just wondering, do "APPGPS.latitude" & "APPGPS.longitude" come from the phone's gps? It suddenly struck me that that is what "APP" might refer to.

I believe that's correct.

 

[slup]

Some may be asking why the .txt log has no location data but the .DAT log does. The location data recorded in the .txt are actually values computed by the Flight Controller. In addition to GPS data the FC uses accelerometer, gyro and magnetometer data to derive higher resolution location data than available from GPS.

Yeah... suspected something like this.

Longitude: 12.4625493
Latitude: 60.6757994

These are the last recorded GPS coordinates...

How come opening the .DAT itself in CsvView only show one position (the last coordinate) the whole flight & with one decimal?


But if taking the .DAT through DatCon, CsvView shows out from the .csv the changing position through out the flight... with 3 decimals?


And if looking into the DatCon created .csv this is found... 7 decimals?


And how did you generate that flight path... CsvView doesn't generate any & the Datcon generated .kml is empty?

 

[BudWalker]

Yeah... suspected something like this.


How come opening the .DAT itself in CsvView only show one position (the last coordinate) the whole flight & with one decimal?
View attachment 169578

But if taking the .DAT through DatCon, CsvView shows out from the .csv the changing position through out the flight... with 3 decimals?
View attachment 169579

And if looking into the DatCon created .csv this is found... 7 decimals?
View attachment 169580

And how did you generate that flight path... CsvView doesn't generate any & the Datcon generated .kml is empty?

CsvView tries to decides how many digits past the decimal point to show. In this case it got fooled by the zero values occurring in the first part of the .DAT. If you run DatCon with the time interval shown here

and then submit the .csv to CsvView those zero values won't be there. CsvView does a better job with more digits but less than the 7 digits produced by DatCon.

To plot the GPS data select this on the GeoPlayer


and then do a Zoom reset

 

[slup]

CsvView tries to decides how many digits past the decimal point to show. In this case it got fooled by the zero values occurring in the first part of the .DAT. If you run DatCon with the time interval shown here
.....

and then submit the .csv to CsvView those zero values won't be there. CsvView does a better job with more digits but less than the 7 digits produced by DatCon.

Is these initial zero values also the reason for that only one single position is shown the whole flight (Sig GPS Long & Lat), besides also limiting the number of decimals... if opening the .DAT directly in CsvView?

To plot the GPS data select this on the GeoPlayer


...and then do a Zoom reset

Thought that I tried this... at least I saw that the GPS tick box wasn't marked, must have forgotten to reset the zoom then, as it works perfectly now.

 

[BudWalker]

Is these initial zero values also the reason for that only one single position is shown the whole flight (Sig GPS Long & Lat), besides also limiting the number of decimals... if opening the .DAT directly in CsvView?


Thought that I tried this... at least I saw that the GPS tick box wasn't marked, must have forgotten to reset the zoom then, as it works perfectly now.

Yes. Suppose the plotting surface is, say, 200 pixels high and the longitude values are in [0.00000, 12.4625493]. Then small changes won't map to different pixels so it appears there is no change. Zooming in will cause those different values to be mapped to different pixels.

But, zooming in doesn't change the format of the value readout.

So zooming in doesn't increase the number of digits past the decimal point.