Detecting "lack of movement" on GPS device

The comments below your question bring up some good points, especially about interpreting satellite data quality (# of satellites, signal strength), and you could use this information either on the mobile device or on the server to filter out "bad" GPS values. The question comes down to two parts: 1) how do you define a spurious GPS reading, and 2) how do you define a stationary state.

Let's start with a couple of parameters:

• stationary_speed = if the mobile unit is going slower than this, then it's stationary
• too_fast = if the mobile unit is going faster than this, then it has given a bogus GPS reading

It's tricky to calculate these speeds with accuracy. Say that you calculate the speed as the / between the previous reading (at t0) and the current reading (at t1). If the time delta is great, and the unit goes around a curve, then the actual distance traveled will be greater than the calculated distance. Also, if you get two spurious readings in a row, and they are near enough to one another, then you can get unpredictable results.

Once you have the speed, just compare it to your parameters to see if the GPS reading is spurious or if the unit is stationary.

You can do more sophisticated filtering with Kalman filters, but that can be much more involved.

We've managed to tweak the motion sensor data.

Using the motion sensor data, ignition data, and speed reported by the GPS tracker we should be able to tell when a vehicle is moving or not with pretty good accuracy.

Also we've taken a look at the number of satellites, and that didn't look to well. While the number of satellites was lower for a vehicle under a roof, it was still relatively high. 9-10 is the usual value for such a vehicle, while under a roof it drops to 7 (but can occasionally get a signal and go up as well). Needless to say, the number of satellites proved to be less than useful.

You can to use the number of sats used to take the last fix, not the ones in view. Eg. View = 11, Fix = 5 And use the Max DB values of the signal of the strongest sat. This has to be over 30Db to get a decent signal.

The devices we use have a concept of moving/non moving, sensors are : Acceleration, vibration, input voltage, input signal (from key contact) , GPS data. To report on positions like start/stop (it's event based) and direction/distance events the device has to be in moving mode (this is a countdown counter, configurable).

Sensors have the possibility to be combined. No direction/distance events nor timers are being reported while the tracer determines not to be in moving mode. When the sensors involved stop reporting, the timer counts down to zero and then a stop-event is generated + the unit is put in non-moving mode. Until the next time. This way you can separate a starting engine acceleration values to 'put' it in moving mode, and a separate lower threshold for 'keeping' it in moving modus since both are very distinct acceleration patterns.

The units we use will report if a point is been taken with bad sat data, not sure if your hardware does that. We have either a SV_Position or an SV_KeepAlive or SV_TimeAlive. The Keepalive will repeat the exact last value since the GPS cannot update it's tables nor get a accurate fix at all, not even a bad one. The TimeAlive is what you'll see when you are crossing a tunnel or someone has parked in a garage.

One way to also monitor, albeit it's a partly making educated guesses and it depends on the kind of assets you're tracking is the voltage power supply. eg. a device operating at 12.30v is a car who's engine is not running. If you see one that reports 14.2v you know it's alternator is spinning. For 24v vehicles there is a similar pattern to spot.

Hope this gives you some idea's. It all depends a bit on how good the hardware is. The source of your data starts there and all the rest after that is only as good as it is. But I would strongly encourage you to use the units capabilities to do quality distinction instead of doing it all serverside (in hindsight). Once you do like 3000 units you'll need a beefy server to constantly analyse all tracking data, so by then you'll realize that it won't scale.