Active Topics
-
Firefox with Leste (10)
to Maemo 7 / Leste by teroyk - 2 days, 16 hrs ago - more...
| The Following 4 Users Say Thank You to jonwil For This Useful Post: | ||
|
2019-02-14
, 09:04
|
|
Posts: 1,293 |
Thanked: 4,319 times |
Joined on Oct 2014
|
#2
|
Probably, it seems devices released before ~2010 will almost certainly be affected.
receivers that follow the ICD-200/IS-GPS-200 specification should be able to deal with the week number overflow. This basically means newer receivers built after, say, 2010 should be fine, provided they follow the specs and notice the rollover.
__________________
You can still support my work by donation - click here
You can still support my work by donation - click here
 |
|
2019-02-14
, 10:47
|
|
Posts: 4,118 |
Thanked: 8,901 times |
Joined on Aug 2010
@ Ruhrgebiet, Germany
|
#3
|
Hard to say.without anyone knowing I would say.
It could be or it could not be.
https://ics-cert.us-cert.gov/sites/d...n_GPS_2019.pdf
Furthermore in the ICD200-C from 2000 this rollover is already mentioned.
https://www.gps.gov/technical/icwg/
So also devices built before 2010 could already handle this correctly, or?
But I guess we just have to wait and see...
Last edited by peterleinchen; 2019-02-14 at 10:57.
It could be or it could not be.
...
Additionally, some manufacturer implementationsinterpret the WN parameter relative to a date other than January 5, 1980. These devices should not beaffected by the WN rollover on April 6, 2019 but may experience a similar rollover event at a future date.For example, a particular GPS device may interpret the WN parameter relative to a firmware creationdate and would experience a similar rollover event 1024 weeks after that firmware creation date.
Furthermore in the ICD200-C from 2000 this rollover is already mentioned.
https://www.gps.gov/technical/icwg/
So also devices built before 2010 could already handle this correctly, or?
But I guess we just have to wait and see...
__________________
SIM-Switcher, automated SIM switching with a Double (Dual) SIM adapter
--
Thank you all for voting me into the Community Council 2014-2016!
Please consider your membership / supporting Maemo e.V. and help to spread this by following/copying this link to your TMO signature:
[MC eV] Maemo Community eV membership application, http://talk.maemo.org/showthread.php?t=94257
editsignature, http://talk.maemo.org/profile.php?do=editsignature
SIM-Switcher, automated SIM switching with a Double (Dual) SIM adapter
--
Thank you all for voting me into the Community Council 2014-2016!
Please consider your membership / supporting Maemo e.V. and help to spread this by following/copying this link to your TMO signature:
[MC eV] Maemo Community eV membership application, http://talk.maemo.org/showthread.php?t=94257
editsignature, http://talk.maemo.org/profile.php?do=editsignature
Last edited by peterleinchen; 2019-02-14 at 10:57.
 |
