, StarTraX wrote:
Hi Sy, Thanks for your input. If I understand you correctly, you are
suggesting I look for a $GPZDA NMEA sentence. I have just checked the SiRF
NMEA Manual and tried it. I'm getting RMC and GGA but no ZDA sentences on
either my SGS 11 or HTC , both running 2.3.3. Am I
in the field,
once we lock on with the RMC the 1PPS pulse is used to generate an
interrupt which ensures that devices are absolutely in sync.
On Wed, Apr 25, 2012 at 8:39 AM, StarTraX gpsanima...@gmail.com wrote:
Further, here are the sentence types I do get:
GPGSA, GPGGA, GPGLL, GPRMC, GPGSV
I've been reading up on the GPS signal structure, and it's true that it
takes 12 1/2 minutes for the full sequence, but... and this is a big but...
the GPS time and GPS/UTC offset are sent with every sub frame, and they
come by every six seconds.
So you can forget about waiting 12 1/2 minutes.
Thanks for your input to this, it's spurred me to further study.
Re the GpsStatus object, that's a great suggestion but for the life of me,
I can't get my SGS 11 to trigger the onStatusChanged event or to get
anything from the GpsStatus object, so that's a bit annoying. But I'll
press on.
Hi Sy, Thanks for your input. If I understand you correctly, you are
suggesting I look for a $GPZDA NMEA sentence. I have just checked the SiRF
NMEA Manual and tried it. I'm getting RMC and GGA but no ZDA sentences on
either my SGS 11 or HTC , both running 2.3.3. Am I missing something here?
Yes I do and will give it a go. Ta.
On Wednesday, April 25, 2012 3:01:33 PM UTC+10, andrewg_oz wrote:
1300ms ahead sounds odd. If it was behind I'd say it was just a reporting
delay as part of the usual message processing, but ahead is weird.
It's not GPS, but if you have an Internet
UTC+10, StarTraX wrote:
I could probably knock you up one quite quickly as I'm currently spending
a lot of time in that space. Could you be more specific about your
requirements? Maybe communicate directly with me through the info {at}
gpsanimator {dot} com
On Mon, Apr 23, 2012 at 12:00 AM
Hey Andrew - what interesting revelations!
What's the story behind the 12.5 minutes wait - is there some time offset
update in the GPS signal? Where can I go to learn more?
I'm now getting some very interesting results from my little app (above).
When first receiving a signal, it's reporting a
I'm trying to get the GPS time for a location using location.getTime on a
location listener using GPS_PROVIDER in my requestLocationUpdates. I was
expecting the provided time to be the time from the GPS clock - accurate to
billionths of a second, but rounded to the millisecond. What I am
for your device decided to use UTC rather than GPS time.
On Sunday, April 22, 2012 6:05:12 PM UTC-4, StarTraX wrote:
I can assure you that the time reported by the quoted gpsclock site is
NOT the time reported by GPS devices. It's really easy to demonstrate:
Compare what you see on your GPS
Hey Sean,
Thanks for your post. Seems like there is some intelligence out there after
all!
I tried to follow your links but hit an Office Outlook web access login
page, so couldn't progress. Is that me or is there a way through?
When you refer to the GPS provider, I wonder what component you
On Friday, April 6, 2012 8:47:03 AM UTC+10, StarTraX wrote:
Hey Sean,
Thanks for your post. Seems like there is some intelligence out there
after all!
I tried to follow your links but hit an Office Outlook web access login
page, so couldn't progress. Is that me or is there a way through
OK can follow links. Something quirky in the embedded URL.
On Friday, April 6, 2012 8:52:50 AM UTC+10, StarTraX wrote:
On Friday, April 6, 2012 8:47:03 AM UTC+10, StarTraX wrote:
Hey Sean,
Thanks for your post. Seems like there is some intelligence out there
after all!
I tried
But then again, maybe not.
Seems there's a bug that interferes with the way the requestLocationUpdates
minTime parameter is implemented for a GPS. See Sean Barbeau's posts in
this forum at
https://groups.google.com/forum/?fromgroups#!topic/android-developers/eyctELxl9kc
--
You received
I'm really fed up reading about the min time and min distance being a
hint. If there's a complex interaction between our parameters and the
resulting effect, why isn't it documented? Just how the heck does it work?
I'm using the NMEA listener and want to have direct but high level control
over
But doesn't that beg the question what the parameter is there for at
all?
My testing indicates that the value is entirely ignored and always
uses around 1000 ms on a Samsung Galaxy S11, Android 2.3.3.
Why would the Android SDK provide something that looks very useful but
actually delivers nothing?
16 matches
Mail list logo
