Adaptive Event Limitation - Revision history

Alexandra at 06:00, 18 August 2020

2020-08-18T06:00:35Z

Alexandra at 05:56, 18 August 2020

2020-08-18T05:56:49Z

Alexandra: Created page with " This mechanism, available from the 40.4 Firmware release, limits the number of events uploaded via cellular on the cloud. All the events are still being stored to the SD card..."

2020-08-18T05:55:56Z

Created page with " This mechanism, available from the 40.4 Firmware release, limits the number of events uploaded via cellular on the cloud. All the events are still being stored to the SD card..."

New page

This mechanism, available from the 40.4 Firmware release, limits the number of events uploaded via cellular on the cloud. All the events are still being stored to the SD card and if necessary, they can be retrieved via the mobile application (Android/IOS).

Event types which are limited are:

:*Shocks
:*Distraction/Drowsiness
:*Safe Distance Warning

The number of events for each type of trigger is dynamically adjusted during a route, using a function which depends on the distance traveled. This limitation is made per driving session (ignition on – ignition off cycle). When a new session begins, the algorithm will be restarted allowing the default 3 maximum events per trigger type and keep increasing the limit with the distance driven.

In a future release we will consider implementing this for a specified time (24 hours for example) instead of per ignition cycle for more hard and precise limitation (for the cases where there are a lot of ignition on-ignition off in a short period of time). For this we will need to store all the events numbers and driven miles across all the routes in that period of time in a local camera database.

The current methodology purpose is to get rid of data traffic for companies which are having excessive number of events (RMS, SSA, etc.). We are waiting to see and analyze the data traffic results of this method combined with the reduction in size of events to decide the future approach of the event limitation.

← Older revision		Revision as of 06:00, 18 August 2020
Line 15:		Line 15:

	[[File:Annotation 2020-08-18 072525.png\|750px]]		[[File:Annotation 2020-08-18 072525.png\|750px]]
		+
		+	This 1st degree function is:
		+
		+	℮ = 3.2 + ∆ * 0.0297
		+
		+	Where:
		+
		+	:*℮ is the number of events uploads available (per trigger)
		+	:*∆ is the route distance since the beginning of the route.
		+
		+	Practically, when you first start the route you have 3 events of each type available for upload, and on every 33 miles the limit increase with 1 event for each trigger. This function stops at 7 maximum events (per trigger) on a session no matter how much you will continue to drive.
		+
		+	'''Example:'''
		+
		+	If the driver has driven 100 miles, and made 3 shocks and 2 SDW’s until now the remaining upload number will be:
		+
		+	::#SHOCKS: 3 (available from the start) + 3 (driven 100 miles and each 33 miles you get another event you can upload) = 6. You already made 3 so you can upload 3 more max
		+	::#SDW: 3 (available from the start) + 3 (driven 100 miles and each 33 miles you get another event you can upload) = 6. You already made 2 so you can upload 4 more max
		+	::#All other triggers: 3 (available from the start) + 3 (driven 100 miles and each 33 miles you get another event you can upload) = 6 upload max
		+
		+	'''Adjustable parameters'''
		+
		+	If necessary, for a client, we can modify the formula, on a specifically trigger (or all) to allow more or less uploaded events or change the hard limit. For this, please contact engineering

← Older revision		Revision as of 05:56, 18 August 2020
Line 13:		Line 13:

	The current methodology purpose is to get rid of data traffic for companies which are having excessive number of events (RMS, SSA, etc.). We are waiting to see and analyze the data traffic results of this method combined with the reduction in size of events to decide the future approach of the event limitation.		The current methodology purpose is to get rid of data traffic for companies which are having excessive number of events (RMS, SSA, etc.). We are waiting to see and analyze the data traffic results of this method combined with the reduction in size of events to decide the future approach of the event limitation.
		+
		+	[[File:Annotation 2020-08-18 072525.png\|750px]]