Bug 64762 - climb rate algorithm deficiencies
climb rate algorithm deficiencies
 Status: NEW None Gypsy Unclassified General (show other bugs) unspecified Other All medium normal iain

 Reported: 2013-05-19 15:59 UTC by freedesktoporg 2013-05-19 15:59 UTC (History) 0 users

Attachments

 freedesktoporg 2013-05-19 15:59:46 UTC ```The climb rate algorithm in gypsy_client_set_position looks bogus to me. Consider a GPS that outputs a new altitude every second (which is typical), and outputs the following sequences of altitudes: 0 1 1 1 1 1 1 1 1 1 1 0 The climb rate algorithm will compute the following: 0 1 1 1 1 1 1 1 1 1 1 -0.1 (Of course the consecutive 1's are not actually computed, but just not updated). I would expect if I integrate the climb rate values, that I would roughly track the altitude values. WIth the current algorithm this is grossly violated (with the above sequence we arrive at 9.9, instead of ~0). This is the code in question: if (fields_set & POSITION_ALTITUDE) { if (priv->position_fields & POSITION_ALTITUDE) { if (priv->altitude != altitude) { /* If we've got a timestamp for the last alt then we are able to calculate the climb. */ if (priv->last_alt_timestamp > 0) { int dt; double da, climb; dt = priv->timestamp - priv->last_alt_timestamp; da = altitude - priv->altitude; climb = da / (double) dt; gypsy_client_set_course (client, COURSE_CLIMB, 0.0, 0.0, climb); } priv->altitude = altitude; priv->last_alt_timestamp = priv->timestamp; changed = TRUE; } } else { priv->altitude = altitude; priv->last_alt_timestamp = priv->timestamp; priv->position_fields |= POSITION_ALTITUDE; changed = TRUE; } } Furthermore, it's a bit unfortunate that the Gypsy API does only support integer second timestamps; GPS with a higher update rate than 1Hz are getting common (Garmin GLO, most newer u-blox chips/modules).```

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.