MTELPage Direct Downloads:  

16/2/2024    Medium release MTELPageDirect V5.2(21)  Official Release

  This is a minor revision.

1. added PDEC_MESSEXPINQ

2. changed SWITCH_NO_RESP to PDEC_SWITCH_NO_RESP

3. added GROUPNOTINBASE to trap log

1/12/2023    Medium release MTELPageDirect V5.2(16)  Official Release

  This is a minor revision.

1. fixed file log names on backup

23/10/2023    Medium release MTELPageDirect V5.2(15)  Official Release

  This is a minor revision.

1. fixed file log names

2. changed MTELRelay grid size

20/10/2023    Medium release MTELPageDirect V5.2(14)  Official Release

  This is a minor revision.

1. cleanup logging added verbose checkbox

2. fixed XML packet IP and Port

12/9/2023    Medium release MTELPageDirect V5.2(8)  Official Release

  This is a minor revision.

1. cleanup to 2 days

2. cleanup of database list date check

 

download\mtelpdecsys.zip

12/9/2023    Medium release MTELPageDirect V5.2(6)  Official Release

  This is a minor revision.

1. when Editor sends a membership packet, PageDirect sends a group then the membership packet

2. added logging to system timer

6/9/2023    Medium release MTELPageDirect V5.2(5)  Official Release

  This is a minor revision.

1. moved Minimise button in menu

2. added DOWNLOAD packet type to MDSE packets. UPLOAD packets are sent immediately to MConnect.

3. DOWNLOAD packets are sent in a timely manner afer download from PageDirect

4. added delay to MDSE packets going to Relay after a delayed connection. 10 per second

24/8/2023    Medium release MTELPageDirect V5.2(2)  Official Release

  This is a minor revision.

1. added new Button  CleanUp. This sends a single cleanup packet to the relay. The Relay then runs a cleanup on the Group database.

2. added button DatabaseUpdate. This performs the 24 hour database download manually.

3. new Registry entry. CleanUpGroupTime. Set this to the time to perform the daily database download to the Relays.

4. downloads speed up to 5-10 packets per second.

5. changed MTELRelay log to be variable height not the Socket datagrid.

21/8/2023    Medium release MTELPageDirect V5.1(39)  Official Release

  This is a minor revision.

1. removed logging to file some TCP activity.

2. fixed logging on startup.

3. removed the RESP from Switch on no response. Converted to RESI so that the no response was a partial response not the last response.

4. added back in the MDSE packets that fail if the relay is not connected.

5. added cancel buttons to the Group and Membership downloads.

 

27/4/2023    Medium release MTELPageDirect V5.1(33)  Official Release

  This is a minor revision.

1. fixed NULL fields in sending records to Relays
2. added special info to the editor packets to the relays

13/4/2023    Medium release MTELPageDirect V5.0(32)   

  This is a medium revision.

1. changed protocol from Editor to receive the GPSQLID only. Then look up the record and send it to all the relays.
2. added activation and special info fields to the updates to relay.
3. major improvement to socket display for relays
4. added Name of the sever to startup config. New setting "ServerID"
5. fixed sending MDSE packets to the Editor

Bug Fixes:

1. added socket name to log instead of socket number

13/4/2023    Medium release MTELPageDirect V5.0(25)   

  This is a medium revision.

1. added database download buttons for Group database
2. added command processing for MDSEditor (single socket)

22/3/2021    Minor release MTELPageDirect V5.0(14)   

  This is a minor revision.

1. added database errors
2. fixed trap log time stamp

22/3/2021    Minor release MTELPageDirect V5.0(14)   

  This is a minor revision.

1. added database errors
2. fixed trap log time stamp
3. fixed relay log naming on backup

 

11/3/2021    Minor release MTELPageDirect V5.0(13)   

  This is a minor revision.

1. fixed Database Error. Now reopens database on any error
2. change LastReportableError from 1 minute to 10 seconds

5/3/2021    Minor release MTELPageDirect V5.0(11)   

     This is a medium revision.

1. fixed TRAP log entry

 

24/2/2021    Minor release MTELPageDirect V5.0(9)   

     This is a medium revision.

1. fixed TRAP log

2. fixed Done in packet back to MTELPage

3. added BackUpFile to RawLogClass for larger file names in the backup list

 

 