|
2019-02-14
, 11:41
|
|
Posts: 269 |
Thanked: 1,096 times |
Joined on Sep 2009
@ Hampshire, UK
|
#4
|
When the last rollover occurred (1999?) GPS units were rather less common than today, but there were a few where I worked for surveying and laboratory timing.
As I recall, units fell into 3 categories :-
1) No effect, continue operation as normal
2) Loss or degradation of time signal (and therefore probably position) until the ephemeris data downloaded from the satellites is all updated. This takes some minutes.
3) Total failure
I only saw one unit which was affected, and that was total failure. The assumption was that the firmware rejected satellite data claiming to be timestamped before the firmware build date. I don't recall the type, but it was an old unit even then.
I suspect the number of unit types which fail this time around will be very small.
As I recall, units fell into 3 categories :-
1) No effect, continue operation as normal
2) Loss or degradation of time signal (and therefore probably position) until the ephemeris data downloaded from the satellites is all updated. This takes some minutes.
3) Total failure
I only saw one unit which was affected, and that was total failure. The assumption was that the firmware rejected satellite data claiming to be timestamped before the firmware build date. I don't recall the type, but it was an old unit even then.
I suspect the number of unit types which fail this time around will be very small.
| The Following 6 Users Say Thank You to epninety For This Useful Post: | ||
|
|
2021-09-12
, 15:28
|
|
Posts: 5 |
Thanked: 8 times |
Joined on Jul 2015
@ Germany
|
#5
|
I often used GPS recorder since 2013 until the SUPL problem occurred. Now I have fixed this, but temporarily by set settings - location on supl.vodafone.com, this is at least not Google 
But now the next problem. GPS recorder sets the system date at GPS fix incorrectly, today to 2002-01-27 (GPS rollover). I can correct this manually, but in the recorded track are still the wrong date for begin, end, break, etc. GPSData also shows the wrong date, but does not change the system date. Mappero shows no date, but the wrong time, 1 h difference between summer time and winter time. In a recorded track the wrong date is stored. I could not find the dependencies for GPSData, but mappero and gpsrecorder use liblocation0, so I think that the reason can be found there. On my N900 liblocation0 0.102-1+0m5 is installed, it seems to be the latest version. Who can fix this? Should be possible by comparing the GPS date with the system time to determine the correct epoch.
But now the next problem. GPS recorder sets the system date at GPS fix incorrectly, today to 2002-01-27 (GPS rollover). I can correct this manually, but in the recorded track are still the wrong date for begin, end, break, etc. GPSData also shows the wrong date, but does not change the system date. Mappero shows no date, but the wrong time, 1 h difference between summer time and winter time. In a recorded track the wrong date is stored. I could not find the dependencies for GPSData, but mappero and gpsrecorder use liblocation0, so I think that the reason can be found there. On my N900 liblocation0 0.102-1+0m5 is installed, it seems to be the latest version. Who can fix this? Should be possible by comparing the GPS date with the system time to determine the correct epoch.
| The Following User Says Thank You to sbk510 For This Useful Post: | ||
 |
|
2021-09-26
, 00:54
|
|
Posts: 868 |
Thanked: 2,516 times |
Joined on Feb 2012
@ Germany
|
#6
|
You could use gpscon to record a track as gpx. There is a date shift option.
__________________
N900: gpxsee, fahrplan, gpscon, genwall, qrcode, hextool, libjansson4, libevent-2.0-5, cnee, psi-plus, mihphoto, shc
Maemo flasher/rescue live image.
Fremantle Harmattan SDK VM
N900: gpxsee, fahrplan, gpscon, genwall, qrcode, hextool, libjansson4, libevent-2.0-5, cnee, psi-plus, mihphoto, shc
Maemo flasher/rescue live image.
Fremantle Harmattan SDK VM
| The Following 2 Users Say Thank You to Halftux For This Useful Post: | ||
|
|
2022-10-25
, 10:48
|
|
Posts: 5 |
Thanked: 8 times |
Joined on Jul 2015
@ Germany
|
#7
|
Simple fix if anybody needs this:
startgpsrecorder.sh
add in /etc/sudoers
user ALL = NOPASSWD: /bin/date
in /usr/share/applications/hildon/ create a file gpsrecorder2.desktop
Now there should be an entry GPS Recorder2 and you can create an icon.
startgpsrecorder.sh
Code:
#!/bin/sh
lYMD=`date '+%Y.%m.%d'`
/usr/bin/gpsrecorder &
while true; do
sleep 3
YMD=`date '+%Y.%m.%d'`
HMS=`date '+%H:%M:%S'`
echo $YMD $HMS
if [ "$lYMD" != "$YMD" ]; then
sudo date -s "$lYMD-$lHMS"
break
fi
lYMD=$YMD
lHMS=$HMS
done
date '+%Y.%m.%d - %H:%M:%S'
user ALL = NOPASSWD: /bin/date
in /usr/share/applications/hildon/ create a file gpsrecorder2.desktop
Code:
[Desktop Entry] Type=Application Terminal=true Name=GPS Recorder2 Exec=/home/user/startgpsrecorder.sh Icon=gpsrecorder
| The Following 4 Users Say Thank You to sbk510 For This Useful Post: | ||
https://www.theregister.co.uk/2019/0...ps_epoch_ends/
is going to cause issues for the N900 GPS?