I have been following android get duration from maps.google.com directions and I seem to be doing okay, but I have a question: does the duration returned in the JSON from google maps adjust for real time traffic?
From the definitions on the google developers documentation for directions api :
duration indicates the total duration of this leg
duration_in_traffic indicates the total duration of this leg, taking into account current traffic conditions
I would take this to mean that no, duration doesn't not adjust for real time traffic.
It's possible to determine the answer to the question empirically by getting the duration at different times of day. I think you'll find it is not real-time based.
The documentation does not make mention of real-time traffic. While that's not conclusive, accounting for real-time traffic conditions would be rather a coup and highly likely to be included.
Related
Requirement: I need to monitor the Twilio account and subaccount usages in near real-time.
Any solution in java, php, python or even curl will do for me.
Twilio provides Usage Records API and allows some subresources which contains Today but that returns all data from the start of that day till the nearest current time. I am unable to find anything in the documents that would retrieve only usages of the last minute or last 10 minutes or even between two time constants. The Usage API accepts two dates but not time.
Hoping someone out there has a solution to offer.
I am currently getting timestamps from accelerometers, magnetometers, and gyroscopes and performing sensor fusion with GPS Location on an android device. I am getting the sensor timestamp using SensorEvent.timestamp and Location.getElapsedRealtimeNanos().
My code is as follows:
Sensor Timestamp
public void onSensorChanged( SensorEvent event ) {
if( event.sensor.getType() == Sensor.TYPE_ACCELEROMETER )
System.out.println( "Acc:" + event.timestamp );
}
GPS Timestamp
public void onLocationChanged( Location loc ) {
System.out.println( loc.getElapsedRealtimeNanos() );
}
My issue is that the timestamps are offset by some arbitrary amount. I know this because all the GPS values are clustered by some offset from the rest of the sensors. Sometimes this offset is in minutes, sometimes hours, sometimes leading and other times lagging. Why does this delay exist in my implementation and how do I fix it?
This is a quick plot of the clustering I was talking about. I sorted the timestamps and timestamps after the sharp disjoint are all timestamps that pertain to the GPS measurements.
In the logs, the data is output sequentially. Message types 1 and 4 pertain to sensor readings, while -1 pertains to GPS. As you can see, the timestamps are not monotonic. The rest of the GPS timestamps are offset from the sensors by a similar amount. Note that this datapoints are from another dataset.
I used the following code to output the time.
System.out.println( SystemClock.elapsedRealtimeNanos() );
After checking the system clock in the hooks, the GPS timestamp is consistent. However the sensor is clearly offset from the SystemClock. The first column is the SystemClock, second column is the timestamp from the respective event object, and the third timestamp is the message type (-1 for GPS, others are IMU sensors).
Things that I've looked into
I've also seen that GPS clock sync is about 10-15 seconds behind, but since I'm using the time from boot, it shouldn't be an issue.
I've looked into this SO question but I don't think it applies because the delay on that issue seems consistent (100 miliseconds) and the magnitude is small relative to what I'm experiencing.
As tempted as I am to use SystemClock.elapsedRealtime() in these event hooks, I know that there is a delay between when the sensors are measured and the events are called. I don't want to introduce any delay/uncertainty into my model.
After doing hours of digging, I have also found lots of android bugs that are a few years old and most are labelled obsolete. I am really stumped. Any light on the issue would be greatly appreciated.
The answer is simple, the SensorEvent.timestamp has an arbitrary zero reference:
It turns out after a bit of Googling (tip o' the hat to StackOverflow, as usual) that the timestamp one receives isn't based off of any particular 0-point defined in the Android OS or the API; it's an arbitrary per-sensor value intended to allow for different measurements from the same sensor to be compared, not for the measurements to be compared to other timestamped events. It's a known issue (bug concerning the documentation; bug concerning the behavior), but as of right now it's the way of the world for Android developers.
Source:
http://fixermark.blogspot.ca/2014/06/quirkiness-of-android-sensor-library.html
My solution is to estimate offsets by adding SystemClock.elapsedRealtimeNanos() into the log and estimating the delay/offset of each sensor.
I am trying to conduct some extremely accurate data measurements. For this, I need to be able to get the current time in microseconds, accurate to 100 microseconds (Or more). I can't seem to be able to find any way on the Android Developer website. Device specific answers are acceptable (I have access to a Nexus 7, so any answers involving that would be awesome).
I had originally thought it possible to use the system sensors which give times accurate to the microsecond, however I have no idea how to set and/or tell if the sensors are accurate. Not to mention whether these event. - SensorManager
Is there any way to get the time in microseconds on an android device that is accurate to within 100microseconds?
you can use System.nanoTime(). according to doc
Returns the current timestamp of the most precise timer available on
the local system. This timestamp can only be used to measure an
elapsed period by comparing it against another timestamp. It cannot be
used as a very exact system time expression.
Returns
the current timestamp in nanoseconds.
From the java doc here you will get some extra explanation of it
I have managed to read the web service to get current time of any given city.
I could get 2 important values from web service, current time (String) and the offset.
Question is
How to set time of any given city correctly?
Option 1:
Read machine/local time
Calculate UTC/GMT time out of machine time
City time = UTC time +/- offset value
But then what happens when machine time is wrong? You will also got
wrong time right?
Option 2:
Read current city time in String (2012-11-24 19:30)
Parse this time value and set it into Calendar
We got correct City time
But how about the next minute? Of course requesting the web service every minute to get current time is not a good solution right? Is it possible to maintain this Calendar instance keep running automatically every minute once we set it?
NB : I'm developing Android clock widget here.
Thanks
Option 1 is far better, in my eyes. Most cell phones have amazingly accurate time as time synchronization is an integral part of GSM and CDMA. Beyond that, I would far prefer a clock to work offline than to require internet connectivity.
If you are worried about ensuring accuracy in the face of incorrect system time, consider placing a call to a web service to get the current time for verification.
This verification could be done in the background, but keep in mind that web services are not the best time sync providers. I would let anything with under 5 minute difference go as it could be due to your server being out of sync or the call taking too long.
I'm trying to make an incentive feature where every 3 hours you will get something free inside my app. However using the
System.currentTimeMillis()
You can easily get around that by just changing your androids time manually to 3 hours in the future and the game will reward you with the free feature. Is there a way to get some kind of time that isn't based off of the system time?
You can use the methods:
SystemClock.elapsedRealtime();
SystemClock.uptimeMillis();
They do not depend on the device clock. If for some reason you can't use them directly, at least you could use them to make a smart validation of changes in the device clock.
good luck.