New trip and stops logic testing

We're working on a new implementation for trips and stops detection. Instead of the old logic that was using speed values and time, we now use distance and time. It should solve some common problems.

We need some help with testing the initial implementation. You can get a preview version from here:

https://www.traccar.org/preview/

Then you need to set report.trip.newLogic to true in the configuration file.

The new logic will apply to motion events and fast reports only for now.

Please try and provide feedback.

Another update. There were some issues and failing corner cases that should now be fixed.

I will start testing this tonight.

Question: To compare the results is it okay to use server.forward , I assume it forwards all data right? so I can have the primary server with existing trip and stop logic and secondary server can run the newLogic.

Yes, it should be fine.

Hi Anton,

I tested the current preview build (as of 2026-01-26) with report.trip.newLogic true. In my case the results were negative when generating Trips from historical data: it repeatedly creates false trips and, in multiple instances, produces negative durations where the trip “end” timestamp is earlier than the “start”.

Example:

• Start: 2026-01-28 10:05
• End: 2026-01-28 08:05
  => negative duration

This affected most of our customers, so I had to urgently rollback by setting:
<entry key="report.trip.newLogic">false</entry>

As soon as I disabled newLogic, the negative-trip issues were immediately resolved.

Because it was a production incident, I reverted quickly and couldn’t extract enough samples/logs to help analysis.

Thanks.

1. Would you be able provide some data samples? I mean raw positions or logs.
2. Are your devices reporting data in the right order by timestamp?

Hi Anton,

I am also noticing with (version: 27/01/2026), when <entry key="report.trip.newLogic">true</entry> is enabled, the trip reports have extra trips present in the report (see below). The trip reports appear to report the additional trips when devices are using the Osmand protocol. Other protocols appear to report consistently when comparing the new logic to the old logic. I am putting this down to the fact that many Traccar Client trips tend to have a less exact motion state (e.g. transition in_vehicle to on_foot), as compared to hardware GPS trackers.

Below is an example of using an "Old Logic" trip report verses an "New Logic" trip report for the same time period. This report is of a friends trip to work this morning. The device used, was an iPhone running Traccar Client 9.7.1 (116).

Old Logic: <entry key="report.trip.newLogic">false</entry>

1. Trip from home to primary workplace (in vehicle).
2. Trip from primary workplace to secondary workplace(in vehicle).

New Logic: <entry key="report.trip.newLogic">true</entry>

1. Trip from home to primary workplace (in vehicle).
2. Movement within primary workplace (on foot).
3. Movement within primary workplace (on foot).
4. Movement within primary workplace (on foot).
5. Trip from primary workplace to secondary workplace (in vehicle).

The configuration settings in traccar.xml file.

<entry key='report.trip.newLogic'>true</entry>
<entry key='report.trip.minDistance'>500</entry>
<entry key='report.trip.minDuration'>300</entry>
<entry key='report.trip.stopGap'>3600</entry>

<entry key='report.trip.minimalTripDistance'>1000</entry>
<entry key='report.trip.minimalTripDuration'>300</entry>
<entry key='report.trip.minimalParkingDuration'>900</entry>
<entry key='report.trip.minimalNoDataDuration'>3600</entry>

AussieTraccar is it possible to share raw data? You can email directly if you don't want to post publicly.