On 03/25/2010 01:07 AM, Menion wrote:
Hi guys,
Mike, please, you wrote that you are pretty sure not to do some
direct processing of satellites ephemeris in Java. But my question is,
do you know some method (probably thanks to JNI) how to obtain direct
measure from GPS receiver? I have some imaginations to do
postprocessing comupation above these values in desktop pc, but
firstly I need to save them into some file. Thanks for answer.
So this is only an educated guess -- remember that Android is
just the OS, not a hardware spec -- but it looks to me that given
that there is a NMEA listener in the API now that what's really
going on under the hood is that they're using a GPS chipset and
that those chipsets are, essentially, uarts hardwarewise. That is,
they speak NMEA over a serial interface. The chipset I'm most
familiar with is the MTK chipset (I have no idea if that's what
some of the phones are using) has a limited set of commands it
understands, and can give you a limited set of information
back along with the normal position updates. What these commands
and responses are don't seem to be especially standarized (they
look like NMEA sentences, but they're proprietary).
So the long and short of this is I doubt very seriously that you're
going to find a low level interface to the raw data, and that even
if there were an interface on one chipset, you wouldn't be guaranteed
that it would work across the various phones.
Mike
And for JFrog, I do same as Mike, just throw away measure that
accuracy is worst then your limit. This will filter biggest anomalies.
On Mar 23, 3:43 pm, mike<[email protected]> wrote:
On 03/23/2010 07:23 AM, JFrog wrote:
Rough, yeah. I'll have to look into the best way to throw out
inaccurate values. Otherwise the application tends to look a bit ugly
(inertial navigation). For instance, if I walk by a window while my
application is estimating movements on its own and happens to get a
gps signal for a moment or two, then all of a sudden I get one or two
inaccurate dots come on the screen and my estimated movement for where
the droid is will start at that new GPS location.
I don't know what your app is, but for mine (tracking skiing/riding, etc)
I just filter out points with horizontal accuracy> 100m. This works
just fine for me because I'm interested in the overall dataset, but
I'm not terribly real time sensitive. But I also do some post-processing
to deal with outliers like looking for silly velocities and accelerations.
I had looked into smoothing the data with Kalman filtering, but it
turned out that it wasn't necessary even though it would probably
do a pretty good job.
At first I thought perhaps I would throw away a couple of initial
values, but it doesn't seem as though there is a consistent number of
bad results before receiving a good one. I'll see if there is a way
to wait for a fine grained result related to triggering the
onLocationChanged segment. Perhaps I can even put up a range zone
around my estimated value, and as long as its close I can throw away
any GPS that fall outside that range. That's my current thoughts.
The hdop and vdop are your friends :) Google them as it's the
GPS measures that eventually get translated into meter-based
accuracy. The bad results are based on the satellite constellation
at the time, where the GPS signal processing state is, and of
course noise like multipath, etc. In normal terrestrial environs
it's just a fact of life that the accuracy is going to better at some
times than others. Adjust accordingly.
Mike
Thanks for the input Mike.
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
To unsubscribe from this group, send email to
android-developers+unsubscribegooglegroups.com or reply to this email with the words
"REMOVE ME" as the subject.
