| Author |
Message |
Isaac Wingfield
Guest
|
 Posted:
Wed Dec 29, 2004 8:11 am Post subject:
Very slow updates with Street Atlas -- SOLVED! |
|
|
A few days ago I posted, asking why the track on the map lagged my
actual position with Street Atlas but not with GPSy.
I now have the answer -- Street Atlas is slower at processing the data
from the GPS unit than GPSy, and it's not smart enough to know how to
deal with it by throwing away what it doesn't need.
Basically, the data queue was filling up faster than the NMEA sentences
were being processed, so the track fell further and further behind until
the queue got full. Then the software would purge it, and the track
would suddenly "jump" to a spot much closer to the actual position, and
then the cycle started over. The result, unfortunately, was fairly
useless for navigation.
The solution was to reduce the rate of some less-critical NMEA sentences
from once per second to once per ten seconds -- something that Street
Atlas is totally incapable of doing -- even with human help -- since it
doesn't provide any way to send general commands to the GPS unit. I used
a simple terminal program (ZTerm), and chose to reduce the rate of
"GPGSV" sentences, since they come in sets of three (lots of data), and
the satellite info just doesn't need updating that often.
Street Atlas now works just fine on my 180 MHz PowerBook.
Isaac |
|
| Back to top |
|
 |
Marvin Hlavac
Guest
|
| Posted:
Thu Dec 30, 2004 2:45 am Post subject:
Re: Very slow updates with Street Atlas -- SOLVED! |
|
|
| Quote: | Street Atlas now works just fine
on my 180 MHz PowerBook.
|
Congratulation Isaac ;-)
You managed it in spite of the minimum system requirements being:
"Intel® Pentium 300 MHz or higher processor (600 MHZ recommended)"
--
Regards,
Marvin Hlavac
Toronto, Canada
"Isaac Wingfield" <isw@witzend.com> wrote in message
news:isw-09F04C.22445828122004@netnews.comcast.net...
| Quote: | A few days ago I posted, asking why the track on the map lagged my
actual position with Street Atlas but not with GPSy.
I now have the answer -- Street Atlas is slower at processing the data
from the GPS unit than GPSy, and it's not smart enough to know how to
deal with it by throwing away what it doesn't need.
Basically, the data queue was filling up faster than the NMEA sentences
were being processed, so the track fell further and further behind until
the queue got full. Then the software would purge it, and the track
would suddenly "jump" to a spot much closer to the actual position, and
then the cycle started over. The result, unfortunately, was fairly
useless for navigation.
The solution was to reduce the rate of some less-critical NMEA sentences
from once per second to once per ten seconds -- something that Street
Atlas is totally incapable of doing -- even with human help -- since it
doesn't provide any way to send general commands to the GPS unit. I used
a simple terminal program (ZTerm), and chose to reduce the rate of
"GPGSV" sentences, since they come in sets of three (lots of data), and
the satellite info just doesn't need updating that often.
Street Atlas now works just fine on my 180 MHz PowerBook.
Isaac |
|
|
| Back to top |
|
|
Isaac Wingfield
Guest
|
| Posted:
Thu Dec 30, 2004 8:14 am Post subject:
Re: Very slow updates with Street Atlas -- SOLVED! |
|
|
In article <_IGdnUIEiLPCuE7cRVn-qg@rogers.com>,
"Marvin Hlavac" <hlavac@rogersREMOVE.com> wrote:
| Quote: | Street Atlas now works just fine
on my 180 MHz PowerBook.
Congratulation Isaac ;-)
You managed it in spite of the minimum system requirements being:
"Intel® Pentium 300 MHz or higher processor (600 MHZ recommended)"
|
With my tongue NOT planted in my cheek, I'll simply state that a 180 MHz
PowerPC processor is easily as capable as a 300 MHz Pentium, especially
on math-intensive operations.
I personally have seen *twice* the throughput from a 500 MHz PPC as from
a 1000 MHz Pentium, on the same math-intensive task (recoding MPEG in
real time).
Isaac
| Quote: |
"Isaac Wingfield" <isw@witzend.com> wrote in message
news:isw-09F04C.22445828122004@netnews.comcast.net...
A few days ago I posted, asking why the track on the map lagged my
actual position with Street Atlas but not with GPSy.
I now have the answer -- Street Atlas is slower at processing the data
from the GPS unit than GPSy, and it's not smart enough to know how to
deal with it by throwing away what it doesn't need.
Basically, the data queue was filling up faster than the NMEA sentences
were being processed, so the track fell further and further behind until
the queue got full. Then the software would purge it, and the track
would suddenly "jump" to a spot much closer to the actual position, and
then the cycle started over. The result, unfortunately, was fairly
useless for navigation.
The solution was to reduce the rate of some less-critical NMEA sentences
from once per second to once per ten seconds -- something that Street
Atlas is totally incapable of doing -- even with human help -- since it
doesn't provide any way to send general commands to the GPS unit. I used
a simple terminal program (ZTerm), and chose to reduce the rate of
"GPGSV" sentences, since they come in sets of three (lots of data), and
the satellite info just doesn't need updating that often.
Street Atlas now works just fine on my 180 MHz PowerBook.
Isaac
|
|
|
| Back to top |
|
|
|
|
|
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in