Click here to get the description of the new Munic Box 3

Click here to get an overview of the standard available fields

Munic.Box is connected to your car and monitors in real time a large numbers of parameters such as position, acceleration ...

Fields

Munic.Box monitor extensively the states of the vehicle and the event of driving, each data is stored in fields.

Below are defined the different type of data

• Journey data
  Munic.Box integrates the notion of Journey, several parameters are then accumulated and recorded at the end and the start of a trip.

• GPS
  Using the internal GPS, the OBD dongle offers multiple location based services such as the acquisition of speed, heading, mileage.

• Driver behaviour data
  Thanks to its in-built accelerometer, the device helps you understand how your vehicles are driven. By detecting brutal acceleration, deceleration and cornering the device can send you precise data on your driver’s style.

• Engine & car diagnostic data
  Munic.Box also includes a ready-to-use OBD protocol stack. It gives you access to all standard car diagnostic information such as engine RPM, speed, mileage, fuel consumption, Vehicle Identification Number (VIN), and more...
  No specific OBD knowledge is required!

Field description

Fields contain the following property:

• name - Name of the field
• field - Integer - ID of the field
• field_type - Type of the field. unknown | boolean | integer | decimal | string | base64
• size- Maximum size of the field in bytes
• ack - Does this field need to be acknowledged? If left blank (null), no ack is required, if 0 an ack is sent at once, if a positive integer, the ack is sent within the time specified (in seconds).

Below is an example of Field:

{
  "field": 8,
  "name": "GPS_SPEED",
  "size": 3,
  "ack": 1,
  "description": "Stores the last valid speed of the GPS in 1/1000th knots.",
}

The possibility for the user to create its own fields is restricted, please ask our support for more details.

Ignition state

Munic.Box monitors the movement and the RPM of the vehicle and then detects if the engine is running or not. Please note that this simulation of ignition is not valid for hybrid and non OBD compliant vehicles.

Movement state

Using the built-in accelerometer, the OBD-II dongle is able to detect every movement of the vehicle. The movement state is activated, when movement is detected during more than 1 minute (to prevent glitches due to unrelated vibrations).

Journey

The definition of journey is based on the ignition (engine running or not) detection. A journey starts when ignition switches from OFF to ON, a journey ends when ignition switches from ON to OFF.

With MorpheusSDK, more specific journey definition can be developed.

Idling & Tow away

In combination with the beginning and the journey' end, Munic.Box is also monitoring the movement of the unit (if the accelerometer detects a movement or a non movement for more than 2 minutes), thus enabling the detection

Vehicle state

The different vehicle states are described in one field, MDI_VEHICLE_STATE, described below:

Journey Fields

Several data are accumulated based on the beginning/end of a journey. Here are a list:

Based on the built in 40 channels GPS receiver, GPS position are sampled every seconds and each recorded information is timestamped and positionned with a GPS frame.

Each of these parameters is computed using valid GPRMC frame (GPS).
Every data sets is sent with the position of the recorded place: longitude and latitude fields.

Mileage

Using the GPS position, Munic.Box is calculating the distance travelled by the vehicle. This mileage is cumulative and is never resetted.

OverSpeed

By monitoring the speed given by the GPS, Munic.Box is able to detect overspeeding event. Below is the configuration of this module:

Feature

Driver behaviour data is sent from the device each time a pattern is matched. Each event is identified by an id (BEHAVE_ID) and is sent with some meta data.

Available patterns

In the current release of the eOBD dongle, you have access to 4 different patterns. Through the Application Store, you will soon be able to get the possibilty to create your own patterns.

Available patterns and their IDs (the value available for BEHAVE_ID) are described below:

Data associated with patterns

And the meta-data of the behaviour frame associated with each event below:

Pattern configuration

Patterns are data mined pieces of information allowing to differentiate a simple brake from a harsh brake.

As a usual driver behavior is all about maintaining speed around the limitation. So, any specific behavior such as a strong deceleration that lasts a short amount of time can be interpreted as an harsh breaking. In short, a pattern is made of several parameters:

• Speed and acceleration on each axis at entry
• Speed and acceleration on each axis at peak
• Speed and acceleration on each axis at exit
• Pattern total duration

These parameters in fact define thresholds to decide when triggering a driver behavior event is relevant.

In the current release of Munic.Box, you have

CrashSensor

Munic.Box integrates a crash detection module. Upon detection, the following field is retrieved:

This advanced algorithm, certified by insurances and homologation centers, is highly configurable.

CrashRecorder - access restricted

