I'm working with the data generated with the sensor accelerometer. I save every sensor event in sqllite. I don´t have any problem With smartphones like Nexus 5 but with old devices, I think that not all the registers are being recorded in the database because the smartphone doesn´t have enought capacity.
I'm thinking in save all the sensorevent in an array and then save all of them with a transaction, but only for the old devices. How can I know the capacity of a smartphone or at least the year?
Thanks,
Manuel
There are multiple options. For example you might:
You may check for old android Versions like Gingerbread, which are usally old devices
You can get the CPU specs (link)
Do a quick benchmark by yourself. E.g. perform some simple sql tasks and measure the time, when you start your app the first time.
You can check the Device Name via Build.DEVICE (link)
There might be an other way. These are just ideas which came to my mind while reading your question.
Related
Well i have read a lot of answers of similar questions (even if they are old from like 2013-2014) and i understood that it is not possible to know it exactly since android doesnt count the hardware usage as usage of the app, and some other possible problems like services etc.
At the moment I'm trying to test the perfomance of an App using a protocol to reach a goal and the perfomance of the same App using another protocol (not well known by everyone) to reach the same goal, the default android battery analyzer is good for me since both cases are like 90% the same and i know how the protocols work
My problem is that i'm not sure which one is the best to measure the mAph consumed by my App, i know that there are some external apps that shows it but i would prefer using the one of default, I believe this is something important not only for me but for other people who might have to compare different protocols.
I know that i can measure it programmatically and I've done it too, i save the percentage when the app is opened and how much has been consumed until it gets closed, but it isnt an exact measure since while the app is opened some other apps can do heavy work and add some kind of noise of what i'm measuring so i would prefer to use the android's battery analyzer.
Get a spare device. Load it completely, then run the protocol until shutdown without other interaction (no youtube or anything), note the time it lasted. Repeat with the other protocol. Imho that is a fair way to compare. Note that every device behaves differently and it may or may not be possible to transfer this result to other devices e.g. with different network chips, processors or even firmware versions.
For a more fair comparison I think you should compare how the protocols work. I.e. number of interactions, payload size etc. because the power consumption can only ever be an estimate.
I'm working on Sensor fusion with Accelerometer, Gyroscope and Magnetic Field on Android. Thanks to SensorsManager I can be noticed for each new value of theses sensors.
In reality and this is the case for my Nexus 5 (I'm not sure for others Android devices), acceleration, rotation rate and magnetic field are sampled in same time. We can verify it using event.timestamp.
On others systems (like iOS, xSens...), Sensor SDK provides a notification with these 3 vectors in same time.
Of course, when I receive an acceleration(t), I can write some lines of codes with arrays to wait rotationRate(t) and magneticField(t). But if there is a way to have an access directly to these 3 vectors together it could be very interesting to know!
An other question relative to sensors data:
Is there advices from Android team to device constructors to provide data in chronological order ?
Thank you,
Thibaud
Short answer, no, Android doesn't provide a way to get all the sensor readings as it reads them.
Furthermore, the behavior that you've observed with SensorManager, namely that readings from different sensors happen to have the same timestamp suggesting that they were read together - should not be relied upon. There isn't documentation that guarantees this behavior (also, this is likely a quirk of your testing and update configuration), so relying upon it could come to bite you in some future update (and trying to take advantage of this is likely much more difficult to get right or fast than the approach I outline below).
Generally, unless all results are generated by the same sensor, it is impossible to get them all "at the same time". Furthermore, just about all the sensors are noisy so you'd already need to do some smoothing if you read them as fast as possible.
So, what you could do is sample them pretty quickly, then at specific intervals, report the latest sample from all sensors (or some smoothed value that accounts for the delta between sample time and report time). This is a trivial amount of extra code, especially if you're already smoothing noisy sensor data.
There is a workaround for this particular problem. When multiple registered listeners are present in an activty at the same time, timestamp for those event may be misleading. But you can multiple fragment objects into the said activity which have different context's. Then listen to every sensor in these fragments. With this approach the sensor reading timestamps become reliable.
Or listen in parallel threads if you know about concurrency...
Well i have successfully obtained the light value, however, it is EXTREMELY delayed. Approx 3~5 seconds even when using .SENSOR_DELAYED_FASTEST also even when entering 0 as the rate. Its so slow. I have the program check light sensor values upon screen on then change brightness accordingly HOPING it would solve the horrible automatic brightness delay. but after messing around with it, it seems to me that this is simply a flaw in android. It simply cannot update fast enough. I have used getDefaultSensor() but according to android documention this value can be delayed/filtered, but upon reading another post on stackoverflow the getSensorList() and getDefaultSensor() return the same values and that getSensorList() is no different than getDefaultSensor()
The reason for my question is: Is this correct? Is android simply a fail at updating immediatly? its funny cause my Windows MOBILE(not phone) can update immediatly and i loved it. but with all android devices ive seen its the same thing. so is this just a flaw in androids programming? Is there a way for me as an app dev to fix this? or do we have to live with it?
As I know you cannot get it faster. Please take a look on this question and answer: https://stackoverflow.com/a/5060690/1381641
I don't have the solution for your problem, but I do have an explanation for it. The Ambient light sensor has a delay because of the integration time downloads Sensor Box for android from the Playstore.
You will get the hardware ID of your ambient light sensor, then google search it, and you will get a PDF with technical details about that specific model number. Every Android or IOS phone does NOT use the same hardware.
In that PDF, you will get an integration time. It exists to keep the brightness control stable and delayed as well as sensible. If it is low, and you are in a disco your brightness level will keep on flickering. The same for outside, sometimes some shadows make it go up and down if the integration time is low. It will flicker more and will not be stable.
This will also cause harm to the backlight, so instead of taking single values they compile down the values of a big time interval. My integration time was 400ms. This value is sent to the processor, and then the decision is taken.
You could change this value. It is easy, AMD hard boh depends on your expertise like to update this you have to program the ALS unit by opening the phone, connecting a programmer to it, and connecting the pins in the right way. Then sending an 8 bit signal as mentioned in the PDF (if model is programmable).
I can't tell if I'm being respectful and courteous to the user or if I'm unnecessarily handicapping the utility of my app in the name of treating the phone like a china doll.
I have a successful app in the Android Market. One main functionality is that it records sports stats from a game the user is scoring. The current level of detail is fairly basic: a row for each player and a field for each basic stat. However, I could conceivably dramatically increase the detail and level of usefulness of the app if I recorded additional information, blowing this up to numerous relational tables and conceivably thousands upon thousands of records.
My question is, is this a responsible thing to do? Up to this point, I've shied away from it, thinking that "it's just a phone" and "it's just SQLite", but I've never really looked at whether that's a legitimate reason to hold back on doing things that I wouldn't give a second thought to doing on a web or desktop app.
So with that, how much data (very quantifiable, I know) is it reasonable to expect a phone app to do in regards to storing and sifting through database records?
EDIT:
To be clear, I'm not simply talking about adding more fields as I know the impact of that is trivial. I'm talking about going from the level of detail of "This player has 5 singles and 3 homers" to storing information about each pitch that comprised each at-bat that lead to 5 singles and three homers. Obviously this will call for additional tables and conceivably a great many records.
For my masters thesis project at CMU, I worte an Android app that collected roughly 300mb (2.5 Million rows in the main table) of data during one day in sqlite. It drained the battery of the phone in about 10 hours and CPU utilization was at around 50%, but nothing of that had a lot to do with data. We were doing online learning on physiological data coming in over bluetooth with 72Hz. With the math intensive parts cut out, the phone was quite fine and useabel while the service was running. And the 10 hours were mostly due to bluetooth running continously. Without bluetooth, we got about 16-18 hours of continous uptime. Which I don't even get these days on the HTC Desire.
AND THIS WAS ON A G1
I think you're fine if you stay in the Megabytes or maybe low 10's of megabytes. As long as you have a a good design and don't do expensive querys in the main thread. SQLite handles well formed queries quite well, and dumping data into it is REALLY fast.
[edit:] just thought of something: Why don't you provide a second version of your app with the additional fields? More calculation obviously means a bit more battery drain, so I would give users some kind of choice. But my intution is that the performance hog won't really be noticeable.
Sounds like SQLite will do just fine for what you need. I wouldn't hesitate to push it's limits. It's a very well implemented product and should be able to handle what you describe. If you get to the point where your application is handling larger volumes of data (more than 100-200MB), you might want to consider Berkeley DB. Berkeley DB supports the SQLite3 API and provides additional data management capabilities that provide better performance, scalability and reliability than native SQLite, especially when dealing with larger data sets. - Dave
Issue:-
I am developing a application which
needs a new acceleration datum every 5
millisecond.
My Approach:-
I have created a remote service
which only reads the acceleration
data from SensorManager.
I had also set the read rate to
"DELAY FASTEST" while initialize the
SensorManager.
Then i use IPC to communicate too my
main application to get these
reading.
Problem:-
If i put a log inside
onSensorChange() event i receive a
new sensor data every 20 ms time. But i need data every 5 ms.
Question ?
Is there any better method to read
the senor data faster.
Is there any way i can poll the
senor data rather that waiting for
the event handler to trigger the
event?
Please help me to find a better solution to read the data in 5 ms time or poll the acceleration data.
As I understand it, the accelerometer is very noisy and not suitable for fast operations. See the GoogleTech talk on sensor fusion at http://www.youtube.com/watch?v=C7JQ7Rpwn2k for a more authorative explanation and what you can do about it. Short explanation: Use the gyro for high speed events and the acceleromenter to correct the drift.
For people referencing this post today, while I think #robinr has a good point and is very true, that is not an answer, however stackoverflow wont let me comment on it directly.
For answers to the first question reference Native Activity. And. Android does not guarantee data rate, it only makes sure that you get the minimum (or maximum if you requesting too much).
The accelerometer is Not noisy, at least not today. Its just way too good at picking up EVERYTHING. So you need to use some filtering if you want a good accelerometer algorithm. If you have excellent filters, accelerometer is actually preferable to all else because it is usually a lower power sensor, has the highest supported frequency, and is most likely to be available when the screen is off(compared to other sensors).
The caveat to a forceful method of using native and extracting the highest frequency is that your device support will be limited. This is why Android doesn't support direct frequency settings.
In response to question 2; your going to have to throttle your sensor events manually by monitoring the timestamp.
Regarding the speed of the Android SensorManager, I would be more inclined to suspect the speed of the Android file I/O that is generating your log. You might try a benchmark of your sensor read code without writing to the log. Something like logging the current time in milliseconds, then doing 1,000,000 sensor reads, then logging the current time again. You might still have to use the C version to get the data, but at least you'll know definitively where the bottleneck lies.
There are a few issues I can see with this. The first is that you are most likely going to bog down the whole rest of the system if you try to force polling of sensor data that fast. If all you are doing is polling sensors that may be ok, but if you want any kind of user interaction, I am not sure that's going to work. Also, why do you need data that fast? If you're interacting with people there is no way there going to notice a lag of even 100ms.
have you resolved your problem?
i have a similar project, to get sample at least every 10 ms (about 100 Hz), here. But, nothing change in samples that i got, even when i set setEventRate = 10 milisec.
So i think there is any hardware limitation since i've read BMA220 datasheet (my sensor hardware) only provides 62,5 Hz for Orientation Sub-mode.