QGC 4.1.6 small things

[EliotBR (Eliot)]

@Boko

There have never been any setup made in Ardusub for that

Our GPS docs would seem to disagree, apparently:

@ardusub.com - GPS Positioning - Autopilot Configuration

There is some configuration that needs to be done on the autopilot in order for the absolute positioning to perform correctly. These parameters need to be set:

• GPS_TYPE = MAV(14) (This is done automatically by the same application that listens for data on port 27000)
• EK2_GPS_TYPE = 2D Position(2) (We don’t want to use the 3D position, we get very good depth measurements from the pressure sensor)

@Boko

Maybee there is an automatic persistent parameter in 0.0.30 that once UW GPS have been detected, a flag is set to always look for GPS?

Is there a parameter to change when not using UW GPS to get rid of message?

Indeed, the GPS_TYPE parameter is set automatically to MAV (14) once an underwater GPS has been detected. I tried setting that manually on my setup and it did indeed bring back the “No GPS Lock” message (which makes sense).

If you set that parameter to None or AUTO in QGC when you’re not using the GPS then the message should go away

@Boko

2. QGC always starts in a small window.
   The solution is a bit odd: Set the QGC shortcut icon preference to open “Normal window” to get fullscreen. Set it to “Maximized” and the QGC window get small.
   Same in Win 10 and Win 7

Why QGC, just why…?
Glad you managed to find a workaround at least

We still weren’t able to replicate the actual “small” window (ours were a pretty normal size), but the icon preferences did seem to have modified behaviour on one of the machines we tested with.

@Boko

When updating to 0.0.30 my MavProxy row --out udpbcast:192.168.2.255:14555
was no longer there, so note to self: check Mavproxy when updating Ardusub

Odd. There are several mavproxy changes throughout the Companion post-update script (depending on which version is being updated from), but I can’t see any that would modify a udpbcast line - perhaps that was done somewhere else in an update, or maybe you reset to the default mavproxy parameters for some other reason and adding back your extra line got missed.

Regardless, good that the direct cause of the issue you were having has now been found and resolved