Opened 10 years ago

Closed 10 years ago

#610 closed defect/bug (fixed)

GPX and TXT tracks are empty since r3395

Reported by: polarbear_n Owned by: KaZeR
Priority: blocker Milestone: version 0.2.0
Component: core Version: git master
Severity: Keywords:
Cc:

Description

GPX and TXT track writing works fine until r3378 (including the time format fix in this revision).

From r3395 on, which is the next available build in http://download.navit-project.org/navit/wince/svn/ these tracks are empty on my WinCE device (the files are created, but only the gpx-header or the type=track line are written into the files).

The NMEA log is written in all revisions.

The problem persists in 3397/3416/3443/3447/3473 which were tested while narrowing down the problem.

My suspicion is revision 3381, where a test has been introduced to avoid logging invalid fixes: http://navit.svn.sourceforge.net/viewvc/navit/trunk/navit/navit/vehicle.c?r1=3381&r2=3380&pathrev=3381

if (fix_attr.u.num != 2 && fix_attr.u.num != 3)

The fix_attr is apparently set by position_attr_get in the vehicle-specific sections.

The numerical value is unclear to me.

vehicle_wince_position_attr_get sets attr_position_fix_type: attr->u.num = priv->status;

however it is not obvious for me which NMEA sentence the values come from:

GGA [0 = invalid ; 1 = GPS fix (SPS) ; 2 = DGPS fix ; 3 = PPS fix]

GSA [1 = no fix ; 2 = 2D fix ; 3 = 3D fix ]

I have both in my NMEA logs, with GGA=1 and GSA=3 for valid fixes.

Attachments (1)

navit_3471_ticket_610.patch (4.9 KB) - added by mvglasow (2) 10 years ago.
Restore broken GPS logging

Download all attachments as: .zip

Change History (7)

comment:1 Changed 10 years ago by mvglasow (2)

I can confirm your suspicion: I tried this morning and got a GPX file with no trackpoints despite some 10 minutes of logging with a good fix. I just commented out the "return" which gets called if the "if" condition evaluates to true in vehicle_log_gpx (effectively disabling the test) and tried again, and this time I got trackpoints.

Conclusion: the if condition is buggy.

comment:2 Changed 10 years ago by mvglasow (2)

Looking at vehicle_wince.c, I can say that at least on WinCE the values come from the GGA sentences.

GSA sentences are discarded altogether, GGA sentences are parsed and the quality field is stored in the status field of the vehicle_priv structure. That same field is read when getting the attr_position_fix_type.

So this code definitely breaks things on WinCE and the line in question probably needs to be changed to

if ((fix_attr.u.num != 1) && (fix_attr.u.num != 2) && (fix_attr.u.num != 3))

I still have to look at other vehicle definitions since the code that gathers this value is heavily OS-specific - to avoid fixing WinCE and breaking things on another OS.

comment:3 Changed 10 years ago by mvglasow (2)

Implementation in vehicle_* is thus:

  • WinCE and file process raw NMEA data and will return the fix as reported by GGA.
  • gpsd returns the value reported by GSA, minus 1.
  • gypsy returns 3 for a 3D fix, 1 for a 2D fix and 0 for an invalid or no fix.
  • Maemo returns 1 for a valid fix, 0 for no valid fix.
  • Android, demo, gpsd_dbus, iPhone and null do not provide this attribute, hence Navit does not perform this verification but logs whatever it gets.

Note: GGA may return the following values (taken from gpsd source code):

0 = invalid
1 = GPS
2 = DGPS
3 = PPS (Precise Position Service)
4 = RTK (Real Time Kinematic) with fixed integers
5 = Float RTK
6 = Estimated
7 = Manual
8 = Simulator

Conclusion: On platforms/APIs that provide this attribute, lack of a valid fix is always indicated by 0. Valid fixes may be indicated by integers from 1 to at least 5; where raw NMEA is used, we might also see 6, 7 and 8 for different kinds of "synthetic" fixes, though I expect such cases to be rare.

Checking for a nonzero value should serve our purposes; I'll prepare a patch.

Changed 10 years ago by mvglasow (2)

Restore broken GPS logging

comment:4 Changed 10 years ago by mvglasow (2)

Here is the patch; I just need someone to apply it to the SVN tree for me.

The patch includes the fix plus documentation for some undocumented functions that I stumbled across.

comment:5 Changed 10 years ago by mvglasow (2)

...for the sake of completeness: the patch was tested on WinCE with a GPX log enabled; track points were logged as expected.

comment:6 Changed 10 years ago by akashihi

  • Resolution set to fixed
  • Status changed from new to closed

The source of that problem, is that navit expects a 'internal fix type' code, supplied by the vehicle plugin. With r3381 path i've incorrectly understood the possible values for this attribute and instroduced a wrong check. Sorry :-)

Fixed in r3489

Note: See TracTickets for help on using tickets.