Mobile Digital Communicator - CrimeStar

Mobile Digital Communicator

Operations Manual

Revised: September 9, 2008

Photo Courtesy of Detective Chris Currier, New London, NH

Presented by:

Crimestar Corporation P.O. Box 53480

San Jose, California 95153-0480 www.crimestar.com

Copyright Information This operations manual and the accompanying Crimestar software application including any and all related database table structures and file formats are copyrighted by Crimestar Corporation 2004-2008 All Rights Reserved. Crimestar® is a registered trademark of Crimestar Corporation. Microsoft®, Visual FoxPro® and SQL Server® are registered trademarks and Windows™ is a trademark of Microsoft Corporation. Throughout this document, references are made to product names (either textually of graphically) that are trademarks of other companies. The names are used in an editorial fashion only, and to the benefit of the respective owners, with no intention of infringement of the trademark.

Crimestar – Mobile Digital Communicator Operations Manual 1

• Table of Contents

TABLE OF CONTENTS ............................................................................................................................................ 1

INTRODUCTION ....................................................................................................................................................... 3

INSTALLATION NOTES ............................................................................................................................................... 3 MDC – CAD NETWORK DIAGRAM ........................................................................................................................... 5

DEFINITIONS ............................................................................................................................................................. 7

MDC CONSOLE OVERVIEW .................................................................................................................................. 8

PROGRAM MENU ....................................................................................................................................................... 8 DISPLAY PANELS ....................................................................................................................................................... 8 PANEL # 1 & PANEL # 2 ............................................................................................................................................. 8 MESSAGE WAITING INDICATOR, ALERT TONE & CAUTIONS ................................................................................... 10 STATUS MONITOR PAGE .......................................................................................................................................... 12 STATUS MONITOR FILTERING .................................................................................................................................. 13 STATUS MONITOR MAP PAGE .................................................................................................................................. 15 MAP FILES INSTALLED / CONFIGURATION ............................................................................................................... 18 CREATING A STATUS MONITOR MAP OVERLAY FILE .............................................................................................. 19 STATUS MONITOR CONFIGURATION / APPEARANCE ................................................................................................ 20 SCRATCH PAD.......................................................................................................................................................... 21

ESTABLISHING AN MDC COMMUNICATIONS LINK ................................................................................... 22

SERIAL COMMUNICATIONS (RF MODEMS) SETTINGS ........................................................................................... 22 IP BASED COMMUNICATIONS (GPRS OR PRIVATE IP RADIO SYSTEM) SETTINGS ................................................... 23 GENERAL COMMUNICATIONS SETTINGS .................................................................................................................. 24 LINK AND HANDSHAKE READY INDICATORS ........................................................................................................... 25 COMMUNICATION STATISTICS ................................................................................................................................. 26

MDC MESSAGE SECURITY .................................................................................................................................. 28

TRANSMISSION ACCESS: .......................................................................................................................................... 28 MESSAGE FORMATS: ............................................................................................................................................... 28 MESSAGE COMPRESSION: ........................................................................................................................................ 28 MESSAGE ENCRYPTION: .......................................................................................................................................... 28 MESSAGE PACKETIZATION: ..................................................................................................................................... 29 ADDRESS VERIFICATION: ........................................................................................................................................ 30 TRANSACTION TYPE VERIFICATION: ....................................................................................................................... 30

GPS ENABLING THE MDC WORKSTATION ................................................................................................... 34

GPS – UNIT TRACKING - LOGGING .................................................................................................................. 36

UNIT STATUS COMMANDS ................................................................................................................................. 37

IN-SERVICE / LOG-ON .............................................................................................................................................. 38 DISPATCH ................................................................................................................................................................ 39 ENROUTE ................................................................................................................................................................. 40 ARRIVE .................................................................................................................................................................... 41 CLEAR ..................................................................................................................................................................... 42 FREE ........................................................................................................................................................................ 43 MISCELLANEOUS STATUS ........................................................................................................................................ 44 VEHICLE STOP ......................................................................................................................................................... 45 OUT OF SERVICE ...................................................................................................................................................... 46

EVENT STATUS COMMANDS .............................................................................................................................. 47


EVENT COMMENT .................................................................................................................................................... 47

OTHER SYSTEM COMMANDS ............................................................................................................................ 47

ADMIN MESSAGES ................................................................................................................................................... 47

PERFORMING CAD-RMS SYSTEM QUERIES ................................................................................................. 49

QUERY EVENT ......................................................................................................................................................... 49 QUERY UNIT HISTORY ............................................................................................................................................. 50 QUERY PERSON ....................................................................................................................................................... 51 QUERY PERSON - IMAGE SIZE / REDUCTION ............................................................................................................ 52 QUERY VEHICLE ...................................................................................................................................................... 54 QUERY ARTICLE (PROPERTY) .................................................................................................................................. 55 QUERY BOAT ........................................................................................................................................................... 56 QUERY FREE FORM ................................................................................................................................................. 56 QUERY GUN ............................................................................................................................................................ 57 QUERY HAZMAT ...................................................................................................................................................... 57 QUERY MDC UNITS ................................................................................................................................................ 58

SAVING & RECALLING WORKSTATION MESSAGES TO/FROM DISK. .................................................. 59

APPENDIX A – FILES INSTALLED ..................................................................................................................... 61

MODIFYING / CHANGING DISTRIBUTED FILES ......................................................................................................... 64

APPENDIX B - INI FILE SETTINGS .................................................................................................................... 65

APPENDIX C – DEFAULT HTML STYLE SHEET VALUES ........................................................................... 75

DAYMODE ( MDCDEFAULT.HTML ) ................................................................................................................ 75 NIGHTMODE ( MDCNDEFAULT.HTML ) ......................................................................................................... 76

APPENDIX D – FUNCTION KEY VALUES ......................................................................................................... 79

APPENDIX E – PROTOCOL SELECTION AND SYSTEM TUNING .............................................................. 80

PACKET BASICS .................................................................................................................................................. 80 TCP: ........................................................................................................................................................................ 81 UDP: ....................................................................................................................................................................... 82 GENERAL SYSTEM PERFORMANCE: ......................................................................................................................... 82


• Introduction • The Crimestar Mobile Digital Communicator (MDC) is a powerful, in field, real time, add-on extension to the Crimestar Computer Aided Dispatch (CAD) system (*Licensed Separately). Crimestar MDC allows you to securely send encrypted data and information to/from field units via computer. The system allows officers in the field to be silently dispatched to calls and to notify dispatch, as well as other units, when they are responding or have arrived. MDC equipped field units can monitor all CAD event and unit activity, maintain their own status for assigned calls/events, provide call/event dispositions and disposition comments, send car-to-dispatch / car-to-car administrative messages as well as perform Name, Vehicle, Property and CAD Event searches. The MDC system is GPS and map enabled providing a real time latitude/longitude coordinates for field units and events. This allows field units as well as dispatchers to visualize via interactive maps where units are and where things are happening. Utilizing its own packet messaging protocol, the MDC can work over either a dedicated radio system utilizing RF Modems or via GPRS/CDMA networks provided by various commercial carriers in different regions of the country.

The MDC system is not necessarily a field reporting system in that it does not have 100% access to Crimestar RMS data. While MDC supports queries into a Crimestar RMS database and to State/NCIC systems via the Crimestar Message Switch Gateway (MSG) product, the primary purpose and intent of the MDC is to provide a highly secure digital data link to/from the Crimestar CAD system for the purpose of providing secure communications as well as dispatch related data and maintaining unit status information. • Installation Notes * Do not try to shortcut the installation by copying files from one computer to another. The MDC setup program installs and registers certain DLL and OCX controls on your computer that will not be transferred as part of a routine file copy process. Accessing the Crimestar Database: The Professional edition of Crimestar CAD uses the “DATAPATH=” entry of the Crimestar INI file. The Enterprise edition of CAD uses the


“SQL_NAME_IP=” entry in the Crimestar.INI file. The MDC Controller will need to access the same database. Therefore, the same INI file entries should be provided or set on the computer functioning as the MDC Controller. IMPORTANT: Crimestar MDC uses TCP/IP-UDP broadcast messages (also known as data-grams) to alert other CAD network workstations of new event or status activity. As such, the machine running as the Crimestar MDC Controller should have the TCP/IP network protocol loaded and should be addressed within the same network segment (or class C address range). In other words the address used in the Class A, Class B, and Class C address blocks should be the same ( ClassA.ClassB.ClassC.ClassD ) as each computer running CAD. Example: 192.168.1.5

192.168.1.42 192.168.1.190 192.168.1.203 etc.

Additionally; if a router or firewall is in place on the network it should allow for the passage of TCP/UDP traffic on port 333 and port 777. These ports are used by the MDC Controller to send the UDP broadcast messages to CAD workstations and to communicate with MDC field units.


• MDC – CAD Network Diagram The MDC Controller software should be installed and run on a separate dedicated Pentium class (or faster) network computer within the same LAN segment as other CAD workstations. The controller interacts directly with the Crimestar RMS/CAD database as well as sending TCP/IP-UDP broadcast messages to other CAD network workstations. The MDC Controller can be connected directly to an RF Modem via a serial port (as diagrammed below) or to a commercial IP Network (such as GPRS).


Windows Screen Resolution The MDC software is best run at a computer screen resolution of 1024x768. While software will work at a resolution as low as 800x600 we would recommend using a higher resolution whenever possible. To check your computer’s screen resolution, use the Windows Control Panel to select Display. You may also Right-Click on your windows desktop and choose properties from the popup menu. Once the Windows Display properties window is active, check the settings page to find the screen resolution setting for the display monitor being used. When running at screen resolutions greater than 800x600, the MDC workstation’s application window can resized. However, the minimum allowable viewing size of the MDC application window is 800x600 pixels.


• Definitions Before we begin explaining the various features and capabilities of this system it will be helpful if we first define some basic terms that we use when discussing this product. CDMA: Short for Code Division Multiple Access, a digital cellular technology uses spread-

spectrum techniques to transfer voice and data. CDPD: Cellular Digital Packet Data (A data communication technology made popular by

AT&T that has generally been replaced by GPRS. GPRS: General Packet Radio Service. Provided by commercial cellular telephone carriers. GPS: Global Positioning Satellite MAC Address: This is the Media Access Control Number also referred to as the Serial # of

your computer’s Network Card (NIC). MDC Controller: This is the instance of the MDC software ( MDCCOM.EXE ) running in

your facility on the same LAN segment as Crimestar CAD. The MDC controller always has an MDC_ADDRESS of zero (0).

MDC Workstation: This is an instance of the MDC software ( MDCCOM.EXE ) running in a

patrol car communicating with the MDC Controller via a radio or GPRS link. This is also sometimes referred to as the MDC Mobile. An MDC workstation always has an MDC_ADDRESS greater than zero and no two MDC Workstations should have the same MDC Address.

NIC: Network Interface Card. Used to allow your computer to communicate on a network. NMEA: National Marine Electronics Association TCP/IP: Transport Communications Protocol / Internet Protocol USB: Short for Universal Serial Bus, an external bus standard for connecting a wide range of

peripheral devices such as mice, modems, keyboards and GPS receivers.


• MDC Console Overview The Crimestar MDC system is comprised of a primary form with 4 pages, a menu and a status control panel (series of command buttons and indicators) located at the bottom of the screen. The MDC user interface has been specifically designed to allow for easy use with a touch-screen type display. When using a touch screen device the MDC application can run without the use of a keyboard. • • Program Menu Similar to the design of most windows applications the MDC user interface provides a main menu where all application related functions and activities can be performed. The menu layout is simple and intuitive with common tasks grouped together into general categories. Menu prompts are spaced further apart than normal so as to be more easily selected when using a touch screen device.

While efforts have been made to make the menu easily accessible, most frequently used functions can be accessed using command buttons and other system prompts. • Display Panels All MDC data is displayed via a series of 4 display panels. The first two panels are dynamic and their content is controlled by the user. The third and fourth panels are dedicated to displaying unit and event status data, where panel three displays that data in attribute format and panel four displays the data in graphical format. In the following sections these panels will be discussed as other features and capabilities of the MDC system are explained. • Panel # 1 & Panel # 2 Both these display panels perform in the same way. When new messages are received they are held in queue until the user chooses to display them. To display a detail data message waiting in queue the user clicks the NEXT button. The system can be configured to automatically display a new message when the currently selected display panel is clear, however usually messages are held in the new “Message Waiting” queue. System design dictates that the MDC is never to assume that a newly arrived message is more important than whatever message the user may currently be viewing. Once the new message is displayed on the display panel, it is automatically moved into a 20 message revolving queue, allowing the user to press the PREV button to move back to the previous displayed message. The message # is shown at the top of the form. Clicking the NEXT button will always retrieve the next new, unread, pending message from the program’s internal message queue if one exists and is waiting to be displayed (Indicated


by the green “Message Waiting” indicator). Since, you don’t know what a message contains until you read it, it is often necessary or desirable to “go back” to a previous message after you have read a new message. This can be controlled by either switching display panels before you click the Next Message button, to force the new message to be displayed on an alternate display panel, or by simply clicking the PREVious message button to cycle back through the previous 20 messages that are automatically held in a circular queue.

Unlike the PREVious button which moves you backward in the circular message queue of already viewed messages, the NEXT button does not move you forward in the circular queue. The NEXT message button always displays new messages on the currently active display panel and moves the message into the circular queue. If there are no new message waiting, pressing the NEXT message button does nothing. The PREVious message button always cycles backwards through the circular queue of already viewed messages. It will never show you a new (not yet viewed) message even when such messages are waiting in the new message queue. The panel that is active will be the panel that receives or displays the message when the NEXT or

PREVious button is clicked. If neither panels 1 or 2 are active when the user presses the NEXT or PREV buttons the MDC software will automatically switch back to Panel #1. By having two display panels available the user can quickly reference two different messages simply by switching panels as opposed to scrolling through the PREVious message queue.


