SkyController 3 connection


I am trying to test my own application using the Sphinx simulator. I can connect to the wifi with the iPad, however, it does not work when trying to connect the SkyController 3.

I’ve checked everything as explained in the wifi requirements page, set wifi_channel to 6 to force the 2.4Ghz frequency, but the SkyController 3 never connects. Would you have any recommendation on how to fix it?


Note: I cannot test by connecting the iPad directly to the wifi since my application requires an internet connection


Have you tried to pair the SkyController 3 with your simulated drone ?
To do that, you need to

  • install FreeFlight 6 on a smartphone/tablet device
  • connect your device to the SkyController 3
  • in FF6: select the SkyController 3 icon > connect > select the simulated drone SSID ( “Anafi_PC_xxxxxx”)

The next time your SkyController 3 sees this SSID it will autoconnect to it (if no other device is currently connected to the drone).

When the SkyController 3 is connected to an SSID, its LED should stop blinking and stay on. You should then be able to connect the SkyController 3 to your iPad and test your application.

1 Like

Thanks for the quick reply.
I’ve tried this method, however the drone does not show up on the list of drones.
I’ve tested the same method with a physical drone, and it did not show up either.

Correction: after multiple attempts, the physical drone did show up, but the simulated drone never shows up in FF6

So this is really a Sphinx related issue after all! (I have just switch back this topic in the Sphinx category).

Have you tried to connect to the simulated drone with FreeFlight 6 directly (without a SkyController3 between your device and the simulated drone) ?
I don’t think it is a SkyController3/Sphinx specific issue so this shouldn’t work either.

What is the Sphinx command line used to start the simulator?
If you have a custom “*.drone” file, could you share it here?
When you start Sphinx, please add the “–log-level=dbg” parameter to your command line and the post the console output here.
When Sphinx is not currently running, what is the output of the ip link command?

If you have a Wifi connectivity issue only with Sphinx there is multiple possible explanations :

  1. Sphinx wifi configuration error
  • wrong interface name in the .drone file “stolen_interface” parameter
  • wrong wifi_channel parameter (set the wifi_channel to 6 to force the 2.4GHz bandwidth)
  1. Sphinx wifi system requirements are not met:
    Please note that the Wifi requirements are relatively hard to met in practice because there is just a few hostapd-compatible wifi chipset references available on the market.
  1. The simulated firmware does not run properly/crawl/crash (this shouldn’t happen if you have met all the recommended system requirements).


I was actually able to connect to the simulated drone with FF6 (without the controller).
The simulated drone does not show up on the list of drones after tapping “Connect” to connect via the controller.

The command line used to start the simulator is:
$ sphinx /opt/parrot-sphinx/usr/share/sphinx/drones/anafi4k.drone

And I modified the .drone file to force the wifi_channel selection:

<?xml version="1.0" encoding="UTF-8"?>

The first eth0 seems to be wrong. It should be your host wifi interface name.
The second eth0 is the name taken by this wifi interface inside the simulated drone net namespace. It should always be eth0 for historical reasons.

When sphinx starts the host wifi interface is no longer visible in the host net namespace (it no longer show up in ip link output).

When sphinx exits the interface should go back to the host net namespace and appear with the same name as before.

Sometimes the interface does not show up in ip link after sphinx has exited, other times it does show up but with a different name.

In the first case, sphinx may have failed to clean up the simulated drone net namespace (the drone firmware is partially running in a zombie state). In this case, performing a fdc drop_all instances command should force the zombie firmware to die and then give you back your host wifi interface.
See: Troubleshooting - 2.15.1

In the second case, the wifi interface does show up but with a different name. Your host installed udev rules have failed to kick-in for some reasons and you end up with an “eth0” wifi interface name on your host.
A workaround is to setup additional udev rules to fix your host wifi interface name once and for all.
See: Troubleshooting - 2.15.1

In any case, you should have something like:




in your .drone file.

1 Like

That was it, cleaned it all and another host wifi interface name showed up, changed the .drone file and was able to connect.

Thanks for your help!

1 Like