Location Services - what timezone does the time property return in

Hardware (GPS, accelerometer, etc.)
#1

It appears from my captured data, that the returned timestamp is using GMT -8 (PST).  Does anyone know if this is correct?  And is there any way to have it returned as GMT?  (yes, I know I can convert it, if it is always PST)

I’ve also noticed that the speed property doesnt initially get set until, I am “assuming”, the satellites have been acquired.  Is this a “safe” assumption, and I can ignore the data prior to that point? (data with a speed of 0)

and - I am setting the threshold to 25 meters, rather than adding/removing the event listener - to help with the battery drain.  Doing this, I know that the satellite acquisition process is taking place since we are continually getting location events.  If I go back to removing and re-adding the event listener, does the acquisition continue to take place when the listener is removed or is it stopped and restarted when the listener is re-added?  I’d prefer to programmatically set the sample rate, but it appears to take longer to get “good” data.

Thanks in advance

#2

I would assume that the physical data from the satellites would be in GMT, but most operating systems will display dates to you in local time.

It takes time to acquire the satellites. When the system starts up it gets GPS data from any WiFi systems it can talk with. WiFi systems don’t convey speed or altitude. You won’t see those values until you have GPS connectivity.

It takes time to connect to the GPS signals. Switching on and off most likely needs a new acquisition of signal. 

Rob

#3

Thanks, Rob.

I thought that it would be giving GMT as well, but when I started comparing it to my own GMT timestamp I was consistantly running just under -8 hours off - which pointed me to PST.

Looks like I should use the threshold setting to save the battery, backing it up with timer to give the appearance of a sample rate in order to avoid having to reacquire.  Would setting the threshold to varying levels based on speed muck something up internally?

Any suggestions on where to look for more detailed info on this?  The docs under location services are pretty thin.

Thanks

#4

There is a lot of magic with Location Services.  You will just need to experiment.

Rob

#5

Hey, Rob.  Thanks for the response.  One last question here.  The system.setLocationThreshold method ties to one of the two location variables (minDistance and minTime) recommended in the Android docs for managing battery life.  The minTime parameter sets the minimum time between firings and is ANDed with the minDistance.  Having the ability to set this would eliminate the need for adding/removing the listener every n seconds - and since the engineers implemented the minDistance, I’m surprised they didnt implement this as well.  OR did they, and I just cant see it?  :)

thanks

Dave

#6

Do you have a reference to the AND’ing your talking about?

Thanks

Rob

#7

My bad, I think.  I was not referring to ANDing in an AND/OR bitwise sense.   The requestLocationUpdate(provider provider, int minTime, float minDistance, listener listener)  method in the Android toolkit, which I think that the combination of the SDK system.setLocationThreshold(minDistance) and  Runtime:addEventListener(“location”, listener) methods are mapped to - uses a combination of the minTime AND minDistance as a set of rules to balance response vs battery life.  Ultimately, the build process maps the SDK to Java for the APK, so I assume that it eventually gets to the requestLocationUpdate method, using the values set either as a default minDistance (0) and the default minTime (0) or set with system calls.  The minDistance can be set with the system call.  The listener is set with Runtime:addEventListener().   It appears that the whole add/remove listener concept (and the effect it has on signal acquisition) can be eliminated with a system.setLocationTime(minTime) method.

Thanks

Dave

#8

Can you provide me a URL to these Android APIs?

#9

https://developer.android.com/reference/android/location/LocationManager.html

Public Methods: requestLocationUpdates()         5 variations of the method

thanks

Dave

#10

@Rob,

Any thoughts on this?

Dave

#11

Actually on Android we hard code the minTime to be 1000 and if I understand correctly, we are not passing in a minDistance. We would need a feature request for this filed. Go to http://feedback.coronalabs.com and create an entry and see if you can get it voted up.

Thanks

Rob

#12

Thanks, @Rob.    Will do.

If you are not passing in a minDistance, what is happening with the system.setLocationThreshold()

Dave

#13

I would assume that the physical data from the satellites would be in GMT, but most operating systems will display dates to you in local time.

It takes time to acquire the satellites. When the system starts up it gets GPS data from any WiFi systems it can talk with. WiFi systems don’t convey speed or altitude. You won’t see those values until you have GPS connectivity.

It takes time to connect to the GPS signals. Switching on and off most likely needs a new acquisition of signal. 

Rob

#14

Thanks, Rob.

I thought that it would be giving GMT as well, but when I started comparing it to my own GMT timestamp I was consistantly running just under -8 hours off - which pointed me to PST.

Looks like I should use the threshold setting to save the battery, backing it up with timer to give the appearance of a sample rate in order to avoid having to reacquire.  Would setting the threshold to varying levels based on speed muck something up internally?

Any suggestions on where to look for more detailed info on this?  The docs under location services are pretty thin.

Thanks

#15

There is a lot of magic with Location Services.  You will just need to experiment.

Rob

#16

Hey, Rob.  Thanks for the response.  One last question here.  The system.setLocationThreshold method ties to one of the two location variables (minDistance and minTime) recommended in the Android docs for managing battery life.  The minTime parameter sets the minimum time between firings and is ANDed with the minDistance.  Having the ability to set this would eliminate the need for adding/removing the listener every n seconds - and since the engineers implemented the minDistance, I’m surprised they didnt implement this as well.  OR did they, and I just cant see it?  :)

thanks

Dave

#17

Do you have a reference to the AND’ing your talking about?

Thanks

Rob

#18

My bad, I think.  I was not referring to ANDing in an AND/OR bitwise sense.   The requestLocationUpdate(provider provider, int minTime, float minDistance, listener listener)  method in the Android toolkit, which I think that the combination of the SDK system.setLocationThreshold(minDistance) and  Runtime:addEventListener(“location”, listener) methods are mapped to - uses a combination of the minTime AND minDistance as a set of rules to balance response vs battery life.  Ultimately, the build process maps the SDK to Java for the APK, so I assume that it eventually gets to the requestLocationUpdate method, using the values set either as a default minDistance (0) and the default minTime (0) or set with system calls.  The minDistance can be set with the system call.  The listener is set with Runtime:addEventListener().   It appears that the whole add/remove listener concept (and the effect it has on signal acquisition) can be eliminated with a system.setLocationTime(minTime) method.

Thanks

Dave

#19

Can you provide me a URL to these Android APIs?

#20

https://developer.android.com/reference/android/location/LocationManager.html

Public Methods: requestLocationUpdates()         5 variations of the method

thanks

Dave