Is there a way to synchronize the timestamps in values meassured by Sensors (e.g. acceleration) (SensorEvent.timestamp) and GPS (Location.getTime()).
SensorEvent.timestamp are the nanoseconds since the device has been booted (local time). Location.getTime() are the miliseconds since1970 (global time).
One solution I had in mind was to calculate the offset between the local time and the global (GPS) time. But the problem is, that the time in Location is the time when the GPS-message arrived at the device, but it takes some time until the GPS-unit (don't know how it is called) of the device calculates the position and forwards it to my application, so I can't calculate at what local time the message arrived. I've read somewhere (can't remember where) that the delay from arrival of the message until it has been processed can be several 100 miliseconds, so I will always have a high offset between GPS-data and data from other sensors, if I algin the local time when the app gets the location-message and the timestamp in the location.
Is there a way to figure out how long it takes exactly to process the GPS-message? Or is there another way to synchronize the meassurements?
The reason why I want to synchronize the values is, that i want to apply a filter (e.g. Kalman-Filter) on the data. For this I want to calculate the offset between a sensor value and a gps-value as exact as possible.
Usually Pulse Per Second (PPS) signals are used to link the time of measurement to the local clock. The GPS receiver toggles a pulse at the moment of measurement. This pulse is then timestamped using the local clock. On Android phones, this is not available.
In addition to the delay caused by processing and transmission time, there might be additional delays caused be filtering in the GPS software. This delay may even be depending on the speed or number of satellites used.
You might be able to 'calibrate' the delay between GPS data and your sensor data by comparing signals from both. E.g.: If you go from accelerating to decelerating, you will see this clearly in you phone's accelerometer and the GPS speed. However, I doubt if you can get a good accuracy for the delay.
You could even add a state in you Kalman filter which estimates the delay.
Related
I am studying the Cordova geolocation plugin for Ionic 2 and want to send the device location to my server when the app is opened.
To keep track of the route of the device I want to send the position all the time to the server. I was wondering how often I should do this. Every time the location changes seems a little too often!?
How do other tracking apps do this?
Granularity of position updates are inversely proportional to the battery power consumed and the network bandwidth used for transmitting the positional information.
I use the following guidelines:
Transmit position whenever the position has exceeded a defined distance 'D'
Transmit position whenever a defined period of time 'T' has elapsed since the last successful transmission
Transmit position when the app starts
Disable transmission when the activity is paused and enable it when the activity is resumed
Always save the last successful transmission (position and time stamp) for future reference
I typically store the defined parameters 'D' and 'T' in a configuration file, making it handy to test how the application performs for different values.
Using coarse GPS for reference, position accuracy is rarely better than 15 meters (without applying GPS corrections). With that in mind, you can set your 'D' value to something between 15-30 meters. If you are tracking vehicles, that distance can be exceeded pretty quickly, in which case a larger value may be preferable to avoid sending too much data.
You can also increase 'D' as a function of your positional velocity (speed). this would increase 'D' the faster the vehicle is moving, thus maintaining a consistent bandwidth usage.
The value of 'T' really depends on your application needs. If a vehicle is sitting idle, then I typically transmit updates once every 5 minutes.
I have used distances ('D') between 30-100 meters. If you are monitoring vehicle positions in an urban environment, you need to be able to pin point where that vehicle is within a crowded street plan. This becomes quite clear if you've ever used a GPS device to navigate in an older city, where the device often gets confused between streets that are in close proximity (i.e., New York, Boston, Montreal, etc.) In this case, a smaller value (> 15m) is preferable.
For added robustness, you might want to add some heuristics into your application. For example, popular after-market GPS devices for automobiles have to implement more intelligence into their applications, in order to snap the vehicle position to a location on a street or road. Otherwise, the vehicle would never show up on the street itself, but rather somewhere in the ditch, or right in the middle of a building on the map.
One example of such heuristics would be to assume that unless the vehicle has reached an intersection, it is still on the same street that was reported previously.
Ultimately, you need to try out different configurations in order to find what best suits your needs.
So I'm dealing with the need for highly accurate, synced times between devices. However, the user might move. I know the phone changes timezones automatically via cell tower. But how/how often does it pull the time?
I'm going to be using NTP protocol to calculate offsets, but it will be an issue if that offset is wrong. For example the app tells the phone to run instruction one at 9pm and calculates the offset so it will go off in sync with another device. An hour later the phone has moved say, 30 miles and thus is in contact with another tower and is about to fire off another instruction.
Will that NTP offset then be wrong because the phone got a slightly different time from a different tower because it pulls the time every time it connects to a new tower? Does it only pull time from the closest tower every arbitrary interval (i.e. 24 hours) unless there's a timezone change? I don't want to be making continual unnecessary NTP calls (e.g. every minute) since the app is cycle intensive and only want to make sure the offset is correct by triggering whenever the device time gets changed.
I am developing an app, where I need (GPS) coordinates every couple of seconds, unfortunately the GPS uses a lot of battery.
Is it possible to get a good estimated position (including altitude) based on the last GPS position(s) and motion sensors from an Android smartphone, for let's say 1 minute?
What algorithms would I need to look into?
This does not work with GPS.
The GPS chip has to track the sattelites all the time, so it makes no difference for battery consumption if you get once a minute or once a second.
Things changes when you only need a position evry 5 minutes, then it could make sense to stop location service, and restart again. (but even that is only a vague estimation).
Finally you have to measure which intervall really saves battery.
bye the way: i can record 8 hours of gps with one fix per second, on iphone 4
I'm writing an app that extends the SensorEventListener interface to listen for changes to the barometer, which I log in a logfile. Before I start logging, I prepend a system time in milliseconds (let's call this Millisecond Timestamp 1, or MT1), and after the logging is finished, I append another system timestamp in milliseconds (let's call this Millisecond Timestamp 2, or MT2).
The SensorEvent has its own timestamp (which I will call Nanosecond Timestamps, or NT), which I also log, between MT1 and MT2.
The problem is this: If the phone goes to sleep during the logging, the SensorEvent rate seems to no longer occur at the rate which I set (for example, SENSOR_DELAY_FASTEST). Furthermore, even though the SensorEvent timestamp is supposed to represent the nanoseconds of uptime since the phone has been rebooted, there are "missing" nanoseconds--the time gap between MT2 and MT1 is often twice or more that between NTN (where N is the number of samples) and NT1.
I've been able to sort of resolve this issue by using PowerManager.Wakelock(), but that results in my app being a huge power hog and seems like a really clumsy hack. Is there any other way to work around this problem?
Sensors are not guaranteed to work if the device goes to sleep, or even if the screen turns off (but the CPU has not necessarily yet powered down). The behavior is undocumented and definitely seems to vary by device.
Either settle for being "a huge power hog" or redesign your app to not require sensor readings except when the screen is on.
Sensors in Android are definitely designed to be used actively by foreground apps, not for long-term logging or monitoring purposes.
I have an application that is a service and what I want to do is have the service kick on when the user is in motion, going faster then 10 mph (or whatever value I want).
What I don't want to do is keep polling the GPS because if I do that, the battery will drain fast.
What are some options that I can use to do this? Realistic options that will not drain the battery would be great! Thank for the help.
One way to minimize having to constantly be listening for location updates (GPS) is you could toggle location updates on/off based on feedback you get from the accelerometer. For example, when you break a set threshold of movement with the accelerometer, you could start listening for location updates and check to see if the device is moving fast enough. If not, you could turn off location updates.
There are optimizations here like "if the accelerometer threshold was broken less than 30 seconds ago, ignore" so that you do not end up thrashing with location updates being turned on and of.
Here is a developer example of Accelerometer Usage.
One idea without GPS would be creating something like a step-counter:
The user has the phone in his trouser pocket.
Every time the phone detects a shake, the user made one step.
You would then need to know his "step-length" and count how many steps he does in one minute. Then, you multiply the count of steps with the length of one step and you have meters/minute
1 meter / minute = 0.0372822715 mph
This would also work with using meters/second:
1 meter / second = 2.23693629 mph
Of course, this only works if the user is actually running/going/riding his bike and it's not very accurate. If you want to check the speed of him traveling by car or boat, this won't work.
One way you could do it is by Inertial Navigation, but this it is doubtful that the built-in sensors are accurate enough to measure anything significant.
Another way would be to reference distances between your device and Wireless Access Points, I was talking to a guy who said this method would be accurate down to a micrometer. However, it presents its own problems. Gets complicated quickly, especially if you're not moving in a straight line, plus you have to have some WAPs.
I think GPS is the most viable option.