for new 3DR Ublox-LEA6 the GPS driver does not seem to update 3D fix field

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Load ArduPlane 2.5 (or current git version)
2. Observe that GPS location and satellite count never get updated
3.

What is the expected output? What do you see instead?

Once the GPS has a fix, the location should change slightly even when 
stationary and the number of satellites should change over time. This bahaviour 
can be overserved in the CLI GPS test but not in the flight mode. 

What version of the product are you using? On what operating system?

Recent 3DR UBlox-LEA6, APM 1280 (setting GPS to UBlox driver).

Please provide any additional information below.

I'm using my custom GCS but that should really not matter due to the different 
observed behavor for example when I connect my Mediatek at the same location, 
which works fine. On the GCS I can verify that the 3D fix is not set, although 
for example I have around 9 satellites and location directly after reset is 
correct even with UBlox, it is just not updated. CLI test works fine. Note that 
the LED on the GPS is flashing, is this correct? (the Mediatek LED becomes 
solid but the UBlox initially seems to have unlid fix LED)

Original issue reported on code.google.com by andre.sc...@gmail.com on 30 Jul 2012 at 7:15

[GoogleCodeExporter]

Seems like an initialization issue. Here is debug output of three restarts 
(after that nothing more is logged):

first:
_parse_gps:178: ACK 1
_parse_gps:178: ACK 1
_parse_gps:178: ACK 1
_parse_gps:178: ACK 1
_parse_gps:178: ACK 1
_parse_gps:232: MSG_SOL fix_status=93 fix_type=3
_parse_gps:223: MSG_STATUS fix_status=93 fix_type=3
_parse_gps:212: MSG_POSLLH next_fix=1
read:153: bad cka 62 should be 5b

second:
_parse_gps:178: ACK 1
_parse_gps:178: ACK 1
_parse_gps:178: ACK 1
_parse_gps:178: ACK 1
_parse_gps:178: ACK 1
_parse_gps:232: MSG_SOL fix_status=221 fix_type=3
_parse_gps:223: MSG_STATUS fix_status=221 fix_type=3
_parse_gps:212: MSG_POSLLH next_fix=1
_parse_gps:178: ACK 1

third:
parse_gps:178: ACK 1
_parse_gps:178: ACK 1
_parse_gps:178: ACK 1
_parse_gps:178: ACK 1
_parse_gps:178: ACK 1
_parse_gps:198: Unexpected message 0x0d 0x01
_parse_gps:232: MSG_SOL fix_status=221 fix_type=3
_parse_gps:223: MSG_STATUS fix_status=221 fix_type=3
_parse_gps:212: MSG_POSLLH next_fix=1

Original comment by andre.sc...@gmail.com on 30 Jul 2012 at 5:48

[GoogleCodeExporter]

Did some more digging and enabled debug info inside GPS.cpp. Now it seems that 
in total the GPS update is only called twice (due to the way groundstart is 
handled inside setup.pde) and unfortunately the timout or initial unsuccessful 
read (e.g., position message before speed message) cause a NO_GPS status 
setting. See debug log: (added one debug line to GPS.cpp)

_parse_gps:178: ACK 1
_parse_gps:178: ACK 1
_parse_gps:178: ACK 1
_parse_gps:178: ACK 1
_parse_gps:178: ACK 1
_parse_gps:178: ACK 1
_parse_gps:232: MSG_SOL fix_status=221 fix_type=3
_parse_gps:223: MSG_STATUS fix_status=221 fix_type=3
_parse_gps:212: MSG_POSLLH next_fix=1
update:39: gps read timeout 13191 0
update:29: gps update! 13291
update:29: gps update! 13292

Mabe one should increase the number of trials from 2 to something larger inside 
setup.pde?

Original comment by andre.sc...@gmail.com on 31 Jul 2012 at 6:29

[GoogleCodeExporter]

Sorry, mixed up, meant system.pde. The following one-line change seems to fix 
the problem:

diff --git a/ArduPlane/system.pde b/ArduPlane/system.pde
index 291f191..25a77e6 100644
--- a/ArduPlane/system.pde
+++ b/ArduPlane/system.pde
@@ -339,7 +339,7 @@ static void startup_ground(void)
                        break;
                }

-               if (counter >= 2) {
+               if (counter >= 4) {
                        GPS_enabled = false;
                        break;
            }

Original comment by andre.sc...@gmail.com on 31 Jul 2012 at 6:35