Munic.Box can store 16 crashes in its circular buffer. Each crash can be retrieved as a JSON Array:

Here's a sample of output :

{
    "severity": 0,
    "id": 9,
    "data": [
        [290445, 2896, 1424, 17520],
        [290447, 1280, 1664, 17776],
        [290450, 1520, 976, 17088], ...
    ],
    "calibration": [
        [0.0065379143, 0.995234, -0.09729508],
        [0.99302, -0.017920008, -0.116576575],
        [-0.11776447, -0.09585382, -0.98840475]
    ],
    "referenceTime": 292,
    "timestamp": 1369232498,
    "v": 3,
    "gpsData": [
        [1369232494, 288990, 236670, 4878356, 0, 0, 111497, 0.9430000185966492, 1.3890000581741333, 1.0210000276565552], ...
    ],
    "pos": 1972,
    "oneG": 16384
}

Feature

With Munic.Box is able to access through the OBD some information about your vehicle. Based on this, Munic.Box will calculate

Fields

Protocol supported

In the current release, Munic.Box is supporting the following protocols:

• CAN
• KWP2000
• ISO9141
• J1850 PWM and VPW will be available soon

Configuration

However, the fuel data calculation needs to be configured since it depends on the type of vehicle. Here are the parameters you can change:

• fuel type: gasoline or diesel (string)
• fuel indication from constructor: intake stroke in mL (int)

Since the fuel consumption depends on the vehicle type, if you operate a mixed fleet you will have to create a configuration for each type. With the device manager, this process is made very easy.

Does it cover every vehicle?
Unfortunately not, although we are doing our best to provide the best accuracy and coverage. Contact us for specific requirements.

The PID I am looking for is not in that list?
For now you are restricted to those basic values. However, with a data extension module, we enable a fully customizable OBD module using JSON. You will not need to develop anything, just send an JSON script with the right syntax, indicating your PIDs and modes and we will send you the value directly. Contact us for more details.

Munic.Box offers the capability to scan the DTC of any vehicle compliant with the OBD remotely. In the basic package, you will have access to the standard OBD diagnostic, if you want to access the proprietary DTC from non OBD ECUs (airbag, ABS, etc...), you can get an application from the store

Basic diagnostic

In standard, Munic.Box gathers the following data:

Interpretating MDI_DTC_LIST (eOBD fault codes)

The basic format for MDI_DTC_LIST is : ECU1:P0001,P0002,ECU2:P0003,P0004
If some ECU answers to the DTC message with 0 DTC's, the value associated with this ECU will be: N/A

Warning: In the next Munic.box version, the format for MDI_DTC_LIST will slightly change: ECU1:P0001,P0002;ECU2:P0003,P0004 (notice the ';' in place of the ',' before the second ECU). To be compatible with both formats right now, we suggest you apply the following regex to the current format: s/,ECU/;ECU/ and then work with splits.

To interpret eOBD fault codes, you can use the following rules

1- The first character indicates which area of the vehicle the code applies to:

2- The second character specifies the type of code:

3- The third character identifies the subsytem, for example in the case of the Powertrain

4- The last two characters identify the specific fault as seen by the on-board systems

Battery voltage measurement

Wake up by external voltage

we have a very advanced way to monitor the external voltage in order to detect a wake up. This mechanism is completely configurable with 3 parameters accessible through our configuration system

The dongle will wake up :

• 1/ if the voltage exceeds the threshold wakeup_voltage_absolute_mV and if wakeup_voltage_delta_mV and wakeup_voltage_delta_t are equal to 0.
  
• 2/ if the difference between min and max exceeds the threshold wakeup_voltage_delta_mV during wakeup_voltage_delta_t.
• 3/ if the voltage exceeds the threshold wakeup_voltage_absolute_mV and the difference between min and max exceeds the threshold wakeup_voltage_delta_mV during wakeup_voltage_delta_t.

Power Modes

Munic.Box supports 2 main power modes:

The orange LED provides you on the GPS and Cellular status.

Device LED pictures

Sleeping/Idle	GPS KO, Cellular OK	GPS OK, Cellular KO	GPS KO, Cellular KO	GPS OK, Cellular OK

Power Mode transition

Switching between the different mode is defined as below:

24 hours Uptime

The devices reboot after 24h of uptime.

Heartbeat

The devices have a maximum sleep time allowed. By default, they will wake-up every 24h. While the car is parked, the device will wake up for a short period of time in order to record a set of data and send them to your server.

Minimum wake time

After idle out or cold boot, Munic.Box requires a minimum time before being able to go idle. This time is fixed by default at 300s.