For Arducopter 3.5.x the ConfigFrameClassType view should be used. But in my case when I connecting via WiFi, the isCopter35plus variable is false, so incorrect view activated.
Ok, but why isCopter35plus is false?
MP does request FW version connecting to FC board (getVersion() method in mavlink\mavlinkinterface.cs).
This method sends AUTOPILOT_VERSION_REQUEST mavlink message and checks for the answer for some time.
The fact is when using USB cable the answer comes immidiatelly, but with Wifi connection the answer newer AUTOPILOT_VERSION comes. So MP thinks that connected arducopter version is 0.0.0.0 (that is also a minor bug).
Need to say that excluding this particular mav message, everything else works perfectly via WiFi connection, so I don’t think it could be related to my Wifi board problems or my firewall settings etc.
The fact is when using USB cable the answer comes immidiatelly, but with
Wifi connection the answer newer AUTOPILOT_VERSION comes. So MP thinks that
connected arducopter version is 0.0.0.0 (that is also a minor bug).
Need to say that excluding this particular mav message, everything else
works perfectly via WiFi connection, so I don’t think it could be related to
my Wifi board problems or my firewall settings etc.
Just tested with 3.6-dev and the isue is the same.
Also I’ve checked connection stats in MP
So when connected via USB there are no packets lost (100% quality)
But when connected via Wifi then Pkts Lost is increasing continiously and quality is only 72%.
Is this expected for Wifi connection?
@dkemxr could you please also check what is your quality and packets lost rate when connected via Wifi.
By the way do you using UTP connection?
UDP yes. A few lost packets but nothing to worry about. Is SERIAL5_PROTOCOL set to 1 and SERIAL5_BAUD to 921600? What firmware are you using on the ESP8266 radio?
Thanks for the info @dkemxr
Yes, PROTOCOL and speed is correct.
It is looks like some problem with my wifi link.
I have a huge number of lost packets for some reason, even more than yesterday. I even cannot enter compass live calibration mode, nor do accels calibration.
I need to investigate more on how to check and update Wifi board firmware.
Just thought may be Wifi interferences with FrSky telemetry receiver?
No, not the Rx. I have 2 PixRacers with WiFi and Frsky telemetry. If it’s a radio supplied with a clone PixRacer the firmware needs to be updated. The one that comes from AUAV/mRobotics is good to go. I have one of each and that was my finding.
@dkemxr thanks again
I didn’t know that wifi FW can be simply updated just by using http://192.168.4.1/update
So I uploaded 1.1.1 firmware and it helped. Looks like I have a stable connection at the moment (tested for a several minutes yet, no packet lost).
The FRAME type selection as well as Compass calibration works as expected now. Great))
I don’t understand what is the cause and what is the effect. But there is definitelly a relation exists between wifi and RC transmitter: when I turn-off the RC then wifi works bad (to be accurate - it almost doesn’t work at all)
And vice versa, turning RC on then wifi also works excellent.
Great news Sergey! Yes the over the air update feature is very nice. I have been impressed with the capability of the ESP8266 radio. It connects to everything (Windows, Android, IOS) with Mission Planner, Tower and QgroundControl. Short range yes but for general configuration and calibration purposes it works great.