So my Solo lost communications with the controller when it was close by on the return path of executing an automated Selfi.
The strange thing was that communications was perfect at the start, and through 90% of the Selfi as it flew up and away to its distant point.
Then on its return trip, when it was only about 30-40 feet up and away from me, it said 'Lost Controller' and started a failsafe and a RTH. Luckily I was able to control it, pressed Pause and flew it back down myself to a safe landing.
I was flying over water from a dock, so there was nothing between me and the Solo. Because I was flying from a dock over water, I couldn't chance an auto landing, so I took over and flew it to land on the dock.
Looking at the logs I see several things glitching at or near the 18:48:33 point.
As an example:
time_boot_ms named_value_int_t variance at 18:48:33 to 18:48:37
This is really strange to me! Shouldn't 'time_boot_ms' be a linearly increasing value? Why would there be a significant change in the slope of time since boot? After 18:48:37 the slope continues on the original slope.
Also onboard_control_sensors_health sys_status_t had significant change in value at 18:48:36 and was back at its original value by 18:48:37.
What sensor messed up? Could this be the Controller's RC signal?
There were other items that also had a variance at this same time point, but I'm not sure which one may be a root cause and which could be caused by it entering fail_safe and deciding to RTH.
At the time of the flight when it reported loss of controller signal I heard a strange large drop in the prop speed, almost like the motors were about to cut out. But things got busy as I flew it to land.
I also noticed a large glitch in its flight as I pressed the start Selfi. Reviewing the recorded video, I can see the Solo make an abrupt yaw change as I started the Selfi. I wonder if there is also a glitch here in the logs too (but I haven't found it yet).
Attached are my logs, can anyone with anyone with better log reading skills than I have figure out what happened and why? Where there two glitches or only one?
Because I was flying over water from a bay on a lake, I wouldn't consider this area one filled with WiFi signals, although there were some homes nearby. If there were lots of WiFi interference, why didn't it happen as the Solo was further away from me, rather than when it was relatively close to me? Was there any evidence of a weak 'RC' controller signal at or near this same 18:48:33 time point? I don't see it myself, but maybe I'm looking at the wrong data points?
Thanks for any help! I'd like to fully understand what caused the short loss of signal.
Replies
I have been researching this and trying to understand why I lost control when the Solo was so close to me.
Here is what I have learned, I could be wrong, but this is what I have come to understand as the reason for the issue.
First (and most important) it seems that the Controller uses the WiFi protocol for all communications with the Solo. This changes all of my assumptions about the robustness of the communications link to the Solo. All of my previous experience 2.4 GHz RF control with flying things has been with the various types of spread spectrum protocols being used for RC flying which has proven to be very robust. In flying RC since the inception of using the 2.4 GHz band, I had never lost control of an RC Flying aircraft, even when flying in a crowded WiFi environment until now with the Solo.
Second (fairly important), even though the Solo manual says to avoid WiFi congested areas, there are no guidelines as to what is considered too congested, and part of the factor in this is that with the current firmware (1.05) the Solo and controller will only use either WiFi channel 6 or channel 11. So this complicated things a bit. First, local strong signals on CH 6 and 11 can directly reduce the bandwidth available to the Solo, or it could cause direct on channel interference.
Here's an interesting article that explains why someone may only want to consider using channels 1, 6 or 11 for use with a WiFi access point. I think that the discussion in this article is very applicable to the Solo:
http://www.extremetech.com/computing/179344-how-to-boost-your-wifi-...
I'm not sure why 3DR didn't include channel 1 in their list of WiFi channels that the Solo would consider. Including the ability to use Channel 1 (in addition to 6 and 11) could have increased the chance of finding a clear channel from 2 to 1 to 3 to 1.
Off channel interference can also occur, because the channels on the WiFi 2.4 GHz band overlap. See this for a good graphic of the WiFi channels:
So an off channel WiFi signal could be seen as a noise source or indirect interference.
Previously I knew none of this (or I should say that I wasn't aware that the Solo was a pure WiFi device). It sure would have helped to properly set my expectations if 3DR had a FAQ or documentation page to help to understand these issues, perhaps they don't because it would scare non-technical oriented users?
Now that I know these things, I tend to use a WiFi Analyzer before I attempt a flight to check the WiFi landscape before I fly.
Using the WiFi scanner, once I was very surprised to find a very strong WiFi hot spot right on one of the Solo channels when I was flying well away from any homes or businesses. It turned out that the automobile that we arrived in had its own WiFi hot spot that the owner wasn't even aware of! We were unsuccessful in finding a method to disable it, and luckily it turned off a few minutes after shutting off the car. Keep this in mind if someone drives up to you or near you when you are flying! It could be a source of on channel interference that shows up when you least expect it! I never would have known this if I hadn't checked the WiFi signals before flying.
I think a lot of people will be surprised by the non-robustness of the WiFi control link to the Solo. Many will say that other brands don't have this issue. The reason for this is that the other brands may be using spread spectrum control link, but WiFi for video and other purposes. I know that I was surprised to learn about this with the Solo, and had a direct experience because of it. I have to say that I never would have expected to lose control link to the Solo when it was so close to me, in the clear, with controller antenna's properly positioned, etc.
I made a suggestion to 3DR to include a WiFi scanner type of app in the Controller. It would make sense to allow users to check the WiFi landscape before they fly. I could understand why they may not want to do this, as a non-technical user may have a difficult time interpreting the results. One also has to understand that while the Solo is flying, it will directly experience a greatly varying number of WiFi signals that the controller may not be able to see from its vantage point on the ground.
Here in the USA, we're not supposed to fly higher than 400 ft and also we need to stay in Line Of Sight of our aircraft at all times. You would expect the Solo to have a fairly bullet proof communications link within these flight parameters, but as I have experienced, this may not always be the case, depending on the WiFi environment. Since most people live in an area with at least some WiFi devices, and now that many cars are coming with WiFi signals, how can we expect to be able to find an area to fly without potential WiFi interference?
I have to admit, I wish there was a way that 3DR could change the control link protocol to the Solo to some sort of robust spread spectrum like protocol similar to all of my other RC flying things use. We can't just say 'this is what RTH is for, if we lose communications then the Solo will just return to where it took off from'. In my case, I took off from a small space (a dock) over some water and I couldn't depend on the Solo landing in a safe area if a RTH was triggered (it could have easily landed in the water if it drifted within its landing accuracy specifications).
So although no one has been able to show me the reason for the failure communications failure in the logs, my only conclusion is that the weaker WiFi protocol communications link to the Solo was the issue. Don't get me wrong, I'm still a big fan of the Solo, but now that I understand what's going on, I'll need to be much more careful where I may consider flying.
If I have any of this wrong, please feel free to correct me, I'm always willing to learn.
Not really, it's just how the antenna gain radiation pattern is. see http://www.cisco.com/c/en/us/products/collateral/wireless/aironet-a... I'm not sure what gain antenna they are using in the sloo, I guess it's vertically polarized (in the risers for the holding the tablet/phone)
scattered & reflected signals are so weak they would be almost eliminated from receiver due the power ratio of the main line sight signal
I understand the basics of antennas (built many massive arrays for my HAM stuff), but wouldn't they build a system into Solo that covered the intended use? That is, you can't make it so focused in just one direction that it loses signal 100 or 150 feet away if not perfectly orientated.
Even my $40 toy quads go a couple hundred feet in just about any direction without losing R/C.
I can understand the loss of FPV and even some telemetry reporting (if on a different channel), but not the total loss of actual R/C control.
I guess no one can help me understand why I lost control so close to the Solo by looking at these logs.
I have started to do a WiFi survey of the area I'm flying in using an Android app 'WiFi Analyzer by farproc' before flying. But I'd like to understand how to decide if an area is OK to fly or not. What are the criteria of an area that is good to fly?
Perphaps the Solo controller could do the same thing and provide a warning to the user if potential interference is noticed (i.e.: Many strong WiFi signals in the area)? Yes I know that the Solo in the air will receive different signals than the controller, but we need to start somewhere!
What concerns me is that I've flown other 2.4 GHz RC equipment in the same area where Solo has had trouble. If Solo is more susceptible to WiFi interference than 'normal' RC 2.4 GHz equipment, then we need some guidelines on how to understand where it is safe to fly.
Just saying to be 'in an open area away from other potential WiFi interference is not an easy task! I was in a car the other day that had its own WiFI hot spot. Even the owner of the car was not aware of this, nor on how to disable it.
Solo won't gain a good reputation if its so overly sensitive to control loss due to growing WiFi usage. So far, I have no data to prove this is the case, but I haven't been able to understand why a loss of control occurred so close to my controller.
Seems to me a lot of this is weakness in the design and implementation. I use the word "seems" because I am not an engineer but have been a HAM and into various tech for 40+ years.
The entire premise of Solo and smart shots is built on having world class GPS and R/C control. From the many reports it is not currently up to this standard.
Many of the explanations don't hold water because the tech exists for it to do better. It would be easier for folks to say "it shouldn't be doing that" as opposed to trying to explain why it does.
IMHO, of course. Loss of R/C signal and corresponding RTH should be a rare occurrence when the thing is in your sight.
Craig,
I mostly agree.. but I want to give someone the chance to tell me I'm wrong.
Not to say that our experience helps (or hurts), but:
I'm also an Extra class ham and have had my License and been active for 40 years (not that means much to them, but it means I know at least a bit about RF).
I've held a principal software engineering position for many years so I understand hardware and software and what it means to release a product based on technology.
I've worked with navigation systems in the past (I was an engineer on LORAN transmitters), and have some experience with GPS back in the day and now via many consumer level products (as well as being a PixHawk user), so this isn't my first flying quad.
I'm currently a Staff Field Applications Engineer, so it means I deal with computer issues and customers daily, many of which spend hundreds of thousands of dollars with me, so I understand what it means to support customers and what to expect with technology.
I've been flying RC aircraft for 40 years and own many 2.4 GHz RC systems, so know what to expect with RC control of flying aircraft.
So far I'm lost to know what is going on here. With the aircraft about 40 feet from me, there should have been no loss of signal. I'm offering the logs to see if someone can explain it.
Or, I'd be happy if someone can tell me how to understand what type of WiFi environment is safe or not-safe to fly in.
I'm aware of the type of antennas on the controller, their expected RF radiation pattern and am always careful to orient them properly.
The 3DR website says: "Physical obstructions can also block communication signals with the controller, causing Solo to attempt to Return Home along an obstructed path." I certainly had NO physical obstruction nearby or between me and the Solo.
I otherwise see nothing in the manual or the online docs that say not to fly in an area with WiFi, but I've seen some posts from others that say that 3DR tech support says that WiFi can cause interference.
Sorry to say but I think you know more than "them".
I've seen a number of engineers similar to you chase explanations from 3DR customer service and not end up too happy.
They are not going to tell you "well, the guys who designed this did this..." or "the factory didn't make this piece up to spec" or something like that. With billions at stake that type of answer is not likely.
They have already told many people that a tree ruined their GPS.
Here is a semi-answer from an EE and Jet Pilot:
http://www.3drpilots.com/threads/controller-signal-strength.448/pag...
I'm no engineer but I play one a lot of the time. It's like with music (I play, but not too well)....but I can 100% tell is music is good or not. Same goes with engineering. I can't do it (other than building Quad antennas, doing prototype metal or wood work, etc.) , but I can judge the results very well.
NO, I don't agree with this: Sorry to say but I think you know more than "them".
Isnt 18 minutes getting to the end of the charge in your batteries?
No, this was 18:48:33, time of day... 6:48 PM here. :)
Batteries were fully charged before the particular flight started.