I’m running the beta version of 4.5.5 - I think it’s the beta1 version:
An odd thing I noticed when I installed this firmware was that the two COM ports (MavLink and SLCAN) were reversed. Normally the MavLink com port is one number lower than the SLCAN com port.
Mission Planner had no difficulty with this - all you had to do is make sure you selected the COM ported labeled as MavLink.
But I ran into a problem with Qgroundcontrol. It would only recognize the COM port for SLCAN- which was a lower number. It won’t connect to this.
So I went into the device manager, and switched the COM port numbers so that the MavLink COM port was one lower than the SLCAN.
Qgroundcontrol would still not recognize the COM port for MavLink - so I could not get a connection via the USB cable to this copter on Qgroundcontrol using the 4.5.5 beta.
To compare - I took an old copter off the shelf with an older version of the firmware. The COM ports showed up in the right order automatically, and Qgroundcontrol recognized the proper port for a MavLink connection.
I don’t really need a USB connection for Qgroundcontrol for the copter running the 4.5.5-beta. But perhaps it will effect someone else - and perhaps the DEVS should comment. Maybe it’s me doing something wrong.
Your screenshots show 4.5.5 stable (and the hash matches Copter / CubeOrangePlus-bdshot / 4.5.5 stable).
In any case, I can’t reproduce it, both on a somewhat stale bootloader and a fresh update to it. I even tried doing some “magic” with the SERIAL0 and SERIAL6 parameters, but all that does is change the protocol on the ports. They are still labeled the same, and at least on my machine, they remain ordered MavLink followed by SLCAN. This holds true for both 4.5.5 and 4.5.6-beta1, again, at least for my hardware.
You might try a reboot of the computer in question, as it seems more likely related to the way the computer’s device drivers are initialized than a firmware issue.
If this particular Cube continues to behave identically regardless of the firmware flashed or the computer to which it is connected, it may also simply be the way that particular Cube identifies itself to the USB host, in which case it’s more likely a hardware “anomaly” vs a firmware version issue.
It appears I did this update just before 4.5.6-beta was released - so when I selected “beta” it took the 4.5.5-beta. Which coincidently, solved my GPIO problem. I simply failed to notice that it wasn’t 4.5.6-beta.
So I’ve now done the firmware update to 4.5.6-beta - and my COM port problem remains - Qgroundcontrol only recognizes the SLCAN COM port.
I have a feeling that when this problem is resolved, I’m going to learn something interesting.
