Page Comparison

...

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.

Following is an example to illustrate how it works:

...

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 - since start of the current tripto 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)

...

You can switch the default setting using the following steps:

...

What do the events mean?

• Status online: when tracker sent the first message after being offline

• Status offline: when no message is received for 200 seconds tracker is considered offline

• Alarm: see above

• Ignition on: when bike gets switched on

• Ignition off: when bike gets switched off

• Machine moving: when tracker starts moving (see trip algorithm above)

• Machine stopped: when tracker stops moving (see trip algorithm above)

Is there a particular cadence of events when a ride starts?

Typically:

1. “Status Online" when bike is slightly moved

2. "Alarm vibration” when bike is moved more

3. "Ignition on” once bike gets switched on

4. “Moving” once bike rides at least 215 meters or for 130 seconds

What does the Stops report tell us?

...

Both of the above should not happen in an ideal world. Usually this is related to a bad GPS reception:

1. The tracker is in an area with no / bad GPS reception like: indoor parking, tunnel, narrow valley,…

2. The tracker was not properly installed within the bike: PowUnity symbol not pointing outwards or put inside the frame (covered with metal)

In case the tracker was offline for a longer period it will take longer to get the first GPS fix, so the beginning of the ride might will have a straight line (from old location to first fix).

...

There are two ways how the push notification (which triggers the sound) is handled by the app depending on it’s state:

1. The app is in the background (or not running):
   none of our app code is run -> the push is handled only by the OS / browser. In that case the alarm will only sound for a few seconds and then stop - unless the backend / server sends another push because the device is still moving and movement alarm was triggered again.

2. The app is in the foreground:
   Notification is handled by our app code and we start playing the alarm sound in a loop until the user switches if off (by toggling the alarm button).

Related articles

...