Fly Away, lost RC uplink. Don't know why

Status
Not open for further replies.
The remote records what to the app?
It's no secret that you can see the joystick input in the recorded flight data.
I look at that every incident I investigate.
Is that what you mean?
no the app data you see translated into the GUI of the ios and android apps only show joy stick movements, some commands,
im talking about the data stored in the app itself, you retrieve these files via iTunes. By the say the data inside the dji app also shows all the custom settings you have of the remote.

Now imagine someone figured out how to disrupt the flight data and then fly the drone back to themselves to claim it was lost, the only way dji can determine this is by looking at the remote data in the app (that we dont see) and then they determine if the remote indeed continued to control the air craft, other drone companies see this telemetry through the remote, dji has both the remote and ios and android interface recording it, its great if you ask me but its simply greed if they dont tell you and instead play dumb.

I can't understand this.
RTH is extremely reliable although many users have a poor understanding of how it works.
Incompatible or corrupted commands don't cause RTH to fail.
RTH either works or gets cancelled which would leave the drone hovering waiting for your control.
DJI confirmed it was a malfunction with the RTH refused to admit it but only stated they did not know why, instead they offered to sell the care fresh which i was just approved of because 48 hours past then 30% of on a purchase which i REFUSED!

[/QUOTE] You've mentioned RTH failure several times but your flight record has no indication that any RTH signal was received. RTH was not involved at all in the loss of your drone.[/QUOTE] It was DJI that determined this because all their drones RTH by default and so they could not explain why this happened..

By the say the data inside the dji app also shows all the custom settings you have of the remote.

That's probably because there's nothing about the remotes that is relevant. btw .. there's no such thing as a flyaway.
There are drones that get lost for various reasons (that are usually made clear in the flight data), but they don't just fly away.
sure there are, instead of this drone RTH it went somewhere else, up down somewhere but RTH., it flew away instead of hover, i lost site of it as it normally would of returned over me but did not at all.

Does the remote give a different alert when it loses signal from when the drone loses power?
I would expect it to be the same because losing power causes a loss of signal.
you can loose video signal at any time for reasons such as interference with
wifi (which did not happen)
cell tower (none near by)
antennas (nothing was on in the park as its closed)
distance (not in this case.)

But when the RTH home function does not work and dji does not know why yet clearly confirmed it was the case its concerning me because it is their responsibility to know and my understanding is that the drone was lost due to this over a un recoverable area like a body of water which they are insured to replace..its not like someone can fool them, you seen the flight data yourself and clearly know its impossible to fake this.

So, if not one confirmed the alert from the remote when pulling a battery out of a spark while hovering i dont know how this conversation will not continue, because the alert i got was identical to one describe by another person who also lost an aircraft over water.

But all those who doubt never tried it.
 
Last edited:
Might I ask a question regarding the OP's dilemma? It seems the control signal was weak due to the aircraft being directly overhead and eventually lost completely after RTH was canceled. As the aircraft drifted away, would the better orientation of the aircraft to the RC not result in regaining a better control signal thus resulting in the opportunity to regain control of the aircraft and possibly re-initiating RTH?
Just curious in case I find myself in the same situation some day.
was never over heard, it was 80+ meters away as well as plus 100m high.

The issue is that the RTH never initiated after loss of video signal., which is what DJI determined and cant explain
 
no the app data you see translated into the GUI of the ios and android apps only show joy stick movements, some commands,
im talking about the data stored in the app itself, you retrieve these files via iTunes. By the say the data inside the dji app also shows all the custom settings you have of the remote.

I think you have misunderstood most of the replies to your comments. Just about everyone posting here is perfectly familiar with the various logs, and no one is talking about the simple DJI flight replay function. The discussion has been about the app .txt log files and .DAT log files, which contain all the data logged by the app.

And the basic point has been that your log data from the app .txt file simply shows that logging terminated at 388.3 s into the flight. There are no further data to indicate what happened but, based on previous similar events, it is likely to have been caused either by sudden failure of the aircraft power system or FC, or by a battery disconnected. Without examining the even more detailed logs on the aircraft there is no way to determine exactly what happened.

Now imagine someone figured out how to disrupt the flight data and then fly the drone back to themselves to claim it was lost, the only way dji can determine this is by looking at the last remote data in the app (that we dont see) to determine if the remote indeed continued to control a air craft, this is why other drone companies see the telemetry if the records stored for the use are disrupted.

No - we do see all the logged data in the app files.

