CrashBoxx Prerequisites

There are several prerequisites for using the CrashBoxx service. This section discusses device types, firmware (FW) 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; the TTU-2830 and TTU-2840 family of app IDs also don't have this support.

A list of the app IDs that support CrashBoxx follows. CalAmp adds new app IDs regularly, so contact your CalAmp FAE (field applications engineer) if you have questions about app IDs 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 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 solutions is that the first generation implemented less of the crash-detection algorithm at the edge. This transmits more frequent crash reports to the CrashBoxx server, which completes the algorithm and sends alerts if it determines that a true crash occurred. The additional crash reports can consume significant cellular data. (The 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. The best way to reduce data consumption for devices leveraging the first-generation solution is to secure the LMU to a rigid point in the vehicle.

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

Script Considerations

For any customer new to CrashBoxx, CalAmp recommends using the version integrated into the firmware. This greatly reduces, but does not fully eliminate, script dependencies. The dependencies that remain include these:

Parameters 909 and 912 must be their default values.
Motion log space (for both short and long logs) is shared between CrashBoxx and the application.

Parameter 909 and 912 Details

Parameter 909 – alignment configuration: This normally has a default value in the FW of 0x31 (hex), which is for a satellite count of >=4 and an HDOP of <=3.0 for GPS quality, a vertical stability of 8 samples, and an average alignment time constant of 50 seconds. The ICN (instant crash notification) setting in the FW uses the exact same defaults, so you will only notice any difference if you change the setting from the predefined values. If you had changed to a lower threshold, you may experience a delay in the accelerometer reaching alignment after power-up/wake-up as it arrives at the higher threshold set by the ICN. In extremely poor GPS conditions, this may result in alignment never occurring or reaching Best status. If you had chosen a higher threshold, you will see the opposite — a quicker time to alignment, as the thresholds are now lower.
Parameter 912 – MEMS accelerometer range select: This normally has a default value in the FW of 0 and sets the Automatic Range and LMU Sleep Behavior settings. 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 as the Automatic setting is usually settled on the highest possible range (+/-16g) when alignment reached Best conditions. If you had previously chosen a setting between Automatic and +/-16g, you may need to adjust your 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 you are 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 startup, 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 log queue size + long log 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

You can find the RAM available for motion logs by app ID 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), which 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 an FNL email or SMS alert notifications. See "CrashBoxx Alerts" (later in this article) for more information.

The second tier is Accident Reconstruction, which allows users to download position, speed, and acceleration information for an accident, as well as the FNL data. This can provide additional insights about the crash, including whether the driver was speeding, whether braking occurred prior to the crash, the vehicle's motion throughout the incident, peak accelerations observed, and where the vehicle came to rest. This is most often used by customers with an interest in generating a custom crash report for the incident.

The third tier is Predictive Physical Damage, which predicts the damage to the vehicle and determines a rough bill of materials (BOM) to repair the vehicle. In many cases, CrashBoxx is used with a device connected to the vehicle's OBDII port. This allows the device to read the VIN and enables CTC to look up the year, make, and model information. Given that and the crash details, the CrashBoxx server predicts damage based on the vehicle class (such as compact car, van, or light-duty truck). For example, a crash in a subcompact vehicle may cause significant use of the crumple zones of the vehicle to protect the driver, which could result in bumper, fender, and light assembly damage. The same crash for a full-size truck may only damage the bumper. CrashBoxx 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 gives 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. Until this step is performed, devices outside CalAmp’s network will not be able to send data to the CrashBoxx server. Notify your FAE or CSM (customer success manager) 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 U.S. server.

NOTE: If you utilize a private APN (access point name) with a firewall, the public IP/port for the CrashBoxx server must be open for UDP (user datagram protocol) 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. You should monitor service activation to ensure that 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.

You can monitor this service activation process using PULS.

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

PULS CrashBoxx Status

Supported: When devices update to a firmware that is ICN capable, their ICN status becomes Supported.
Active: When the devices are registered in CTC, CTC and PULS exchange APIs that agree the device is registered for ICN and supported, so PULS downloads the service profile 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 it.
Operational: After 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.

You should inform your CalAmp FAE if you have requested the CrashBoxx service to be activated and your devices do not reach Operational status.

CrashBoxx Alerts
Alerts are typically set up by CalAmp for customers when the service is activated. These are the three most common alert types:

Email: When purchasing the CrashBoxx service, customers provide an email address and other contact information to which to send email alerts. The alert contains the majority of the FNL data. Here is an example of an email alert:

SMS: An SMS alert is similar to an email alert and requires only an SMS-enabled phone number to configure. Much of the same information is provided via a text message.
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 you to generate your own crash notification messages that include the FNL data. It is also handy for use with the Accident Reconstruction and Predictive Physical Damage APIs, as they require a case ID to access. The case ID is sent in the FNL post, which can then be used to automate access for the Accident Reconstruction and Predictive Physical Damage APIs.