Hi, I think you could still extrapolate (average) speed for some trip with intermittent GPS signals.
If you get a GPS fix at the start of the journey and then at the end you can calculate an average speed based on the time duration and straight line distance between these points, any additional points (GPS or course grained towers/wifi/skyhook) during the journey would be a bonus to increase the accuracy of the speed and distance calcs. This depends on whether you actually require real time speed ? Regards On Jan 13, 5:37 pm, Bob Kerns <[email protected]> wrote: > I've never gotten around to experimenting to see just how good you CAN > get -- but there are some reference points that should help > considerably. > > * Gravity > * The magnetic field > * Any period of low acceleration noise in the vicinity of about 1 g > total acceleration probably indicates it has been set down on a > surface (or in the original scenario -- the car has come to a stop). > > There other possibilities in other situations: > * Camera data can indicate relative motion > * Acoustical echoic signature and ambient sounds > * Wifi transmitter signal strengths > * 3G signal strengths. (Hey, I'm outdoors, maybe try GPS again!) > * Sonar! > > A typical android device has more senses than humans. We synthesize an > understanding of our location and environment via a process of sensor > fusion. There's more opportunity for this sort of thing on Android > than Nintendo, as there's more processing power available and more > sensors to gather information -- especially when connected to a power > source or otherwise on a larger power budget than a cell phone. Look > at Dempster-Shafer Theory and Kahlman filters for techniques to handle > this sort of process. > > On Jan 12, 5:10 pm, keyboardr <[email protected]> wrote: > > > > > > > > > I know Nintendo originally tried to use accelerometers to figure out > > where it was pointing, and while that's theoretically possible, in > > practice the accuracy just isn't good enough. The acceleration most > > of the time is small enough that even the slightest error will throw > > the whole calculation way off, and since you're relying on all of your > > previous results, errors get compounded over time. That's why > > Nintendo switched to an IR camera setup. > > > On Jan 12, 7:22 am, cellurl <[email protected]> wrote: > > > > couldn't you use the accelerometer? > > > Integrate that? Use time. s=Integral(a dt) > > > If that doesn't work, look to skyhook wireless! > > > -cellurl > > > > On Jan 12, 8:20 am, Brill Pappin <[email protected]> wrote: > > > > > Well you pretty much need distance traveled over time to find speed, > > > > so anything you can do to determine distance travelled should allow > > > > you to calculate the speed. > > > > > For instance you could use cell tower location, but I wouldn't class > > > > it as even remotely accurate. > > > > If you want to give an actual real value, your going to need the > > > > accuracy of the GPS unit. > > > > > - Brill Pappin > > > > > On Jan 11, 11:13 pm, darrinps <[email protected]> wrote: > > > > > > All the examples I see use GPS, and I have that working just fine but > > > > > I've noticed that every time I'm in a car, that unless the phone is > > > > > close to a window or the windshield the GPS does not work so... > > > > > > I thought that there should be a way using course grained location > > > > > between cell towers. Does anyone know if this is possible and if so > > > > > might know where I could find some sample code please? > > > > > > Thanks! > > > > > > Darrin -- 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
