4G/LTE Flyaway Case


There seems to be a flyaway case in the execution of the FlytOS.

Under my current setup, I am using a Pixhawk that has two telemetry links; on TELEM1 I have 3DR radio connected for gcs comms for backup and on TELEM2 I have RPI3 (with FlytOS) connected to the Pixhawk. The frame I am using is an OCTO

Flyaway Case:

  1. Start OCTO in Stabilize mode
  2. Climb and settle at an altitude
  3. Switch mode to Guided mode
  4. Start Mission from the website flytbase.com . (NOT the link) During the entire flight, the GCS is never connected to the WIFI-AP on the raspberry pi on the link.
  5. Now with the mission started, the telemetry link on TELEM1 is lost.
  6. Following the TELEM1 link loss, the TELEM2 loses connection with 4G network.

The Issue:
When TELEM1 link was lost the OCTO should have gone into RTL mode due to loss of reception of heartbeat signal from GCS. However, since there is a secondary telemetry link from the PI, this never occurs, which is the expected behavior. However, when the 4G/LTE connection is lost, as mentioned in step 6, the OCTO still continues to do it’s mission and doesn’t switch over to RTL mode. This can result in a possibly FLY AWAY situation as there is no failsafe for this.

I think the problem may be with how the heartbeat signal is dealt with in the FlytOS, where the RPI3 keeps on generating the heartbeat signal internally to get telemetry, even after the 4G/LTE network connection to flytbase.com server has been lost.This possibly prevents the OCTO from ever going into RTL as the heartbeat signal is still available locally from the RPI3, since the script dealing with sending the telemetry information to website doesn’t feedback the “comms loss” status back to the OCTO itself.

Software version : 1.56 PE

Please let me know if there is some setting that i am missing or if the aforementioned issue is actually a bug


Thanks for letting us know your issue in detail.

Can you please also let us know your expected behaviour of the drone when 4G connectivity drops?
Do you have RC connected to the drone? If yes, it would not FLY AWAY if you have configured RC failsafe. Correct me if I am wrong.

Let me also give a situation where triggering Failsafe may not be a right idea.
FlytOS has lost its 3G connectivity. But there is an onboard Precision Landing/ Obstacle Avoidance algorithm, which is still running and controlling the drone. In this situation, should Failsafe be triggered? As triggering failsafe, would stop Precision Landing from occurring.

But we can definitely have a separate configuration parameter, which users can set to trigger failsafe if 3G connectivity is lost for more than ‘x’ seconds.

Feel free to post your suggestions.


Thanks for getting back to my issue on such short notice, the expected behavior in my case would be to RTL since we don’t have a precision landing algorithm of any sort on board. As for the RC connection, yes we do have an RC connection during takeoff and mode change, but for behavior testing, I turn off RC controller after a few minutes into its mission, where the drone is currently in GUIDED mode, to simulate a telemetry and RC signal loss to understand how the companion computer behaves.

in addition, I just conneted to the WIFI-AP and was looking and the settings under the flytconsole and see that you have an failsafe called “dataloss link failsafe trigger” I think this may do what I am looking for and just want to clarify the functionality. I have broken them down into the following cases


I am expecting the drone to go in RTL mode when it can’t make a connection with the flytbase.com website.


This failsafe gets triggered when connectivity between FlytOS and autopilot gets hampered due to any hardware/software fault. This has nothing to do with connectivity between FlytOS and cloud.

As I mentioned before, If you think the above feature would solve your problem, I will add this to our backlog.


Ok, please go ahead and add 4G/LTE link loss to cloud as a feature request.



Ok. I have added this into backlog.