Re: [Phys-L] accelerometer apps - android version

[John Denker <jsd@av8n.com>]

On 05/09/2016 10:56 AM, Bill Nettles wrote:
> Looking at all the free accelerometer apps available for the android
> smartphones  is worse than inverting a 10x10 non-sparse matrix by
> hand … well, maybe not that bad.
>  But at least with the inversion, I have a plan.

Asking for suggestions from this forum is not a bad plan.
 
> Which app (or apps) do you recommend for 1) data collection and
> transfer  and 2) on-screen examples/illustration?

I am not an expert, but I can relate some observations.  (As the
saying goes, imperfect data is better than no data.)

I have some small experience with this app:   "Sensorstream IMU+GPS"
by Axel Lorenz
  https://play.google.com/store/apps/details?id=de.lorenz_fenster.sensorstreamgps

It can do two of the three main things you might want:
 ++ It can stream data in real time via UDP over wifi.
  This is good for lab work.
 ++ It can log data to a file on the phone.
  This is good for field work.
 -- It does not do any graphics on the phone.

Here's a python program to receive the UDP packets and put the data
into proper columns.
  https://www.av8n.com/physics/phone-sensors.py
It's not great, but it's more complete than the program on the app
website.  Also in that file are some notes about the orientation of
the X,Y, and Z axes.

Beware that the data is noisy.  Here is a plot of time versus time,
i.e. android time versus GPS time:
  https://www.av8n.com/physics/img48/t-versus-t.png
The errors are highly nonrandom, and distressingly large.  I would
have expected errors on the order of milliseconds, but this is a
factor of 30 or 50 worse.

This app has some ridiculous rough edges, including the fact that you
have to type in the IP address every time you use it.

All these apps are kinda new, and the authors seem interested in
suggestions. So if there's a feature you want that's not yet
implemented, you might be able to ask for it.  I would start by
asking for a decent timebase.



> worse than inverting a 10x10 non-sparse matrix by
> hand … well, maybe not that bad.

It's not nearly that bad.
-- Gaussian elimination requires on the order of N^4 multiplications.
-- A simple planning spreadsheet requires more like N·M
 multiplications, where there are N possibilities each with M features.

I would just make a spreadsheet, with one row per product and one
column per feature.  You can define an /objective function/, perhaps
a simple linear weighted sum over features, or at worst a low-order
polynomial.  Then it is a simple matter to find the row that maximizes
the objective.

It could be that App A is better for Purpose A, while App B is
better for Purpose B.  That would require two different objective
functions.