sure there are, instead of this drone RTH it went somewhere else, up down somewhere but RTH., it flew away instead of hover, i lost site of it as it normally would of returned over me but did not at all.

Did you actually observe it flying away, or did it simply not return as expected? There is no indication that this was the result of lost uplink or downlink - that would have been a quite separate failure from failing to RTH.

But when the RTH home function does not work and dji does not know why yet clearly confirmed it was the case its concerning me because it is their responsibility to know and my understanding is that the drone was lost due to this over a un recoverable area like a body of water which they are insured to replace..its not like someone can fool them, you seen the flight data yourself and clearly know its impossible to fake this.

I have no idea why you keep repeating that DJI is "insured" to replace aircraft in this situation, or that they have a responsibility to know what happened if you lose the aircraft. They can only see the data that are logged. And why do you think the data cannot be faked? These log files have been reverse engineered to read, so there is no reason to assume that they cannot be changed.

The issue is that the RTH never initiated after loss of video signal., which is what DJI determined and cant explain

You still don't understand how this works. RTH is not triggered by loss of video (downlink), it is triggered by loss of control (uplink) for more than 3 seconds. The log shows no uplink or downlink degradation prior to the abrupt end of the log. And if the aircraft simply failed in mid-air then obviously it was never going to have a chance to initiate RTH.
 
  • Like
Reactions: Meta4
The issue is that the RTH never initiated after loss of video signal.
Might want to re-phrase that, if you are so confident that the remote was the issue. RTH does not initiate after loss of video signal. Only from loss of Uplink.
 
@sar104 You don't suppose the Spark also records a .dat file on the device as the P4's do you? I do not know. But if so, that would tell you.
 
Loss of uplink signal, primarily. I do believe it has that data.
 
@sar104 You don't suppose the Spark also records a .dat file on the device as the P4's do you? I do not know. But if so, that would tell you.
The Go App does create a .DAT for the Spark but doesn't contain the info you're after. Like all the other platforms it doesn't contain the RC status info normally found in the AC .DAT file. The RC status contains the app_lost and (RC)connected data. It also contains the frame_lost data which is used to derive the uplink signal strength.
 
The Go App does create a .DAT for the Spark but doesn't contain the info you're after.
Well, so much for that thought. Thanks for the info. Was worth a shot anyway.
 
Might want to re-phrase that, if you are so confident that the remote was the issue. RTH does not initiate after loss of video signal. Only from loss of Uplink.
It initiates RTH after a period of both signal with remote and video with the spark according to DJI, at least its what i read.

I lost site of the Spark, the sun was rising behind it and i could not see where it went., nothing fell into a lake and from what i see here no one has actually confirmed alerts from the remotes if it is a power issue and how that would of not been registered in the log, why?
 
You still don't understand how this works. RTH is not triggered by loss of video (downlink), it is triggered by loss of control (uplink) for more than 3 seconds. The log shows no uplink or downlink degradation prior to the abrupt end of the log. And if the aircraft simply failed in mid-air then obviously it was never going to have a chance to initiate RTH.
again...your talking about a DJI Spark right?
 
It initiates RTH after a period of both signal with remote and video with the spark according to DJI, at least its what i read.
If this is indeed factual, which I can not confirm myself, then the Spark operates much differently than the Phantoms ( Transmission wise). Downlink has nothing to do with control of the aircraft from the RC. You can lose downlink and remain in complete control of the aircraft.
 
The Go App does create a .DAT for the Spark but doesn't contain the info you're after. Like all the other platforms it doesn't contain the RC status info normally found in the AC .DAT file. The RC status contains the app_lost and (RC)connected data. It also contains the frame_lost data which is used to derive the uplink signal strength.
I told you all already that a senior rep at DJI is going to replace my drone because its clear that the RTH function did not work or as we all concluded to be a POWER FAILURE (malfunction) non of which a end user is responsible for or could recover the aircraft due to it disappearing over a body of water., if i recovered the drone i could of used both my insurance and dji fresh as i was already proved....but sadly it takes longer to be sure this does not show up..

I would love to find out if it landed somewhere besides water and someone found it in the amusement park area behind the lake but we shut everything down a few days prior to this flight for the off season...amazing timing..and ir does rain freaken hard this time of the season.
 
If this is indeed factual, which I can not confirm myself, then the Spark operates much differently than the Phantoms ( Transmission wise). Downlink has nothing to do with control of the aircraft from the RC. You can lose downlink and remain in complete control of the aircraft.
Spark uses wifi and ATI when GPS is not available, it was always rock solid until i updated the firmware., just after this took place i read that some people who use a OTG cable had issues with inconsistent video signal and constant RTH.

