E911 Interface Configuration

There are a few Crimestar INI configuration setting that must be made at each CAD workstation position to prepare the workstation for interaction with the E911 interface.  First since 911 calls can be answered at different telephone PSAP/workstation positions and transferred between positions these positions are usually identified by a unique PSAP/station id #.   When the E911 telephone equipment sends data to the CAD E911 interface the data being sent it always identified by this position ID so that CAD has a means to determine where the ALI data belongs.  As such each Crimestar CAD workstation must be assigned a PSAP position ID that matches the telephone workstation ID # for a given 911 workstation.   This is done using the PSAP_POSITION= setting in the [CAD] section of the Crimestar INI file.  This becomes the message delivery address (Position #) for a specific CAD workstation and is used by both the E911 interface and MDC (Mobile Digital Communicator) CAR-TO-DISPATCH messages. Next you will want to ensure that the E911 data import button is visible on the CAD call taker – event forms, This button can be made invisible so that CAD installations that do not have or use the E911interface do not see that button option.  To make sure that the E911 data import button is visible to CAD workstation users use the E911= setting in the Crimestar INI file.  Examples of the E911 and PSAP_POSITION INI file entries:

[CAD]

E911=ON
PSAP_POSITION=1

Once these two INI settings have been made the CAD workstation is ready to receive E911 data from the Interface.

The E911 interface application program can be run on the CAD workstation computer when only one CAD workstation exists but is more typically run on a completely separate computer or server machine (as shown in the diagram above).  Regardless of where the application is installed, only one instance of the E911 interface application should be running.  No matter where the program is installed and run, it should be on a computer that will not be exceptionally busy performing other tasks.  While the E911 interface requires very little CPU processing time, it is a communications oriented program and its proper performance can be negatively impacted when other programs that consume large percentages of the machine processing power are running at the same time on the same computer.  If the computer’s CPU becomes too busy it may result in failure to properly receive data messages from the PSAP telephone equipment.  Likewise, if the PSAP telephone equipment uses a periodic “heartbeat” signal to monitor the presence of a CAD interface, it will usually expect the CAD interface application to reply to that “heartbeat” signal within 1 or 2 seconds.  If the computer’s CPU becomes exceptionally busy as a result of other programs or applications being run on the same computer, the E911 interface application may not be able to respond to the “heartbeat” within the allotted time to do so.  If the PASP telephone equipment fails to receive acknowledgements to it’s “heartbeat” signals it may consider the CAD E911 interface to be stopped or off-line, which could prevent further ALI data from being sent to CAD.

The E911 interface has a simple design but is quite flexible in its ability to handle a variety of different serial communications and ALI record layouts.  


 

The first page of the interface screen shows if the interface is currently active/running or if it is idle.  When the E911 interface detects CAD workstations on the network the “CAD Workstation(s) indicator will turn green; otherwise it is red as shown in the diagram here.  The first page also shows the interface program Version # and the Crimestar Software license information as it relates to this separate interface product.  While this product works with and is distributed as part of the Crimestar CAD installation, the E911 Interface is an add-on product that is licensed and support separately from Crimestar CAD.

Once the interface has been properly configured using the fields and options presented on the second and third pages of this form (described below) it can simply be started and no other user interaction is required. When you start the E911 interface it will open the serial communications port using the current parameters and begin receiving data.

The second page of the Interface labeled “Data Com Settings” provides a means to set the various serial communication parameters required to receive data from a 911 PSAP controller’s serial output port.  The Data port used will depend on which physical serial port you use to connect to your computer.  A serial connection (RS-232) can use either a 25 pin or 9 pin connector and will vary from machine to machine depending upon the hardware manufacturer. Most new computers use a DB9 (9 Pin Connector) for external serial connections. A cross-over cable may be needed to cross the RS-232 pins 2 & 3 (Data Transmit & Data Receive).  Check with the provider of your telephone PSAP equipment for cabling or wiring specifications to the PC computer running the Crimestar E911 Interface software.

The Baud Rate (speed) Parity, Data Bits and Stop Bit parameters can all be altered as needed from this page.  The most common configuration settings for a PSAP-to-CAD connection are 9600 Baud, No Parity, 8 Data Bits and 1 stop bit. Also on the Data Com Settings page you can configure certain communication protocol options such as if the interface should expect that all inbound data will be wrapped by an STX (or other defined character) at the beginning and an ETX (or other defined character) at the end.  When defining Start and End characters other than an STX and an ETX use the decimal ASCII value for the character desired.

 

As was mentioned previously, some PSAP Controllers will send a “Heartbeat” message at periodic intervals to continuously monitor the condition of the connection with the CAD interface.  On this screen you can indicate if the Crimestar E911 interface is to expect a heartbeat transmission and if so, what the heartbeat character string sequence will be.  Characters are again represented by their ASCII values wrapped in a CHR() function and concatenated together using the + symbol.  Thus and heartbeat string consisting of the 3 characters;  

would be represented in the heartbeat string field as CHR(2)+CHR(72)+CHR(3) as shown in the illustration above.   This page allows you to define the reply data strings that should be sent to the PSAP controller when valid messages, invalid messages or heartbeat transmissions are received.  In the illustration above responses are as follow;

 Here you can also log the data received by the E911 Interface which can be helpful in configuring the data formats on page 3 of this form (Described Below).

