Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

But there is a difference in when the server (or the app) detect and show it as a trip (via the /trips API).

The system analyzes positions and switch motion state according to the configuration. Traccar switches state from stopped to moving if a device is reporting motion as true (calculated based on the speed value and the speedThreshold parameter) for more than minimalTripDuration seconds or trip distance more than minimalTripDistance meters. Traccar switches state from moving to stopped if a device is reporting motion as false for more than minimalParkingDuration seconds or the ignition is off (useIgnition eenabled). Only continuous periods can switch the state, any fluctuations reset the detection.

The following parameters are used in the detection algorithm:

  • minimal trip duration - Trips of less than 130 seconds are ignored.

  • minimal trip distance - Trips of less than 215 meters are ignored.

  • minimal parking duration - Parking for less than five minutes does not detected as stop.

  • minimal no data duration - Gaps in reported positions longer than one hour are considered as stops.

  • ignition - Force switch to stop state if eBike is switched off.

  • speed threshold - If the speed is above 0.01 knots, the bike is considered to be in motion.

...

Trip 2 is also detected correctly from row 27 on, rows 24-25 are ignored as fluctuation. Parameters are more than minimal, and it started and followed by positions with zero speed.

...

The second example illustrates a case when the backup battery of BikeTrax is empty, so powered only when the bike is switched on (ignition is on). Then BikeTrax has to cold-start, resulting in a delay in GPS fix. For such cases it is common to start reporting with a speed higher than zero. It is impossible to use same algorithm as in the first example, so additional logic was introduced. Gaps between reporting intervals are detected as stops.

...

The report.trip.minimalNoDataDuration parameter is set to 3600 (one hour). You can see that the speed is never less than the speedThreshold, but the gap (rows 15 - 28) is more than 10 minutes. It is interpreted as a stop. Preceding trip is detected correctly. Following movement period is not detected as a trip because the algorithm cannot determine when it ends. Only full stops or trips are recorded.

Why and how straight lines occur and what does it imply on the status of the tracker?

...

Generally the GPS server supports many different tracker manufacturers with varying use cases, but for us the interesting columns are:

  • Device Name

  • Time - fix time / GPS time. Multiple positions can have the same fixTime if the device sends invalid messages but attributes like alarm change.

  • Latitude

  • Longitude

  • Speed - in knots/hour

  • Alarm - with possible values:

    • vibration - when tracker is moved / shaken

    • movement - when

    • powerCut (bike switched off),, speed,…

    • lowBattery - when backup battery state is getting low

  • Hours - duration the tracker was moving / operated

  • Input - will include the data as received from CAN bus

  • Battery Level - SOC of the backup battery

  • Ignition and Charge - if tracker has external power supply (e.g. bike switched on / off)

  • Distance - to previous position

  • Total Distance - since tracker was created / added to platform

  • Motion - tracker moving yes / no

  • Armed - if the trackers vibration alarm is switched on (this should mostly be true)

...