CrashBoxx Prerequisites

There are several pre-requisites to use the CrashBoxx service. This section discusses devices types, firmware version, script considerations, User and Account Permissions, service profiles, network access and monitoring the service activation state.

Device Type

Most of the LMUs based on our 32-bit platform support CrashBoxx as well as the EdgeCore products. 8-bit products do not support this service, nor do the TTU2830 and TTU2840 family of App IDs.

A list of the list of the App IDs supporting the service follows. CalAmp adds new AppIDs regularly, so please contact your CalAmp FAE if you have questions about AppIDs not listed.

Device Firmware Version

CrashBoxx was initially developed using common PEG features, but implementing it required significant effort to merge the CrashBoxx features into a customer’s script. CrashBoxx functionality was later integrated into the LMU firmware as an easy to enable feature in version in LMU firmware version 7.2a. There is now a second generation of this integrated solution released in LMU firmware version 8.5b and greater. Both generations have excellent crash detection performance.
The primary difference between the first and second-generation solution is the first generation implemented less of the crash detection algorithm at the edge. This sends more frequent crash reports to the CrashBoxx server, which completes the algorithm and alerts if it determines a true crash occurred. The additional crash reports can consume significant cellular data. Actual data consumed depends on the installation and driving conditions. The range of data consumed with the first generation CrashBoxx implementation is typically between 500kb to 2MB per month. Securing the LMU to a rigid point in the vehicle is the best way to reduce data consumption for devices leveraging the first generation CrashBoxx solution.

The second-generation implementation does more of the CrashBoxx processing within the LMU, which reduces crash reports sent to the server by roughly 99%. While any firmware after 7.2a can be used, CalAmp recommends LMU FW 8.5b or later to reduce data consumption.

Script considerations

For any customer new to CrashBoxx CalAmp would recommend using the version integrated into the firmware. This greatly reduces, but does not fully eliminate script dependencies. The dependencies that remain include:
• Parameters 909 and 912 must be their default values.
• Motion log space (both short and long logs) is shared between CrashBoxx and the application

Parameter 909 and 912 Details

Parameter 909 – Alignment configuration: This is normally defaulted in the FW to a value of 0x31 (Hex) which is for a Satellite Count of >=4 and HDOP of <=3.0 for GPS Quality, a Vertical Stability of 8 samples, and an Average Alignment Time-Constant of 50 seconds. The ICN setting in FW uses the exact same defaults, so only customers who change this setting from default will notice any difference. For those customers who had changed to a lesser threshold, they may experience a delay is the accelerometer reaching alignment after power up and wake up as it reaches the higher threshold set by ICN. In extremely poor GPS conditions, this may result in alignment never occurring or reaching “Best” status. Customers who had chosen a higher threshold will see the opposite, a quicker time to alignment as the thresholds are now lower.

Parameter 912 – MEMS Accelerometer Range Select: This is normally defaulted in the FW to 0 whet sets Automatic Range Setting and LMU Sleep Behavior. The ICN setting, used when enabled, is +/-16g but DOES NOT override Bit 7 of Param 912, which determines LMU or TTU sleep style. Most customers will not notice a difference in this setting as the Automatic setting usually settled on the highest possible range (+/-16G) when alignment reached “best” conditions. Those customers who had previously chosen a setting between Automatic and +/-16G may need to adjust their back-end processing to accept a higher range of results from the accelerometer.

Motion Log Details

ICN uses 7168 bytes of Motion Log memory when enabled. ICN will override any existing settings on the LMU that would prevent it from using its full 7168 bytes. If other motion logs are enabled, they must share space, using whatever memory remains. If setting custom Motion Log sizes, Custom Motion Log RAM usage + ICN RAM Usage (7168 bytes) should be <= Motion Log RAM pool for the APP ID that is being used. During start-up, the debug will show the amount of Motion Log RAM as well as how it is allocated.

Motion Log Settings that are affected are 1061,0 (Short Motion Log size) and 1061,1 (Long Motion Log size).

Custom Motion Log RAM Usage is defined as Short Logs Queue Size + Long Logs Queue Size + Compression Queue size (If enabled this will be 850 bytes).

Example:

Motion Log and ICN are requested. (No compression, Short Log1 -816 bytes, Long Log0 – 816 bytes, ICN)

app[23:25:46] MOTLOG: Allocated Memory 9172

app[23:25:46] MOTLOG: Algn 6000 Compr 0, 0 Shrt 816, 816 Lng 0, 0, ICN: 816, 352

RAM available for Motion Logs by APP ID can be found in this table:
https://calamp.atlassian.net/wiki/spaces/EFG/pages/36732929/LMU+Resource+Usage

