On android, trip end is not detected when underground

[shankari]

When underground, or in other locations where the GPS is unable to have a fix, we keep getting invalid locations. Invalid locations are those with low accuracy. If we don't filter these, we detect a trip end every time we travel underground (e.g. on BART).
Filtering was added as part of
4286d60
and fixed several issues like
#45

But if we do filter them, then we don't detect a trip end even if we are stationary but underground, eg. in Soda 3rd floor.

I can't actually find logs for this right now, so I'll look around some more, otherwise I will just go and sit in the third floor for a while on Friday and get logs to attach here.

[shankari]

Ok so I can't actually find saved logs that support this. So I'm going to have to go the library or to 305 Soda to get out some logs that show this. I do have some logs from my husband when he was complaining about battery drain, but that looks like #71.

Basically, he keeps getting spurious exits but because there's no doze mode, they end after 5 mins. But this happens multiple times a day.

bash-3.2$ grep "05-02.*handleAction" /tmp/loggerDB.tom.onallday.withdate.log

489757,1462204443.99,2016-05-02 09:47:03.987000-07:00,"TripDiaryStateMachineService : TripDiaryStateMachineReceiver handleAction(local.state.waiting_for_trip_start, local.transition.exited_geofence) called"
491240,1462205717.34,2016-05-02 10:08:17.341000-07:00,"TripDiaryStateMachineService : TripDiaryStateMachineReceiver handleAction(local.state.ongoing_trip, local.transition.stopped_moving) called"


491366,1462218166.5,2016-05-02 13:35:46.502000-07:00,"TripDiaryStateMachineService : TripDiaryStateMachineReceiver handleAction(local.state.waiting_for_trip_start, local.transition.exited_geofence) called"
491635,1462218427.33,2016-05-02 13:40:07.332000-07:00,"TripDiaryStateMachineService : TripDiaryStateMachineReceiver handleAction(local.state.ongoing_trip, local.transition.stopped_moving) called"


491660,1462218731.65,2016-05-02 13:45:11.653000-07:00,"TripDiaryStateMachineService : TripDiaryStateMachineReceiver handleAction(local.state.waiting_for_trip_start, local.transition.exited_geofence) called"
491946,1462219038.27,2016-05-02 13:50:18.274000-07:00,"TripDiaryStateMachineService : TripDiaryStateMachineReceiver handleAction(local.state.ongoing_trip, local.transition.stopped_moving) called"


492010,1462228009.63,2016-05-02 16:19:49.630000-07:00,"TripDiaryStateMachineService : TripDiaryStateMachineReceiver handleAction(local.state.waiting_for_trip_start, local.transition.exited_geofence) called"
492332,1462228353.46,2016-05-02 16:25:33.458000-07:00,"TripDiaryStateMachineService : TripDiaryStateMachineReceiver handleAction(local.state.ongoing_trip, local.transition.stopped_moving) called"


492428,1462233873.0,2016-05-02 17:57:32.998000-07:00,"TripDiaryStateMachineService : TripDiaryStateMachineReceiver handleAction(local.state.waiting_for_trip_start, local.transition.exited_geofence) called"
492725,1462234158.95,2016-05-02 18:02:18.953000-07:00,"TripDiaryStateMachineService : TripDiaryStateMachineReceiver handleAction(local.state.ongoing_trip, local.transition.stopped_moving) called"


492789,1462238082.13,2016-05-02 19:07:42.133000-07:00,"TripDiaryStateMachineService : TripDiaryStateMachineReceiver handleAction(local.state.waiting_for_trip_start, local.transition.exited_geofence) called"
494376,1462239536.35,2016-05-02 19:31:56.349000-07:00,"TripDiaryStateMachineService : TripDiaryStateMachineReceiver handleAction(local.state.ongoing_trip, local.transition.stopped_moving) called"

[shankari]

I have attached a log file that illustrates this phenomenon. Before this line, there are very few false points.

230095,1466553067.43,2016-06-21 17:44:07.432000-07:00,LocationChangeIntentService : Current point status = false

Between these two, we have intermixed false and true points

230095,1466553067.43,2016-06-21 17:44:07.432000-07:00,LocationChangeIntentService : Current point status = false
...
231491,1466554658.01,2016-06-21 18:10:38.009000-07:00,LocationChangeIntentService : Current point status = false

Then we have a short streak of all trues

231510,1466554664.86,2016-06-21 18:10:44.859000-07:00,LocationChangeIntentService : Current point status = true
...
231900,1466555191.76,2016-06-21 18:19:31.762000-07:00,LocationChangeIntentService : Current point status = true

And then a long streak of falses

231968,1466555222.73,2016-06-21 18:20:02.728000-07:00,LocationChangeIntentService : Current point status = false
...
234330,1466559934.45,2016-06-21 19:38:34.450000-07:00,LocationChangeIntentService : Current point status = false

After which we return to trues

234346,1466559951.83,2016-06-21 19:38:51.828000-07:00,LocationChangeIntentService : Current point status = true
...

loggerDB.shankari.library.trip.withdate.log.gz

[shankari]

We should generate the tracking_error transition in that case, which will cause the FSM to go to the start state.