Zino "disconnects" the root cause?

[501Pete]

OK, those over on FB may have seen my post rom last night.
Basically I'm trying to establish (as no one else appaers to be doing anything ), whatthe root cause of disconnects is, how many different causes there are, and wheter we can or cannot do anything abouit them.
The two obvious ones are:
1. Faulty lead between phone and controller (or bad connections/ports etc)
This also includes incorrect signal handling by the OS in use (eg Ipads and some Android devices)
2. The AP cycling due to a failed boot when a "rogue" SD card is left in the device at boot time.

The unanswered one is Wifi interference and band congestion.
So here's the question I asked on FB (to which I've had a few answers so far).

I'd like to take a straw poll here for those of you who suffer from the "disconnect issue".
Firstly, I have never seen any disconnect with my zino, unless I purposely put it into a mode where the Access Point (AP) on the quad continuously cycles between up and down, or I go out of range.
My short sampling of the complaints show this issue is most prevalent in the USA. Would I be right in drawing that conclusion?
One advantage we have in Europe, is that the wifi band used by the Zino, is almost devoid of Wifi signals. That is because it is used primarily for only short range devices (SRD) and not for wireless access. I have yet to see another AP within the band other than the ZIno. Whilst there are other emitters on the band, they mostly are all SRD devices and they are rarely observed. Most phones in europe do not support wifi in Band C.
The opposite is the case for instance in the USA, where Band C (channels 149 - 165) are used for wireless access and supported by mobile devices. From videos I have seen, people also appear to see many APs when they do a band scan when connecting the Zino.
So are these disconnects actually just entirely due to interference with other APs on the band?
Do people monitor the band with a WiFi monitoring tool and check band usage in their area? When the Zino disconnects, have you correlated the disconnection with other wifi signals on the band?
If the issue is purely wifi interference, then the only way to resolve this is fly somewhere else or build a quad that operates in a different band
So what's the consensus. Is this an interference issue, or is it a fault with the Zino?

To put things in perspective. Here's what the 5G Wifi band looks like where I fly. This is exceptional to see 3 signals. However in Europe you'll rarely see anything in Band C where the Zino operates (Ch149 -165) as most devices are not enabled for it.
.

wifi5g.png (140.43 KiB) Viewed 14564 times

.
In comparison this is the busy 2.4Ghz Wifi segment.
.

2.4G wifi.png (170.65 KiB) Viewed 14564 times

.
You can see why Hubsan chose to avoid that.

So lets see your band usage in your area.
Are Ch149-165 clear?
If not, do you get disconnects and have you correlated them with band usage at the time of the disconnect?

[Gorillaman]

That is interesting, but from the several disconnects and fly-aways I have seen/experienced... The areas where the Zino flew was void of WiFi congestion. As I have posted in other forums... The X-Hubsan App operates several of their products of which I have a few. I flew in the exact same location with no other WiFi signals present. I flew the drone 8m off the ground and 20m out... It disconnected, raised up to about 12m (by itself) and flew off never to be seen again. I then bought the exact same drone and flew it in the exact same spot and had zero disconnects or problems. The first one I had disconnects all the time to which Hubsan said there was nothing wrong with it (I sent it back for their inspection). But the second one I bought operated flawlessly. So my thought is... Hubsan products are .. (you guessed it)... "Like a box of chocolates" ! ... Probably QC on the WiFi boards but why flying two exact same drones, in the exact same WiFi Free zones, in perfect weather, produces completely different results... Has me head scratching.

[501Pete]

Thanks for the response.
It does however raise another issue, which came to light also in the FB responses.
Is this really a "disconnect" in terms of loss of the network between quad and controller?
The reason I ask is from your description. Your quad flew off.
That is NOT a condition you should see from a simple disconnect. What you expect to see is a quad coming back home and landing.
That is all I see,again and again and again when I test.
If the quad is doing something other than that, it can only mean one of several things.
1. It is being "controlled" from some other source. (this should never happen in reality, but never say never )
2. The disconnection is a result of some interfering signal (jammer) that also takes out the Quad GPS reception.
3. Something within the quad is resetting creating not only a disconnect, but preventing autonomous FC operation.
4.The Home point location was corrupted and incorrectly saved.
5. The GPS just happened to fail at the same time as the disconnect.
7. The quad is not actually disconnected at all, and is getting spurious commands from the controller or the mobile device.
6. Something else

[3108vibhash]

