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 Support

Most of the LMUs based on our 32-bit and EdgeCore platforms support CrashBoxx, unfortunately the 8-bit product line does not support this service. For a full list of supported and non-supported app-id's please select the link below or contact your CalAmp FAE (field applications engineer):

CrashBoxx Supported Devices

Device Installation

CrashBoxx requires the device be mounted to a secure, solid location in the front of the vehicle to ensure proper crash detection and device communication. For further installation guidance please select the link below:

CrashBoxx Installation Guide

Device Firmware Version

There is now a second generation of this integrated solution implementing more of the CrashBoxx processing within the device on the edge to reduce the number of irrelevant crash reports sent to the server by roughly 99%.
Although Crashboxx will work with all versions of EdgeCore firmware and any 32-bit firmware after 7.2a, CalAmp recommends use of the latest EdgeCore firmware and 8.6o or later for 32-bit devices.

Script Considerations

For any customer new to CrashBoxx, script dependencies are still required, details below:

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

CrashBoxx uses 7168 bytes of motion log memory when enabled. Crashboxx 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

Service Profiles Activation

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. 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, DMCTC will push a message to device next time it checks into DMCTC.

You can monitor this service activation process using DMCTC:

DMCTC 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.

Collision Severity Levels

Very light – typically the lower range occurs around 5 mph Delta V (Change in Velocity during the impact).\
Light – May or may not have air bag deployment (Depending on impact angle), minor damage.
Moderate – Almost certainly air bags deployed (Depending on impact angle), and mainly sheet metal damage with minor structural involvement.\
Heavy – Structural damage to frame rails or vehicle structure likely with major sheet metal damage.
Very Heavy – On the upper end of the vehicle's capability to manage the energy of the crash.