Does anyone have a list of data types that produced by the apple watch without any additional apps or integrated devices? It must be a subset of these, but I can't figure out which ones
The exact list of data types depends on the model, but the latest Apple Watch models automatically collect data for all of the following HealthKit types:
Active energy
Basal energy
Environmental audio exposure
Headphone audio exposure
Noise notifications
Exercise minutes
Flights climbed
Heart rate
Heart rate variability
Resting heart rate
Walking heart rate average
High heart rate notifications
Low heart rate notifications
Stand hours
Stand minutes
Step count
Walking + running distance
VO2 max
Apple Watch will also collect cycling distance, but only if the user explicitly records a cycling workout. There are also other types of HealthKit data that can be recorded manually by the using the built-in apps on the Apple Watch, such as mindful minutes.
Related
I wish to build a timer with a start button that once pressed begins to monitor environmental decibel levels through HealthKit. And then once a decibel passes a threshold I wish to log event.
Is something like this available through health kit? Can I actively monitor decibel levels of my environment? Almost as how the native Noise app currently works on the Apple Watch. But I wish to gather this data when the user clicks a start button.
If so, how often can I sample this data? Can I get distinct decibel events that occur between each other within less than a second? A half second? A tenth of a second?
I'll start with the question.
Is the BTLE RSSI a good way to indicate two devices proximity to each other or not? does it only work with small devices like fobs etc?
The Issue:
I am currently looking at making an app that will use BTLE and allow connections based on proximity. In this regard it is much like the demo app that apple show in the Advanced Core Bluetooth keynote (When two devices are almost touching they then connect).
As I understand it the proximity is determined based on the RSSI value when the central discovers the peripheral. When I try this however with two iPads the signal seems too strong for this it is also too inconsistent to have an accurate stab at the proximity as it doesn't show very much correlation to the devices proximity.
I have tried the Apple sample code and that is similar in that the devices don't have to be close at all for the information to pass from one to another.
If only there was a way to reduce the signal strength of the peripheral devices advertisement....
Thanks in advance for any help.
The experience of Matthew Griffin matches mine. However - when we can measure for a fair period of time two things have helped us calibrate this better.
We did have to wrap a simple (kalman) filter on the antenna orientation and the IMU to get a rough running commentary though - and this is not very CPU or battery light.
Using the IMU you get a fair idea of the distance/direction of travel - and if this is over a short period of time - we assume the other 'side' is stationary. This helps a lot to get a value for 'current' orientation and 'callibrate current environment noise.
Likewise - do the same for rotations/position changes.
We've found that in general a re-orientation of the device is a better way to get direction; and that distance is only reliable some up to some 30 to 600 seconds after a 'move' calibration' and only if the device is not too much rotated. And in practice once needs some 4-5 'other' devices; ideally not too mobile, to keep oneself dynamically calibrated.
However the converse is quite reliable - i.e. we know when not to measure. And the net result is that one can fairly well ascertain things like 'at the keyboard' and 'relocated'/moved away through a specific door/openning or direction. Likewise measuring a field by randomly dancing through the room; changing orientation a lot - does work well once the receiver antenna lobes got somewhat worked out after a stationary period.
You are entirely correct about RSSI jumping wildly and randomly. You should retrieve your RSSI values every two seconds (any faster and you get a bunch of errors). Throw out the RSSI values that are more than a ~-40 decibel spike and use an aggregate of the past values before you declare your approximate range to the user.
As for your following statement, you are in luck.
If only there was a way to reduce the signal strength of the
peripheral devices advertisement....
The service you are looking for is called the TX Power Service. Implementing this service on your peripheral will allow you to decrease the transmit power of the device. That way you can throttle down the range that the advertisement data is visible from. We unfortunately do not however, have access to this service on an iOS device. But if you are writing your own firmware for a BLE peripheral, this is the service you want.
I've spent the last week dealing strictly with RSSI, trying to use Wifi and Bluetooth LE sensors for location triangulation and for distance conversion.
Unfortunately, what I have found is that RSSI is just too finicky and unreliable to consistently use to determine distance. In theory, the RSSI and distance behave according to the inverse square law (double the distance, and the RSSI will go down a fixed number of decibels), but in practice the RSSI is affected by uncontrollable factors such as weather (dry weather allows RF fields to travel better) and obstacles (any metal objects or humans in the path from one sensor to another will cause attenuation, and any metal objects closely positioned by one of the sensors will cause gain in the signal strength).
There are ways to try to compensate for this. This paper is one of the best papers I read on how to get accurate results, but the bottom line is that is an unreliable method unless you just want a general idea of where the device is.
If I understand well, you are trying to implement similar functionality that to what seen in the WWDC demo and what apps like Bump implement. For that RSSI will be adequate. Test for appopriate threshold values (e.g. >-30) and you will be fine.
I am working on a CoreLocation based application which should show the position of the user on a map.
My current problem is, that the precision of CL is not very good.
I am testing the app in an urban environment, so i am walking through a the streets around our office and see how precise it is. The horizontalAccuracy is usually around 47m - 50m when i am walking, and updates occur randomly between every 10 seconds and 1 minute. The updated position can vary between almost accurate and 20 meters or more off my real position. When i stop and wait for a minute, the position will almost always be correct within a minute, and the precision may rise to 17m.
I have tested this with three iPhone (3G and 3GS) and one iPod Touch(which is less precise).
However, there is a difference in the final usage of the product: The target audience of our product will use it in a rural, open environment without any houses nearby.
Will this improve accuracy?
How accurate can the iPhone get at best in terms of horizontalAccuracy?
Are there any best practices, tips and tricks to improve the precision?
Your problem is not CL, but the urban environment. Buildings block view of the GPS satellites used to calculate location. The more satellites you can see the better the accuracy.
The iPod Touch doesn't have GPS capability and location based solely on WiFi signals it can detect and lookup in an online database. It will probably give poor or no location data when in a rural environment since it depends entirely on nearby WiFi signals.
For more info see:
iphone-gps-performance
iphone GPS Tips and Tricks
The absolute best accuracy you can expect is about 2.5m (8') without WAAS and with SA turned off. You won't get that in an urban environment though, you need a clear sky for that best case accuracy.
I'm making an accelerometer-based app using cocos2d, and I noticed that it's possible to set the accelerometer update interval.
[[UIAccelerometer sharedAccelerometer] setUpdateInterval: (1.0f / 60.0f)];
Is updating the accelerometer very often like this (60 times a second) a significant battery drain?
Given the numbers in the accepted answer the power usage by the actual accelerometer is trivial. Your real hit will come from your app having to process the events and thus making the CPU not sleep more often.
The 3GS has a 4.51 Watt hour battery. Drain from only the accelerometer when running at 100 hz would kill the battery in (roughly) 6000 hours (assuming the 0.75 mW value is correct)
(Also, the iPhone 4 has a 5.25 Watt-hour battery, 4S 5.3 Whr and 5 5.45 Whr, in case you're curious)
According to the LIS302DL accelerometer data sheet, it consumes ~0.75 mWatts of power at an update rate of 100Hz, and 0.0025 mWatts of power when in stand-by mode (i.e., no readings taking place).
So, the short answer is "Yes", but off the top of my head, I can't put those numbers in perspective to give you an idea of, say, "how many minutes of on time" it drains from the battery.
My recommendation would be to do a bit of testing. Find the lowest update rate that provides satisfactory results.
From the Event Handling Guide for iPhone OS:
When configuring the update interval
for acceleration events, it is best to
choose an interval that minimizes the
number of delivered events and still
meets the needs of your application.
Few applications need acceleration
events delivered 100 times a second.
Using a lower frequency prevents your
application from running as often and
can therefore improve battery life.
According to this, the more expensive part of having a high update frequency may be the fact that your application has to process each of those accelerometer events, rather than idling for a longer period.
Also, from the iPhone Application Programming Guide:
If you use the UIAccelerometer class
to receive regular accelerometer
events, disable the delivery of those
events when you do not need them.
Similarly, set the frequency of event
delivery to the smallest value that is
suitable for your needs.
http://www.google.com/search?hl=en&client=firefox-a&hs=7ew&rls=org.mozilla%3Aen-US%3Aofficial&q=iPhone+accelerometer+battery+drain&aq=f&aqi=m1&aql=&oq=&gs_rfai=
My answer would be yes. It does drain battery faster. And 60 times / seconds is excessive.
Is there any way to let's say, user clicks a button, and then he needs to say something to the mic, but only after he finishes to talk to the mic, the app will wait 5 seconds, and then the app will do something. is there any code or example for this? to check if there is an input to the mic or not.
thanks in advance!
If you're recording with AVAudioRecorder, you have the ability to enable metering and get basic power metrics for your current recording. One way to determine silence for a period of time is to sample the average power and peak power over a time period of your choosing (1/2 second to a few seconds). If the ratio remains low enough during that arbitrary period, the input has been relatively quiet and you can end the recording. You can view the docs for that class here. If you're using Audio Queue Services, this may be a little more involved, but the concept is the same.