Waypoint, signal loss

I fly a Mini 2. From my experience, the drone will behave at signal loss in the attitude it was set too within the app. Any loss of connection between the drone and controller will automatically initiate RTH command. The RTH data is actually stored in the drone memory. Not so with waypoint maps. The mission requires the remote to feed the data. Missions must be set within these parameters. I have also notice when in close proximity to controlled airspace, waypoint missions will be interrupted if the next pin and altitude are not in compliance with FAA Facility Map altitude limits set for the mission area. Hope this helps. Happy Flying!

1 Like

Thanks to everyone for the answers. Now I understand. I thought the Waypoint map was stored in the drone, and it would continue on its way even after the signal was lost.

1 Like

For drones older than the Mini-1 this is the case.
The mission is uploaded to the drone and the drone does all the flying, exept for changes in flying speed and gimbal pitch.

Drones build for the DJI FLY App are controlled by “Virtual Stick Commands” send continuously to the drone.

I have the mini 2 and on the very first waypoint (48ft high, 57 ft away), I had 2 signal losses reported. On lasted 4 sec and the other 7 seconds. The drone did an automatic RTH. I also had this happen another time, but the drone was well over 0.5 mile away (several waypoints away), and signal loss occurred several times, but did not RTH until I pressed it on the RC. If perhaps, I waited longer, it would have automatically occurred, but the way point 1 at 57 ft, initiated the RTH right away.

A good day to you all:

Is it still true that DJI Mini 2 cannot store waypoints/mission onboard that upon signal loss from RC it will only RTH? Any firmware updates out there can improve this? If this is still the case unfortunately I’ll have to return my Mini 2 since that’s a big loss in range & functionality. I have a P3S in excellent condition that allows me to run waypoints up to 10km+ per mission.

Anyone know if DJI Mini 3 Pro will have the same Mini 2 limitations described above?

Thanks in advance for your insights.

All the DJI drones that use DJI fly are like this as they don’t have the onboard memory and use a VSC function, so yes the mini 3 pro will be exactly the same

1 Like

I routinely fly Litchi waypoint missions that range way beyond the reach of my RC controller, but this is only possible with the Phantom 3 and 4 series drones, and with the Mavic Pro1 and Pro Platinum first-generation DJI drones, all of which store the entire waypoint mission parameters of GPS location, altitude, and camera (horizontal) direction, onboard the drone.

This type of beyond visual range and beyond RC signal range drone mission is not permitted in most of the EU and USA, but since I reside in a remote Third World backwater where drone operation guidelines don’t exist, I am free to send the drones anywhere I like within the range of their flight batteries. A typical mission flown by any of my drones is 6 miles round trip, and 22 minutes flight time, during which 4GB of 2.7K resolution video footage is recorded to the SD memory card.

All newer DJI drones than the ones listed above will revert to RTH the instant a waypoint mission exceeds the drone’s radio link to the controller. To fly fully autonomous Litchi missions beyond RC signal range, there is currently no alternative to using an older DJI drone.

Another image taken well beyond RC signal reach out over the course of a river.

This final picture was taken from video footage filmed at 140 feet above a river valley which translates to 50 feet below the launch point. With all pre-programmed waypoint GPS coordinates stored in the onboard memory of my trusty Phantom3 Standard, Litchi faithfully returns my drone to base each time, even after well over 2,300 miles and 131 hours flown thus far.

1 Like

Flying DJI mini SE. This is the worst of excuses to explain bad logic. Signal lost is multi faceted and requires simple analysis in order to manage same. The way DJI is failing to support this issue is not a valid basis to neglect being diligent.

When a litchi waypoint mission is temporary interrupted due to signal lost, control is either manually by operator or by litchi interface, but the mission is abandoned. Under such circumstance, there is a lack within litchi interface not to provide the operator with a very logically option when signal is restored, which would be an option to “resume” the mission.

There is already an option of pausing and continue under full signal scenario. So, with a bit of logic one can easily “resume” mission as if the temporary signal lost is equal to “pause” by either pressing the “play” function, or to make a dedicated “resume” function.

To confirm, pressing “play” after regaining signal on temp signal lost, did not cause continue of mission.

To abandon a mission on temporary signal lost by being forced to either
1 continue manually
2) rth, edit mission and fly amended mission
is not at all efficient.

