iPhone 4S Accelerometer Specifications - iphone

Can anyone help me to find some full specifications for the accelerometer of the iPhone 4S?
I tried to search something over or inside apple.com, however, I wasn't successful.
I would like some full specifications regarding the measurements of the accelerometer: measure scale, how often do the readings refresh, mainly everything about it.

The iPhone 4S uses the STMicro STM33DH 3-axis accelerometer and the STIMicro AGDI 3-axis gyroscope. I was unable to find a specifications sheet or product page.
Sources:
http://www.bigigloo.de/wordpress/wp-content/uploads/2011/04/CoreMotion.pdf
http://www.ifixit.com/Teardown/iPhone-4-Teardown/3130/2

The real accelerometer model is LIS331DLH, see this (emphasis mine)
Of the major design wins, Infineon found itself with the transceiver (marked with 'Apple 338S0626') and the X-GOLD 61x (marked '3833') baseband processor. [However], the most notable of parts though was from ST Micro, who provided not only the LIS331DLH 3-axis accelerometer (incorrectly identified as the STM33DH) [along with] the 3-axis digital gyroscope...
The Chipworks webpage also identified it as the LIS331DLH
The specifications for accelerometer are here.

Related

pARK working on iPhone 3GS

I have been building on top of the iphone augmented reality framework found here
but sadly, on mobiles without gyro (namely the 3GS) it doesn't work (as it states.)
Does anyone know of a fix to make it work with the motion sensors and compass heading instead ? Or would anyone be so bounty-hungry to provide the codes to a such framework ?
I will need a way to either make the vectors work, and if it is not possible, I will need to push through and just use heading only.
CoreMotion do work in devices like 3GS. However, this Framework pARk is for devices with gyroscopes (Runtime Requirements: iPad 2 or iPhone 4 running iOS 5.0 or later)
Gyroscope is a fundamental piece of inertial navigation systems (INS) and thus without it you'll have a severe loss in precision.
Check the paper: "Usability of apple iPhones for inertial navigation systems" for a comparison of the performance of iPhone 3GS and iPhone 4. The author's conclusion is:
However, the tests show that even with the use of filters
it is challenging to build a precise INS using sensors from
common devices because of their inaccuracies and high
error rate. The results show that the iPhone 4 can provide
tolerable results for a short time, but then the deviation
becomes too high because of the error rate. Currently we are
implementing a multi-dimensional Kalman filter to examine
possible enhancements. Furthermore we try to improve the
system by using more sensors from the iPhone 4, e.g. light
sensors and camera.
I believe you should think your app to support only iPhone4 or newer.

iPhone - CMMotionManager properties and iPhone hardware

Do someone know, for each property of CMMotionmanager.deviceMotion and their subproperties, on what kind of hardware they are based on (magnetometer, accelerometer, gyroscope, ...) ?
My question is about HARDWARE, not software.
I need to know from which piece of hardware the CMMotionManager get its values to know on which kind of iPhone my CMMotionManager calls will work. And to write consequent text on my web site.
So what piece of hardware is use to build :
deviceMotion.attitude.roll
deviceMotion.attitude.pitch
deviceMotion.attitude.yaw
deviceMotion.rotationRate (sole gyroscope ? Iphone 4 / 4S with iOS4)
deviceMotion.gravity (sole accelerometer ? So it should work on all iPhones with iOS4)
deviceMotion.userAcceleration (sole accelerometer ? So it should work on all iPhones with iOS4)
deviceMotion.magneticFied (sole magnetometer ? Iphone 3GS / 4 / 4S with iOS4)
Update (hardware):
The deviceMotion property is only available on devices having both an accelerometer and a gyroscope. This is because its sub-properties are the result of a sensor fusion algorithm i.e. both signals are evaluated together in order to decrease the estimation errors. Especially gravity estimation on fast moved devices is still hard work when high precision is demanded (car navigation, satellite positioning,... face the same problems). Popular fusion algorithms are for instance the Kalman filter and derivatives but I guess the CMMotionManager's internal implementation is based on simpler and thus faster algorithms.
Given that, you have only the raw sensor data properties of CMMotionManger accelerometerData and gyroData that are related 1:1 to a sensor - and in case of iOS 5 magnetometerData. deviceMotion and all its sup-properties are the calculated result of the internal implementation of fusion algorithms.
Old answer:
iOS 4.x:
CMMotionManager supports gyroscope and accelerometer. It provides for isXxxAvailable and isXxxActive to query hardware capabilities and determine the status, e.g. accelerometerAvailable and accelerometerActive. Furtheron there is a simple but quite efficient sensor fusion algorithm called DeviceMotion if the device has an accelerometer and a gyroscope on board - compass is not needed and thus not used. Analog to the sensors you use deviceMotionAvailable and deviceMotionActive for getting information.
Magnetometer is only available via CLLocationManager.
I experienced sometimes trouble with deviceMotionActive when the app is getting to foreground again after suspending (got true although DeviceMotion was definitely stopped before).
iOS 5.x:
Magnetometer support is added to CMMotionManager and handled like the two other sensors.
General:
You can use CMMotionManager even on iPhone 3g (with iOS4). You don't have access to CMDeviceMotion but can query accelerometer updates. Thus you have to use low pass filtering to get a gravity estimation and it's far more worse than DeviceMotion.
You should not use the pre-iOS 4 interface UIAccelerometerDelegate.
See the reference
A CMMotionManager object is the gateway to the motion services
provided by iOS. These services provide an application with
accelerometer data, rotation-rate data, magnetometer data, and other
device-motion data such as attitude. These types of data originate
with a device’s accelerometers and (on some models) its magnetometer
and gyroscope.