( This illustration shows a CAD Event being displayed in Panel #1 )

Data displayed on panels1 & 2 can be larger than the display window itself and users can scroll up/down through the message as needed. The display format of the data is determined by the MDC software and depends on what type of message it is and how the MDCDEFAULT style sheet has been configured. See Appendix “C”. Additionally the MDC can be set to “NIGHT MODE” where all displays and command buttons (except the map page) are rendered as red text on a black background. The color scheme of red on black is used because red has the least effect on a person’s night vision. When in night mode the MDC uses an alternate style sheet named MDCNDEFAULT.HTML to rendering message text. • Message Waiting Indicator, Alert Tone & Cautions As was mentioned above, when the MDC receives a message, it will display a flashing green “MESSAGE WAITING” indicator and sound an audible tone. Clicking the NEXT button will retrieve that message from the message queue and display it on the either Message Panel #1 or #2 depending upon which one is active. If neither panel is active, the message will be displayed on Panel #1. When the message waiting queue contains multiple messages they will be displayed in the order in which they were received.


When a high priority message is received by the MDC software, it will display a flashing red “PRIORITY MESSAGE” indicator and sound an audible alert tone. High priority messages are always placed in the front of the waiting message queue and will be displayed before any other waiting messages regardless of the order in which the messages were received. An example of a PRIORITY MESSAGE would be the receipt of a digital dispatch message to any CAD event with an event priority of zero (0) or one (1). Remember that in the CAD environment high priority message have low numbers and and low priority messages have high numbers. Thus the highest priority message in CAD is zero ( 0 ) and the lowest priority message in CAD is a nine (9). * The Alert Tone is generated via the mdc_alert.wav sound file. See Appendix: “A” You can change the alert tone to whatever you want by replacing the .wav file distributed with the software, to a new .wav file of your choice. Just make sure the name of the .wav file does not change. In addition to priority message delivery, the MDC controller can flag messages so that the user is made aware that some kind of “cautionary condition” exists. A message can be flagged with a cautionary condition for a variety of reasons, including Crimestar Master Name Record (MNI) caution flags, warrants or a special keyword match. See ALERT_ACTIVATION_STRING in Appendix “B” for more information of keyword alerts. When a message is flagged as a cautionary message it will always be delivered to the MDC workstation as a priority message. In addition to priority delivery, when the message is first displayed the MDC software will display a large red cautionary dialog form to make the user aware of a cautionary condition. This dialog

form is ONLY displayed when the cautionary message is initially retrieved from the waiting message queue. Returning to this

message within the circular displayed message queue via the PREVious message command will not reactivate the cautionary dialog. When the last message in the waiting message queue has been displayed the software will indicate that no more messages are waiting to be displayed.


• Status Monitor Page The status monitor page (Display Panel #3) shows a snapshot of the CAD status monitor as of a specific time indicated at the top of the status monitor page display. The status monitor page can show or hide both units and events and can be filtered to show only specific units or events as desired. This page can also be scrolled up/down to show more data if the size of the message return is larger than what will fit in the viewable area of the display. The MDC Controller can be configured to automatically broadcast status monitor updates at regular predefined intervals and the MDC workstation can specifically request a status monitor REQUERY to refresh the status monitor display with current information.

( Status Monitor shown with optional “Hyperlinks as Buttons” turned ON ) The font size and colors used on the MDC Status Monitor page are determined based on how the MDCDEFAULT.HTML style sheet has been configured. See Appendix “C”. The MDC status monitor contains two hyperlinks for each event. The first hyperlink is on the far left side of the display and is associated with the “Event #” field. Clicking on this hyperlink will query the MDC controller and return a copy of that event. The next hyperlink is in the event call type column. Clicking on this hyperlink will activate a large confirmation dialog to dispatch/attach you to that event. Once activated, the user will have 10 seconds to confirm the


action. Failure to confirm the action within 10 seconds will cause the confirmation dialog to timeout and no dispatch/attach action is taken. • Status Monitor Filtering • In some environments it may be desirable to filter or not display all the unit and event data returned to the MDC workstation by the controller. This may be due to the volume of information to display or the type of information desired. The MDC status monitor will allow events to be filtered based on event priority and/or geographic designation as indicated by the agency, beat, sector or district codes associated with the event. Likewise Unit data can be filtered by unit type (Police, Fire, Medical, Other) and by the geographic assignment of the unit (beat, sector, district). To filter record click the “FILTER” button located at the top of either the status monitor page or status monitor map page to activate the “Filter Status Monitor” dialog form.


Once the Filter Status Monitor dialog form is active, you can filter the events display by check-marking each event priority level you wish to view. The default is events of ALL priorities are shown. Next you can filter the units display check-marking each unit type you wish to view. The default is that ALL unit types are shown. Likewise both events and units can be filtered geographically by selecting the agency, beat, sector or district code desired. (up to 3 codes) Geographic filtering uses and explicitly OR condition within a category (i.e. Beat) and uses an explicit AND condition between categories meaning that the only events or units shown will be those that match ALL selected geographic filtering options. Example: Here only Units and Events associated with agency HPD that are either in beat 1 or beat 2 will be shown. * The MDC does not need to be logged-on to receive unsolicited automatic status monitor broadcast messages.


• • Status Monitor Map Page The status monitor map page shows a snapshot of the CAD status monitor as of a specific time in a special (map) format. The data represented on this map will be identical to the data represented on the status monitor page providing that all units and events have latitude and longitude information associated with them. Any status monitor unit/event hiding or filtering that has been activated will be honored on the map page as well as on the primary status monitor display.

Units and Events are depicted on the map using icons to represent the event or unit type being referenced. These icons will change or move on the map as new status information is received from the MDC controller. Map Icon Click - Information: By clicking on either Unit Icons or Event Icons that are displayed on the map, the MDC software will display the related status monitor data associated with that specific map icon. Latitude & Longitude Reference: As you view the MDC map page you will notice that in the upper right corner of the page the system will show you the latitude, longitude, county and state reference. This information is automatically updated as you move the mouse cursor/pointer over different parts of the map. Latitude and Longitude values can be defined in Degrees or as a Decimal value. By default latitude and longitude coordinates are represented as degrees. To


change them to a decimal value select “Show Latitude & Longitude as Decimal” from the Options menu. Reverse Geo-code Reference: When you click on the MDC map page the system will attempt to mathematically calculate the nearest physical address to that specific map point. Map Views: Similar to the map page used in CAD, the MDC status monitor map page has 3 different map displays that can be selected. The map files installed on the MDC workstation and your specific environment will determine which displays you use and when. • The CAD Activity Map is a calculated map and will display a region that encompasses all defined

units and events. • The “Default Map” displays a map based upon a default view that you define. Using the zoom and

scroll keys to position the map to the desired display, the user can right-click the Default Map button to SET the default map display. Once set the user can return to that map view at any time by clicking the Default Map button.

• The “State Map” display will show a high level view of the state. Zoom+ / Zoom - : These buttons will zoom in or out on the current map page without changing the center point reference of the map. Find Address: This button will activate a find address dialog box prompting the user to enter an address delimited by commas. Once entered the software will attempt to find or locate that address on the map and will center the map page on the point that calculates to that address. Find Unit: This button will prompt the user to identify a unit to locate on the map. One the user identifies the unit to find the MDC software will locate the unit on the map page and center the map on that unit.


Navigation Arrows: The blue directional navigation arrows can be used to reposition the map by moving the center point of the map up, down, right or left. Map Configuration Panel: Clicking the map configuration page toggle button (as shown) will switch the map navigation panel to a map configuration panel. This will allow the user to set certain map attributes and activate certain map functions to be activated. When this toggle button is clicked the graphic on the button will change to the blue navigation arrows, so the same toggle button can be user to toggle back to the map navigation panel. On the map configuration panel various map attributes can be turned on or off. This will affect how the map is displayed and how much detail it will provide. Generally the default setting for these map attributes provide the best map usability. Also on this page is the ability to track units. The “Track this Unit” option can only be used when a GPS receiver has been installed and is activated. This option will cause the MDC software to always keep the map centered on this MDC unit (“this unit”). The optional update distance parameter can be used to determine the amount of movement needed before the map is updated. Keeping this setting at zero (0) will cause the map to be updated in real time. The “Track Unit” field allows you to define a unit to track and center the map around. This is accomplished using the LAT/LNG data of the other units as supplied by status monitor broadcasts or by a manual REQUERY of the unit status data. This update will not be real-time and will be delayed by the frequency of status monitor updates but will keep the map focused and centered on a specific unit. * The “Track this Unit” setting will always override the general “Track Unit” setting. When tracking units the system will always attempt to calculate the nearest address and display that address for your reference.


Map View Overlays: By clicking the “Map Overlays” option turn this feature on while selecting either “Beat”, “Sector”, “District” or “Agency” will determine which series of map overlays are to be displayed. (See “Creating a Status Monitor Map Overlay Files” for more information on map overlays) • Map Files Installed / Configuration The Crimestar MDC software distributes with the basic mapping controls and components but not with street level map files that you will need for detail map displays. To obtain street level map files for your specific state (or states) visit the Crimestar web site download page at www.crimestar.com, download the map files desired and install those files into the \maps folder of the MDC installation directory. The mapping portion of the software references a file called “pwstreet.ini”. This file is installed into the WINDOWS directory of your computer. The pwstreet.ini file contains the following entries: BasePath=c:\crimestar\maps CellData= c:\crimestar\maps Make sure that the path reference in these entries properly points to the location of your map files, if those files have been installed to a different location than the default. Map Unit Icons: The graphic of the map shown above illustrates the use of static image icons showing a police car, fire truck, ambulance etc. While these icons do represent the unit type they cannot represent the unit’s direction of travel as reported by the GPS system. Alternately, unit icons (bitmap graphics) representing police, fire, ambulance/medical and other units will be displayed using color coded triangular graphic icons. Whenever possible the triangular icon will be oriented in the compass heading/ course direction (N, NE, E, SE, S, SW, W, and NW) of the unit as reported by the GPS signals from that unit.

Police Unit Icons:

Fire Unit Icons:

Medical Unit Icons:

Other Unit Icons:

This Unit Icon:


• Creating a Status Monitor Map Overlay File The Crimestar MDC software distributes with a companion program called mapoverlays.exe that can be used to create map overlays file (mapareas.xml) depicting various beat, sector district or agency boundaries as graphical semi-transparent color map overlays. Once the map overlay file (mapareas.xml) is created it must be manually distributed to each MDC workstation before the overlays will be viewable.


• Status Monitor Configuration / Appearance The font size and color attributes of the text status monitor can be altered by modifying the following html style sheet properties via the “mdcdefault.html” file. Color attributes are saved as 6 digit RGB hex values (EXAMPE: #000000=BLACK, #FF0000=RED, #00FF00=GREEN, #0000FF=BLUE, #FFFF00=YELLOW). The following represents the default values as found in the mdcdefault.html file used in DAYMODE. tr.UNIT_MISC { color: #FF0000; font-size: 14pt; vertical-align: top; font-family:Arial } tr.UNIT_AVAILABLE { color: #FFFFFF; font-size: 14pt; vertical-align: top; font-family:Arial } tr.UNIT_ARRIVED { color: #00FFFF; font-size: 14pt; vertical-align: top; font-family:Arial } tr.UNIT_DISPATCHED { color: #00FF00; font-size: 14pt; vertical-align: top; font-family:Arial } tr.UNIT_ENROUTE { color: #FFFF00; font-size: 14pt; vertical-align: top; font-family:Arial } tr.UNIT_TRANSPORT { color: #FFFF00; font-size: 14pt; vertical-align: top; font-family:Arial } tr.UNIT_RADIOLOG { color: #FFFFFF; font-size: 14pt; vertical-align: top; font-family:Arial } tr.UNIT_FREE { color: #FFFFFF; font-size: 14pt; vertical-align: top; font-family:Arial } tr.UNIT_CLEAR { color: #FFFFFF; font-size: 14pt; vertical-align: top; font-family:Arial } tr.EVENT_PENDING { color: #FFFFFF; font-size: 14pt; vertical-align: top; font-family:Arial } tr.EVENT_ACTIVE { color: #00FFFF; font-size: 14pt; vertical-align: top; font-family:Arial } tr.EVENT_COMPLETE { color: #00FF00; font-size: 14pt; vertical-align: top; font-family:Arial } tr.UNIT_HEADER { color: #FFFFFF; font-size: 14pt; font-family:Arial; font-weight:bold; background-color:#0000FF } tr.EVENT_HEADER { color: #FFFFFF; font-size: 14pt; font-family:Arial; font-weight:bold; background-color:#0000FF } tr.WT { color: #FFFFFF; font-size: 14pt; vertical-align: top; font-family:Arial } a.EVENT_PENDING { color: #FFFFFF } a.EVENT_ACTIVE { color: #00FFFF } a.EVENT_COMPLETE { color: #00FF00 } a.UNIT_MISC { color: #FF0000 } a.UNIT_AVAILABLE { color: #FFFFFF } a.UNIT_ARRIVED { color: #00FFFF } a.UNIT_DISPATCHED { color: #00FF00 } a.UNIT_ENROUTE { color: #FFFF00 } a.UNIT_TRANSPORT { color: #FFFF00 } a.UNIT_RADIOLOG { color: #FFFFFF } a.UNIT_FREE { color: #FFFFFF } a.UNIT_CLEAR { color: #FFFFFF } For more information on HTML Hex Color values, refer to an HTML editor, or any number of references freely available about formatting HTML text. Once the mdcdefault.html file has been configured with the parameters and options desired, the file can be manually copied from workstation computer to workstation computer to replicate the HTML configuration.


• Scratch Pad The MDC provides a simple scratch pad form that allows the user to enter and save notes or random information that they might need later during their shift of duty. The scratch pad data is persistent and will stay available to the user even if the MDC is powered off. When the user/unit logs off the MDC, the scratch pad file is automatically erased. To activate the MDC scratch pad, click the “SCR” button located on the top right portion of the MDC display, next to the Link and Ready Handshake indicators (discussed later in this document). Once the MDC Scratch Pad form is active, the user can enter notes and comments as desired.

*Note that there is no save button. All notes and comments are automatically save when the form is closed. Within the MDC Scratch pad form, the user may type CTRL+T to automatically insert a time stamp as is shown in the illustration above.


• Establishing an MDC Communications Link The Crimestar MDC workstation is designed to communicate with the MDC Controller over RF using either a dedicated Radio Modems operated by the law enforcement agency or via commercial carrier systems such as GPRS. These services provide the user with an IP connection to either the Internet or a VPN (Virtual Private Network). These commercial services are typically provided by cellular phone carriers for a monthly fee. Similar to Cellular telephone service, fees vary widely from carrier to carrier. Some companies offer discounted pricing to government entities or in conjunction with annual contracts etc. While this type of commercial service is constantly expanding it is not available in all areas. You should consult with your local carrier to determine if this type of service is available to you and the fees charged for the service. Additionally private IP based radio systems can be purchased from various suppliers.

By running the MDC controller on a machine that is connected to or exposed to either the Internet or your VPN (For security reasons a VPN is HIGHLY RECOMMENDED) with a fixed IP address, each MDC workstation can connect to and communicate with the controller via either the TCP or UDP protocol. When running in TCP mode a persistent connection is established between the MDC controller and its workstations. While this technology is highly reliable using fixed desktop machines with dedicated connections, use of this communication protocol can be problematic in mobile environment. Since (like cellular telephones) signals can drop when an MDC unit moves into a "dead-spot", the MDC software has error detection capabilities that will sense disconnects and automatically attempt to reconnect when a sufficient signal is again present.

Configuring the Crimestar Mobile Digital Communicator to communicate over your chosen infrastructure requires the system to be configured properly. The configuration settings that control how the MDC software behaves are located in the Crimestar.INI file. • Serial Communications (RF MODEMS) Settings The following INI settings should be used, when communicating via standard RF Modems that do not employ an IP protocol but rather accept serial data input from the computer for direct transmission. These setting exist (or should be added) to the [MDC] section of the INI file and will be required by both MDC Workstations and the MDC Controller. [MDC] COMTYPE=1 SERIAL_PORT= TX_DELAY= The COMTYPE setting of 1 is used to indicate to the MDC software that the program should send and receive all data via a serial port and will not use the TCP or UDP protocol. The SERIAL_PORT setting should be set to the actual serial port number on the computer that is connected to the RF modem.


Do not confuse the use of standard serial communications with other devices and services that use Windows Dial-up Networking Services (DuNS) to communicate serially to a modem for the purposes of providing an IP network type connection. When such a configuration exists the MDC software should be configured with either a COMTYPE=2 for IP communications or COMTYPE=3 for UDP communications. The TX_DELAY setting is used to cause a deliberate delay before sending data to the serial port for transmission. With some devices a delay can be necessary so that data is not sent too to the RF modem too fast, before it is ready to receive data. Dedicated RF modem systems can be very fast and reliable and are ideal in situations where commercial data services are limited or unavailable. Likewise, a use of a dedicated RF modem radio system avoids monthly fees to commercial carriers, but does require a substantial investment in equipment and the appropriate FCC licensing. For use with Crimestar’s MDC system any RF Modem used must be able to support the transmission of binary data. • IP Based Communications (GPRS or Private IP Radio System) Settings The following INI settings should be used, when communicating via either TCP or UDP protocol on an IP based communications infrastructure regardless of how that infrastructure is established. These setting exist (or should be added) to the [MDC] section of the INI file and will be required by both MDC Workstations and the MDC Controller. [MDC] COMTYPE=2 (2=TCP : 3=UDP) CONTROLLER_IP=192.168.1.1 PORT_ID=777 The COMTYPE setting of 2 is used to indicate to the MDC software that the program should send and receive all data via a TCP connection based protocol. The COMTYPE setting of 3 is used to indicate to the MDC software that the program should send and receive all data via a UDP connection-less protocol. On all MDC workstation computers CONTROLLER_IP setting should be set to the fixed IP address of the computer serving as the MDC Controller (192.168.1.1 is the default address). The PORT_ID should be set to the IP Port used by the software for communication between the MDC Controller and the MDC Workstation. Port 777 is the default. Please be sure to configure any network routers or firewalls to allow TCP/IP traffic to pass on the port defined in the Crimestar INI file. * Although modern technology (such as a VPN) provide sufficient security, some states still prohibit the use of commercial carrier networks or Internet connectivity on any machine or network that is also interfaced to your respective state law enforcement or motor vehicle computer system. When these types of security restrictions are applicable a private dedicated RF modem system may be a better communications choice.


• General Communications Settings Regardless of the communications backbone used (Serial Radio, TCP or UDP) there are some communications setting that are applicable to all environments. These more generic settings control certain aspects of the communication and can be adjusted as necessary to achieve more optimal performance. These setting exist (or should be added) to the [MDC] section of the INI file and will be required by both MDC Workstations and the MDC Controller but may have different values on different machines. [MDC] ADDRESS=1 MAXPACKETSIZE= MAXRETRYCOUNT= MAXRETRYDELAY= The ADDRESS setting should be unique for each MDC Workstation. The MDC address of zero ( ADDRESS=0 ) is reserved for the MDC Controller and there should be only one MDC controller in your MDC system. All MDC Workstations should have a unique address between 1 and 9999 that identifies that specific mobile device. If possible it may be easiest to simply use the vehicle ID number as the MDC Address number. If two or more cars have the same MDC address then they will constantly interfere with each other creating unreliable communications results. The MAXPACKETSIZE entry of the INI file is used to determine the maximum size of a data packet sent by the MDC software. This setting can be used to optimize communications throughput. Since all data transmissions are broken into packets a larger packet size means that each message consists of fewer packets. Fewer packets mean fewer radio transmissions and greater speed of message delivery. However, larger packets are more susceptible to interference, corruption or damage during transmission, thus packet sizes that are too large may require more retry transmissions which could slow message delivery or cause message delivery to fail. For IP based communications the default setting of 512 may be too low. Generally a setting of 1024 (1K) data packets is probably a good choice. However, this setting should not exceed the maximum packet size of network infrastructure you are using. For Serial RF based communications the default value of 512 is acceptable. When using Serial RF modems the same basic rules about packet sizes and optimizing performance apply however this value should never exceed that maximum capacity of input data buffer on the RF Modem. The MAXPACKETSIZE entry should generally be the same for all MDC computers (Workstations and Controller). Each time a data packet is transmitted the MDC sends an acknowledgment of packet receipt back to the sender. If a packet is sent and no acknowledgment is received, the sending MDC will resend the data packet. This is referred to as a RETRY. Retries are important in a mobile environment since the car may be temporarily going through a tunnel, behind a building or


otherwise be in a location where radio communications are temporarily interrupted. The MAXRETRYCOUNT setting determines how many times the MDC will attempt to deliver a data packet before declaring the recipient unreachable and giving up. The default is 5. If the communication backbone is based on a private IP radio system, that system MAY employ its own strategy for retries and failed delivery’s. In circumstances where a private IP based system buffers data and handles message retries external from the MDC software, this setting should not be increased, and the MAXRETRYDELAY (discussed below) may need to be increased to give that external process time to deliver the message before the MDC tries to send the data packet again. However in circumstances where no retry mechanism external to the MDC exists, increasing the MAXRETRYCOUNT value can increase the likelihood of a successful message delivery. The MAXRETRYDELAY setting determines how many seconds the MDC will wait without receiving an acknowledgment before attempting a retry sending a data packet. See Appendix “B” for a complete list of all the MDC INI file settings and their usage. • Link and Handshake Ready Indicators Once all the communications setting have been made to the MDC Controller and the MDC workstations they should immediately recognize each other’s presence on the system when the software is run. The MDC software provides some simple visual clues to alert you as to the communications status of the device. In the upper right corner of the MDC Controller/Workstation screen are three (3) small indicators. The Link (L) will change from red to green as soon as the MDC devices recognize that a network or communication path exists. The Handshake (H) indicator will change from red to green as soon as the MDC Workstation sends a connection signal and receives an acknowledgment message back from the MDC Controller. The connection signal is sent automatically as soon as the MDC software is started. The (G) indicator is used to display the status of the GPS interface (discussed later in this document). Once the Link and Handshake indicators are green, this is your signal that you can log on to the MDC system if you have not already done so. See the Unit Status Commands section of this manual for more specific details on logging on to the MDC system from a workstation. Note that while the MDC Controller can perform workstation type functions it is not necessary to login to the MDC Controller in order for it to function.


• Communication Statistics In an effort to assist the process of optimizing your data communications environment, the MDC software can expose or show you certain diagnostics statistics related to MDC packets and messages. To activate the hidden MDC Message Statistics Display popup window, double-click on the MDC# / Unit# display area. During normal operation this diagnostics display window should remain closed.

You can take a snapshot of the MDC Message Statistics at any given moment by clicking the “Save Snapshot” button on the MDC Message Statistics Display. This will automatically write the current MDC statistics and workstation information to a text file named: “MDC_Diagnostic_YYYYMMDDHHMMSS.txt (Where YYYYMMDDHHMMSS represents the Year (YYYY), Month (MM), Day (DD), Hour (HH), Minutes (MM), Seconds (SS) ). * The Packet Retry Counters track packets that were not ACK’d and subsequently re-sent. Retries and Failures are never tabulated for Broadcast and non-acknowledged messages and no deliver confirmation is required. In older version of the MDC software packet retry counters were level cumulative however this is no longer the case. If, for example, it requires 2 retries to deliver a message only the Packet Retry #2 counter is tabulated. In addition to the statistics display panel a radio TRACE window can be activated to monitor MDC data transmit and receive activity. Data is displayed as packetized blocks in sequence to how it is transmitted. When message encryption is turned off all text is human readable although


it is broken into chunks (defined by the MAXPACKETSIZE= setting) and presented in descending order with the most recent data packets and acknowledgment transmissions shown first. When message encryption is turned ON only the packet header information is human readable.

MDC data is usually compressed and encrypted (see: Message Security) thus only the record header will be human readable in the trace windows.


• MDC Message Security Few data transmission can be totally secure against someone with communication access, knowledge about the system and desire get into “hack” the data. However, some systems are inherently more secure than others and make it extremely difficult for unauthorized people to access the data. Crimestar MDC certainly falls into the category of a difficult system to “hack”. The MDC software uses address verification, user verification with passwords, as well as message compression, strong encryption and packetization. The sections below provide a brief explanation of how messages are handled and why these methods ensure the security of MDC data. Transmission Access: It should be mentioned that the first layer of data security is the mere access to it. Before anyone can read (or try to read) your data, they must first get a hold of it. Often the Dedicated Radio system or VPN that you use to transport MDC messages can be difficult for others to get into, and if hackers can’t get it, they can’t read it! Message Formats: MDC messages consist of a message header and message content. Message headers are not compressed or encrypted. Message content is compressed and encrypted. Message headers are variable length with an approx maximum size of 60 bytes and contain MDC delivery and source addresses, a packet sequence #, latitude, longitude, speed and compass heading data from the MDC’s GPS receiver, message flags and a 32 bit packet message checksum value (Used to verify the integrity of the data packet). Message Compression: MDC message data is compressed prior to being encrypted and packetized (see: Message Encryption & Message Packetization below) for transmission. The compression process minimizes the length of the MDC message string and subsequently reduces the amount of data to be sent over the message transport system. This reduces message size helps to optimize system performance. In addition to the performance benefits of message compression, it also provides an additional level of security, in that compressed data is a binary string and is not human readable. Message Encryption: After MDC message data is compressed into a non-readable binary string it is encrypted. Using the Advanced Encryption Standard 256 bit algorithm (AES256) as published by the National Institute of Standards and Technology (NIST) Federal Information Processing Standards, Publication 197. * Since one simple way to know if data has been successful decrypted is the ability to read or understand the results, having a successful decryption result in non-readable binary data makes detection of a successful decryption more difficult.


The MDC software will encrypt each message using one of 9,999 unique 256 bit (32-Byte) encryption keys selected at random. This means that each message sent is likely encrypted with a different encryption key than was used for the prior message. This random use of encryption keys helps to maximize system message security. While the 9,999 encryption keys imbedded into Crimestar provide excellent security, it only protects data from someone who does not have those encryption keys. Since the Crimestar MDC software may be obtained by other law enforcement agencies, outside of your organization, they too would have imbedded into the software, the same default encryption keys. Therefore, in order to further enhance security and make data encryption specific to each installation a system administrator can create a customized list of encryption keys for the MDC software to use. Simply create a text file named “MDCKEYS.TXT” where each new line (up to 9,999 lines) in the file contains a unique 32 character (32 Byte / 256 Bit) key and distribute that file to each MDC within your fleet or system. Example of MDCKEY.TXT file:

UZ7X3hHYEPvCVOY7NAqB2qBA9WSU6S83 NR2NB8OyW8K9JPa387R8Qm96yYDM4VRP zRJEnTTP24DCIRLTTEDYP0OYS3QZ5cWB DFDAMAE6oB8Hg1EC61TRK9UKVYDN4N7N RMWW9G0EVQCc1KRQFl61PoEDNVIVAT3D AL30O9v66C6V9Qw2OUL757AHX5CLT4GL QMCT35BEK10E747ZT9U6USU82IPSHCGK Etc. (up to 9,999 lines total)

Crimestar supplies a small utility program named KEYGEN9K.EXE to randomly create an “MDCKEYS.TXT” key file of 9,999 random 256 bit encryption keys. Each time the program is run a new set of random keys are generated. *Be sure that when you use this program you don’t run it on each MDC workstation but rather run it once to generate a file containing a list of encryption keys then distribute that file to all MDC’s within your fleet or system (Controller & Workstations). WARNING: If the encryption keys used by a workstation do not match the keys being used by the MDC controller the workstation and controller will not be able to successfully communicate message data. Message Packetization: MDC messages are delivered in a series of data packets. The configured maximum size of a data packet will determine the number of data packets that are required to get a message delivered. A very small message may be deliverable in a single packet while are large message will require several packets. When messages span multiple data packets, each packet will contain a portion of a compressed and encrypted message. Since compression and encryption (explained above) is performed on the message as a whole and not on each packet, individual packets are completely unreadable and cannot be unencrypted or decompressed. Once all required packets are received and verified for integrity they are reassembled, decrypted and decompressed to create the original data message to be processed and/or displayed by the MDC.


Address Verification: Before any data transactions can be performed from an MDC device the device’s MDC address must configured into the device security table of the MDC controller. All transactions from devices whose MDC address is not configured or authorized are rejected. As part of the MDC address verification process the MDC controller can also optionally verify the computer’s Media Access Control (MAC) ID of the remote MDC device. When MAC ID verification is enabled each MDC submitting transactions must provide both an authorized MDC # and an authorized MAC ID associated with that specific MDC address. Unlike MDC addresses, MAC ID’s are not part of the message header but rather are part of the encrypted data making the unauthorized interception of valid MAC ID’s virtually impossible. Transaction Type Verification: Once the MDC device (and optionally the device MAC ID) is confirmed as authorized, individual transactions can be submitted. However, individual transaction types can be authorized or de-authorized at the MDC controller on a device by device basis. This allows the same MDC system to be used for various agency types (i.e. Police, Fire, Ambulance, etc.) for dispatch purposes while preventing unauthorized access and maintaining the security of sensitive data local database and State/NCIC data .


The number of MDC devices that can be defined in the Device Security table is restricted to the number of MDC device licenses purchased. In addition to MDC device level control all MDC users are required to Log-On to the system by providing their UNIT ID (aka: Radio Call ID. This is the value used by CAD to identify the unit) and a Password. Users may also optionally provide additional login information such as their Officer ID, Radio #, Mileage etc. However the transaction activity of all users is regulated by the User Security authorizations for that specific user. Therefore any transaction submitted by a user must be a transaction that is authorized for BOTH that user id and the MDC device from which it is being submitted.

The MDC system has no restriction on the number of authorized users that you can defined in the system security tables. Unlike the device table the user table is not limited to the number of MDC licenses purchased. You will notice that we are using 3 different terms (UNIT IT, OFFICER ID & USER ID) when discussing the user security aspect of the MDC system. As was mentioned above the UNIT ID is the way a unit is defined and identified in CAD. The OFFICER ID is a value that defines a particular officer or person in the system. The USER ID is a more generic term that we are using


for the purposes of MDC user security because the value that is defined as the USER ID can be different depending upon how your organization operates. In some dispatch environments the UNIT ID is unique to a person and any time you see that unit id you know who that designation represents. In such cases it is reasonable to use the terms Unit ID and User ID synonomously and you would want the UNIT ID that is supplied on the MDC login screen to be used as the MDC Controller security USER ID for the purposes of logging into the system (This is the default configuration). In this environment enter the valid UNIT ID values in the USER ID field of the MDC User Security screen and associate a password with each respective value. In other environments, where the cad UNIT ID is not necessarily always unique to a person and is perhaps reused by multiple people on different days or on different shifts then it becomes a much less secure value to use for MDC Security purposes. In that environment it is better to use the OFFICER ID value supplied on the MDC login screen as the USER ID value for the purposes of MDC security. To force the MDC Controller to verify USER logins using the OFFICER ID value supplied on the MDC login screen, simply check the box labeled; “Always use Officer ID as User ID”. In this environment, enter the valid Officer ID values in the USER ID fields of the MDC User Security screen and associate a password with each respective value. When an MDC attempts to log in to the MDC controller, there are several verifications that take place and all verifications must succeed before an MDC login will be permitted. Please consider the following rules regarding MDC logins. • Regardless of any entry made into the MDC Controller User Security table, the UNIT ID

value supplied must be a valid unit ID as defined in the CFS/CAD Unit ID table of the RMS configuration system.

• Regardless of any entry made into the MDC Controller User Security table, the OFFICER ID

value, if supplied, must be a valid OFFICER ID as defined in the CFS/CAD Officer table of the RMS configuration system.

• Passwords are always case sensitive


The illustrations below give an over-view of the messaging process used between the MDC workstation and the MDC Controller. They also show, where the MDC Controller passes message transactions to the Crimestar Message Switch Gateway (MSG) product that those messages are also encrypted and an additional layer of device and user verification are performed before any transactions is submitted out to the state/NCIC systems.

Where Message output from either the MDC Workstation or MDC controller utilizes either the TCP or UDP protocols all messages could be routed thru the tunnel of a Virtual Private Network (VPN) for an additional layer of message security.

The MDC Controller performs device and user security verification on each message processed and performs either CAD or RMS (or Both) inquiries and transactions against the Crimestar Database. In addition to local Crimestar RMS query transactions, if both device and user security authorization exists, query requests can be re-encrypted and forwarded to the Crimestar Message Switch Gateway (MSG) system (Licensed Separately) to submit those respective transactions to State/NCIC systems.


• GPS Enabling the MDC Workstation The Crimestar MDC workstation can be used to visually show field event and unit data in a spatial map format. In order to do this, each MDC workstation must able to notify the MDC controller of its respective latitude and longitude coordinate location on an ongoing basis. To facilitate this process the MDC workstation software has been designed to interface with National Marine Electronics Association (NMEA 0183) compliant Global Positioning Satellite (GPS) receivers. Once interfaced to a GPS device the MDC workstation sends GPS latitude and longitude coordinate data with each respective transmission, and/or upon regular time intervals and/or upon traveling or changing coordinates within a predefined tolerance (movement). The serial port used by the MDC workstation to receive the GPS data, the time intervals and the movement parameters are controlled by the following Crimestar INI settings:

GPS_PORT= GPS_DISTANCE= GPS_TIME=

The above settings apply only to the MDC Workstation. They are meaningless on the MDC Controller. See Appendix B for information on INI file configuration settings. The MDC is designed to receive NMEA 0183 compliant input via a standard RS-232 serial com port at 4800 Baud, No Parity, 8 data bits and 1 stop bit (4800,N,8,1). Some GPS devices connect

to the computer via USB and create a virtual com port on your computer rather than connecting to a physical com port. These devices will also work, providing you have the device drivers to create the virtual com port and know which com port the device is assigned to. The Crimestar MDC software will not communicate directly via the Universal Serial Bus Controller. Once the appropriate comport has been identified, set the GPS_PORT entry of the

Crimestar INI file to that respective value and start or restart the MDC software to connect. (Note: a serial com port can only be opened by one program at a time, so if any other program is accessing that com port you must quit the other program before the MDC software will be able to open that port and read the GPS data) Once connected, the MDC workstation specifically watches for the input of an “RMC” data message. Make sure that the GPS device you use is configured to send RMC data strings. The following is an example of that specific input string: RMC - Recommended minimum specific GPS/Transit data RMC,225446,A,4916.45,N,12311.12,W,000.5,054.7,191194,020.3,E*68 225446 Time of fix 22:54:46 UTC A Navigation receiver warning A = OK, V = warning 4916.45,N Latitude 49 deg. 16.45 min North 12311.12,W Longitude 123 deg. 11.12 min West 000.5 Speed over ground, Knots 054.7 Course Made Good, True 191194 Date of fix 19 November 1994 020.3,E Magnetic variation 20.3 deg East *68 mandatory checksum


Once the MDC workstation begins receiving valid RMC data input from the GPS device the GPS indicator (G) in the upper right corner of the MDC Workstation will switch from red to green. This indicates that the MDC software is communicating with the GPS device and that a latitude and longitude coordinate fix has been established by the GPS receiver and that the navigation receiver warning indicator provided as part of the RMC data string is OK (”A”) . If the MDC workstation stops receiving RMC data from the GPS receiver for a period of more than 60 seconds or if the GPS receiver sends an RMC record with a navigation receiver warning indicator of “warning” (V) the MDC workstation GPS indicator (G) will revert back to red.

You can view the actual RMC data record being received by the MDC workstation software from the GPS receiver via the MDC Message Statistics Display diagnostic window. This is a special window that shows certain statistics and counters related to all MDC communications. To activate the Message Statistics Display window, double click on the Unit ID display indicator located at the bottom of the MDC display panel.

Once the Message Statistics Display window is active, the GPS NMEA DATA RECEIVED field will automatically update on the form in real time showing the most recent coordinate fix received from the GPS device.

For best system performance during normal MDC operation this special Message Statistics Display window should remain closed.


• GPS – Unit Tracking - Logging The MDC Controller can be configured to log the unit GPS coordinate information at regular time intervals creating snap-shots of field unit location data. This is accomplished by setting the LOG_LAT_LNG_FREQUENCY= configuration parameter of the Crimestar INI file to a value greater than zero where the value represents, in minutes, the frequency of the unit GPS logging. (See Appendix A –INI File Settings) Turning GPS logging on will create a text file named “MDCLLLOG.TXT” in the program directory/folder which will contain one record for each GPS enabled unit at each snapshot time interval. This text file is a variable length delimited file using the vertical bar “|” as the delimiter character. The file contains the Date-Time, MDC ID, Unit ID, Latitude, Longitude, Speed, Compass Heading and Unit Status. The file format looks similar to the following example:

10/17/2006 15:18:06|145|006|37237200|-121761000|19|273|AV Once a GPS log file has been created it can be later replayed using the “gpsreplay.exe” application which is also distributed during an MDC software installation. The GPS Replay application reads an MDCLLLOG file and replays the movement of each respective GPS enabled unit over a given period of time. * A STRONG WORD OF CAUTION: GPS enabling field units is one of the most important things you can do to aid in the safety of your officers. It can assist others in locating a unit in order to render aid or assistance in an emergency. While Crimestar MDC provides the ability to replay or retrace historical unit movement and activity, use of such information for administrative disciplinary actions is discouraged. If/when field officers view the MDC’s GPS as a “big brother” device that will be used against them, they may choose to intentionally unplug, break or disable the GPS device in order to avoid being tracked. If and when this happens, the more important officer safety aspect of GPS tracking is compromised!


• Unit Status Commands The following sections discuss the various unit status commands and the various steps or actions that can be taken to assign a unit to a particular status. Unit status commands can also be accessed by selecting the desired command from the Unit Status menu pad on the main program menu. In addition to the menu, Unit Status commands are typically performed by clicking a series of status buttons located on the lower portion of the

MDC display. The unit status command buttons are always visible to the user and are labeled with a 3 or 4 character plain text abbreviation for the status command they represent. The labels can be modified to reflect short abbreviations or codes that are more specific or meaningful to your organization. You may customize the labels on the buttons or chose which buttons to display and which buttons to hide by using the Buttons & Display (Status) option from the Options Menu.

As buttons are shown or hidden the remaining buttons on the status button panel will automatically resize to fill the defined status button area. Obviously the more buttons you display the smaller each button becomes. Fewer buttons result in each button being larger and can be easier to use with certain touch screen computers. Note that hiding a button does not disable the function on the Status Menu, however disabled functions will not be selectable on the Status Button Configuration form.


• In-Service / Log-on

Status Monitor Code: AV To place your unit in-service with CAD and log-on to the MDC, double-click the Blue Keys

button on the far left of the MDC control panel. This will provide you with a popup MDC Log-on dialog form where you will specify your CFS UNIT ID as used in CAD and the MDC password as configured at the MDC controller (See Appendix: B). For

security reasons the user is not prompted or provided a list of valid unit id’s from CAD. While the user may input any value, the input will be validated against a list of known authorized unit id codes defined for CAD and only valid unit id codes will be permitted to log on to the MDC system.

* An MDC workstation must be logged-on to the MDC controller and CAD before any transactions can be performed.


• Dispatch

Status Monitor Code: D To Dispatch your unit to an EVENT via the MDC, click the “DISP” (ALT-D) command button. When you do, you will be prompted with a dialog screen to specify the Event # and an optional comment. The Unit # field will be pre-filled with your log-in unit id and is not editable. Provide an event # to be dispatched or attached to, the click the Transmit Button (Alt-T) to send the dispatch transaction request to the MDC controller.

When the MDC Controller receives and processes your transaction, it will return a confirmation unit status message. When the MDC workstation receives this confirmation from the controller, the Unit Status window will change to: “DISP:”+Event # and your new unit status will be represented on the status monitor window the next time the data on that windows refreshes. The example illustration below shows unit 112 logged on to MDC #1 (ADDRESS=1) and indicates that the unit is in a DISPATCH status attached to event #0405070001. The Mobile Digital Communicator system follows the same basic logic and business rules as does, Crimestar CAD. Before a unit can be dispatched to an event, the unit must be in an AVAILABLE status. Any attempt to dispatch a unit that is not in an available status will result in an error message being returned. If a unit is not currently in an AVAILABLE status and it is necessary to dispatch a unit to a different event, the unit should first be FREE’d using the free command.


• Enroute

Status Monitor Code: EN To Enroute your unit to an EVENT via the MDC, click the “ENR” (ALT-E) command button. In order for an Enroute command to be processed, your unit must already be dispatched to the event. You will be prompted with a dialog screen to provide an optional comment. The Unit # field will be pre-filled with your log-in unit id and is not editable. Click the Transmit Button (Alt-T) to send the enroute transaction request to the MDC controller.

When the MDC Controller receives and processes your transaction, it will return a confirmation unit status message. When the MDC workstation receives this confirmation from the controller, the Unit Status window will change to: “ENRT:”+Event # and your new unit status will be represented on the status monitor window the next time the data on that windows refreshes. The example illustration below shows unit 112 logged on to MDC #1 (ADDRESS=1) and indicates that the unit is in an ENROUTE status attached to event #0405070001. The Mobile Digital Communicator system follows the same basic logic and business rules as does, Crimestar CAD. However unlike CAD which has the ability to place a unit enroute directly from an Available status, this is not permitted via the MDC. When using the MDC system to place a unit enroute, the unit must first be in a DISPATCH status. Any attempt to enroute a unit that is not in a dispatch status will result in an error message being returned.


• Arrive

Status Monitor Code: A To Arrive your unit to an EVENT via the MDC, click the “ARV” (ALT-A) command button. You will be prompted with a dialog screen to provide an event #, location and comment. The Unit # field will be pre-filled with your log-in unit id. In order for an arrive command to be processed, the unit must either already be dispatched to the event, or you must specify the Event # on the popup dialog form. If you are already dispatched on the event, you do not need to specify and Event #. If you are not already dispatched to the event you MUST specify an event # so that CAD knows which event to attach your unit to. If you do not specify a Location it will be presumed by dispatch that you are at the location of the event. However, in some circumstances you can be attached to an event, but be at a different location. The location field on the Unit Status Arrive dialog form allows you to specify that alternate location. Click the Transmit Button (Alt-T) to send the arrive transaction request to the MDC controller.

When the MDC Controller receives and processes your transaction, it will return a confirmation unit status message. When the MDC workstation receives this confirmation from the controller, the Unit Status window will change to: “ARRIVE:”+Event # and your new unit status will be represented on the status monitor window the next time the data on that windows refreshes. The example illustration below shows unit 112 logged on to MDC #1 (ADDRESS=1) and indicates that the unit is in an ARRIVED status attached to event #0405070001. The Mobile Digital Communicator system follows the same basic logic and business rules as does, Crimestar CAD. To arrive a unit on an event without explicitly specifying an event # the unit must be first attached to that event and in either a DISPATCH or ENROUTE status. Any attempt to arrive a unit that is not in a dispatch status will result in an error message being returned. If you explicitly reference an event # on the arrive unit form, then the unit will be attached to and arrived on the event. If the unit is attached to an event, and the user explicitly specifies a different event # on the MDC arrive form the command will be rejected and an error message will be returned.


• Clear

Status Monitor Code: AV To clear your unit from an EVENT via the MDC, click the “CLR” (ALT-C) command button. You will be prompted with a dialog screen to provide a disposition and an optional comment. The Unit # field will be pre-filled with your log-in unit id. In order to clear an Event the unit must already be arrived. If the unit is not already arrived, use the FREE command rather than the clear command. When clearing an event, you must provide a disposition code. You may also optionally provide a comment. Click the Transmit Button (Alt-T) to send the clear unit transaction request to the MDC controller.

When the MDC Controller receives and processes your transaction, it will return a confirmation unit status message. When the MDC workstation receives this confirmation from the controller, the Unit Status window will change to: “AVAILABLE” and your new unit status will be represented on the status monitor window the next time the data on that windows refreshes. The example illustration below shows unit 112 logged on to MDC #1 (ADDRESS=1) and indicates that the unit is in an AVAILABLE status. The disposition code used on the clear unit form is selected from a list of pre-defined or authorized codes downloaded from the Crimestar RMS/CAD database via the MDC controller. To load or re-load the codes used by the MDC, select LOAD EDIT CODE TABLES from the Options menu. When clearing from an event, a disposition code is required. Disposition related comments are optional.


• Free

Status Monitor Code: AV To free your unit from an EVENT via the MDC, click the “FREE” (ALT-F) command button. You will be prompted with a dialog screen to provide an optional comment. The Unit # field will be pre-filled with your log-in unit id. In order to free a unit, the unit must either be in a miscellaneous status or already attached to an event and be in a dispatched, enroute or arrived status. Click the Transmit Button (Alt-T) to send the free unit transaction request to the MDC controller.

When the MDC Controller receives and processes your transaction, it will return a confirmation unit status message. When the MDC workstation receives this confirmation from the controller, the Unit Status window will change to: “AVAILABLE” and your new unit status will be represented on the status monitor window the next time the data on that windows refreshes. The example illustration below shows unit 112 logged on to MDC #1 (ADDRESS=1) and indicates that the unit is in an AVAILABLE status. When multiple units are dispatched (or attached) to an event and a unit FREE’s from that event, a priority Digital Dispatch Warning message will be sent to the other event related units to notify them which dispatched/responding units is no longer responding. In a digital dispatch environment this is an important safety issue since without notification a responding unit may be left unaware that their fill/backup unit is no longer responding. If desired this functionality can be suppressed using the ‘DISABLE_FREE_UNIT_ALERT=ON’ setting in the Crimestar.ini file. (See Appendix B – INI File Settings)


• Miscellaneous Status

Status Monitor Code: M A Miscellaneous status is a non-event related status used to indicate that the unit is currently busy with an activity and generally unavailable for dispatch. To place your unit on a miscellaneous status via the MDC, click the “MISC” (ALT-M) command button. You will be prompted with a dialog screen to provide a location and an optional comment. The Unit # field will be pre-filled with your log-in unit id. In order to place a unit on a miscellaneous status the unit must be in an available status. Click the Transmit Button (Alt-T) to send the miscellaneous status unit transaction request to the MDC controller.

When the MDC Controller receives and processes your transaction, it will return a confirmation unit status message. When the MDC workstation receives this confirmation from the controller, the Unit Status window will change to: “MISCELLANEOUS” and your new unit status will be represented on the status monitor window the next time the data on that windows refreshes. The example illustration below shows unit 112 logged on to MDC #1 (ADDRESS=1) and indicates that the unit is in a MISCELLANEOUS status. To make a unit currently on a miscellaneous status available again, use the FREE command. Units do not “clear” from a miscellaneous status. The clear command is reserved for units attached to events, and since a Miscellaneous status is not event related the clear command is not appropriate.


• Vehicle Stop

Status Monitor Code: A To place your unit on a vehicle stop via the MDC, click the “VEHS” (ALT-V) command button. You will be prompted with a dialog screen to provide a license plate, state, location and comment. The Unit # field will be pre-filled with your log-in unit id. In order to place a unit on a vehicle stop the unit must be in an available status. Click the Transmit Button (Alt-T) to send the miscellaneous status unit transaction request to the MDC controller. * It is strongly recommended that for officer safety reasons, units ALWAYS advise dispatch of vehicle stops via voice radio instead of or in addition to using the MDC. It is important that other units who may not be monitoring their computer know of your activity.

When the MDC Controller receives and processes your transaction, the Unit Status window will change to: “ARRIVE:” + Event # and your new unit status will be represented on the status monitor window the next time the data on that windows refreshes. The license plate state code used on the vehicle stop command form is selected from a list of pre-defined or authorized codes downloaded from the Crimestar RMS/CAD database via the MDC controller. To load or re-load the codes used by the MDC, select LOAD EDIT CODE TABLES from the Options menu.


• Out of Service

(Removed from Status Monitor) To out-of-service your MDC, click the Blue-Keys button on the far left of the MDC control panel. This will provide you with a Log-off dialog. Depending upon the CAD_LOGOUT setting of the Crimestar INI file on the controller (see Appendix: B ), this action may also remove your unit ID from the CAD status monitors and take you completely out of service in CAD.


• Event Status Commands • Event Comment When a Unit is dispatched or otherwise attached to an event it is often necessary or desirable for a unit to make a comment directly associated with the EVENT so that the comments appear as part of the Event History. This can be done using the RADIO LOG command. Since the unit is attached to the Event any comment associated with the UNIT automatically becomes part of the EVENT history. • Other System Commands • Admin Messages The MDC Administrative Message format provides a way for general car-to-car and car-to-dispatch messages to be send digitally. The Admin Message format can accept up to 5 different deliver addresses at once. The deliver address is the Login Unit ID of the destination MDC. To send a broadcast message to all operational MDC units use a broadcast delivery address of “BCST”. To send a message specifically to dispatch via a CAD message, use a delivery address of “DISP” followed by the dispatcher position you wish to communicate with. Thus to send a message to Dispatch position #1 you would address your admin message to “DISP1”;Dispatch position #2 = “DISP2”; etc. (Use the PSAP_POSITION setting of the Crimestar INI file to designate dispatch position #’s). Once a delivery address has been provided you may compose a simple text message of up to 4000 characters. Messages without any message text and at least one destination address will not be transmitted.

After entering the desired delivery address and message click the TRANSMIT button. Note that the TRANSMIT button can be activated using the ALT+T accelerator key sequence. When REPLYing to an admin message, the MDC software can optionally copy the original message into the reply, to help maintain the message subject continuity. Use the Options menu to turn this feature on or off.


The admin messaging capability of the MDC system is not an email system, per-se! Messages are only delivered to currently active (logged-on) MDC units, similar to an instant messaging system and are not saved for future or later delivery similar to the way email works. Administrative Messages may optionally be logged to disk at the MDC Controller by setting an INI file option. See LOG_ADMIN_MESSAGES in Appendix “B”.


• Performing CAD-RMS System Queries The MDC system allows you to perform a variety of queries against both Crimestar Computer Aided Dispatch (CAD) and the Crimestar Records Management Systems (RMS). The initiate a query click the Query (QRY) button located on the MDC display panel. You may also use the Accelerator key sequence of ALT+Q to activate this option.

When the Query (QRY) button is clicked the top row of command buttons will change to reveal the various query related buttons.

Each query related command button performs a specific task and will, if necessary, activate a popup window so that additional information or search criteria may be provided. • Query Event A query event returns a detail display of a specific event along with all associated unit activity. The query event command activates a simple popup dialog window that allows the user to specify the event number of the CAD event that they wish to query. The event number may be a full qualified 10 digit event number of may be just the sequence number for that event. If for example, the date is 07/04/2005 and the user enters only the number “1” then the query would be performed for event number 0507040001 accordingly. After entering the desired event number click the TRANSMIT button. Note that the TRANSMIT button can be activated using the ALT+T accelerator key sequence. The query will be submitted to the MDC Controller for a database search for that event and the appropriate and complete event detail data will be returned as a message to the requesting MDC.


• Query Unit History A query unit history returns a summary display list of all the status transactions and radio log comments for a specific unit on a specific date. The query unit history command activates a popup dialog window that allows the user to specify the unit number and date for the CAD unit history that they wish to query. The default unit ID will be the ID of the current MDC login and the default date will be the current date as indicated by the computer. Either of these values may be modified. After entering the desired unit number and date click the TRANSMIT button. Note that the TRANSMIT button can be activated using the ALT+T accelerator key sequence. The query will be submitted to the MDC Controller for a database search for that unit id and the appropriate unit history data will be returned as a message to the requesting MDC. Unit History summary data is displayed in its natural order from oldest to newest and provides the Unit ID, Status, Event # (if applicable), Date/Time the unit entered that status and any comment that may have been made at the time. Summary data is color coded based on the unit status code and the color definitions defined for the status monitor in the “mdcdefault.html” file.

Event numbers (if any) referenced in the Unit History summary list will all serve as links to retrieve an event detail record message for that respective event.


• Query Person A query person returns a summary display list, up to a maximum of 25 records from the Crimestar RMS Master Name Index file that specifically match the search criteria provided. If the search criteria to too broad, the result of the query may contain more than 25 records. If/when this happens the MDC controller will not return a summary list of names, but rather notify the requesting MDC that too many records matched and the search criteria should be narrowed. The query person command activates a popup dialog window that allows the user to specify either a last name, first name, Date of Birth (DOB), Drivers License Number (DL#) and DL State. The search may be conducted using any or all of the search criteria fields. This form contains no default values except for the Local, DL and Warrant search options which are defaulted to ON. After entering the desired person search criteria click the TRANSMIT button. Note that the TRANSMIT button can be activated using the ALT+T accelerator key sequence.

The person query will be submitted to the MDC Controller for a database search based on the search criteria provided by the user. Once the database search is completed, the appropriate master name index record(s) will be returned as a

message to the requesting MDC. The summary return data for a Person query displays the Last Name, First Name, DOB, Race, Sex, Height, Weight, Hair Color and Eye Color. While this is likely not all the information that is available on the subject(s), it should be enough to narrow down or allow the user to select the specific master name Index record that they wish to view.

The last name value on each row is underlined and functions as a Link to that specific record. Clicking on that link will cause the MDC workstation to initiate a query for that specific record. The results of that new specific record query will be returned to the requesting MDC workstation as a new message containing the detail information for that subject. The number of records returned in a summary list can be controlled via the MAX_SUMMARY_MATCH INI setting on the controller. See Appendix “B”.


When a detail person record is returned from the local Crimestar RMS database, information is gathered primarily from the Master Name Index (MNI) file. In addition to the MNI data a warrant and caution check is performed for that specific subject any associated warrant and caution data is presented at the top of the page. While the Crimestar RMS MNI file maintains an address history for each subject, only the most recent address of record is returned. Likewise, if an MNI photos for the subject are available only the most recent photo is returned to the MDC.

A detail person record will contain a list of that subject’s involvements where each involvement is a hyperlink to the RMS detail record for that MNI involvement. • Query Person - Image Size / Reduction Sending an image to the MDC can consume considerable radio / communications band-width and can, depending upon your network, significantly delay message response time. By reducing the image size the number of packets required to deliver a message can be reduced. Reducing the total number of message packets will speed up the delivery of the message and increase overall system performance. How much to reduce the image size will depend upon the screen resolution of the MDC field units and personal preference. Below are two examples of the same image. When full sized the image is 250x250 pixels and measures approx 3.5” square. At that size the image is 30,000 bytes consuming considerable band-width. Additionally an image at this size will consume a considerable amount of screen space when displayed. This may cause other data fields on the screen to wrap or be shifted altering the readability of the form.


30,000 byte image. This image measures approx 3.5” square. It was captured at: 250 x 250 pixels, (72 pixels per inch) 24 bit (16 Million ) color resolution. The same image can be reduced to a much smaller size that is still very legible. Here is the same image reduced to 75x75 pixels at 24 bit (16 Million ) color resolution resulting in a file that measures approx 1” square. This reduced size image consumes only 4.5K (4,500 bytes) making it much easier and more efficient to transmit.


• Query Vehicle A query vehicle returns a summary display list, up to a maximum of 25 records from the Crimestar RMS Master Vehicle Index file that specifically match the search criteria provided. If the search criteria to too broad, the result of the query may contain more than 25 records. If/when this happens the MDC controller will not return a summary list of vehicles, but rather notify the requesting MDC that too many records matched and the search criteria should be narrowed. The query vehicle command activates a popup dialog window that allows the user to specify either a license plate, VIN # or owner name. The search may be conducted using any or all of the search criteria fields. This form contains no default values except for the Local, Reg and Warrant search options which are defaulted to ON. After entering the desired vehicle search criteria click the TRANSMIT button. Note that the TRANSMIT button can be activated using the ALT+T accelerator key sequence. When the query vehicle summary list is returned, it shows the vehicle license plate, state, year, make, model, and vehicle style. The license plate field serves as a link to return a specific vehicle detail record for the selected record. The number of records returned in a summary list can be controlled via the MAX_SUMMARY_MATCH INI setting on the controller. See Appendix “B”.

The license plate state field used on the query vehicle form is selected from a list of pre-defined or authorized codes downloaded from the Crimestar RMS/CAD database via the MDC controller. To load or re-load the codes used by the MDC, select LOAD EDIT CODE TABLES from the Options menu.


• Query Article (Property) A query article returns a summary display list, up to a maximum of 25 records from the Crimestar RMS property and evidence file that specifically match the search criteria provided. The query article command activates a popup dialog window that allows the user to specify the property search criteria that they wish to query. After entering the desired search criteria click the TRANSMIT button. Note that the TRANSMIT button can be activated using the ALT+T accelerator key sequence.

When searching for property you may enter partial search criteria if you wish. Example: To search for all property items where the serial number starts with a “123” you may simply enter “123” in the serial number field. If the search criteria are too broad, the result of the query may contain more than 25 records. If/when this happens the MDC controller will not return a summary list of property items, but rather notify the requesting MDC that too many records matched and the search criteria should be narrowed. The query will be submitted to the

MDC Controller for a database search for that unit id and the appropriate unit history data will be returned as a message to the requesting MDC. The Article Summary Return will contain the Article, Brand, Model, Description and related Incident#. The Article serves as a link to recall details on a specific property item. The number of records returned in a summary list can be controlled via the MAX_SUMMARY_MATCH INI setting on the controller. See Appendix “B”.


• Query Boat Since Crimestar RMS does not contain a module or file specific to boats, a query boat transaction does not return a local Crimestar response. However, if the Crimestar Message Switch Gateway (MSG), has been purchased and installed, the Query Boat transaction will be submitted to your respective state system.

• • Query Free Form The Query Free Form input is intended to provide command line query pass-through transaction capability to the State/NCIC system. This feature is only applicable if the Crimestar Message Switch Gateway (MSG), has been purchased and installed. The syntax that you use on the Query Free Form screen will vary from state to state and is defined in the documentation for your state system.

• • •


• • Query Gun Since Crimestar RMS does not contain a module or file specific to boats, a query boat transaction does not return a local Crimestar response. However, if the Crimestar Message Switch Gateway (MSG), has been purchased and installed, the Query Boat transaction will be submitted to your respective state system.

• • Query Hazmat Since Crimestar RMS does not contain a module or file specific to hazardous materials, a query Hazmat transaction does not return a local Crimestar response. However, if the Crimestar Message Switch Gateway (MSG), has been purchased and installed, the Query Hazmat transaction will be submitted to your respective state system.


• • Query MDC Units A query MDC Units returns a summary display of all the Unit ID’s currently logged-on to the Crimestar MDC system. The display shows both the UNIT ID and the corresponding computer MDC # as known by the controller at the time of the query. Upon clicking the Query MDC Units command button the query is transmitted immediately. This query does not use a popup dialog.

When performing this same query from the controller, the display will also show the date and time of the last transmit activity from that specific MDC unit and if (COMTYPE=2) running in a TCP based communications environment, it will also show you the Connection ID and IP Address of the MDC units. Once an MDC address communicates with the controller, the controller will remember that MDC address and register it. Once the number of MDC addresses registered equals the number of MDC workstation licenses purchased, attempts by additional MDC Addresses to login to the controller will be denied. Units can logon and logoff of MDC addresses as needed but the number of MDC licenses purchased will always limit the number of unique MDC Addresses than can be registered with the controller.


• Saving & Recalling Workstation Messages To/From Disk. The MDC Workstation software saves all session messages to a file for later retrieval. Session messages are always automatically deleted once the user logs off the MDC. Additionally the MDC provides users with the ability to explicitly save message to a file for later retrieval. Explicitly saved messages are not automatically deleted when the user logs off, and will remain available unit they are explicitly deleted. This can be very useful since all recent messages are stored in 20 message, memory resident circular message queue. These 20 most recent messages are strictly held in the computer’s memory while the MDC program is running. When the MDC program is shutdown or in the event that the workstation computer loses power these messages will be lost. To explicitly save a message to disk, the message must be displayed on the currently active Display Panel. Using the

command button bar on the bottom of the display panel click the Save button or activate it by using the ALT+S key sequence. Once the save message

command is initiated a Message Save dialog box will appear. This dialog box prompts the user to provide a plain text message title that will be used to later identify the message for retrieval. Once a title is provided, click the Save button or activate the save using the ALT+S accelerator keys. The Message Save Dialog box will disappear and the message will be saved to the disk resident message file. Note that saving a message to disk does not remove the message from the circular message queue and does not clear it from the screen. To recall a saved message, click the Recall (RCL) command button on the command button bar located on the bottom of the display panel. This will activate the Message Recall dialog window. From this


form both session message and explicitly saved messages can be recalled to the active display panel by selecting the desired message from the appropriate message list and clicking the Recall button. Note that recalling a message, sends a copy of the message to the active display panel and the original message will stay in the save file. From this dialog window saved message may also be deleted from the disk resident message file. Deleting a message from the disk resident message file does not remove the message from the circular message queue (if it is still in the queue) and does not clear it from the screen (if it is displayed on any of the display panels). *Remember session messages are automatically saved and automatically deleted when the user/unit logs off of the MDC. Explicitly saved message remain in the MDC workstation until explicitly deleted. The disk resident message file is actually two files that work in conjunction with each other. Those files appear in the same directory where the MDC software has been installed and is running. The files are named “mdcmsave.dbf” and “mdcmsave.fpt”. In order to ensure proper save operation it is important that windows security allow that the two files be modified. Additionally, if these files are deleted from disk, all saved messages for the specific workstation will be lost and cannot be recovered.


• Appendix A – Files Installed The following is description of the Crimestar MDC installation and the files included in it. BuildSQL.app – program support file used to build connections to an SQL Server database when running the Enterprise Edition of CAD. Cadengine.dll – program support file used by the MDC Controller to post transactions to the RMS/CAD database. Crimestar.ini – This is a persistent, workstation specific, configuration file. This file is installed only if it does not already exist in the installation folder. Gdiplus.dll – Microsoft Windows Graphical Driver Interface support library. Gpsreplay.exe – Companion program to replay the MDC Lat/Lng Log (mdclllog.txt) files. ipdaem50.ocx – This is a TCP-IP Active-X control used by the MDC Controller to communicate transactions with MDC workstations. ipport50.ocx – This is a TCP-IP Active-X control used to communicate transactions to the MDC Controller. Map_Overlay.exe – This is a companion program that can be used to create a map overlay (polygon) file. Mdccom.exe – This is the primary MDC program file. Mdc_alert.wav – wav sound file, used to alert the user to awaiting priority message. Mdc_confirm.wav – wav sound file, used to indicate audio confirmation of a command. Mdc_citytozip.dbf – city/zip code database lookup file. Mdc_fire_e.bmp – bitmap graphic used on map display (Fire Unit Traveling East). Mdc_fire_n.bmp – bitmap graphic used on map display (Fire Unit Traveling North). Mdc_fire_ne.bmp – bitmap graphic used on map display (Fire Unit Traveling North East). Mdc_fire_nw.bmp – bitmap graphic used on map display (Fire Unit Traveling North West). Mdc_fire_s.bmp – bitmap graphic used on map display (Fire Unit Traveling South).


Mdc_fire_se.bmp – bitmap graphic used on map display (Fire Unit Traveling South East). Mdc_fire_sw.bmp – bitmap graphic used on map display (Fire Unit Traveling South West). Mdc_fire_w.bmp – bitmap graphic used on map display (Fire Unit Traveling West). MDC Operations Manual.pdf – This is an Adobe Acrobat PDF (Portable Document Format) file that explains how to use the features and capabilities of Crimestar CAD. This file can be read and printed using the Adobe Acrobat reader program provided free from Adobe Systems. Mdc_medical_e.bmp – bitmap graphic used on map (Med Unit Traveling East). Mdc_medical_n.bmp – bitmap graphic used on map (Med Unit Traveling North). Mdc_medical_ne.bmp – bitmap graphic used on map (Med Unit Traveling North East). Mdc_medical_nw.bmp – bitmap graphic used on map (Med Unit Traveling North West). Mdc_medical_s.bmp – bitmap graphic used on map (Med Unit Traveling South). Mdc_medical_se.bmp – bitmap graphic used on map (Med Unit Traveling South East). Mdc_medical_sw.bmp – bitmap graphic used on map (Med Unit Traveling South West). Mdc_medical_w.bmp – bitmap graphic used on map (Med Unit Traveling West). Mdc_other_e.bmp – bitmap graphic used on map (Other Unit Traveling East). Mdc_other_n.bmp – bitmap graphic used on map (Other Unit Traveling North). Mdc_other_ne.bmp – bitmap graphic used on map (Other Unit Traveling North East). Mdc_other_nw.bmp – bitmap graphic used on map (Other Unit Traveling North West). Mdc_other_s.bmp – bitmap graphic used on map (Other Unit Traveling South). Mdc_other_se.bmp – bitmap graphic used on map (Other Unit Traveling South East). Mdc_other_sw.bmp – bitmap graphic used on map (Other Unit Traveling South West). Mdc_other_w.bmp – bitmap graphic used on map (Other Unit Traveling West). Mdc_police_e.bmp – bitmap graphic used on map (Police Unit Traveling East). Mdc_police_n.bmp – bitmap graphic used on map (Police Unit Traveling North).


Mdc_police_ne.bmp – bitmap graphic used on map (Police Unit Traveling North East). Mdc_police_nw.bmp – bitmap graphic used on map (Police Unit Traveling North West). Mdc_police_s.bmp – bitmap graphic used on map (Police Unit Traveling South). Mdc_police_se.bmp – bitmap graphic used on map (Police Unit Traveling South East). Mdc_police_sw.bmp – bitmap graphic used on map (Police Unit Traveling South West). Mdc_police_w.bmp – bitmap graphic used on map (Police Unit Traveling West). Mdc_receive.wav – wav sound file used to indicate receipt of a message. Mdc_reject.wav – wav sound file used to indicate rejection of a command. Mdc_status.wav – wav sound file used to indicate a status change. Mdc_thiscar.bmp – bitmap graphic file used on map display. MDCCompression.fll - FoxPro Linkable Library file. MDCEncryption.fll - FoxPro Linkable Library file. Map Files –(F1, M0, M1, M2, M3, M4, M5, M6, M7, M8, M9, M10, M11, M12, M13, M14,

M15, R0, R1, R2, R3, R4, R5, R6, R7, R8, R9)

*** Street level map files are not distributed with this software installation and must be downloaded separately from the Crimestar internet web site.

Msvcr71.dll – Microsoft Visual C++ 7.1 runtime library. Pwstrv2.ocx - Associated Control used for CAD Geographic references. mcast50.ocx – This is an IP multicast Active-X control used broadcast messages and intercommunicate transactions between multiple networked CAD workstations. Mscomm32.ocx – Microsoft common control library Pwstreet.ini – Initialization / Configuration file for the Pwstrv2.ocx file Pwstrv2.ocx - Associated Control used for CAD Geographic references. Udppor50.ocx – This is an IP/UDP Active-X control used broadcast messages VFP9r.dll - Microsoft Visual FoxPro 9 runtime library.


VFP9renu.dll - Microsoft Visual FoxPro 9 runtime library. VFP9t.dll - Microsoft Visual FoxPro 9 runtime library. • Modifying / Changing Distributed Files Changing the way icons appear on the map: The bitmap files used to render images of units on the MDC map may be modified or replaced with other customized bitmap images of the same name, causing the MDC map to display your image(s) instead of the images shipped with the MDC product. • Images MUST of a Windows Bitmap file type. • The color of the pixel in the upper left corner of the bitmap image will be the color used as

the transparency color for the image. Changing the sounds and alert tones: The .wav files that are used to sound various audible notifications may be replaced with other .wav files to create different sounds and audible alerts. The duration of the .wav file should be kept as short as possible to avoid delaying MDC processing.


• Appendix B - INI File settings The Crimestar Mobile Digital Controller/Mobile can work differently depending upon how various entries in the [MDC] section of the CRIMESTAR.INI file are set. This section will explain the available INI file settings that relate to the MDC and will explain what they do. The description of each INI file entry will be prefixed with a reference to indicate if the entry is relevant to the MDC Controller (Controller), Mobile (Mobile) or both (Controller & Mobile). Entries prefixed as (Dynamic) are entries that need not be configured directly within the INI file as they are dynamically changed by the program as a result of user selected preferences. • (Controller & Mobile) The Address entry holds the logical address of the MDC device. An

MDC address can be any value from 0 to 9999. A device address of zero (0) is reserved for the MDC controller, and there can only be one controller in the MDC network. MDC addresses used need not be sequential however; no two field units should be configured to the same MDC address. All MDC addresses must be unique.

ADDRESS=1 The MDC Address is shown on the panel display immediately to the right of the console command buttons and just above the current unit status indicator display.

• (Controller) The Alert Activation entry is used to flag certain messages as a cautionary

message. When the MDC Controller processes query requests it scans the return results of that request searching for a specific keyword or phrase as defined by the alert activation entry. If that specific keyword or phrase is found in the result text the message is flagged as a cautionary and returned to the requesting user/MDC as a priority message. Multiple keywords or phrases can be defined by separating them with a comma

ALERT_ACTIVATION_STRING= keyword, keyword, keyword Example: Setting the ALERT_ACTIVATION_STRING=WARRANT,GUN would result in any query return that contains the word “WARRANT” or the word “GUN” being flagged as cautionary and sent as a priority message.

• (Controller & Mobile) By default when the MDC receives a message it displays the message

waiting indicator and waits for the user to request the display of the next waiting message. In this circumstance even is the users display screen has been cleared no message will be displayed until the user specifically requests it by pressing the Next Message button. However, some agencies prefer that if the user screen in blank or clear when a message arrives that the message be displayed automatically. Use the following INI setting to turn on this automatic display when the users screen is blank or clear. (Default is OFF)

BLANKSCREEN_AUTODISPLAY=ON


• (Controller & Mobile) The BUTTON_ INI settings can be used to change the unit status

command buttons to reflect short (3-5 character) user defined labels for certain unit status commands.

BUTTON_DISPATCH= BUTTON_ENROUTE= BUTTON_ARRIVE= BUTTON_CLEAR= BUTTON_VEHSTOP= BUTTON_PEDSTOP= BUTTON_FLDEVENT= BUTTON_RADIOLOG= BUTTON_MISC= BUTTON_FREE=

• (Controller) The following INI setting determines if, when an MDC logs off, the associated

unit ID is also logged out of CAD. The default is ON

CAD_LOGOUT=ON/OFF • (Controller) The following INI setting determines if, when a unit clears an event and that

unit is the last unit on the event, if the MDC controller will also close the event (providing all required fields for the event have been satisfied). If ON the MDC controller will attempt to clear the event. If OFF the event will be changed to a COMPLETE ‘C’ status and will require intervention by the dispatcher to close the event. The default is OFF

CLOSE_ON_CLEAR=ON/OFF

• (Controller & Mobile) The Comtype entry in the INI file determines the type of communication backbone that the MDC is being used with:

COMTYPE=1 ( Serial RF Broadcast / Default ) COMTYPE=2 ( TCP – Connection Based Protocol) COMTYPE=3 ( UDP –Connectionless Protocol)

• (Controller & Mobile) The Controller_IP entry on the INI file is used for a few different

operations within the program. How it is used and what it should be set to differs from the MDC Controller to the MDC Workstation. The default value is 192.168.1.1

CONTROLLER_IP=192.168.1.1

o MDC Workstation/Mobile: When the COMTYPE=2 or 3, the Controller_IP setting

should be set to indicate the TCP/IP address of the host MDC Controller. This is the TCP/IP address that the MDC Workstation must connect to in order to communicate


with the Controller. In Circumstances where the MDC Controller is behind a router performing NAT (Network Address Translation) the Controller_IP address should be the public address of the Router and it shall then be the router’s responsibility to Forward the port (Port 777 default) traffic to the proper IP address (The internal network address of the MDC Controller) behind the router.

o MDC Controller: In all cases, no matter what the COMTYPE setting is, the CONTROLLER_IP address should be set to the TCP/IP address for the controller machine on the internal department LAN segment. This should be the address on same LAN segment where the Crimestar CAD workstations are running. The MDC Controller communicates with the CAD Workstations by sending UDP data-grams on the LAN. By default UDP data-grams only live or exist within a single “C” class LAN segment (AAA.BBB.CCC.DDD). Under most circumstances setting this value would not be necessary, however, in some cases the MDC Controller machine may have multiple network cards installed where each network card is operating on a different network. Because of this possibility, it is necessary to identify which network the MDC Controller should use to both listen for and send UDP data-gram messages so that messages are both received from and delivered to CAD workstations.

• (Controller & Mobile) The following INI entry can be used to cause the MDC to copy

message text from an ADMIN message into your reply to that message. Copying admin message text can help maintain message subject continuity, but will increase message sizes and may impact system performance. The MDC will always truncate an Admin message to a maximum of 1K bytes. The default for this setting is off.

COPY_REPLY_TEXT=OFF


• (Controller & Mobile) The following entries create DEFAULT values for some common input fields. These entries are dynamically set by the application via user input. DEFAULT_PLATE_TYPE= DEFAULT_RACE= DEFAULT_REASON= DEFAULT_SEX= DEFAULT_STATE=

• (Controller & Mobile) The following INI entries can be used to disable certain MDC functions from being available to the MDC system. If the setting is activated (“ON”) at the MDC Mobile, the corresponding command button and menu option for that function is disabled so the command cannot be transmitted to the MDC Controller. This setting merely controls the forms buttons and menus. In all circumstances the ability to actually submit a particular transaction is controlled via the MD Controller’s Security settings. The default setting for all the disable function command entries is ‘OFF’ (not disabled)

DISABLE_DISPATCH=OFF DISABLE_ENROUTE=OFF DISABLE_ARRIVE=OFF DISABLE_CLEAR=OFF DISABLE_FREE=OFF DISABLE_RADIOLOG=OFF DISABLE_SUBJECTSTOP=OFF DISABLE_VEHSTOP=OFF DISABLE_FLDEVENT=OFF DISABLE_MISC=OFF DISABLE_COMMANDLINE=OFF DISABLE_QPERSON=OFF DISABLE_QVEHICLE=OFF DISABLE_QARTICLE=OFF DISABLE_QBOAT=OFF DISABLE_QGUN=OFF DISABLE_QHAZMAT=OFF DISABLE_QFREEFORM=OFF

• (Controller) The following INI entry can be used on the MDC controller to disable the

FREE Unit Alert function which sends a Digital Dispatch Warning message to units attached to an event when one or more units attached to the same event free from the event. The default setting for this disable function command entry is ‘OFF’ (not disabled).

DISABLE_FREE_UNIT_ALERT=ON


• (Dynamic) The following entries are used to hold the status monitor and map filter preferences selected by the user. FILTER_PRIORITY= FILTER_AGENCY= FILTER_BEAT= FILTER_SECTOR= FILTER_DISTRICT= FILTER_AGENCY2= FILTER_BEAT2= FILTER_SECTOR2= FILTER_DISTRICT2= FILTER_AGENCY3= FILTER_BEAT3= FILTER_SECTOR3= FILTER_DISTRICT3=

• (Mobile) The GPS_PORT entry is used to indicate the physical RS-232 serial port # (or Virtual COM port) that the NMEA compliant GPS receiver is plugged into. Check your windows system configuration to confirm the proper port # to use for this setting. This port will be opened by the MDC software at 4800 Baud, no parity, 8 data bits and 1 stop bit.

GPS_PORT= Setting GPS_PORT to a value of -1 will cause the software to scan through various com ports looking for the GPS signal. Scanning for GPS signaling can be beneficial if/when the com port used dynamically changes depending upon what other devices are plugged in at the time. If the GPS port used is fixed, then defining the port number directly will provide a quicker connect and GPS fix to the MDC unit.

• (Mobile) The GPS_DISTANCE entry is used to indicate the physical distance that must be

traveled by the MDC before it will automatically send a communication to the MDC controller updating its latitude and longitude position. GPS position broadcasts do not require the recipient MDC controller to acknowledge receipt and no retry transmissions will be made to help ensure delivery. The minimum value is 100 (100 feet). The default is approx. 300 feet.

GPS_DISTANCE= * CAUTION setting this value too low can cause the MDC to transmit latitude and longitude position coordinates very frequently and cause excessive congestion on your radio/network communications channel. Remember a car traveling at an average speed of 30MPH is changing its lat/long coordinate position at a rate 44 feet per second.


• (Mobile) The GPS_TIME entry is used to indicate the amount of minutes that must elapse before the MDC will automatically send a communication to the MDC controller updating its latitude and longitude position. GPS position broadcasts do not require the recipient MDC controller to acknowledge receipt and no retry transmissions will be made to help ensure delivery. The minimum value is 3 (3 Minutes). The default is 20 minutes.

GPS_TIME= * CAUTION setting this value too low can cause the MDC to transmit latitude and longitude position coordinates very frequently and cause excessive congestion on your radio/network communications channel.

• (Controller & Mobile) The following entries can be used to assign user definable function keys and key combinations to specific unit status commands, message display and panel display functions. Each of the following entries is directly associated with the task or command that corresponds with the INI entry name. The key sequence definitions to use in conjunction with these INI file entries are defined in Appendix “D”: Function Key Values. KEY_ADMIN= KEY_DISPATCH= KEY_ENROUTE= KEY_ARRIVE= KEY_CLEAR= KEY_VEHSTOP= KEY_MISC= KEY_FREE= KEY_TOGGLE_PANEL12= KEY_PANEL_CLEAR= KEY_NEXT_MESSAGE= KEY_PREV_MESSAGE= KEY_SAVE_MESSAGE= KEY_RECALL_MESSAGE= KEY_EMERGENCY= (Sends Emergency/Distress Broadcast)

• (Dynamic) The following entry is used to hold the last known status of the unit so that if the MDC is turned off or otherwise looses power, the status indicator can be resumed/set when the MDC comes back online or powers up. This value is set dynamically by the program and should not need to be modified directly.

LASTSTATUS=

• (Dynamic) The following entry is used to hold the last known unit ID of the unit so that if

the MDC is turned off or otherwise looses power, the Unit ID indicator can be resumed/set when the MDC comes back online or powers up. There is no need to do anything with this setting, as it is dynamically set by the software during normal operation.


LASTUNIT=

• (Controller) The following entry is used to determine if administrative (car-to-car and car-to-dispatch) messages are logged to a text file on disk. Setting this value to ON turns admin message logging on. The log file is a simple text file named “MDCADMIN_ccyymmdd.LOG” (where ccyymmdd is the current date in Year, Month, Day format). Because these log files can become excessively large, a new log file is created each day as needed. The log file is located in the \LOGS\MDC\ADMIN directory of the MDC Controller installation folder. The default is OFF (No Logging).

LOG_ADMIN_MESSAGES= ON/OFF

This can be a very controversial issue, and many agencies that have had MDC systems for years deliberately do not log this data. The theory, right or wrong is that; you can't subpoena something that does not exist. For many agencies this logged information, has only served as evidence against them in court.

• (Controller) The following entry is used to determine if administrative (car-to-car and car-

to-dispatch) message logs are automatically erased/purged after a specified number of days. The value specified indicates the number of days to keep the logs. The default is 0 (No Purge, logs are kept indefinitely).

LOG_ADMIN_RETENTION=0

• (Controller) The following entry is used to determine the frequency (represented in minutes) of MDC latitude / longitude logging to a text file on disk. Setting this value to zero (the default) turn latitude/longitude logging off. The log file is a simple text file named “MDCLL_ccyymmdd.LOG” (where ccyymmdd is the current date in Year, Month, Day format) and is located in the \LOGS\MDC\LATLNG directory of the MDC Controller installation folder. Because these log files can become excessively large, a new log file is created each day as needed. The file will only contain entries for MDC units where LAT/LNG information exists (even if the vehicles position has not changed for a considerable amount of time). The default is 0 (No Logging). LOG_LAT_LNG_FREQUENCY=

This can be a very controversial issue, and many agencies that have had MDC systems for years deliberately do not log this data. The theory, right or wrong is that; you can't subpoena something that does not exist. For many agencies this logged information, has only served as evidence against them in court.

• (Controller) The following entry is used to determine if latitude and longitude logs are automatically erased/purged after a specified number of days. The value specified indicates the number of days to keep the logs. The default is 0 (No Purge, logs are kept indefinitely). LOG_LAT_LNG_ RETENTION=0


• (Controller) The following entry is used to determine the maximum number of records returned in a summary list from the Crimestar RMS database, when performing a Query Person, Query Vehicle or Query Article search. This setting can be any numeric value between 1 and 100. The default is 25.

MAX_SUMMARY_MATCH=25

• (Controller & Mobile) This entry is used to determine the maximum size of a message packet sent by the MDC software. Setting the message packet size larger can improve performance because each message consists of fewer packets; however, longer/larger packets may be more susceptible to corruption/damage during transmission causing message packet retries to occur. Generally a value of 256 (Min) to 1024 should work well. The default is 512.

MAXPACKETSIZE=

• (Controller & Mobile) This entry is used to determine the maximum number of retries that

should be attempted by the MDC when it sends a message and fails to receive an acknowledgment. After MAXRETRYCOUNT if the message packet still has not been acknowledged the message is regarded as undeliverable. The default is 5.

MAXRETRYCOUNT=

• (Controller & Mobile) This entry is used to determine how many seconds the MDC will wait

for a response or acknowledgement before attempting to send the message packet again. The default is 5 seconds.

MAXRETRYDELAY=

• (Controller & Mobile) This entry is used to turn encryption of message transferred by the

MDC system ON/OFF. The MDC software provides Advanced Encryption Standard 256 Bit (AES-256) data encryption as defined by the Federal Information Processing Standard (FIPS) publication 197 for all data transmissions (excluding packet headers). The default is ON

MSGENCRYPTION=ON

• (Controller & Mobile) The following entries hold the Crimestar license information for the

MDC system. This information is provided to you by Crimestar Corporation when you license the product.

MDC_LICENSE_COUNT= MDC_KEY=


Crimestar Mobile Digital Controller software is licensed per car (or per ADDRESS) and not per concurrent users. Thus the MDC_LICENSE_COUNT value represents the maximum number of unique MDC addresses or devices the controller will recognize and allow to connect, regardless of whether any field unit is currently logged on to the MDC device(s). This licensing scheme is different from the concurrent user license methodology implemented by Crimestar RMS.

• (Mobile) This entry is used to determine if and how often the normal message alert tone will

repeat. The value of this entry represents the frequency in seconds that the normal message (not a priority message) alert tone will sound until the user presses the next message button to acknowledge that a message or messages are in queue. Unlike the Priority Alert Tone setting, this audible alert disables as soon as the user presses the next message button no matter how many normal messages are waiting in queue. When a NEW message is received in queue the normal audible alert is once again enabled. The minimum value is 10, meaning that the alert tone will resound every 10 seconds the user presses the next message button. Setting this value to zero (0) causes the normal message alert tone to not repeat. Zero (0) is the default.

NORMAL_ALERT_TONE=

• (Controller & Mobile) This is the TCP or UDP port that the MDC will use to communicate

when running with COMTYPE set to a value of 2 or 3. The default is port 777.

PORT_ID= • (Mobile) This entry is used to determine if and how often the priority message alert tone will

repeat. The value of this entry represents the frequency in seconds that the priority message alert tone will sound until ALL the priority messages in queue have been read. The minimum value is 10, meaning that the audible alert tone will resound every 10 seconds until all priority messages in queue have been read. Setting this value to zero (0) causes the audible alert tone to not repeat. 10 Seconds is the default.

PRIORITY_ALERT_TONE=

• (Controller & Mobile) This is the machines Serial port that the MDC will use to communicate when running with COMTYPE set to a value of 1. The default is 1.

SERIAL_PORT=

• (Mobile) When MAC verification is used it is essential that the proper/authorized MAC ID

be sent to the controller. Likewise, if the State Interface Message Switch Gateway (MSG) is being used, MAC Address verification is required. However, on computers where more than one Network Interface Card (NIC) is installed, more than one MAC address will exist. Thus Microsoft Windows may provide the MDC Workstation application with the wrong MAC address to send to the MDC controller for verification. If that happens the MDC workstation will fail the device security authorization. Sometimes you can configure


Windows to always report a specific MAC ID however, in circumstances where you can’t configure MS Windows for consistent behavior, the STATICMAC entry in the INI file can be used to force the MDC Workstation to use a pre-defined MAC address. STATICMAC=

• (Controller & Mobile) This is the transmit delay that the MDC will use so as to prevent data from being sent to the serial port too fast for external modem devices to handle. The value of this setting is a representation of seconds or fractions of a second. Example: 1=One second; 2=Two seconds; 2.5 = 2 and one half seconds; etc. etc. When running in COMTYPE=2 or 3 this value should probably be zero (0). When running with COMTYPE=1 this value may need to be increased slightly. The default value is 0.

TX_DELAY=

• (Controller) This is the interval, in minutes that the MDC controller will use to send

unsolicited status monitor broadcasts to field units. These unsolicited broadcasts do not require the recipient MDC to acknowledge receipt and no retry transmissions will be made to help ensure delivery. Sending these unsolicited broadcasts to infrequently will result in the information displayed on the field unit status monitors being less timely. The default is 10 minutes.

SMBROADCAST_INTERVAL= *CAUTION: sending these status monitor broadcasts too frequently may consume too much band width on your communication backbone and seriously impact system performance. The status monitor and map page on the MDC controller are updated/refreshed every 15 seconds regardless of the SMBROADCAST_INTERVAL value.

• (Mobile) This setting determines if the MDC Login Screen will provide prompts for a separate state interface login. The default is OFF. STATE_INTERFACE_LOGIN=ON/OFF

• (Mobile) This setting determines if the User ID and Password values provided via the

separate state interface login prompts will be automatically shifted to upper case, lower case or will remain as mixed case values before being transmitted to the MDC Controller. Some state interfaces require upper case values. The default is Mixed Case. STATE_INT_LOGIN_CASE=UPPER / LOWER / MIXED

•


Appendix C – Default HTML Style Sheet Values If the mdcdefault.html or mdcndefault.html style sheets already exist the MDC software will use the contents and settings in the existing sheet to render the various MDC display forms. By modifying this style sheet you can control the colors, font styles and font sizes used for various aspects of the MDC display. If the mdcdefault.html style sheet does not exist, it will be created using the following default values. These default values are best viewed at 1024x768 screen resolution. For lower 800x600 resolution displays the font point sizes should be reduced.

• DAYMODE ( MDCDEFAULT.HTML )  <html> <head> <style> body { color: #FFFFFF; background-color: #000000; font-family:Arial; font-size: 14pt; } table { width: 100% }  tr.UNIT_MISC { color: #FF0000; font-size: 14pt; vertical-align: top; font-family:Arial } tr.UNIT_AVAILABLE { color: #FFFFFF; font-size: 14pt; vertical-align: top; font-family:Arial } tr.UNIT_ARRIVED { color: #00FFFF; font-size: 14pt; vertical-align: top; font-family:Arial } tr.UNIT_DISPATCHED { color: #00FF00; font-size: 14pt; vertical-align: top; font-family:Arial } tr.UNIT_ENROUTE { color: #FFFF00; font-size: 14pt; vertical-align: top; font-family:Arial } tr.UNIT_TRANSPORT { color: #FFFF00; font-size: 14pt; vertical-align: top; font-family:Arial } tr.UNIT_RADIOLOG { color: #FFFFFF; font-size: 14pt; vertical-align: top; font-family:Arial } tr.UNIT_FREE { color: #FFFFFF; font-size: 14pt; vertical-align: top; font-family:Arial } tr.UNIT_CLEAR { color: #FFFFFF; font-size: 14pt; vertical-align: top; font-family:Arial } tr.EVENT_PENDING { color: #FFFFFF; font-size: 14pt; vertical-align: top; font-family:Arial } tr.EVENT_ACTIVE { color: #00FFFF; font-size: 14pt; vertical-align: top; font-family:Arial } tr.EVENT_COMPLETE { color: #00FF00; font-size: 14pt; vertical-align: top; font-family:Arial } tr.UNIT_HEADER { color: #FFFFFF; font-size: 14pt; font-family:Arial; font-weight:bold; background-color:#0000FF } tr.EVENT_HEADER { color: #FFFFFF; font-size: 14pt; font-family:Arial; font-weight:bold; background-color:#0000FF } tr.WT { color: #FFFFFF; font-size: 14pt; vertical-align: top; font-family:Arial } a.EVENT_PENDING { color: #FFFFFF } a.EVENT_ACTIVE { color: #00FFFF } a.EVENT_COMPLETE { color: #00FF00 } a.UNIT_MISC { color: #FF0000 } a.UNIT_AVAILABLE { color: #FFFFFF } a.UNIT_ARRIVED { color: #00FFFF } a.UNIT_DISPATCHED { color: #00FF00 } a.UNIT_ENROUTE { color: #FFFF00 } a.UNIT_TRANSPORT { color: #FFFF00 } a.UNIT_RADIOLOG { color: #FFFFFF } a.UNIT_FREE { color: #FFFFFF } a.UNIT_CLEAR { color: #FFFFFF }  tr.DD_HEADER { color: #FF0000; font-size: 18pt; vertical-align: top; text-align: center; font-family:Arial; font-weight:bold } tr.DD_UNIT { color: #FFFFFF; font-size: 14pt; vertical-align: top; font-family:Arial } tr.DD_EVENT { color: #FFFFFF; font-size: 14pt; vertical-align: top; font-family:Arial } tr.DD_CALLTYPE { color: #FFFFFF; font-size: 14pt; vertical-align: top; font-family:Arial } tr.DD_LOCATION { color: #FFFFFF; font-size: 14pt; vertical-align: top; font-family:Arial } tr.DD_DETAILS { color: #FFFFFF; font-size: 14pt; vertical-align: top; font-family:Arial } td.DD_HEADER { color: #FF0000; font-size: 18pt; vertical-align: top; text-align: center; font-family:Arial; font-weight:bold } td.DD_UNIT_LBL { color: #00FF00; font-size: 14pt; vertical-align: top; font-family:Arial; font-weight:bold; width: 120 } td.DD_EVENT_LBL { color: #00FF00; font-size: 14pt; vertical-align: top; font-family:Arial; font-weight:bold; width: 120 }


td.DD_CALLTYPE_LBL { color: #00FF00; font-size: 14pt; vertical-align: top; font-family:Arial; font-weight:bold; width: 120 } td.DD_LOCATION_LBL { color: #00FF00; font-size: 16pt; vertical-align: top; font-family:Arial; font-weight:bold; width: 120 } td.DD_DETAILS_LBL { color: #00FF00; font-size: 16pt; vertical-align: top; font-family:Arial; font-weight:bold; width: 120 } td.DD_UNIT { color: #FFFFFF; font-size: 14pt; vertical-align: top; font-family:Arial } td.DD_EVENT { color: #FFFFFF; font-size: 14pt; vertical-align: top; font-family:Arial } td.DD_CALLTYPE { color: #FFFFFF; font-size: 14pt; vertical-align: top; font-family:Arial } td.DD_LOCATION { color: #FFFFFF; font-size: 16pt; vertical-align: top; font-family:Arial } td.DD_DESCRIP { color: #FFFFFF; font-size: 16pt; vertical-align: top; font-family:Arial } a.DD_EVENT { color: #FFFFFF }  tr.EVENT_UNIT_HEADER { color: #FFFFFF; font-size: 14pt; font-family:Arial; font-weight:bold; background-color:#0000FF } td.EVENT_LABEL_LEFT { color: #00FF00; font-size: 14pt; vertical-align: top; font-family:Arial; width: 120 } td.EVENT_LABEL_INNER { color: #00FF00; font-size: 14pt; vertical-align: top; font-family:Arial; width: 120 } td.EVENT_LABEL_RIGHT { color: #00FF00; font-size: 14pt; vertical-align: top; font-family:Arial; text-align: right }  tr.MHL { color: #FFFFFF; font-size: 14pt; font-family:Arial; font-weight:bold; background-color:#0000FF } tr.MDL { color: #FFFFFF; font-size: 14pt; font-family:Arial; font-weight:bold } tr.MIL { color: #FFFFFF; font-size: 14pt; font-family:Arial; font-weight:bold; background-color:#0000FF } td.MLH { color: #00FF00; font-size: 14pt; vertical-align: top; font-family:Arial; width: 120 } td.MIH { color: #00FF00; font-size: 14pt; vertical-align: top; font-family:Arial; width: 120 } td.MIR { color: #00FF00; font-size: 14pt; vertical-align: top; font-family:Arial; text-align: right }  tr.VHL { color: #FFFFFF; font-size: 14pt; font-family:Arial; font-weight:bold; background-color:#0000FF } tr.VDL { color: #FFFFFF; font-size: 14pt; font-family:Arial; font-weight:bold } tr.VIL { color: #FFFFFF; font-size: 14pt; font-family:Arial; font-weight:bold; background-color:#0000FF } td.VLH { color: #00FF00; font-size: 14pt; vertical-align: top; font-family:Arial; width: 120 } td.VIH { color: #00FF00; font-size: 14pt; vertical-align: top; font-family:Arial; width: 120 } td.VIR { color: #00FF00; font-size: 14pt; vertical-align: top; font-family:Arial; text-align: right } a.WT { color: #FFFFFF }  tr.ARTICLE_SUMMARY_HEADER { color: #FFFFFF; font-size: 14pt; font-family:Arial; font-weight:bold; background-color:#0000FF } tr.ARTICLE_SUMMARY_DATA { color: #FFFFFF; font-size: 14pt; font-family:Arial; vertical-align: top } td.ARTICLE_DETAIL_LFT_LBL { color: #00FF00; font-size: 14pt; vertical-align: top; font-family:Arial; width: 120 } td.ARTICLE_DETAIL_INR_LBL { color: #00FF00; font-size: 14pt; vertical-align: top; font-family:Arial; width: 120 } td.ARTICLE_DETAIL_RGT_LBL { color: #00FF00; font-size: 14pt; vertical-align: top; font-family:Arial; text-align: right } td.ARTICLE_STOLEN_ALERT { color: #FFFFFF; font-size: 14pt; vertical-align: top; font-family:Arial; font-weight:bold; background-color:#FF0000 } a.PROPERTY_ITEM { color: #FFFFFF } </style> </head> <body bgcolor="#000000" font='Arial' > </body> </html>

• NIGHTMODE ( MDCNDEFAULT.HTML )  <html> <head> <style> body { color: #FF0000; background-color: #000000; font-family:Arial; font-size: 14pt; }


table { width: 100% }  tr.UNIT_MISC { color: #FF0000; font-size: 14pt; vertical-align: top; font-family:Arial } tr.UNIT_AVAILABLE { color: : #FF0000; font-size: 14pt; vertical-align: top; font-family:Arial } tr.UNIT_ARRIVED { color: : #FF0000; font-size: 14pt; vertical-align: top; font-family:Arial } tr.UNIT_DISPATCHED { color: : #FF0000; font-size: 14pt; vertical-align: top; font-family:Arial } tr.UNIT_ENROUTE { color: #FF0000; font-size: 14pt; vertical-align: top; font-family:Arial } tr.UNIT_TRANSPORT { color: : #FF0000; font-size: 14pt; vertical-align: top; font-family:Arial } tr.UNIT_RADIOLOG { color: #FF0000; font-size: 14pt; vertical-align: top; font-family:Arial } tr.UNIT_FREE { color: #FF0000; font-size: 14pt; vertical-align: top; font-family:Arial } tr.UNIT_CLEAR { color: : #FF0000; font-size: 14pt; vertical-align: top; font-family:Arial } tr.EVENT_PENDING { color: : #FF0000; font-size: 14pt; vertical-align: top; font-family:Arial } tr.EVENT_ACTIVE { color: : #FF0000; font-size: 14pt; vertical-align: top; font-family:Arial } tr.EVENT_COMPLETE { color: #FF0000; font-size: 14pt; vertical-align: top; font-family:Arial } tr.UNIT_HEADER { color: #FF0000; font-size: 14pt; font-family:Arial; font-weight:bold; background-color:#333333} tr.EVENT_HEADER { color: : #FF0000; font-size: 14pt; font-family:Arial; font-weight:bold; background-color: #333333} tr.WT { color: : #FF0000; font-size: 14pt; vertical-align: top; font-family:Arial } a.EVENT_PENDING { color: : #FF0000} a.EVENT_ACTIVE { color: #FF0000} a.EVENT_COMPLETE { color: #FF0000} a.UNIT_MISC { color: : #FF0000} a.UNIT_AVAILABLE { color: #FF0000} a.UNIT_ARRIVED { color: #FF0000} a.UNIT_DISPATCHED { color: : #FF0000} a.UNIT_ENROUTE { color: #FF0000} a.UNIT_TRANSPORT { color: : #FF0000} a.UNIT_RADIOLOG { color: : #FF0000} a.UNIT_FREE { color: : #FF0000} a.UNIT_CLEAR { color: #FF0000}  tr.DD_HEADER { color: : #FF0000; font-size: 18pt; vertical-align: top; text-align: center; font-family:Arial; font-weight:bold } tr.DD_UNIT { color: : #FF0000; font-size: 14pt; vertical-align: top; font-family:Arial } tr.DD_EVENT { color: : #FF0000; font-size: 14pt; vertical-align: top; font-family:Arial } tr.DD_CALLTYPE { color: : #FF0000; font-size: 14pt; vertical-align: top; font-family:Arial } tr.DD_LOCATION { color: : #FF0000; font-size: 14pt; vertical-align: top; font-family:Arial } tr.DD_DETAILS { color: : #FF0000; font-size: 14pt; vertical-align: top; font-family:Arial } td.DD_HEADER { color: : #FF0000; font-size: 18pt; vertical-align: top; text-align: center; font-family:Arial; font-weight:bold } td.DD_UNIT_LBL { color: : #FF0000; font-size: 14pt; vertical-align: top; font-family:Arial; font-weight:bold; width: 120 } td.DD_EVENT_LBL { color: : #FF0000; font-size: 14pt; vertical-align: top; font-family:Arial; font-weight:bold; width: 120 } td.DD_CALLTYPE_LBL { color: : #FF0000; font-size: 14pt; vertical-align: top; font-family:Arial; font-weight:bold; width: 120 } td.DD_LOCATION_LBL { color: : #FF0000; font-size: 16pt; vertical-align: top; font-family:Arial; font-weight:bold; width: 120 } td.DD_DETAILS_LBL { color: : #FF0000; font-size: 16pt; vertical-align: top; font-family:Arial; font-weight:bold; width: 120 } td.DD_UNIT { color: : #FF0000; font-size: 14pt; vertical-align: top; font-family:Arial } td.DD_EVENT { color: #FF0000; font-size: 14pt; vertical-align: top; font-family:Arial } td.DD_CALLTYPE { color: : #FF0000; font-size: 14pt; vertical-align: top; font-family:Arial } td.DD_LOCATION { color: #FF0000; font-size: 16pt; vertical-align: top; font-family:Arial } td.DD_DESCRIP { color: : #FF0000; font-size: 16pt; vertical-align: top; font-family:Arial } a.DD_EVENT { color: : #FF0000}  tr.EVENT_UNIT_HEADER { color: #FF0000; font-size: 14pt; font-family:Arial; font-weight:bold; background-color: #333333} td.EVENT_LABEL_LEFT { color: : #FF0000; font-size: 14pt; vertical-align: top; font-family:Arial; width: 120 } td.EVENT_LABEL_INNER { color: : #FF0000; font-size: 14pt; vertical-align: top; font-family:Arial; width: 120 } td.EVENT_LABEL_RIGHT { color: #FF0000; font-size: 14pt; vertical-align: top; font-family:Arial; text-align: right }  tr.MHL { color: : #FF0000; font-size: 14pt; font-family:Arial; font-weight:bold; background-color: #333333} tr.MDL { color: : #FF0000; font-size: 14pt; font-family:Arial; font-weight:bold } tr.MIL { color: : #FF0000; font-size: 14pt; font-family:Arial; font-weight:bold; background-color: #333333} td.MLH { color: : #FF0000; font-size: 14pt; vertical-align: top; font-family:Arial; width: 120 } td.MIH { color: : #FF0000; font-size: 14pt; vertical-align: top; font-family:Arial; width: 120 } td.MIR { color: : #FF0000; font-size: 14pt; vertical-align: top; font-family:Arial; text-align: right }


 tr.VHL { color: : #FF0000; font-size: 14pt; font-family:Arial; font-weight:bold; background-color: #333333} tr.VDL { color: : #FF0000; font-size: 14pt; font-family:Arial; font-weight:bold } tr.VIL { color: #FF0000; font-size: 14pt; font-family:Arial; font-weight:bold; background-color: #333333 } td.VLH { color: : #FF0000; font-size: 14pt; vertical-align: top; font-family:Arial; width: 120 } td.VIH { color: : #FF0000; font-size: 14pt; vertical-align: top; font-family:Arial; width: 120 } td.VIR { color: : #FF0000; font-size: 14pt; vertical-align: top; font-family:Arial; text-align: right } a.WT { color: : #FF0000}  tr.ARTICLE_SUMMARY_HEADER { color: #FF0000; font-size: 14pt; font-family:Arial; font-weight:bold; background-color:#0000FF } tr.ARTICLE_SUMMARY_DATA { color: : #FF0000; font-size: 14pt; font-family:Arial; vertical-align: top } td.ARTICLE_DETAIL_LFT_LBL { color: : #FF0000; font-size: 14pt; vertical-align: top; font-family:Arial; width: 120 } td.ARTICLE_DETAIL_INR_LBL { color: : #FF0000; font-size: 14pt; vertical-align: top; font-family:Arial; width: 120 } td.ARTICLE_DETAIL_RGT_LBL { color: #FF0000; font-size: 14pt; vertical-align: top; font-family:Arial; text-align: right } td.ARTICLE_STOLEN_ALERT { color: : #FF0000; font-size: 14pt; vertical-align: top; font-family:Arial; font-weight:bold; background-color: #333333} a.PROPERTY_ITEM { color: : #FF0000} </style> </head> <body bgcolor="#000000" font='Arial' > </body> </html>


• Appendix D – Function Key Values Specifies the key label name assigned to the key when setting the KEY_ labels in the INI file. The KeyLabelName is the letter or digit on the key or a special name assigned to the key. The following table lists the special key label names.

For this key Specify this KeyLabelName value HOME HOME END END PAGE UP PGUP PAGE DOWN PGDN BACKSPACE BACKSPACE SPACEBAR SPACEBAR INS INS TAB TAB SHIFT+TAB BACKTAB Left Brace LBRACE Right Brace RBRACE F1 to F12 F1, F2, F3 ... CTRL+F1 to CTRL+F12 CTRL+F1, CTRL+F2 ... SHIFT+F1 to SHIFT+F12 SHIFT+F1, SHIFT+F2 ... ALT+F1 to ALT+F12 ALT+F1, ALT+F2, ALT+F3 ... ALT+0 to ALT+9 ALT+0, ALT+1, ALT+2 ... ALT+A to ALT+Z ALT+A, ALT+B, ALT+C ... CTRL+LEFT ARROW CTRL+LEFTARROW CTRL+RIGHT ARROW CTRL+RIGHTARROW CTRL+HOME CTRL+HOME CTRL+END CTRL+END CTRL+PAGE UP CTRL+PGUP CTRL+PAGE DOWN CTRL+PGDN CTRL+A TO CTRL+Z CTRL+A, CTRL+B, CTRL+C ... CTRL+0 CTRL+0


• Appendix E – Protocol Selection and System Tuning • If your implementation of the MDC is via RF Modem (COMTYPE=1) much of the information discussed in this section will not apply. However, if your implementation will be using a commercial carrier or private IP based network then you have a choice of using TCP (Transport Control Protocol) or UDP (User Datagram Protocol). Choosing between TCP and UDP will depend on the specifics of your communications environment. Sometimes the only way to know for sure which protocol will work best is to test it. Having said that, the following information and discussion will help you understand some basic elements of each communication protocol, identifying the pros and cons of each and how to tune Crimestar MDC software accordingly. PACKET BASICS: Almost all data messages that are sent over an IP based communications transport are generally broken down by the protocol into a series of smaller chunks referred to as “packets”. Then each of these data packets are sent to their respective destination where they are reassembled into the original message. The size of these packets is managed by the configuration of the IP communications layer. The smaller the defined packet size, the more packets that are needed to deliver the same volume of data. If the IP packets are too small, lots and lots of packets are required to deliver the data and all those extra packets need to be reassembled in the proper order to recreate the original data. If however, the packet sizes are too big, then there is a higher the likelihood or probability that a packet will get damaged or become corrupted during transport which will require the re-transmission of that packet. The optimum packet size depends on your network. Understanding the basics of this packet style of communication is important to understanding a few of the distinctions between the TCP and UDP protocols. The MDC software itself uses packets to break larger messages into smaller chunks (even when implemented via RF Modem COMTYPE=1) but don’t confuse MDC message packets with IP data packets as they exist at different layers of the communications path and are not the same thing. For example the MDC software may take a large 2000 byte message and divide it into 4 different 500 byte MDC message packets. The actual size of an MDC message packet is controlled by the MAXPACKETSIZE entry in the Crimestar INI file. The MDC software implements a packet acknowledgement protocol where each MDC message packet sent must be ACK’d by the receiving MDC. An MDC message packet that is not Ack’d is presumed to have not been delivered and is resent. The maximum number of time the MDC software will reattempt to send a message packet is controlled by the MAXRETRYCOUNT entry in the Crimestar INI file. So if for example; suppose the defined IP packet size is 250 bytes and the defined MDC maximum packet size is 500 bytes. When the MDC software needs to deliver that 2000 byte message, it divides it into the 4 different 500 byte packets and, each of those MDC message packets are sent via the IP communication layer (using whichever protocol has been selected). The IP communications layer sees each MDC packet as a message and divides it into 250 byte data packets and attempts to deliver those packets to the destination address. As the IP communication layer receives the packets it assembles them and delivers them to the MDC software. The MDC software then analyzes the received MDC packet to verify its integrity and replies with an ACK to let the sender know that it can now send the next MDC packet. Once all MDC packets are received by the MDC software the packets are reassembled into the original message. So as you can see for this discussion there are two layers of packets that exist. There are the MDC message packets which represent smaller chunks of the original message and there are IP packets which would be smaller chunks of an MDC message packet.


If the defined MAXPACKETSIZE used by the MDC is either the same as or small than the packet size utilized by the IP transport layer then there is a 1-to-1relationship between MDC message packets and IP packets where each MDC message packet only requires 1 IP packet. TCP: The TCP protocol (COMTYPE=2) is a connection based protocol. This means that the MDC client in the car will search for the host MDC controller using the controller’s IP address defined in the Crimestar INI file and establish a “connection” (data pipeline) with that host. The TCP connection based protocol generally provides a more reliable form of message/data delivery between two points because of this established connection. Rarely are the sending machine and destination machine on the same subnet (common group of network addresses), especially when using GPRS via a commercial carrier. Usually the two machines must communicate with each other by having their data packets relayed from point-to-point/machine-to-machine until the packet arrives at its destination. This persistent connection that is inherent to TCP helps route packets through gateway machines, routers and the maze of systems that must be traversed to get data from one point to another. TCP guarantees that data packets will get through the maze and be delivered in sequential order making their reassembly much easier.

As a general rule, when using TCP the maximum size of an MDC message packet should be fairly large ( 1024 ) as TCP will manage the division of that MDC packet into smaller

packets and ensure delivery in the proper order. While TCP can provide reliable data delivery, it can only do so when a connection between the client and host exists. The challenge presented by the MDC environment is that the client (i.e. the computer in the car) is moving around and relies not on wires but rather radio signals to stay connected. Much like what you might experience from time to time when using a cell phone, the GPRS service provided by commercial carriers can have ”dead-spots” where the radio signal is weak or blocked completely. When that happens, the TCP connection can and often is broken. When the data connection breaks between a client and the host the MDC system cannot communicate. In an attempt to account for this condition, the MDC client software attempts to detect connection disconnects and will automatically try to re-establish a connection with the host controller. Please realize that attempts to re-connect can only be done by the client software in the car, because the IP address of the host MDC controller is located at a fixed known static IP address. Therefore the client know the address to go to try to connect with the host controller but the host controller does not necessarily know the IP address of the client so the host cannot effectively and reliably re-initiate a connection. When these connection breaks occur it presents an additional burden on the MDC controller. As each connection to the host controller consumes a certain number of system resources. When a client establishes a connection, the host controller allocates system resources to manage that connection. If the connection experiences a hard-break; (meaning that the break occurred as a result of something other than a disconnect sequence issued by the client machine) the controller does necessarily know that the connection is broken and holds those system resources. In the mean time the client re-attempts to establish a new connection with the host. This new


connection in turn consumes some system resources. As this connect/disconnect dynamic repeats the host controller can slowly consume more and more of the memory resources on the computer until it communication is interrupted. To combat this condition the MDC controller must monitor internal connections and try to determine though inactivity which connections are no longer being used and automatically disconnect them in order to free up the system resources consumed by the broken connection. This connection housekeeping process requires extra work for the host controller on an ongoing basis. So while the connection that is inherent to using TCP provides for a better and more reliable data transfer, this benefit is offset by the fact that vehicles in motion often experience radio signal interruptions that subsequently break the TCP connection; requiring the MDC software to detect and attempt to automatically repair or re-establish a connection with the host. UDP: The UDP protocol (: COMTYPE=3) is a connectionless protocol. As such data packets do not have a connection path or pipeline that they can follow. Each packet transmitted must find its own way to its destination. This means that, depending upon the network, different packets can take different paths to get to the destination IP address and some data packets may be delayed and subsequently not delivered in the order that they were transmitted. While this can be a problem it is easy to manage through proper configuration. By ensuring that the MDC maxpacket size is less than the IP packet size used for UDP, each packet must reach its destination and be acknowledged before the next packet is sent. .

As a general rule, when using UDP the maximum size of an MDC message packet should be no larger than the packet size used by the IP communication layer. This will help

ensure that each MDC message packet will consume only one IP packet and that packet will be delivered to the MDC software in the order that they were transmitted. The advantage to UDP is that since it does not use a connection, there is no connection for the controller to keep track of and no need to monitor for timeout or broken connections. Likewise, there is no need to re-establish connections if/when they break which can speed up the process of communication recovery after having lost radio communication. However, since UDP delivery requires the controller knowing the IP address of the client, UDC is best suited for situations where the MDC client in the car uses a static or fixed IP address. General System Performance: Depending upon your activity level and the number of MDC field units deployed the MDC Controller may sit idle much of the time. However, when it does need to process transactions it must be able to do so very very quickly. As such the machine functioning and the MDC controller should: 1.) Be a dedicated machine where the only application that the computer is responsible for

running is the MDC controller. (Running the MDC Controller on your “Server” or other shared computer that may, at times be busy with other processing will likely cause an increased error rate in handling communications with MDC workstations.)

2.) Have a very fast CPU processor (Intel Pentium 4 or fasters) with ample memory. 3.) Have a high speed and stable connection to the Crimestar database.