On the third page of the E911 Interface you can define the byte offsets and data lengths of the various data elements that make up the E911 ALI record.  Since not all data is positioned as fixed length text you can also create user defined functions to more precisely parse the data into the specific fields that will allow the data to be used in CAD.  If user defined functions are required to format the data you may need to contact Crimestar technical support for additional assistance with building or setting up these functions.

It is very helpful if your PSAP telephone supplier provides you with the ALI CAD interface record layout specification.  This will help you determine it the ALI data is always presented as a fixed position record. When working with fixed position records you can simply use the spinner controls on the “Data Parsing Values” page to define each respective data element.  For each data element there are two spinner controls.  The first spinner defines the starting byte position, and the second spinner determines the length of the data element.  Thus, for example, if the phone number begins at byte position 44, and is 8 bytes long, the spinner controls for the phone number field would be 44 and 8 respectively.  

Sometimes, simple byte offsets won’t work because the data is not in fixed length fields.  When data is in a variable length format a more sophisticated approach must be taken to parse the ALI data into its logical elements.  To accomplish this task the Crimestar E911 Interface application provides for the use of user defined functions “UDF”.  This is an extension of the underlying development tools that have been used to create the E911 Interface itself.  The process of creating a UDF is more complex than can be described in this document, but suffice it to say that the implementation of some simple functions can almost always get the desired results.  Data that has been defined by the offset (start position) and length spinners is passed into the UDF as a parameter, the UDF acts upon the data string and returns a result to the data element field.  Here is an example.  Suppose the ALI data record contains a field to define the subscriber name. That field starts at byte position 204 and is a 60-character field.  The spinners for the subscriber field would be 204 and 60 respectively.  But suppose the data that appears inside this field varies from record to record.  In other words sometimes the field contains a business name such as the “SONIC DRIVE-IN” while other times the field contains a proper person name in last name comma first name format such as “SMITH, ROBERT”.  Now consider that when the subscriber name is a person’s proper name we want to complete the last name and first name data element fields. To accomplish this we look for some kind of common circumstance that we can count on.  In this example the common circumstance is that whenever the data is a person’s proper name the data string contains a comma “,”.  Therefore we can write a UDF to test for the existence of a comma then separate the last name and first name from each side of the comma.  The following function would accept the defined data as input, identify and extract everything up to the comma (the last name) and return the result.

LPARAMETERS  lcInputText

RETURN GETWORDNUM(lcInputText,1,”,”)

In this simple two-line example the GETWORDNUM function is used and we provide it 3 parameters.  The GETWORDNUM function separates strings of data into “words” based on a defined delimiter character. The first parameter is the lcInputText that was passed into the UDF, the second parameter is the word number we want to extract (1=first word, 2=seconds word etc) and the third parameter is the character to use as a delimiter which in this case is a comma “,” (Note that the delimiter character must be in quotes). The GETWORDNUM function returns the first word based on its position in relation to the delimiter and the result is we have extracted the last name from the string.  Again this is a very simple example and there are many more functions that can be used to manipulate the ALI data.  It is not expected that you will know or understand how to do this, however it I important to understand the basic mechanics of how the E911interface can use UDF’s to achieve the desired results.  NO doubt Crimestar technical support will, if needed assist you in defining the UDFs to properly parse the ALI data provided by the PSAP telephone equipment.

This screen also gives you the ability to import a known record from a file, which can be very helpful when trying to configure the data offsets, data lengths and UDFs needed.

Finally on the fourth page of E911 Interface you can define ALI Filtering conditions that will determine which ALI records the interface will process and which records it will ignore.

This is particularly helpful if your site is not its own PSAP but an ALI data feed from a remote PSAP is being sent to your respective agency.  In this circumstance the remote PSAP may be sending ALI data records for ALL calls received at the PSAP site, but only a subset of those 911 calls are subsequently transferred to your respective agency.  By using the E911 interface ALI filtering, you can instruct the E911 interface to ignore all ALI data records transferred that do not match a specific filter condition.

The E911 interface offers two (2) types of filtering; Acceptance Filters and Rejection Filters.

When Acceptance Filters are used ALL inbound ALI records will be rejected unless they contain some specific text that will cause them to be explicitly accepted.  Five (5) different acceptance filter test can be defined.  In other words, you may define up to five (5) different text strings that will cause an ALI record to be accepted.  If, any of the five (5) defined text strings are found within the ALI data record the record is processed, otherwise it is rejected.  In the illustration shown above ALL inbound ALI data records are rejected unless they specifically contain the text strings of “VAN ALSTYNE” or “ANNA”.

When Rejection Filters are used ALL inbound ALI records will be accepted unless they contain some specific text that will cause them to be explicitly rejected.    Five (5) different rejection filter test can be defined.  In other words, you may define up to five (5) different text strings that will cause the ALI record to be rejected.  If any of the five (5) defined text strings are found within the ALI data record the record is rejected, otherwise it is processed.

If both Acceptance and Rejection filter strings are defined, only the Acceptance string filters will be processed since any record that does match at least one acceptance filter is rejected by default.


E911 Auto Start

If you wish to have the E911 interface automatically start and go on-line upon running the E911.EXE program file you can place the following entry in the [CAD] section of the Crimestar.INI file

E911_AUTOSTART=ON