I'm looking for a way to turn timestamp found on CoreMotion events into proper, high precision "wall date-time". I want to correlate events on iPhone and Apple Watch, so need to translate those timestamps to the single domain.
I tested several approaches on internet, like this: https://stackoverflow.com/a/53250802. Which gives utterly wrong results.
And this
extension TimeInterval {
static var bootTime = Date().timeIntervalSince1970 - ProcessInfo.processInfo.systemUptime
var unix: TimeInterval {
return (TimeInterval. bootTime + self)
}
}
which seem to work on first sight. My tests shown that over time, there is increasing discrepancy between result unix TimeInterval:
In this picture you can see sessions that gather events. Single session events has the same color. On upper line you see watch events and on lower phone events. We see that it seems like timestamp on watchOS advances slower then on iPhone. This looks like timestamp might be connected to processor cycle count?
My question is: How to translate CoreMotion timestamps into Date in proper fashion both on iPhone and watchOS?
This is actually correct solution.
extension TimeInterval {
static var bootTime = Date().timeIntervalSince1970 - ProcessInfo.processInfo.systemUptime
var unix: TimeInterval {
return (TimeInterval. bootTime + self)
}
}
My problem with lagged timestamps on watchOS was connected to cluttering processing queue, so event handlers was lagged over time more and more. For some reason, MotionManager does not react to stopMotionDeviceUpdates() and I was getting those over and over again, despited the fact, I turned it off. I just tried to process too much data - I increased sensor frequency to 1/100.
Related
I've been playing with Core Motion's framework lately and while trying to get more juice to come out of the limited CMAltitude class just stumbled with some weird data at the end of the call. So to recreate if you call up:
import UIKit
import CoreMotion
class ViewController: UIViewController {
let corey = CMAltimeter()
override func viewDidLoad() {
super.viewDidLoad()
self.getter()
}
#objc func getter() {
corey.startRelativeAltitudeUpdates(to: OperationQueue.main, withHandler: { (altitudeData:CMAltitudeData?, error:Error?) in
print(String(describing: altitudeData.unsafelyUnwrapped))
Just for the visual purposes doing this really scratchy thing will respond with:
Altitude -0.589237 Pressure 101093.882812 # 2377.566172
Altitude -0.618303 Pressure 101094.234375 # 2378.602637
Altitude -0.618303 Pressure 101094.234375 # 2379.640150
Altitude -0.620945 Pressure 101094.250000 # 2380.678124
Altitude -0.628872 Pressure 101094.343750 # 2381.714421
What I would like to know is the last part # 2381.714421, it looks like seconds but actually I'm not really sure, when comparing with a timer, and with boottime time_t that number start +4 seconds, after some time of inactivity it drifts and becomes less time than boottime.
Does it drifts away because of app inactivity?
But how come that it starts with more time than even boot-time?
Can anyone explain what's going on?
CMAltitudeData inherits from CMLogItem, this is where the last field, timestamp is coming from. According to the documentation, timestamp should match the amount of time in seconds since the device booted.
However, according to this question on SO the boot time can indeed drift slightly and it seems that timestamp doesn't simply copy time_t at each measurement, but rather it copies it at the first measurement and after that it just increments it based probably on a different Timer. Comparing to a Timer is not a good idea, since Timer runs on a runloop, so it only works while your app is in the foreground and even then it isn't really precise.
I've developed an iOS app that collects data from both the phone's accelerometer and gyroscope, and it should process some data and send it over to the cloud.
The issue is that the CMAccelerometerData for ex. is based on CMLogItem which stores the timestamp as 'the amount of time in seconds since the phone booted' (apple documentation).
In order to find the real time in epoch (seconds since 1/1/1970) i tried to use NSProcessInfo().systemUptime, but it turned out that this value isn't accurate in some cases and gave me an offset of up to few hours!
In some posts it's mentioned that the uptime parameter is affected by system sleeps, and that could be the issue for these offsets (i must mention that when debugging there's no offset at all).
Any idea how can i get the timestamp of a CMLogItem?
(even getting a 'close enough' timestamp is enough, i can skip the milli-seconds accuracy...)
Thanks in advance!
If I've understood your question correctly, CMAccelerometerData and CMLogItem are not the types you need to work with.
CMSensorRecorder.accelerometerData(from:to:) returns CMSensorDataList, which allows to iterate over CMRecordedAccelerometerData objects, and each of them have startDate: Date parameter.
Additionaly, following extension will make iteration over samples easier:
extension CMSensorDataList: Sequence {
public func makeIterator() -> NSFastEnumerationIterator {
return NSFastEnumerationIterator(self)
}
}
SO basically all is in the title. I've searched quite a lot, but didn't find any right solution which doesn't require internet connection.
If the user changes time in settings - i can't find real time since last launch.
I need that for my game, in it for every hour, even when you don't play the game, you get some coins.
If the user changes time in settings - that affect the time in NSDate() and user can cheat with coins.
So save the NSDate() to user defaults on app launch. The next time the app comes to the foreground, or gets launched again, get the current NSDate and subtract the saved date from it. That will give you the number of seconds between the two dates. Calculating hours from seconds is a simple matter of dividing by 3600. – Duncan C just now edit
EDIT:
Note that in newer versions of Swift (starting with Swift 2?) Most Foundation classes were defined as native Swift classes without the NS prefix. For newer versions of swift, replace all occurrences of NSDate with Date in the above.
Also note that in iOS ≥ 7.0, the Calendar has some methods that make this sort of calculation neater and easier. There's a new method dateComponents(_:from:to:) that lets you calculate the difference between 2 dates in whatever units you want. You could use that to calculate the seconds between the 2 dates more cleanly than calculating seconds, as outlined in my original answer. Calendar methods also tend to handle boundary conditions like spanning daylight savings time, leap seconds, etc.
Consider the following Swift 4/5 playground code:
import UIKit
let now = Date()
let randomSeconds = Double.random(in: 100000...3000000)
let later = now + randomSeconds
if let difference = Calendar.current.dateComponents([.second],
from: now,
to: later)
.second {
print(difference)
Try this.
Step 1. When user exits game. Set a NSUserDefault with current time.
Step 2. When app launches, in your appDelagate file, get this value.
Step 3. Calculate diff between and award coins accordingly.
I want to do a sleep analysis for the user in my app.And I think the CoreMotion Framewrok should help.
func queryActivityStartingFromDate(start: NSDate!, toDate end: NSDate!, toQueue queue: NSOperationQueue!, withHandler handler: CMMotionActivityQueryHandler!)
So I use the API above to get the user motion data in the last 7 days.And Now I get a list of CMMotionActivity Object.
And My question is how to calculate the user sleep status from these thousands of CMMotionActivity Object.Is there any algorithms? Or any other way to achieve sleep analysis.
Many Thanks!
CMMotionActivity includes a stationary property which might be useful in your case.
Look for contiguous periods of inactivity, paired with location, timezone & CMDeviceMotion data you should begin to detect patterns in the dataset you have. use statistical variation to define thresholds and fine-tune your results.
Caveat, you will make assumptions which might not be true. Some people sleep in moving vehicles for instance.
I found this pdf useful ftp://ftp.tik.ee.ethz.ch/pub/students/2010-HS/SA-2010-26.pdf
a relatively simple question that I've not been able to find a clear answer to. My app is more complex, but answering this question will suffice.
Suppose you're writing a stopwatch app. When the user taps "start", the app stores the current date and time in startTime:
startTime = [NSDate date];
When the user tapes "stop", the app stores the current date and time in stopTime:
stopTime = [NSDate date];
The duration is calculated by:
duration = [stopTime timeIntervalSinceDate:startTime];
and is displayed with something like:
[durationLabel setText:[NSString stringWithFormat:#"%1.2f", duration]];
The typical durations that my app is timing range from 2 to 50 seconds. I need accuracy to 1/100th of a second (e.g. 2.86 seconds).
I'm assuming that there is some protocol that iOS devices use to keep their clocks accurate (cellular or NTP sources?). My concern is that between starting and stopping the stopwatch, the clock on the iOS device is updated which can result in a shift of the current date/time either ahead or back. If this were to happen, the duration calculated would be inaccurate.
I've seen a few posts relating to timing methods for purposes of improving code efficiency. Some suggest using mach_time.h functions, which I'm not familiar with. It's not obvious to me which is the best approach to use.
Is it possible to disable iOS from updating the date & time? Is mach_absolute_time() unaffected by iOS clock updates?
Many thanks!
Tim
You are correct in thinking that CFAbsoluteTime and its derivatives (NSDate dateand so on) are potentially skewed by network updates on 'real' time. Add that to the fact that NSTimer has an accuracy of 50-100ms and you have a timer that is not suited to the most critical of time-sensitive operations.
The answer to this problem seems to be CACurrentMediaTime.
It is a member of the Core Animation group, but there shouldn't be any problem integrating it into non-animation based applications.
CACurrentMediaTime is a wrapper of mach_absolute_time() and makes sense of the "mach absolute time unit," which from my understanding is no fun to tinker with. mach_absolute_time() is calculated by running a non-network synced timer since the device was last booted.
There is relatively little information on CACurrentMediaTime but here are some sources and further reading:
Apple's sparse documentation of CACurrentMediaTime
Stack Overflow - NSTimer vs CACurrentMediaTime()
http://bendodsonapps.com/weblog/2013/01/29/ca-current-media-time/
http://blog.spacemanlabs.com/2011/09/all-in-the-timing-keeping-track-of-time-passed-on-ios/
http://forum.sparrow-framework.org/topic/accurate-timer
Note: If you do use CACurrentMediaTime, make sure you include and link the QuartzCore.framework
Check out this here. I would say forget about the current time check and use a precision timer since it won't rely on the current time but instead uses an interval.