|
|
|
|
MTELPage Direct
This instruction is specific to the PagerDEC 2011 server application. This application provides decoded pager data from the Hutchison "3 Paging" network as well as a transmission paging message interface into the MDS system. This page only describes the decoder part of the application.
Downloads If required the install package is here. The current version V4.2(99) is here. The local system database is here. The script to create the SQL PDEC_miss_cc table is here. The local ~~MDSUser database is here. The empty ~~MDSUser database is here.
The PagerDEC application provides decoded pager data to the MTELpage products for message acknowledgement. Whilst the PagerDEC application does not form part of the MDS system when decoding, it uses the MDS tables for determining the names and the pager numbers of the decoded data. Therefore it is considered part of the MDS system. 1.3 Setting up the PagerDEC application MDS SQL tablesMDSClient table For the Springhill system: The input to the PagerDEC decoder is normally a fixed baud rate, serial data stream delivered by the hardware decoders. The comms setup for the app in MDSClient. For the new OAD hardware: TCP port configuration is defined in the MDSClient table. In this configuration described above the OutputMethod field is changed from TCP or SERIAL to OAD2. OAD2 indicates to the application that there are two TCP ports required and that the new protocol is to be used on the data stream. If OAD2 is entered into OutputMethod, the fields PortType, Destination, SerialPort, HostAddress and HostPort are all ignored. Instead the TCP ports are defined in the StartUp field. The settings strings are "F1_SOCK_IP=192.168.0.100" and "F1_SOCK_PORT=10001" for the IP socket for the F1 hardware and "F1_SOCK_IP=192.168.0.101" and "F2_SOCK_PORT=10001" for the IP socket for the F2 hardware. (where the IP and port numbers in this example are for the MTEL local systems.)
PDec_Messages table PagerDEC writes the decoded data to a SQL table called PDec_Messages. Check that the fields are correct in the current version as shown below. The new version writes to the Agency field, pager_id_capcode, pager_id_number, pager_id_name. pager_id_name has been increased to 100 nvarchar.
PDec_miss_cc table PagerDEC monitors the data stream and looks for messages that appear to come from the VisiCAD system. If the capcode (the air interface number) is not in the MDSUser table then an entry is made into this table. It indicates that the capcode should be investigated and added to the MDSUser table. PDec_log table This table is no longer in use. It should be deleted. MDSLog table PagerDEC will send all logging from the System Log to this SQL table as well as a text file located at LogsDir (from Registry table. see below).
1.4 Setting up the PagerDEC application System databaseMTELPDecsys table This database is new and a replacement for registry based start up parameters used in previous versions. click here (MTELPDECsys.mdb Configuration Access Database) for a sample copy. In the past this system file was located in c:\MTELsys. In this application the database must reside in the current directory for the application. It has 2 tables. Registry and MTELRelay. Each provides a distinctive set of parameters to allow the PagerDEC to connect to a variety of devices. Registry table PagerDEC will use these settings to configure application settings. Many settings will operate in default satisfactorily and can be changed at a later point in time.
Registry table parameters that must be changed The following settings are unique to the installation and should be changed to the correct settings for the local instance. The PagingIPAckAddress is the IP of the machine the application is on. This IP is sent to the Switch in MDS so the Switch knows were to send the ACK back. DecoderType is always RAW. MTELOffice is a different protocol and will not work in the current MDS system.
This is a list of the MTELRelay potential client sites. A port is allocated for each relay. This port acts as a server (listener). The Relay will act as a Client. The servers can be disabled to stop the Relays from connecting. The Region field is critical and must match the Region in MDSUser. This field determines which relay will receive a data packet from the Decoder. At this point in time the single wild card character * in the Region field means all the packets are sent to that relay. In this case relay client Test in the table below will receive every decoded packet. The other critical field is Port. Each port must be unique, although duplicate ports can be assigned, only one should be active at any time. This field is only used when a listener socket is established, prior to this the port is just a member of the array. Changing the Active field to Y will allow the application to attempt to bind a socket. Y is in this field is active. Any other character will constitute a N or disable the port.
~~MDSUser Access Database In the past the PagerDEC decoder received all the capcode from the decoder hardware and queried the MDSUser table for a valid record. If found an ACK was sent to the hardware to request the message for the received capcode. The reason for this was to reduce the serial I/O flow which was 9600 baud which in turn reduces overloading the buffers in the decoder hardware. Only messages for valid capcodes are sent across the serial link. However the new PagerDEC is now capable of looking for lost or unknown capcodes for certain message types. To do this PagerDEC requires all the messages and uses filters to determine what to do with the message. However the capcode is still searched against the MDSUser table so that the correct messages are decoded and distributed just as in the previous versions. As part of this process, PagerDEC now uses a local database to decide which capcodes are to be decoded. This database must reside in the application directory. This table can start with no entries as it is populated after there is a successful match for a capcode in the SQL MDSUser table. In the decoding process the local Access table is tested first and if there is no entry for a capcode then the SQL table is tested. If a match occurs in the SQL table then a copy is placed in the local table. The purpose of this design is to reduce the dependency on the remote SQL server and to reduce I/O traffic to that server particularly if the SQL server is on different hardware.. The table below is an example of the local table. Note this is a subset of the master SQL table and only contains current users which have been decoded by PagerDEC. The local table 6 fields. The MDSCheck date field is used by the periodic function which tests the oldest local table entry (must also be older than 1 day) against the SQL MDSUser table. This means the records in the local table are the same as the master SQL table up to the last 24 hours. This periodic function detects changes in the master table which are then copied to the local table. This function performs one test each minute a the single record with the oldest MDSCheck date value.
Entries in the Decoder Status tab debug window will indicate the local table operation. In general the decodes will indicate a capcode was found in the local database. If not the display will indicate a capcode is being inserted into the local database. The periodic function will also indicate its processes. There will be entries for periodical updates. If a record is different the fields will be displayed and the information will also be logged to the system log.
Capcode Memory Array: The capcode array lasts the life of the application it is purely a memory array. The array is a list of known capcodes which are not to be decoded. The purpose of the array is to reduce the number of database hits by using the array to identify the capcodes which are for everyone NOT in the decoder tables. Since the DES capcodes are a smaller subset of all the capcodes decoded on the paging networks, the number of database hits is reduced by this same ratio. In addition to this Hutchison generate thousands of capcodes a day to alarm and monitor their systems. These capcodes will be in the array saving thousands of completely unnecessary I/O to the database as well. The array is created by looking for capcodes in the ~~MDSUser table. If this fails then look in the SQL database. If this fails it is considered to be a non DES pager and is then added to the array. The System/General tab contains the size of the contents of the array. Currently this is 5000 capcodes long. So the array is a representation of the last 5000 known capcodes not to be decoded. The array is circular so the oldest is over written and the size is shown in this tab. The Clear Array button is required to clear the array if a capcode is in the array and is now required to be decoded again. This is an odd situation and will rarely be required.
|
|
|