24/2/2021    Minor release MTELPageDirect V5.0(6)   

     This is a medium revision.

1. Added trap log back in.

 

4/2/2021    Minor release MTELPageDirect V5.0(3)   

     This is a medium revision.

1. Added to Registry table new record MTELRelayIP which binds the IP to the Relay sockets.

Registry

Key_Description	Key_Data	Description
MTELRelayIP	192.168.0.20	Base Address on the local machine to bind relay sockets

4/2/2021    Medium release MTELPageDirect V5.0(1)   

     This is a medium revision.

 

1. Removed all OAD components

2. Removed Database polling

3. Added Switch receiver

4. Add module k01 to MDSTCPClient table to make the Switch Receiver operate

5. Added new field in MTELRelay Table called WDOG as short text. N and Y are valid.

MTELRelay

Description	Active	WDOG	Port	Region
QAS Brisbane	N	N	7505	A5

 

PagerDEC Downloads:   

21/8/2014    Medium release PagerDEC V4.2(112)   

     This is a medium revision.

Added "QueueSendPeriod" to the Registry. This changes the rate at which messages are feed to the Switch. This entry must be added manually.

When the registry is change the following 3 variables are updated in the application immediately. The application does not require a restart to get the new values.

QueueSendPeriod        This is the period messages are sent to the switch.

PagingTIQWaitSwitch    This is the period the PagerDEC waits after sending a message to the switch, and does not get a response back from the switch. When the period expires the message is deleted from PagerDEC queue and a response is sent back to MTELPage to indicate SWITCH_NO_RESP.

PagingTIQPeriod            This is the maximum time a message can sit in the queue regardless if has been sent to the switch or not. This is a safeguard for the PagerDEC queue.

Changed the MTELRelay sockets to handle TCP buffer overwrites.

Added additional information to system log.

Fixed count bug on channel 2.

Added new log for the Relay TCP packets. It is called system_log_Relay_k01.txt. It is backed up at the same time as the System log. This log contains information relevant between the Relay and PagerDEC.

Added Manual Backup button in the General tab to back up the trap log only.

Rearranged the front display.

1. Changed number of channels from 6 to 2. Current system only has Vodafone F1 and F2 as the data streams.
2. Removed Bad packets count. No longer relevant on the new hardware
3. Removed System packets count. No longer relevant on the new hardware
4. Comms log width increased.

   

 

18/2/2014    Minor release PagerDEC V4.2(108)   

     This is a minor revision.

F1 heart beat had a run time error. This has been corrected.

10/2/2014    Minor release PagerDEC V4.2(107)   

     This is a minor revision.

If the Switch receives a new message packet from PagerDEC with the "Destination" field set to anything other than null it will send the message to the network in that field only.

The intention is to bypass the creation of associated network messages and group messages in the MDS. The message is already part of associated networks and groups created in MTELPage.

If the network in the destination field is not in the MDS Network table the message is aborted by MDS and the message is redirected to MTELQue.

If the pager number is not in the User table the message is aborted by MDS and the message is redirected to MTELQue.

 

PagerDEC packet now includes a network for all messages from MTELPage. MTELPage creates all associated network and the group messages .

6/6/2012    Minor release PDEC Start Up database (MTELPDECsys.mdb)   

1. The main change to this database is the addition of the DecoderType which is either RAW for the older style or MTELOffice which is the new decoders.

2. The other changes relevant to release V4.2(102) is the change in the timer values PagingTIQPeriod and PagingTIQWaitSwitch

   PagingTIQPeriod  this is the maximum period any message will stay in the PagerDEC queue. Typically it should be set to 30 minutes. These will always be low priority messages.

   PagingTIQWaitSwitch this is the period PagerDEC waits after a message is sent from the PagerDEC queue to the Switch and to receive a response in the event log indicating message is completed. Typically it should be about 2 minutes.

    

21/5/2012    Minor release PDEC V4.2(102)   

1. Added a watchdog response to the Relay WDOG request. This assists the Relay to determine if PagerDEC is operating in low volume centres where there is not enough packets to determine if the link is operational.

2. Changed the queue size to 100.

3. Changed the message time stamp to the Switch to the current time when a message moves from the queue in PDEC to the Switch. The creation time can become quite old if left at the entry to the queue time during message throttling of large groups.

2/5/2012    Minor release PDEC V4.2(99)   

