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 Support

Most of the LMUs based on our 32-bit platform support CrashBoxx as well as the EdgeCore products. LMU-3030, TTU-2830, TTU-2840 family of devices, 8-bit products do not support this service. Contact your CalAmp FAE (field applications engineer) if you have questions about device type support.

Device Firmware Version

CrashBoxx functionality is integrated into the LMU/TTU firmware as an easy-to-enable feature in FW versions 7.2a and later. 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 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, 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

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 which includes:

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

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 by selecting a device and going to the Services tab:

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.