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.

Found and fixed a few corner cases in the new logic. If you have a chance, please try the new preview.

Hi ,
I started testing with the latest release
<entry key='report.trip.newLogic'>true</entry>
I noticed that it cuts trip short ,I tried to play around with below , but they did not help much.

report.trip.minDistance
report.trip.minDuration
report.trip.stopGap

Anton , if you want I can allow access to my dev server to check.

I just need the data, not full access. Need positions, actual and expected trips.

I'll share some example sets tomorrow.

Hi Anton,

I’ve been doing more testing with the new trip logic and wanted to share something I’m seeing pretty consistently.

In my case, with the old logic, the trip start was usually correct, but the trip end was often not.

With the new logic, it’s almost the opposite now: trip end and stops look really good for me, much better than before. But trip start now seems delayed.

In many cases, the trip starts 100 to 400 meters after the actual point where the vehicle was parked. Looking closely, it often feels like it is picking the start from one tracking point later than it should. For it to be perfect, it would need to start one point earlier, so it shows more accurately where the vehicle was parked and where the trip really began.

I’m not sure whether this is expected with the new logic or if there is still something to adjust on the trip start side.

For reference, I first tested it with the default setup, only enabling report.trip.newLogic=true. I also tried changing report.trip.minDistance, report.trip.minDuration, and report.trip.stopGap, but in my case the result stayed basically the same: the trip start is still detected late.

I have tested this on 6.12.0, 6.12.1, 6.12.2, and also the latest preview, and I still see the same pattern.

I’m going to prepare a small positions file and send it to you by email. Hopefully it can help.

Thanks.

This is kids of expected behavior. That's why defaults are lower for the new logic. If you reuse old values, you will get worse results.