One problem with PDEC is if a pager number generated by external databases such as MTELPage is not on the MDS User base then the origin of the message is not recorded in the MDS. Therefore it is not known which comms centre sent the message without searching all the MTELPage databases. This new feature traps these messages and stores them in a local log file for maintenance.

1. Added a log called system_log_TRAP.txt which traps all messages which contain a USERNOTINBASE flag. The log file is located in the same directory as the normal log file.

2. The file contains the date time, name of the originating socket, MTELPage message id, MDS message id, pager number , message and finally the MDS event log.

28/3/2011    Major release PDEC V4.2(95)   

1. Added two TCP ports for the new MTEL OAD hardware. The new hardware runs a broadcast protocol over TCP rather than the original slower interactive serial port protocol.

   The two ports and the new hardware operate on the two Hutchison 3 Paging frequencies rather than a combined hardware solution as in the original design.

   The diagram below is the older Springhill system.

    

   

    

    

   The diagram below is current solution.

    

   

    

    

    

2. 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.)

   

   The PagerDEC system log shows the TCP ports have been configured correctly.

   

    

   These address are the terminal server address in the OAD hardware. They should be configured first and tested with HyperTerminal to confirm their operation. (Note that if the IP addresses are not configured on the same IP segment then the Blackbox software will be required to find the MAC of these servers and allocate the IP to that device.)

   This is an example of the output from the OAD decoder if HyperTerminal is used to connect to the OAD socket.

   

    

3. The version has not been tested on the older serial based hardware. This version therefore may not be backward compatible.

    

4. This version is using the memory array processing for the capcode exclusion list. As shown below. The memory array reduces reads to the local and MDS database.

28/3/2011    PDEC V4.1(91)   

1. Memory array processing back in but debug printed if in error.

2. added debug on all database function errors which create an reopen on the database.

3. changed search on ~~MDSUser to simply get the oldest by using a sort rather than a query. Previous query was not working correctly.

4. TCP connection to decoder hardware had a state machine bug where a close on the port could prevent the socket from reopening. Changed the state machine to always process if socket closed.

28/3/2011    PDEC V4.1(84)   

1. Memory array processing commented out

PDEC V4.1(83) 2011

PDEC V4.1(83) 2011

1. Note PDEC Decoded Messages tab gets the last 1 hour of decoded messages. It uses the following query:

   "SELECT agency, pager_id_number, gps_time, log_time, unfiltered_message FROM PDec_Messages WHERE DATEDIFF(MI, log_time, GETDATE()) < 61 ORDER BY log_time DESC"

   The table should have an index on the "log_time" field to speed up the process.

    

2. The Decoded Messages tab has been changed to only populate when the tab is selected. This saves on processing time and resources.

    

3. Local memory array: This version introduces the capcode memory array which lasts the life of the application. 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 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.

   

    

28-2-2011    PagerDEC version (V4.1(81)) PagerDEC.htm has been updated

Minor Change

1.    Clicking on Reset Counters clears the Channel Active flag as well as clear the counters.

 

21-2-2011    PagerDEC version (V4.1(80)) PagerDEC.htm has been updated

Minor Changes

1.    Changed log startup text to (Catalog Server)

    Looking for SQL Database on MDSMKII 192.168.0.36

2.    Added On-error statements to timers and tab events.

3.    Concatenated MDSUser SQL table fields Vehicle and Description into one field for decoder outputs.

 

        PagerDEC version (V4.1(77)) PagerDEC.htm has been updated

        Minor Changes

16-2-2011

1. Fixed Bug: problem in backing up on start up. log file not ready so not backed up. This is only a problem for the first few seconds of the application. Used a global to avoid back up until app is fully loaded.

2. Changed the Decoded Messages to re-query when the tab is selected. Previous to this the record set was rebuilt on every new message added (crazy waste of resource).

16-2-2011 V4.1(76) PagerDEC    

        Major Changes

1. added local MDSUser table. This table is updated as capcodes are tested against the SQL MDSUser table. The local table is checked first, if there are no entries then the SQL MDSUser table is searched. If there is a match it is used in the decoder and a short form copy is sent to the local MDSUser table.

2. The decoder can operate without the SQL MDSUser table if the connection breaks. It will retry every 5 minutes, however it will delay the data stream by the SQL timeout which is about 30 seconds. Unfortunately opening the SQL database is a blocking function.

