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.
; We use the 1PPS pulse at work to synchronise remote devices 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 wrote:
>
>> Further, here ar
TC+10, 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 ,
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 co
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?
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.
Despi
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 NM
12 7:52:09 AM 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
42:50 AM UTC+10, lbendlin wrote:
>
> The OEM 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
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 getting
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 t
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
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 th
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
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
