robertlipe
commented
5 years ago It's entirely possible that doesn't work. It's a super-esoteric "feature" added over ten years ago and exists solely as a workaround for a rarely encountered GPS bug. It's entirely possible that hunk got moved to the wrong place over the years. That flag was kind of a stab in the dark anyway; it's not like it's a suggested thing in their protocol and GPSes that need this are kind of inherently in a semi-broken state anyway.
If you move that down and confirm that it works for you, please send us a pull request and we'll merge it. I agree with your analysis that Send_Time before Gps_Init is probably bad but there may be something in _Init (which causes an avalanche of traffic on the connection) that falls off the track if the GPS date is super hosed.
On Sun, May 12, 2019 at 10:30 PM rlsolomon notifications@github.com wrote:
In garmin.cc main() the snippet
if (resettime) { GPS_Command_Send_Time(qPrintable(fname), current_time().toTime_t()); return; }
is called long before GPS_Init is called (3 if clauses lower)
Unfortunately, in gpscom.cc, the GPS_Command_Send_Time() function first checks that global variable gps_date_time_transfer has value pA600. This cannot be true, as gps_date_time_transfer is first set in function GPS_A000 in gpsapp.cc - where it's set to -1, then later (potentially) overwritten by function GPS_A001 in gpsapp.cc called from within GPS_A000. GPS_A000 is called from GPS_Init.
So resettime never works, even for units supporting pA600 because gps_date_time_transfer hasn't been set when the value is checked. It seems like moving the resettime check AFTER the GPS_Init() call would solve the problem?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/gpsbabel/gpsbabel/issues/350, or mute the thread https://github.com/notifications/unsubscribe-auth/ACCSD3YKENQDTQLA6H5HR23PVDOE7ANCNFSM4HMMCILA .
rlsolomon
tsteven4
GPSBabelDeveloper
In garmin.cc main() the snippet
if (resettime) { GPS_Command_Send_Time(qPrintable(fname), current_time().toTime_t()); return; }
is called long before GPS_Init is called (3 if clauses lower)
Unfortunately, in gpscom.cc, the GPS_Command_Send_Time() function first checks that global variable gps_date_time_transfer has value pA600. This cannot be true, as gps_date_time_transfer is first set in function GPS_A000 in gpsapp.cc - where it's set to -1, then later (potentially) overwritten by function GPS_A001 in gpsapp.cc called from within GPS_A000. GPS_A000 is called from GPS_Init.
So resettime never works, even for units supporting pA600 because gps_date_time_transfer hasn't been set when the value is checked. It seems like moving the resettime check AFTER the GPS_Init() call would solve the problem?