3. The local MDSUser database is located in the current directory as is called ~~MDSUser.mdb and is an Access database. This should not require compaction however if the table was excessivly large > 1 MByte then it should be copied out by the ~~empty MDSUser.mdb table.

4. 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 every minute.

5. LastToAir field is accurate.

        Minor Changes

1. Fixed Bug: problem in CheckMessageFilter added the check in the MDSUser . Just required one test that capcode was not in MDSUser.

2. added start up label to General tab.

3. added new column pager_id_capcode to PDec_Messages

4. added capcode, pager number and pager description to PDec_Messages.

5. increased the length of pager_id_name from 20 to 100 to match MDSUser

    PDEC_Messages Table

   

    

6. added (dd-mm) to list box system log

7. added startup messages to log after log is opened from system log list box.

8. fixed Ack to decoder hardware for TCP as well as serial

9. fixed Activity in MDSClient table. Now sends an update every 2 minutes which is the watchdog period. The Activity in this case means at least one message is acked in 2 minutes. The message is any message from the decoder hardware. It is mainly an indication that PagerDEC is in communication with the hardware equipment. It does not mean the Hutchison network is running. The threshold statistics logs are used for this activity.

10. Colours labels in the decoder have been changed to avoid looking like hyperlinks.

 

   7-2-2011 V4.0(69)

1. Fixed Bug: problem in CheckMessageFilter. Used the wrong variable in the sort.

2. added debug to display. Now has capcode in the missing message.

Added the following Registry entry. This must be added manually.

The default if it is not present is RAW. RAW is required for the current MDS system. MTELOffice is a different protocol. All other entries default to RAW.

7-2-2011 V4.0(68)

Added debug into the GeneralRecordset to show the failed SQL statement.

V1.00  5/1/2011

Missing Capcodes for PagerDEC       

This is the current Excel spreadsheet of missing capcodes for PagerDEC. It has been exported from the PDEC_miss_cc table in MDS.

 

Script for Missing Capcodes Table in MDS-PagerDEC       

This is the script to generate the missing capcodes table in MDS. The table is called PDEC_miss_cc.

 

The list contains the following fields;

 

Capcode

PagerNo

LastToAir

LastMessage

422493

0082983

29/10/2010

Updated database pager no 0082983 with capcode

421960

Duplicate

29/10/2010

Duplicate capcode in database. Investigate!

388533

Missing

14/11/2010

#:02084901,1A,31D01 ,31D UNCONSCIOUS , ,,UNIT

There are only three types of records, one to one, duplicate and missing.

All searches are based on the idea that the VisiCAD start of message is always "#:". If a message has a date in front it wont be detected. Some pagers in Hutch have this field turned on which is useless and will truncate some of the longer messages. When the #: has been detected in the first two characters of the message it trips off the search routines below.

The problem with this technique is it wont find QFRS messages. However QFRS capcodes are far more stable than QAS as they are generally hardware grouped. We could in the future use a special pattern to trip off the decoder e.g. "Test only. PLeaSe IGnoRe 10:58:22" This pattern of upper and lower case and time stamp would allow the decoder to uniquely identify that the message is intended to be searched whilst giving meaning to the user.

The message can then be searched in the MDS_Messages and the pager number can be used to update the MDSUser table.

 

Record Descriptions:

The first record is a one to one. This means the decoder did not find the capcode in the MDSUser table. The capcode number was searched in the Hutch database and only one match for the Pager Number was found. The Pager Number and capcode therefore have a one to one relationship.

This type of record can be updated in the MDSUser by matching the PagerNo field in the missing table to the Pager Number in the MDSUser table then inserting the missing capcode.

On the current database there are about 700 missing Hutch capcodes. The missing table has found 325 all are probably QAS pagers which are active. The rest are QFRS or pagers not in the metro network.

 

Record Duplicate:

The Duplicate record indicates Hutch has more than one pager number for the capcode. In this case the pager number can only be found by looking at all the matches and compare them to the pager number of the original message. This will need to be done manually.

Record Missing:

The missing record means the decoder has found a VisiCAD looking record and the capcode is not in the Hutch database. In this case the Hutch database may be old. Again a manual intervention is required to determine if the message is in fact a VisiCAD message then contact Hutch to get a pager number for the capcode.

  

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