Active Topics
-
The N900 is now 15 years old! (8)
to Nokia N900 by whayong - 16 hrs, 10 mins ago -
Sailfish OS for the Motorola Moto G7 Power (XT1955-5) - (ocean) (4)
to SailfishOS by Maemish - 5 days, 12 hrs ago - more...
jussik |
2008-02-07
, 07:12
|
|
Posts: 139 |
Thanked: 24 times |
Joined on Sep 2005
|
#81
|
Originally Posted by kernelpanic
No, there is not. It's my blog and it has the same information and same web addresses that I've linked to from here.
|
|
2008-02-07
, 08:43
|
|
Posts: 139 |
Thanked: 24 times |
Joined on Sep 2005
|
#82
|
Originally Posted by ag2
I can confirm that last bit: I've used the GPS (with a good fix) without running gpsd, libgpsbt or libgpsmgr, and in that case /var/lib/gps/gps_last_saved_report does not get updated. But apparently this file is only used for the UI...
I am still not 100% convinced the leap bug has no effect on the hardware. If N810 uses last location to initialize GPS, that location needs to be stored somewhere. The only place I know which stores a location is /var/lib/gps/gps_last_saved_report. This file is generated by gpsd and stores the incorrect timestamp.
Jukka R. explicitly stated that gpsd timestamp is not fed to the chip, so I'd say that's ruled out. But he also said "almanac and ephemeris are fed back to the chip", somthing I wasn't sure about earlier (the chip could have had an internal memory, although I guess that's unlikely).
Ephemeris data has to live in /var/lib/nvd_data (That's the only file I see getting updated with the setup mentioned above). ag2, are you familiar with almanac / ephemeris data? Does the size of the file look like it's in the ballpark?
The data structure seems variable so the following could be different each time.... The file I'm looking at has two digit hex numbers in six groups, padded with zeros in several places:
1: 3457 numbers (everything after 752 is zero)
2: 1153 numbers
3: 25 numbers
4: 35 numbers (mostly zero)
5: 73 numbers
6: 25 numbers
|
|
2008-02-07
, 08:54
|
|
Posts: 2,102 |
Thanked: 1,309 times |
Joined on Sep 2006
|
#83
|
Has anyone (who can get their gps to work more easily than me) captured the NMEA sentences for the Almanac data? If so, could they post them and nvd_data for people to take a look at please?
The ephemeris data aren't exported in the NMEA output afaik, so we'll have to work out the format ourselves. The other problem is that the GPS chip may need to be told to output and intput the almanac/ephemeris data (perhaps why there are lots of 0x0s in nvd_data).
The ephemeris data aren't exported in the NMEA output afaik, so we'll have to work out the format ourselves. The other problem is that the GPS chip may need to be told to output and intput the almanac/ephemeris data (perhaps why there are lots of 0x0s in nvd_data).
|
|
2008-02-07
, 09:13
|
|
Posts: 164 |
Thanked: 132 times |
Joined on Dec 2007
|
#84
|
Originally Posted by lardman
Almanac ($GPALM) is not exported via NMEA by gpsdriver
Has anyone (who can get their gps to work more easily than me) captured the NMEA sentences for the Almanac data? If so, could they post them and nvd_data for people to take a look at please?
The ephemeris data aren't exported in the NMEA output afaik, so we'll have to work out the format ourselves. The other problem is that the GPS chip may need to be told to output and intput the almanac/ephemeris data (perhaps why there are lots of 0x0s in nvd_data).
strings gpsdriver | grep "^\\$"
$GPGGA,%s,%s,%s,%c,%s,%s,%s,%s,,
$GPGLL,%s,%s,%s,%c,%c
$GPGSA,%c,%c,
$GPGST,%s,%s,%s,%s,%s,%s,%s,%s
$GPGSV,%u,%u,%02u
$GPRMC,%s,%c,%s,%s,%s,%s,%s,%s,%s,%c
$GPVTG,%s,T,%s,M,%s,N,%s,K,%c
$PNOKU,%s,%s,%s,%s,%s,%s
Again, I believe that almanac data is not used by the chip at all. This is the only explanation for 3 minute cold starts I can think of.
The problem with GPS5300 is that it was designed to be a cell phone chip, to be used primarily with A-GPS. Without A-GPS the chip more or less stinks.
__________________
See my collection of maemo apps: http://nitapps.com
See my collection of maemo apps: http://nitapps.com
|
|
2008-02-07
, 09:21
|
|
Posts: 139 |
Thanked: 24 times |
Joined on Sep 2005
|
#85
|
Originally Posted by ag2
Yep.
Almanac ($GPALM) is not exported via NMEA by gpsdriver
Originally Posted by ag2
This is quite possible. Knowing the approximate amount of bytes this data takes would probably tell a lot...
Again, I believe that almanac data is not used by the chip at all. This is the only explanation for 3 minute cold starts I can think of.
|
|
2008-02-07
, 09:23
|
|
Posts: 164 |
Thanked: 132 times |
Joined on Dec 2007
|
#86
|
Originally Posted by jussik
Jukka also said he wasn't the maintainer of gpsdriver, so it is possible that the left hand at Nokia doesn't know what the right hand is doing
Jukka R. explicitly stated that gpsd timestamp is not fed to the chip, so I'd say that's ruled out. But he also said "almanac and ephemeris are fed back to the chip", somthing I wasn't sure about earlier (the chip could have had an internal memory, although I guess that's unlikely).
Ephemeris data has to live in /var/lib/nvd_data (That's the only file I see getting updated with the setup mentioned above). ag2, are you familiar with almanac / ephemeris data? Does the size of the file look like it's in the ballpark?
Ephemeris data is 600 bits per satellite, and the entire almanac is 15000 bits. I believe almanac data is not stored in nvd_data. The only group to hold 15k bits is B 1 (3457 bytes), but it is mostly filled with zeroes.
__________________
See my collection of maemo apps: http://nitapps.com
See my collection of maemo apps: http://nitapps.com
|
|
2008-02-07
, 09:34
|
|
Posts: 164 |
Thanked: 132 times |
Joined on Dec 2007
|
#87
|
Also, one good test to see if B 1 is indeed the almanac is to see whether the data changes significantly over time. Almanac data should be fairly static (it is valid for 180 days).
Never mind my previous assertion that B 1 being mostly 0 means that it is not the almanac. The almanac's size is fixed, and perhaps it is designed to hold information for a lot more satellites than are currently launched. So zeroes could actually make sense.
Perhaps B 1 is the almanac and B2 is the ephemeris. The size of B2 is roughly in the right range (600 bits x 12 satellites = 900 bytes).
B 3 - B 6 could be the location, time, etc
Never mind my previous assertion that B 1 being mostly 0 means that it is not the almanac. The almanac's size is fixed, and perhaps it is designed to hold information for a lot more satellites than are currently launched. So zeroes could actually make sense.
Perhaps B 1 is the almanac and B2 is the ephemeris. The size of B2 is roughly in the right range (600 bits x 12 satellites = 900 bytes).
B 3 - B 6 could be the location, time, etc
__________________
See my collection of maemo apps: http://nitapps.com
See my collection of maemo apps: http://nitapps.com
|
|
2008-02-07
, 10:01
|
|
Posts: 91 |
Thanked: 4 times |
Joined on Dec 2007
|
#88
|
So now I have a serious question:
1. Why did Nokia use a cell phone GPS chip and not provide us with the possibility to use A-GPS?
2. Why did they not use a different GPS chip when they know that cold start would take that long?
1. Why did Nokia use a cell phone GPS chip and not provide us with the possibility to use A-GPS?
2. Why did they not use a different GPS chip when they know that cold start would take that long?
|
|
2008-02-07
, 10:08
|
|
Posts: 164 |
Thanked: 132 times |
Joined on Dec 2007
|
#89
|
Originally Posted by cycroft
They are a cell phone company. It is easier for them to put the same chip in all devices. Fewer suppliers, fewer drivers to write, etc.
So now I have a serious question:
1. Why did Nokia use a cell phone GPS chip and not provide us with the possibility to use A-GPS?
2. Why did they not use a different GPS chip when they know that cold start would take that long?
__________________
See my collection of maemo apps: http://nitapps.com
See my collection of maemo apps: http://nitapps.com
|
|
2008-02-07
, 10:29
|
|
Posts: 139 |
Thanked: 24 times |
Joined on Sep 2005
|
#90
|
Originally Posted by ag2
True. I have not saved earlier nvd_datas, but did save one now: http://folks.o-hand.com/jku/nvd_data/20080207-jku
Also, one good test to see if B 1 is indeed the almanac is to see whether the data changes significantly over time. Almanac data should be fairly static (it is valid for 180 days).
You can send your nvd_data to me (jhkukkon@cc.hut.fi), I'll put them up. The last NMEA cycle might be useful too but I didn't save that. Maybe we can see something useful if we have a few of those.
