MTELPage Direct

Home

 

Up
Revision List

 

MTELPage Direct

1.1       Focus

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.

 

1.2       Overview

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 tables

MDSClient 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 database

MTELPDecsys 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

Key_Description

Key_Data

Description

All Traffic TimeOut

30

The number of seconds the All Traffic button will operate before reverting back to normal filtered display

ChannelCRCPercentage

1

Maximum percentage of CRC errors in ChannelSamplePeriod

ChannelCRCThreshold

5

Maximum number of CRC errors in ChannelSampleCount

ChannelInactivityPeriod

40

The time in seconds a channel is inactive before raising an alarm

ChannelMinimumSamples

10

The minimum number of samples required in the ChannelSamplePeriod

ChannelOVFPercentage

1

Maximum percentage of Overflow errors from hardware decoder in ChannelSamplePeriod

ChannelOVFThreshold

1

Maximum number of Overflow errors from hardware decoder in ChannelSampleCount

ChannelSampleCount

10

The number of packets sampled to determine thresholds for CRC and OVF alarms

ChannelSamplePeriod

30

The time in which to sample packets to determine thresholds for CRC and OVF alarms

DecoderBadPacketThreshold

2

The number of bad packets limit for decoder hardware in DecoderPacketSamples

DecoderMaximumPacketLength

600

The maximum packet length for the OAD packets. Packets longer than this are truncated.

DecoderNoPacketPeriod

60

The number of seconds of lack of activity from the OAD decoder hardware.

DecoderPacketSamples

12

The number of samples of packets from the decoder hardware to check for errors

Log Bad Packets (CheckSum)

True

Set to true to activate test

Log OAD OverFlows (OVF)

True

Set to true to activate test

LogsDir

c:\logs

The directory for the logs. This directory must exist. It is not created.

MDSUserFieldsSQL

[PagerID],[Network],[Region],[Capcode],[Vehicle],[Description],[DT_Last_Sent]

Fields to be selected in a SQL statement to display record in CCMaint grid

PagingHash

This is a dummy hash

The Switch expects a hash for every message. This system generate a dummy one. The Switch returns the hash in the Acknowledgement.

PagingIPAckAddress

192.168.0.47

The Switch expects a return address for paging sender acknowledgement.

PagingIPAckMachine

PagerDEC

This is the name of the machine that generated the message.

PagingIPAckPort

8000

The Switch expects a return address for paging sender acknowledgement.

PagingTIQPeriod

12:15:00 am

This is the maximum time the message will stay in the queue if it hasn’t been sent to the switch. After this time the message is deleted.

PagingTIQWaitSwitch

12:01:00 am

This is the maximum time in queue waiting for a response from the switch

ScreenPauseSeconds

60

The number of seconds the screen is paused before it resumes the scroll.

SQLCatalog

MDSMKII

SQL database catalog name

SQLServer

IBM300-3\Y2011

SQL Server device

 

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.

 

Registry

Key_Description

Key_Data

Description

LogsDir

c:\logs

The directory for the logs. This directory must exist. It is not created.

Registry

Key_Description

Key_Data

Description

PagingIPAckAddress

192.168.0.47

The Switch expects a return address for paging sender acknowledgement.

Registry

Key_Description

Key_Data

Description

PagingIPAckPort

8000

The Switch expects a return address for paging sender acknowledgement.

Registry

Key_Description

Key_Data

Description

SQLServer

IBM300-3\Y2011

SQL Server device

Registry

Key_Description Key_Data Description
DecoderType RAW MTELOffice or RAW. Default is RAW. RAW is normal.

 

 MTELRelay table

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.

 

MTELRelay
Description Active Port Region
Kawana QFRS Y 7003 F2
Maroochydore QAS N 7004 A2
QAS_Cairns N 7030 A5
Rockhampton QAS N 7005 A3
Rockhampton QFRS N 7006 F3
Southport QAS N 7007 A4
Southport QFRS N 7008 F4
Springhill QAS N 7009 A5
Springhill QFRS N 7010 F5
Test Y 7031 *
Toowoomba QAS N 7015 A6
Toowoomba QFRS N 7016 F6
Townsville QAS N 7017 A7
Townsville QFRS N 7018 F7

 

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

 

local MDSUser
PagerID Region Capcode Description LastToAir MDSCheck
0012345 A5 233333 Paramedic Unit FORD F250 1994 REGONO: 502COE 5190 NORTHGATE 16/02/2011 8:02:53 AM 16/02/2011 8:02:04 AM
0077770 A4 1666663 Unit 4903 NAMBOUR STN. 15/02/2011 9:27:48 PM 16/02/2011 8:01:20 AM
0044483 A4 4555529 4435 Commodore Gin Gin 16/02/2011 8:00:26 AM 16/02/2011 8:00:26 AM
0222205 A4 5555763 4772 Caloundra 15/02/2011 9:28:10 PM 16/02/2011 8:00:19 AM

 

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.

 

 

 

Home ] Up ] Revision List ]  
Copyright © 2012-2021 MTEL Communications Pty Ltd
Last modified: 01-Jun-2022