With my first zino which was sent for inspection , had disconnect issues but each time drone triggered auto return. There was no consistency as at the same site I got disconnection sometimes, sometimes it doesn't. Only thing I noticed with consistency was distance above 100 m. On contacting hubsan they initially said I was flying near houses which could be the reason but I was not totally sure. They send me a replacement drone and this drone disconnects intermittently. During first test flight, I was hovering at 5 m and suddenly nothing on screen. No auto return was triggered so once it connected again I landed it. this happened intermittently at home also, so I thought may be the cable. Tried on Ipad and no disconnection. did not have cable to fly using Ipad. I thought this could be due to lose connection on android due to phone cover preventing it going all the way inside. So tried it without the cover, did ok initially but after 40 meters disconnected. Triggered auto-return and when it connected again I was able to control it but video button function did not work. Tried clicking pictures but came home and on SD card no pics. I do not think the lack of functioning of video button was due to faulty cable as I was able to control the drone and all other buttons like autoland etc worked.
overall I think this could be android issue. the problem is as there is no consistency even with seeing issues , its hard to tell what is causing what.

[Djose24]

If you think it is a bug in the Android app, you could indicate the ones that experience the disconnections, what version of Android you have and the model of your mobile device. It is by discarding even if it's also on iphone

[3108vibhash]

Android 8.0 using samsung note 8. But the thing is there is no consistency and its hard to just keep testing it all the time. Like my last flight went ok maximum distance 54 m, however this was at a different location.

[me_95698clKrv]

OK, those over on FB may have seen my post rom last night.
Basically I'm trying to establish (as no one else appaers to be doing anything ), whatthe root cause of disconnects is, how many different causes there are, and wheter we can or cannot do anything abouit them.
The two obvious ones are:
1. Faulty lead between phone and controller (or bad connections/ports etc)
This also includes incorrect signal handling by the OS in use (eg Ipads and some Android devices)
2. The AP cycling due to a failed boot when a "rogue" SD card is left in the device at boot time.



.
wifi5g.png
.

The zino wifi signal is visible on the analyzer?

[501Pete]

The zino wifi signal is visible on the analyzer?

No. Because this is a screen shot off my phone.
I live in europe where mobile devices do not generally have any access to Band C.
This is the point I'm trying to make
There is generally no traffic in Band C in europe, whereas in other parts of the world and especially USA, it is widely used.

[501Pete]

With my first zino which was sent for inspection , had disconnect issues but each time drone triggered auto return. There was no consistency as at the same site I got disconnection sometimes, sometimes it doesn't. Only thing I noticed with consistency was distance above 100 m. On contacting hubsan they initially said I was flying near houses which could be the reason but I was not totally sure.

That does indeed sound like a "link failure". The RTH working correctly also indicates that is what it is, because that is exactly what happens in that scenario.
I also agree it could be due to interference/congestion, or possibly a faulty antenna or wifi module.

They send me a replacement drone and this drone disconnects intermittently. During first test flight, I was hovering at 5 m and suddenly nothing on screen. No auto return was triggered so once it connected again I landed it. this happened intermittently at home also, so I thought may be the cable. Tried on Ipad and no disconnection. did not have cable to fly using Ipad. I thought this could be due to lose connection on android due to phone cover preventing it going all the way inside. So tried it without the cover, did ok initially but after 40 meters disconnected. Triggered auto-return and when it connected again I was able to control it but video button function did not work. Tried clicking pictures but came home and on SD card no pics. I do not think the lack of functioning of video button was due to faulty cable as I was able to control the drone and all other buttons like autoland etc worked.
overall I think this could be android issue. the problem is as there is no consistency even with seeing issues , its hard to tell what is causing what.

This sounds like a different issue.
removing the cable completely causes the link to go down, and the bird to RTH.
Having a lose and intermittent cable can cause strange issues.
I think I saw a screenshot of your video issues.
You had no video channel connected in that (the control and video use seperate "channels" within the same wifi "connection").
This and the intermittent disconnects could be down an improperly initiated Access Point (AP), which I've shown and demonstrated previously.
I agree entirely with what you are saying.
We will never get to the bottom of this until actual data is collected of what is happening in each individual case.
There is undoubtedly more that one issue, but they are all being lumped together as "disconnection problems".
There is a wealth of information in the flight logs, (there could be more if Hubsan populated all the fields) and it's a good starting point to investigation, yet no one seems to be analysing them.
It will at least show whether the quad went into RTH, Lost GPS, or had an abnormal system status.
The failing here is Hubsan not gathering the right information, analyzing it and providing feedback to each issue, both individually and as an overall group, if it is not an isolated or unique incident.

[me_157abXgZCo]

I think also, that we as users need to provide more information and the circumstances of failures/unintended behavior.
On the other hand, it would also help Hubsan, if they will set up a certain formular, where they are asking in a structured process the circumstances, FW, mobile device/operating system, and so on.

On the topic: I fully agree, that the sudden disconnects have most probaly nothing to to with flyaways, as described above.