Your description is technically in focus in that we are looking at the
same thing, I just want phone to use the accelerometer(s) to emulate 1
meter GPS and compass functions when no GPS or compass is available.

1.) So all the programming involves is: behavior is
f(dx,dy,dz,orientation). The system provides the data from whatever
costs the least. The function is already there on location, but
accelerometer (inertial) estimates were not on the list of location
service providers. This should be on the list with whatever caveats
come with it (like requires consistent orientation since last known

2.) The other thing is that when data is bad and tower location cannot
resolve exactly where the phones are I want the system to present
choices  in addition to precision estimates. The local program can
have stored information about routes and history to  pick from several
possible positions.  This will maintain continuity in the application
whereas having precision suddenly go to a km with no more bearing data
really blows up a pedestrian level program that requires a simulated

3). Also, when comparing two poor signals (think like interpolating
steam tables), the comparison needs to be done before any rounding. I
want the phones to be able to share and compare raw data with each
other without asking the system to make an independent (non-
differential) estimate of where each is. If I am trying to locate
someone and I cannot read a map, all I care about is relative
position.  The system can act like some systems engineer and insist on
giving me only absolute data and throw the baby out with the
bathwater, but it does not have to.

In other words, android location services can be more robust than
systems costing 4 times as much.  This is a difference all customers
will recognize when they do the inevitable side by side comparisons.
Each time that happens Android takes share.

ed (the systems engineer :-)

On Jul 9, 7:05 am, whitemice <[EMAIL PROTECTED]> wrote:
> There are a lot of interesting use cases for sub 1m accuracy and/or
> indoor positioning on a mobile phone – hence I am following your ideas
> with interest.
> Your proposal as I understand it:
> If the communication API (at either the server or the client side)
> gives you access to signal strength and packet delay information, you
> may be able to get some idea of distance (but not direction?).  This
> estimate would become less reliable as more walls and furniture get in
> the path of the signal.
> Communicating with two Wi-Fi transmitters (if this is possible on the
> client side?) with known positions and coverage areas, would give you
> two or more overlapping regions where the handset might currently be
> located.
> By fixing your results along known walking routes and integrating path
> data (from the accelerometer) you might be able to guestimate a user’s
> current position.
> With all these uncertainties, I think claims of sub 1m accuracy are
> overly optimistic (but not unachievable), although such a system could
> have other benefits.
> To the original question: the Android Wi-Fi API has not yet been
> released, so I can’t comment on how well your proposal might work on a
> real device.
> Also, I am also investigating using accelerometers for estimating
> position *inaccuracy* for my Snowball platform, which has
> significantly lower accuracy requirements:http://blog.zedray.com/snowball/
You received this message because you are subscribed to the Google Groups 
"Android Discuss" group.
To post to this group, send email to android-discuss@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 

Reply via email to