ve3wmb
commented
4 years ago A fix for this issue was submitted in Orion V0.28b as follows :
v0.28b - Fix for GITHUB issue number 7 - Orion System Date Anomaly on GPS LOS.
The solution was to re-define the criteria for a valid GPS time fix from (fix.valid.time == true) to (fix.valid.status == true) && (fix.status > STATUS_TIME_ONLY ). This prevents the Orion system clock from being updated by the GPS unless there is a current 3D fix.
VE3WMB
The Orion V0.27b running on VE3GTCs Frankentracker ( Quectel GPS module) seems to be time-warping back to 2015 during periods where GPS satelllite coverage is NIL. Orion Date/Time recovers via timeset from GPS once there is a valid fix. It is possible that time is still ok (to be validated). (see attached log from VE3GTC) tracker_Quectel_027a_20191225_1430UTC.log
This is a snippet from the telemetry debug log:
[2020-01-02 04:48:05.188] > 2020-1-2 4:48:4 Sampled Freq Hz x 100 : 0320000010 Old Corr factor : -9020 New Corr factor : -9010 [2020-01-02 04:48:05.188] > iteration: 23 overflowCounter: 488 TCNT1: 18431 [2020-01-02 04:48:16.182] > 2020-1-2 4:48:15 Sampled Freq Hz x 100 : 0319999990 Old Corr factor : -9010 New Corr factor : -9020 [2020-01-02 04:48:16.182] > 2020-1-2 4:48:15 >> orion PRE sm trace: curr_state: 2 curr_event: 3 [2020-01-02 04:48:16.374] > 2020-1-2 4:48:15 << orion POST sm trace: curr_state: 3 event_just_processed: 3 action: 0 [2020-01-02 04:48:16.374] > 2015-12-31 4:49:1 Info: System Time set from GPS [2020-01-02 04:49:01.860] > 2015-12-31 4:49:3 >> orion PRE sm trace: curr_state: 3 curr_event: 4 [2020-01-02 04:49:04.041] > 2015-12-31 4:49:3 << orion POST sm trace: curr_state: 4 event_just_processed: 4 action: 2 [2020-01-02 04:49:04.041] > 2015-12-31 4:49:3 Telem Grid:FN25IG, alt_m:77, spd_kn:0, num_sats:0, gps_stat:0, batt_v_x10:34, ptemp_c:13, temp_c:-127 [2020-01-02 04:49:04.375] > 2015-12-31 4:49:3 >> orion PRE sm trace: curr_state: 4 curr_event: 5