BJR981S
Well-Known Member
One of the judgement errors I've made is that I've scanned both 2.4 GHz and 5 GHz bands with my mobile phone (I have a phone dedicated to data hotspot, Wi-Fi scans and other tasks) assuming the 5 GHz band would be the same as the Wi-Fi standard because I've heard it said several times in the videos so I just assumed... and I assumed it wrong.
I have no idea what there was on the 5.8 GHz spectrum. This I admit is a novice error.
If say the 5.8 GHz was full, considering the 2.4 GHz might have been completely saturated when sampling all the lengths and heights this still doesn't explain why I haven't got notices of interference, weak connection, adjusting antennas or else...
You have some big logic errors here. You have heard people talk about the uplink and downlink.
The Controller is a Wifi TX and RX. The Drone is a Wifi RX and TX.
The controller has a specific Power rating for Wifi for broadcast. It has reasonable antenna.
The Drone has a lower power rating for Wifi Broadcast. It does not have great antenna.
The distance specification from DJI does not relate to the Power of the Controller (This is the Power rating that is used in their documentation) But relates to the combination of the Controller and the Drone.
You cannot use any device to measure WIFi interference.
This is the reason why. You do this from the position of the Controller and the results will give you the perspective of the Controller. But the more susceptible is the drone and you have no idea of what the interference is around the drone as it is mobile and can fly into dense Wifi interference without you knowledge it would just report that the connection is being impeded.
Which you had. I read your total blog article. You did many things that were what I would call poor practice and an incident was inevitable.
Your warning was the "channel change" advice you got. The EU (CE) MM is 5.8 and 2.4Ghz. When the Spark was released it had some significant issues with WiFi interference and country localisation. This indication would be that it had roamed into a high interference area on the current allocated channel / band and needed to renegotiate a change in the channel number or band.
If it dropped the connection to the controller it would attempt a renegotiation of channels and frequencies. During this renegotiation it would continue with the commands that it last received. i.e. flying forward at full tilt would continue in that attitude while negotiatiating.
A few Sparks were lost in this fashion but fortunately the obstacle avoidance could help in some cases. DJI rectified this issue. I don't know if something similar exists with the MM yet. Mine has been flawless to date. But I have the FCC version.
No obstacle avoidance on the MM and no hover if you move into a GPS dead zone (Not enough sats to get an accurate GPS fix) and you are above the optical flow sensors height limit on the bottom of the drone.
Another factor is the signal to noise. This can have extremely bad impacts. The complete loss of signal is good. The high Signal to noise ratio is very bad.
I fly many manufacturers drones, helicopters, fixed wing both electric, gas, nitro and kero turbines.
Setting up a Radio to these models have one thing in common. You have to program the signal loss behaviour on your controller and it transmits the commands to the RX on linkage. so the RX knows what to do in the event of a signal loss.
If you are programming a GPS drone you would set a RTH. On a fixed wing you would drop the throttle and set then flight controls to neutral and hope that you got signal back before it crashed.
Now the RXs in the models keep a track of the incoming signal. Its not about signal strength but the packet errors in the signal itself. Each command for position of all the controls (and it sends these constantly in its data stream) has a checksum so that the RX can tell if the command is corrupted. It counts these errors and if its reaches a preset continuous limit it will activate its loss of signal logic. But if it gets a good packet it sets the count back to zero.
So in the case of a MM. if you got high signal to noise at the MM end it may not enter into signal loss RTH but respond to commands from the controller as good packet were received. So no auto RTH depending on what you did with the controls, some commands would be accepted. Including RTH and Cancel RTH.
The other factor is the direction of flight. This is driven by the compass and not the GPS. In a dense urban environment, the possibility of magnetic anomalies is significant. You have to keep clear of all buildings particularly any that have steel structures. I don't know what the
Tower you were next to was made of, but way too many potential compass interference possibilities for safe flight.
In reading your Blog you were continually trying "remote landings" behind objects. This is highly dangerous for a number of reasons. GPS shadows, compass interference, no VLOS so you cannot see what is not in the camera in front of you. (If it is working at the time). And no obstacle avoidance at all on the MM.
You were doing things that I would not do, even on my Phantom 4 Pro Plus or my MAvic 2s with all round obstacle avoidance. To do that on an entry level drone with minimum protection sensors is going to fail at some point. It was inevitable.
Now, as you don't have the logs off the drone what happened is only conjecture. You only have the perspective of the controller.
I would suspect that basically you ran into something, while still in control of the drone.
A good hypothesis based on the information posted above.
I would classify this completely as Operator Error. Not Pilot error. Asking the drone to perform in a hostile environment, in an unsafe manner, without adequate sensors, and an operator that was unaware of the dangers involved and the correct operating capability and warnings the MM did provide.