Can a Smartphone read RFID tags from a distance of few feet (NOT NFC)?

Being a bit more specific: I would like to know whether there's a Smartphone that can detect an RFID tag from few feet away using its original HW (no external devices) and OS capabilities.
Any comment/direction to reading material will be highly appreciated.
I think the answer depends on your use of the word "RFID Tag". In the classic sense, a read-only transponder, equivalent to a bar code, the answer is not yet. There are proposals for 2.4 GHz RFID that could use existing WIFI chipsets to identify nearby objects. Nothing standard or accepted is available.
However, based on the application you describe. One potential answer may be to flip how you are thinking of setting this up. If you just need to know if a certian, unique, person is near a spot in the mall, maybe instead of their phone looking for an RFID tag you need a low cost bluetooth sniffer (connected to a low cost computing board) looking for their phone, via bluetooth MAC addresses, within say 5m. As long as the customer has bluetooth enabled, has signed up for your service and your read points are connected to the internet this approach should cover your use case.
Basically the possibility is very low.
Near field refers the the property of RF fields with very close proximity between the devices. In the case of NFC as it applies here the devices are even closer, in what is termed the "Reactive near-field". Moving further away these properties are lost.
From Wikipedia: "Theoretical working distance with compact standard antennas: up to 20 cm (practical working distance of about 4 centimeters)"
I just found this solution:
http://www.ugrokit.com/
I don't have any experience with it.
Any android device with NFC chip and antenna embedded is capable enough to read RFID tags.

Compass on 3GS is Different than on 4

I have a EMF meter app, similar to the teslameter source code given by apple. the app works perfectly on the 3gs reading the numbers fine but on and iphone 4 it does not work at all. Is there some major difference in the compass hardware?
The app is based on the magnetic readings from the compass
No, there isn't any relevant hardware differences.
The iPhone 4 also has a gyroscope, but it shouldn't alter magnetometer data.
Which behavior do you have? Any data at all?

How accurate is the triangulated GPS of the non-3G iPhone?

Does anyone have any experience with the triangulated GPS used by the non-3G iPhone? How does it compare with 3G positioning? Does the iPhone 3G use triangulation in the event that there is no GPS signal available? Is there anyway to determine the accuracy of the non 3G coordinates? Thanks.
I have done a lot of mobile software with a bunch of different devices including 3G iphones and 3G blackberry's and here is what I have found.
The blackberry and iPhone GPS is really good when you have clear line of sight and at least 9 satellites present. In some dense residential or urban areas you might only get 5-6 satellites which can take a while to converge.
If you do not have a signal, GSM phones like the iPhone will try and find your position using cell tower signal strength but it is NOT as accurate as GPS... not by a long shot.
I have heard, though this has not been confirmed that the iPhone also uses some server side machine learning when it can't find a GPS lock meaning that it takes the average all of the cell towers, plus the average of all the users who have used GPS in your area to try and find your best position. This is sometimes called AGPS or assisted GPS where the GPS information and cell tower strength are used together.
Also, the only thing I can think of for finding the accuracy of the non 3G coordinates would be to programmaticly switch providers in your code, or simply go into preferences and turn off 3G and write an application that does some tests.
The Pragmatic Programmers have a great iPhone SDK book that just added a chapter on using the Location API, so that might be a great place to start.
Hope this helps.
The CLLocation class has the properties 'horizontalAccuracy' (for latitude/longitude) and 'verticalAccuracy' (for elevation).
In addition to cell towers and GPS, locations may also determined by Skyhook Wireless, which has a database of Wi-Fi base station MAC addresses and locations.
When using only GSM towers, it's +/- 500m (it varies greatly, sometimes it's more precise).
If it finds known Wi-Fi network, then it's down to +/- 50m.