I have a thread over at the Sparkforums, i dont think the spark remote is anything like the P4s, believe me i can fly a P4pro with confidence nothing stupid will happen like this as i fly safe and plan everything before hand..i have to with its size and all.
 
Explain please?
just saying P4Pro uses Lightbridge which is not the same technology, anyhow the people i spoke to at hobby shops where french naval aviation technicians and know all about radio signals, the one thing that is certain is nothing on the ground where i am interfered with the flight of a DJI spark.

There has to be a better explanation from DJI then "we dont know why the RTH function did not work" then IGNORE explaining the alerts from the Remote and what they mean..


So will you explain them?
 
So will you explain them?
First, I know the difference between Wi-Fi and Lightbridge but your statement " when GPS is not available" makes no sense. GPS and W-Fi are 2 different entities and have no relation to each other. As for explaining the alerts. What alerts? There is no way to know what these were. Nothing in the log files say anything about any alerts. Lastly, there is no need to try and explain to others that of which you have no data for anyone to help you with. That is to say to prove or dis-prove any findings by yourself or by DJI. In other words, we can't help you without enough data to support right or wrong.
 
First, I know the difference between Wi-Fi and Lightbridge but your statement " when GPS is not available" makes no sense. GPS and W-Fi are 2 different entities and have no relation to each other.
i know GPS and wifi and radio ghz and lightbridge etc are all different but your assertion to incline they have no relation to conflicts i mentioned here caused between them and the subject im talking about which is the actual remote, when firmware updates, issues between each due to poor grounding, glitches between the software and remote functions (pause, RTH, Sports mode) as well as anything effecting them by the environment which is what DJI stated to of suspected in one email.

As for explaining the alerts. What alerts? There is no way to know what these were. Nothing in the log files say anything about any alerts..
If you believe the drone lost power then whip out the battery of one while its hovering and listen to your Spark remote., of course you can verify them, two beeps pause RTH, one beep pause?? long beep pause...not sure if you owned hobby drones in the past but they all have alerts indicating incidents such as sync errors, firmware updates etc etc etc , curious why no one here would test to confirm and instead ignore all of this if we are talking about the remote.

I am not trying to offend or anything like that, i appreciate your time and actually find this site very helpful although i know DJI has a whle army of people working on line trying to calm people with issues down while ........doing nothing but charging them for after sales services etc.
but anycase i am confident you have more experience and trust what your talking about but i keep trying to tell you that we are talking about something only DJI can confirm, the only answers i got from them is they do not know why the RTH function did not work ( i call this a malfunction) and or if the cause of this was the environment which they later agreed was not the case and considered looking at the remote.

And by no means have i ever flown anything outside what DJI recommends, when there is no explanation its like you need to carry out a forensic internal investigation here., all i can say is i have had more issues with this DJI Spark then i ever had with the P1, P4Pro and mavic Pro and while i only testing several mavic pros all the issues i had with them where gimbal related..even when the apps crashed the babe hovered or continued on path depending on my settings., this little weezle spark was scary, i had one with out the remote and freaked out when i tried a few gestures as it was backing upwards towards the trees, i immediately grabbed the iphone and got that sucker back in the box where it belonged., the remote was solid all the time until this firmware update and i read around comments from people and iam NOT alone...
 
but your assertion to incline they have no relation to conflicts i mentioned here
This, I never said. I merely stated that GPS and W-Fi are completely un-related entities. Not once did I say otherwise. Now, with everything being said, if you are honestly wanting to look at ALL the data that you have access to. Upload the .dat file from your device to a sharable location and share that link here. Not the .txt file. The .dat file. Obviously you can't retrieve the one from the Spark itself, but there is that one last piece of evidence that you have not uploaded. It may show nothing, or something completely different, but from hence I am off the discussion until that data is shared for all to view.
 
Upload the .dat file from your device to a sharable location and share that link here.
ok , here are two which seem to be back to back
 

Attachments

  • 2018-01-12 11_23_37-0BMUE8D001035V.dat
    107 bytes · Views: 224
  • 2018-01-12 11_11_30-0BMUE8D001035V.dat
    339 bytes · Views: 218
Status
Not open for further replies.

Recent Posts

Members online

Forum statistics

Threads
143,095
Messages
1,467,610
Members
104,981
Latest member
Scav8tor