CrashBoxx Tiers and Account Permissions

CrashBoxx has a three-tiered feature set. The first tier is “First Notice of Loss” (FNL). This tier provides basic information about a crash to the customer, including the crash severity, date and time of the incident, vehicle information, crash location and impact direction. Often customers operating at this tier do not use APIs to retrieve data. Most of the crash information available at this tier is available in the FNL email or SMS alert notifications. See CrashBoxx Alerts for more information.
The second tier of CrashBoxx is called “Accident Reconstruction.” This allows users to download position, speed, and acceleration information for an accident, as well as the First notice of loss information. This can provide additional insights about the crash, including if the driver was speeding, braking occurred prior to the crash, the vehicles motion throughout the incident, peak accelerations observed during the incident, and where the vehicle came to a rest. This is often most often used by customers with an interest in generate a custom crash report for the incident.
The third tier is “Predictive Physical Damage”. This service predicts the damage to the vehicle and determine a rough Bill Of Materials (BOM) to repair the vehicle. In many cases CBX is used with a device connected to the vehicles OBD-II port. This allows the device to read the VIN and we can look up the year make and model information. That information along with the crash details allows the CrashBoxx server to predict damage based on the vehicle class (e.g. compact car, van, light duty truck). As an example: A crash in a subcompact vehicle may cause significant use of the crumple zones of the vehicle to protect the driver. This may result in bumper, fender, and light assembly damage. The same crash for a full size truck may only damage the bumper. This API can also return an image of a similar vehicle to help show the damage.
Depending on the tier of service purchased, the account must have proper permission set to access the Specific APIs. The CTC API Docs permission is also required to access these APIs.

Service Profiles and Servers

The LMU firmware version of CrashBoxx is activated using a service profile. The service profile provides the LMU notification that it should start its CrashBoxx service, and provides the IP and port information required. Service profiles are configured for customers by CalAmp at the CTC account level. If the service profile is left at the default setting, the account will be assumed to be associated to CalAmp’s private network settings.
For customers leveraging their own network plans, the setting must be switched to use a public IP address for the CrashBoxx server. Devices outside CalAmp’s network will not be able to send data to the CrashBoxx server until this step is performed. Notify your FAE or CSM if you believe you need your service profile updated.
The publicly accessible IP addresses for the CrashBoxx server are shown below. Typically, customers throughout Europe will use the UK server, and customers outside of Europe will have their devices on the US Public server.

Note: If you utilize a private APN with a firewall, the public IP/port for the CrashBoxx server must be open for UDP traffic.

Monitoring Service Activation

CalAmp’s operations team enables CrashBoxx on devices when the service is purchased, or a request is made to enable it on devices sold under the Device as a Service (DaaS) program. Customers should monitor service activation, to ensure the devices are communicating with the CrashBoxx server.
After CalAmp sets the service profile, the devices are loaded into CTC, and CrashBoxx is enabled, CTC will push a message to PULS to activate the service profile the next time the device checks into PULS.
This service activation process can be monitored by customers with PULS.

In PULS the location of this status message is shown below:

PULS CrashBoxx Status

• Supported Status: When devices update to a firmware that is ICN capable, their ICN Status becomes supported.
• Active Status: When the devices are registered on CTC, CTC and PULS exchange APIs that agree the device is registered for ICN and Supported, so PULS downloads the Service Profile (SP) file to the device and the device status moves to Active. The device reads the service profile file and does a soft reset to accept the new parameters from the SP file.
• Operational Status: Once the Device finishes resetting, it does a check-in to PULS and if proper communications with the CrashBoxx server were established, the status moves to Operational.

Customers should inform their CalAmp FAE if they have requested the CrashBoxx service to be activated and your devices do not reach operational status.

CrashBoxx Alerts
Alerts are typically setup by Cal/Amp for customers when the service is activated. The three most common alert types are discussed below:

1. Email
When purchasing the CrashBoxx service, customers provide the email address and contact information for an email alert to be created. The alert contains the majority of the FNL data. An example of the alert is below.

2. SMS

An SMS alert is very similar to an email alert, and requires only an SMS enabled phone number to configure. Much of the same information is provided.

3. URL Post

URL Post alerts allow the CrashBoxx server to post the First Notice of Loss information to an endpoint on a customer’s server. The primary use case for this alert type is to allow customers to generate their own crash notification messages that include the FNL data. It is also handy in another sense, which is the Accident Reconstruction and Predictive Physical Damage APIs require a case ID to access. The CASE ID is sent in the FNL post, which can then be used to automate access the Accident Reconstruction and Predictive Damage APIs.