Permanent or long term signal lost is a different scenario.

A simple function option can only make the app better.

If the Mini SE operates with DJI Fly and NOT DJI Go4, then the drone MUST have uninterrupted connectivity to the controller in your hand throughout a Litchi mission, for all waypoints to be overflown as planned in the Litchi Mission Hub.

For newer drones like yours using DJI Fly, the waypoint GPS coordinates are NOT stored on board the drone’s internal memory, but are instead stored in the controller which then requires continuous connectivity to transmit the waypoint GPS coordinates as the drone flies the mission.

Unless DJI releases an SDK that will enable DJI Fly drones to store Litchi waypoint mission GPS data on board the drone as opposed to in the controller’s memory, Litchi will not be able to offer waypoint mission completion beyond RC signal range. The problem you are describing is therefore created by DJI’s new policy on where GPS coordinates are stored, rather than due to any fault on the part of Litchi.

NOTHING is stored in the controller.

Have a look at this topic:

Would it then be correct to say that for DJI Fly drones, Litchi waypoint GPS coordinates are stored in the smart device’s memory, but then retrieved and transmitted to the drone by the controller?

1 Like

I’m sorry, but you miss the whole point.

Temporary signal lost is experienced by Litchi as abandon mission, or do nothing.

The point is, on regaining signal after temporary loss, there ought to be a “resume” function from Litchi to start controlling the drone again, but to ensure to continue the mission from last known point.

Forget about what DJI is failing to do or how they make life difficult for you, we get that, but it is a totally different point.

Try and concentrate on the concept of “temporary signal lost” and “resume” as analogous to “pause” and “play” already active with Litchi.

Hope the penny drops.

All the best.

Ah, I see. As the owner of older DGJ Go and DJI Go4 drones, I am clearly out of my depth on this consideration, so I’ll stop my flailing typing fingers and allow the pros to weigh in with more relevant perspectives.

Come to think of it, litchi can outwit dji. It is enough to programmatically replace wp with the “home” point, and each time change it on the map when there is a signal with the remote control, then it will not matter if the signal is lost or not, the drone will think that it is flying home every time. And it will fly straight without jerks.
I have suggested this idea before.

Yes, there will be problems with the camera, perhaps, but at least the drones will not wind around the map

You are flying a mission whose configuration causes a loss of signal. This would cause the drone to go into RTH mode (assuming DJI Fly drone). However, after regaining the signal, you would choose to attempt to try again from the point at which the signal was lost? This sounds like a recipe for disaster. Unless something has changed, the drone would loose the signal again and go into RTH mode.


Ok, so too many assumptions.

Temporary signal loss is just that, a temporary interference that goes away “soon” after, restoring proper signal, even on RTH and re-starting same mission. It would be ridiculous to suggest re-attempting any similar action on permanent signal loss - thus the reason to state repeatedly “temporary signal loss”. So, the suggestion is not to bang your head against flying in a zone where no signal could be regained.

There are a few possible scenarios, of which one is that the drone is just hovering at the last point of control (point where temp signal loss occurred), and possibly one where the drone is set to RTH. The two are mutually exclusive - also, the Litchi would be informed of what the drone is doing at the moment of regaining signal.

The most logically thing for Litchi to do is to establish whether control can be regained - no disaster there. If time to signal loss occurred long enough ago, and the drone RTH’ed, then it is logical that gaining control is similar to any other interruption to RTH - if the drone allows same - no disaster there.

Should the drone be in RTH at time of regaining control by Litchi - provide the option to the operator to decide whether aborting RTH and returning to last known point and resume. Also, if the drone is still hovering above the last known point, leave it to the operator to decide on RTH or resume.

Why do you want to pre-determine that it can only be a disaster on temp signal loss? All of these issues are multi faceted situational issues. Provide the operator with more logical choices, which is for the operator to assess given the reality, rather than an apriori pre-emptive blind restrictions excluding the obvious.

Again, the proposal is totally realistic - and again, analogous with “pause” “play” during a mission.

I can see where a RTH would be very irritating and costly if mission time was limited and you didn’t have time to retry the flight. Possibly something like a “Wait” button next to the RTH and Hover buttons in Setup that would give the drone a limited time to begin receiving signals again before an automatic RTH started. Any future intermittent signals could also trigger a RTH if desired. @Kaehn, is something like this possible? Thanks!