Line monitoring

See also: IP Station Supervision

In security systems where intercom stations are used in emergency situations only, maybe just once per year, it’s extremely important that the equipment works when it’s finally used. To make a security system useful in practice, it’s necessary that the equipment has built-in line monitoring.

ASLT subscriber lines

Wire test

Error detection

The AlphaCom’s line boards ASLT (4-wire TouchLine station) and ATLB (2-wire telephone) monitors station wires continuously based on the fact that certain currents flows during the stations when everything is OK, and that either wire break or short-circuit creates abnormal currents that are detected and reported. The line boards has an on-board microcontroller which performs the line monitoring along with other tasks. This means fast response (errors are reported after 2-4 seconds), and there is no load on the functional software that runs on the AMC board.

NOTE:

The ASLT board determines automatically whether a station has display or not depending on the ab-wire 
current (display stations draw a constant 10 mA  to power the display). Some line error conditions may 
be detected to be wrong station type rather than a line problem. When the exchange is in doubt, 
a so-called “extended check” is performed - see detailed description below.

Error state: Station down

When a station wire is detected to be faulty, the station is assumed useless and is blocked by the exchange software. It’s no longer possible to dial to the station, i.e. attempts are rejected with a failure tone. (Group Calls will be connected, as there is no check of each station’s error state due to group set-up speed). Other station tests does not cause station down, they are just reported.

ASLT

ASLT performs continuous line monitoring, which can NOT be disabled.

Trick:

If you need a “portable” station that can be plugged in and out without causing line error reports,
you can connect resistors close to the exchange to form a “dummy station”, and then modify the 
portable station so that it lacks the corresponding resistors (contact support for details).

TouchLine station without display

• Break of all wires (station un-plug) is detected, but needs 1 to 3 minutes before report.
• The ab-wires (speaker) encodes the functions Off-hook, On-hook, M-key, C-key where off-hook is close to wire break, and C-key is close to short-circuit.
  

- Off-hook is not possible to separate from break, and is reported if the handset is off for more than one hour and no dialling takes place. (AMC feature, from version 07.20.)
- M key in idle for more than 10 minutes (from AMC 07.12/07.60: 1 hour 50 min) causes “station down”, then change to display-station mode.
- Short-circuit close to the station may not be detected on long lines (1 km) as the wire loop resistance limits the current to the normal C-key area.

• The cd-wires (microphone, keyboard) encodes the functions OPEN, PRIVATE, digit-key where OPEN is close to wire break, and digit-key is close to short-circuit. Single error on cd is not reported.
• Note that some cross-connects like c-wire shorted to b-wire is not possible to detect as the line currents change very little.

TouchLine station with display

• In this case the ab-wire is supplying power for the display, by adding a constant current of 10 mA to the ab-wires.

- Break is here detected immediately as there is a guaranteed 10 mA current in normal Off-hook.
- Short circuit on long lines is even more difficult to detect here as the C-key current is higher.

• From AMC 07.20: You can select a special station type “Interguard”, which means that line monitoring shall report deviations from display station limits immediately. Station type CRM 3 & 4 is included also.

ASLT Extended Line Check

In order to distinguish between the otherwise indistinguishable "station disconnected" and "non-display station with off-hook" states, a so-called "extended check" is initiated every 23 seconds if the station is presumed disconnected or in off-hook idle.

PS: The station is still considered idle when passively listening to audio programs, simplex (program) conferences or group calls.

The extended check utilises 4 closely spaced polarity reversals on the CD wire pair (double flash in station LED) to do this. As a side effect there will be double flashes on a station every 23s when the handset is left (or has fallen) off-hook so long that the handset dial tone has timed out. This is not a bug -- it is a feature! Consequently, this is done for display stations also.

When the station is actively used or a change of station is being detected, no such checks are done. All activities will, however time out and return to idle, allowing the plugging in or out of a non-display station with handset off to be detected eventually, no matter what.
Exception: Conversation does by default not time out -- time-out must be programmed explicitly.

ASLT error codes

The ASLT reports a code value to pinpoint a problem. Note that only the first detected error is flagged, and that there may be additional errors on the same station.
80 (1000 0000) = AB Shorted
40 (0100 0000) = AB Open
20 (0010 0000) = CD Shorted
10 (0001 0000) = CD Open

Tone test

General

To monitor a greater part of the total system than the default line monitoring does, it’s possible to run a “tone test”. A tone is then sent from the exchange via the line card to the station speaker. This acoustic tone is picked up by the station microphone, and returned via the line card to the exchange. Thus a complete test of the audio path is performed, i.e. both wires, electronics and electro-acoustical devices.

Tone test can only be run on typical loudspeaking intercom stations, as it must be able to generate a tone which the microphone can pick up clearly (well-defined difference between “silence” and “tone”). This fact has some implications:

• The test should be run in low-traffic periods of the day both to reduce background noise, and to avoid disturbing staff.
• It is possible to skip stations that does not have sufficient acoustic crosstalk, like handset stations, goose-necks witch close-talk microphone, etc. Stations that are used frequently, like guard stations, are “monitored” by humans, and may also be skipped.
• Some exchange functions like group call and high priority program/conference will be active while the speech channel is tested. Stations using there features should be skipped, or the test must be run outside normal working hours.
• Each station is tested once. If the test fails, the test is repeated a few times with a delay in between each test. If a repeated test gives correct result, the station is assumed OK. A station is reported faulty only if all repeated tests fails.

• Note 1: When using tone test in AlphaCom XE1, minimum software requirement is AMC 11.2.3.5 and IP Station software 02.2.3.3.
• Note 2: Analog stations uses a test tone at frequency 500 Hz, IP Stations uses a test tone at frequency 1.500 Hz.

Day-to-day use

Automatic

The tone test is run automatically once per hour during night time (configurable), at low priority. The test uses 3 seconds per tested station, i.e. 20 stations per minute. A 550 liner uses some 30 minutes for a full test.

The exchange’s log port will print one line per each station that changed state (faulty/OK) during the test.
Example log:

14/09-19:00 TT === ToneTest START   ===
14/09-19:04 Line Audio  ERROR  Code: 1F  Dir:   101 Phys:   1 [N001 M65 B01-1]
14/09-19:06 Line Audio  OK     Code: 45  Dir:   101 Phys:   1 [N001 M65 B01-1]
14/09-19:07 TT === ToneTest END     ===  Errors: 0(0) Skip: 19 OK: 3(1)

Manual

A service man must be able to start the test during commissioning and before/after repair to get a full line error status of the exchange. This is done by dialing a feature code (default 7885) that starts a full test, running full speed with 0,3 seconds per tested station, i.e. 180 stations per minute, or 3 minutes on a full 550 exchange.

The exchange’s log port will print one line per station that have “line audio” error, plus one line for each station that was skipped either due to busy (possibly handset off-hook error) or line wire error status.

Example log:

14/09-19:03 TT === ToneTest START   ===
14/09-19:04 Line Audio  ERROR  Code: 1F  Dir:   101 Phys:   1 [N001 M65 B01-1]
14/09-19:04 TT Skip: Line Down (Faulty)  Dir:   104 Phys:   4 [N001 M65 B01-4]
14/09-19:04 Handset Off ERROR  Code: 00  Dir:   105 Phys:   5 [N001 M65 B01-5]
14/09-19:04 TT Skip: Line Down (Faulty)  Dir:   106 Phys:   6 [N001 M65 B01-6]
14/09-19:04 TT Skip: Board Missing       Dir:   131 Phys:  31 [N001 M255 B64-1]
14/09-19:04 TT Skip: Board Missing       Dir:   132 Phys:  32 [N001 M255 B64-2]
14/09-19:04 TT Skip: Board Missing       Dir:   133 Phys:  33 [N001 M255 B64-3]
14/09-19:04 TT Skip: Board Missing       Dir:   134 Phys:  34 [N001 M255 B64-4]
14/09-19:04 TT Skip: Board Missing       Dir:   135 Phys:  35 [N001 M255 B64-5]
14/09-19:04 TT Skip: Board Missing       Dir:   136 Phys:  36 [N001 M255 B64-6]
14/09-19:04 TT Skip: Line Down (Faulty)  Dir:   152 Phys:  52 [N001 M65 B09-4]
14/09-19:04 TT Skip: Line Down (Faulty)  Dir:   153 Phys:  53 [N001 M65 B09-5]
14/09-19:04 TT Skip: Line Down (Faulty)  Dir:   154 Phys:  54 [N001 M65 B09-6]
14/09-19:05 TT === ToneTest END     ===  Errors: 1(1) Skip: 21 OK: 0(0)

The log info

Error Code

The tone test uses two audio level measurements, one of silence and one of tone. The tone level must be somewhat higher than silence to pass the test, and if it fails, the difference is shown here as Code (hexadecimal). If the value is 00, it means identical or negative difference.

Autoload value for limit is 0x28, decimal 40, which corresponds to some 16 dB. When an error is reported, the Code will be below 0x28. When the station is reported OK, Code will be above 0x28, typically 30-50.

Test statistics

When the test finishes, one line with statistics is printed.
Statistics includes both total counts, and also changes since last test in parentheses (0).

• Errors: The number of stations actually tested with tone, and that failed.
• Skip: Stations that are configured as testable, but could not be tested right now either due to wire error “Line down (faulty)”, “handset off” timeout, or in use (“resource busy”).
  

This means that you should consider these as possibly faulty stations, and re-run the test later.

• OK: The number of stations actually tested and passed in the tone test.
  

The sum of (errors + skip + OK) are constant, equal to the number of testable stations.

Test Algorithm

Activation:

• Automatic

• Enabling on system level on/off. Autoloaded off.
• Start hour, end hour (runs once per hour in this period). Autoload 00:00, 00:00.

• Manual, by dialing feature code.

• Feature dir.no is autoloaded.

COS autoloaded only for superuser.

• Manual activation is allowed even if automatic is disabled.

The function can be used as a commissioning test for all systems, where the service man hooks up his laptop PC to the log port just to test the installation before leaving.

• Manual activation while a automatic/manual test is running will just restart the test with new test parameters.

Algorithm:

• The test works like this is:

Connect speaker to silence for 200 ms, then measure level. Connect speaker to 500 Hz for 200 ms, then measure level. If the difference is larger than 16 dB, OK, else failure.

• Tone test runs only if station is idle and free.

The station is allocated while it’s used, with normal (low) priority. Normal allocation has the following effects:

- Tone test will not disturb normal operations in the exchange

- Stations with wire error and non-connected stations can’t be allocated, so they are skipped automatically

- Audio program is switced off. Notifier blink/bleep is switched off.

- Allocation with result “busy” causes periodic re-try, like unsucessful test (gives a camp-on effect)

• Tone tests handles only loudspeaking stations

- ASLT positions with “station type - PNCI” are skipped

- AGA ports with “port use - station” are tested

- all other board types are skipped (ATLB, ASVP, AGA program,. AGA multimodule, AGA AlphaNet)

- it’s possible to configure “disable tone test” on a per-station basis

• Tone test may be disturbed by noise

→ Reports unsuccessful test, but does not shutdown the station. It’s important to keep the functionality of the station which may be left even after a unsuccessful tone test, e.g. the push-button may still be able to signal emergency.

• Testing of noisy stations

- A station is accepted as OK after a single silence/tone sequence, i.e. minimum test time.

- If a test sequence fails, the station is re-tested up to a configurable number of times (default 3), each with a delay of 5 seconds in between, thus reducing the chance that temporary noise disturbed a test.

- The station is allocated and released for each attempt. This strategy also handles possible faulty level (duplex) scanners, which have no self-test.

TST NVRAM configurable options for Tone Test

The following algoritm parameters can be modified using the TST Console NVRAM command:
.ex_profile .line_monitoring .tt_retries

Autoload value 3.

This is the number of re-tries on each station that fails the tone test. Between each re-try the long 3.6 seconds tone_test_timeout is used (see below). If a re-try gives an acceptable measurement the station is declared OK, else it’s declared a failure when all re-tries have been done.

.ex_profile .line_monitoring .tt_limit

Autoload value 40 (hexadecimal 0x28).

This is the limit for the difference in audio level between 500 Hz and silence, where 40 corresponds to some 16 dB.

If there are problems with background noise etc., it’s possible to reduce this limit somewhat. Inspect the error log, and check the code field to see what values you get in practice (observe that the code field is hexadecimal). Then set the limit below this. Reducing the value too much reduces the value of the test, as differences in background noice may be enough to pass the test over a few re-tries!

.ex_profile .timeouts .sli_measure_duration

Autoload value 1, i.e. 100 ms (plus 100 ms minimum).

This is the duration of the silence and the 500 Hz tone periods.

If there is a problem e.g. with echoes, try setting this value to 5 or 10 (0.5 to 1 second). Note that the actual measurement is just 20 ms, this setting just delays when it’s taken.

.ex_profile .timeouts .tone_test_timeout

Autoload value 35, i.e. 3.5 seconds (plus 100 ms minimum).

This is the delay between each tested station in automatic (night-time) mode, which you can observe as time between each station blink/beep. The automatic test can be run once per hour, so setting this value higher means that the test may not finish in one hour if there are a few errors. Setting it much lower means that the exchange becomes more busy when the test runs.

.ex_profile .timeouts .skip_test_timeout

Autoload value 2, i.e. 200 ms (plus 100 ms minimum).

This is the delay between each skipped station.

The test progresses quckly to the next station when no test can be performed (board not in position, no test configured, or station has som other error). This value can be reduced to increase the speed of the manual test somewhat, on the expence of a more busy exchange.

Troubleshooting

The test depends on a good ratio between silence and tone. To improve the measurement quality, you can try different things:

• Increase measurement duration time, so that audio stabilizes e.g. in rooms with echo
• Increase number of re-tries, which increases the likelihood that one test passes
• Increase speaker volume, so that the tone becomes louder than background noise
• Reduce microphone sensitivity. The level measurements which are done by the duplex scanners on the ASLT boards are non-linear at high levels and thus may not distinguish noise from noise+tone very well.
• Be aware of stuck call buttons, M-keys etc. The exchange is allowed to call to (and tone test) such stations, even if they may function not very well audio-wise.

Error reporting

Error reporting was designed to inform personnel when an error occurred, on standard exchange devices. Each error is reported only once, and only when the station becomes faulty, NOT when it’s OK again. Staff should inspect the faulty station immediately, and must keep written records of the total exchange error status.

System “Faulty line” event

This event is on the system level, i.e. all stations will be processed identically by the actions set up here. It’s possible to assign one or more actions during commissioning. Typical:

• MST, i.e. mail to station. One or more stations can be notified via the mail queue that a station is faulty.

In addition to notifying a local station, an additional mail can be sent to a station in another AlphaNet node.

• MPP, i.e. mail to pocket pager. One pager can receive display calls when line faults occur. This will normally be in addition to the MST action. Pagers often have short displays, and can present reduced error identification only.

Configuration: AlphaPro RCI screen, below the 60 RCI’s in the scroll box.

Station “Line error” event

This event is per station, i.e. unique error actions for selected stations. It’s possible to assign one or more actions during commissioning. Typical:

• RCO, i.e. control an digital (relay) output which switches over e.g. a power amplifier to a standby unit.

(this event is reported both for error ON and OFF, but is not restored after reset - se below).

Configuration: AlphaPro Users/Event screen. (from AMC version 07.00)

Exchange log port (serial printer)

The log port prints a lines when a fault occurs, identifying the station and the physical position (Node, Module, Board-port) it’s connected to.

14/09-18:44 Line Wire   ERROR  Code: 10  Dir:   106 Phys:   6 [N001 M65 B01-6]

Configuration: AlphaPro System Info/More screen.

Data protocol support

AMC 07.20 and earlier versions

There are no direct error reports in the exchange’s AlphaCom data protocol.

It’s possible to use the mail to station information though. Every time a station receives a mail a broadcast is made. It’s then possible for an external computer to read out the mail entry using additional data commands, and thus get the mail’s display text which contains information about the kind of error, and the technical address of the faulty station (or device).

This information is available when the error occurs only, and there is no information when the error is corrected (the external computer can poll the faulty station by attempting conversation set-up, which is rejected until the station becomes OK and free).

AMC 07.30 and newer versions

See separate chapter describing data protocol messages and routing possibilities.

TouchLine data protocol

The TouchLine data protocol never reports errors.

(The upcoming AMC 08.00 will be able to send text to the TouchLine port from the Event Handler. This can be used to generate TL error messages based on error events.)

Data protocol support for Error reports

Overview

From AMC 07.30 there are two new data protocol messages which are used during exchange status monitoring:

• STATUS_REPORT, which is used for errors
• LOG_STRING, which is used for free text like “tone test end”

Routing of status information

When an exchange generates an error message, it will be sent to one or two destinations.

There is two configurable addresses, labelled “Log local” and “Log global”. Both addresses are full node+device description, so there is no functional difference.

(Fields available in AlphaPro 08.00). The fields can be configured in AMC 07.30 using the TST NVRAM:
.ex_profile .line_monitoring .report1_addr…
.ex_profile .line_monitoring .report2_addr… , both with sub-fields .node_id and .device_id.

Address configuration

• If “local” is 0+0 (autoload value), status reports are directed to the exchange’s local log port.

Typical application: Simple standard log port.

• If “local” is different from 0+0, status reports are sent to that address.

Typical application: A PC connected to this exchange, e.g. a local guard.

• If “global” is different from 0+0, status reports are sent to that address also.

Typical application: A PC connected to an operational central exchange, e.g. main guard.

• If you have to send to 2 devices, and also need a printout, this must then be handled by the PC devices.

Valid addresses

• The AlphaCom’s log port can be addressed as node+65
  

- The AlphaCom will print time/date, the message formatted, and <CR/LF>.
- When several AlphaComs are used as a single huge exchange, it’s possible to get all error reports on a single printer. A distributed security network can report errors in the central guard exchange.

• It’s possible to use broadcast device address 255

This way several PCs connected to one exchange can get a copy of the error report. Consider use of broadcasts carefully, preferably only in low-traffic systems!

• It’s possible to use broadcast node address 255

This way all PCs connected to all exchanges can get a copy of the report. AlphaNet broadcasts should only be used in very special situations, as they create a lot of network traffic.

Forwarding of error reports

Incomming data protocol messages addressed to an exchange’s log port (node+65) will be processed through the same addressing mechanism as error messages generated internally. This means that it’s possible to set up forwarding of log messages.

• A network of exchanges can initially be configured to do centralized logging in one exchange. You can then later modify what this central loging actually does, e.g. change from a simple printer logging to a PC based logging (or both), or even forward to yet another exchange.
• If some device like RIO in the future gets logging capability, it can be set up always to use the local exchange’s log port. These log entries will then be routed identically to messages generated by the exchange itself.

Reported events

AMC 07.30 has been re-written to produce station line monitoring errors as data protocol messages. In addition, we have done some general preparations to allow a more complete error reporting in AMC 08.00.

DP message: LOG_STRING 117

This is a free text report message. It will be used to inform maintenance personell about events not directly related to error/OK status of specific equipment, e.g. start and stop of tone test. The data protocol message LOG_STRING has the following data fields:

Text

The text does not contain the “header” time/date or the “trailer” <return><linefeed>.

Node number of source exchange

Note that an external system must get the source node number from the net-layer header if it handles info from several exchanges. The <text> itself normally contain no node info.

DP message: STATUS_REPORT 114

This data protocol message is very general, intended both to report precence of, and error state for all kinds of exchange resources. Due to the broad use, the stringent specification in the data protocl document is not easy to read. The exchange generates only one message per station, possibly with several error statuses. Here is a description of what station error messages will look like:

• Station id (physical) number

NET_OBJ_REF with entity class ECL_STATION, and value 1..552. Entity sub-class is supplied to indicate board type ASLT/ATLB/AGA for AlphaCom.

• Station physical address

NET_OBJ_REF which identifies Node, Device, Board, Port where this station’s wires are connected. AlphaCom exchange devices are 65, 66, 67, 68 (1 to 4 modules). Board is position in module’s card cage, i.e. 1..26. Port is interface within board, 0..5 on ASLT or ATLB line boards.

• Error flags

The flags are sorted in a kind of priority sequence, as an error in the first makes the rest meaningless. (Future stations may have tests that can fail independently).

IF_PRESENCE	I.e. ASLT/ATLB line board present - not implemented in 07.30
INTERFACE_TEST	I.e. the line wire monitoring performed by the line board itself.
	        Note:  Only ERROR is reported in 07.30, not OK.
	        This error status is generated on all 6 lines also if the line board fails.
AUDIO_TEST	Result of the current Tone Test, both ERROR and OK.
DEV_DEP_TEST_1	Reports Handset OFF Timeout, both ERROR and OK.

• Change flags

The exchange knows the error status of many tests. E.g. the Tone Test can be run manually many times, and ERROR will be repored every time. The corresponding CHANGE flag will be TRUE only the first time after a chage to ERROR or OK. This can be used by an external system e.g. to log the event on disk only once, but a screen symbol could be refreshed every time.

• Reporting flags
  

Only VERBOSE currently. E.g. will the Tone Test when started manually report all faulty stations, and the external system can use this flag to display all received info to the user.

• Error info 1
  

INTERFACE_TEST error code: A value from ALST/ATLB with ab and cd wire info.

• Error info 2
  

AUDIO_TEST error code: The (tone signal - silence) difference value measured. If this value is less than 40 (0x28) the station is reported as faulty.

• Station directory number
  

NET_OBJ_REF holding the station’s dir.no, 1-4 digits. If the station has no directory number, the parameter is missing.

Exchange cold start and reset

The exchange uses NVRAM, i.e. battery backed RAM. The NVRAM holds static configuration data and dynamic operation status while power down.

Boards

In NVRAM there is a table which shows the status for all line boards. The statuses are:

• Never used (initial value after autoload/coldstart)
• Board in place and OK
• Board not in place or faulty.

During system startup, each board is tested by AMC, and all boards that are found then changes state to present and OK.

A faulty board causes line error status on all it’s 6 subscriber lines. On the other hand, a never used board blocks line monitoring so that there are no irrelevant line errors reported.

To allow reduction of the number of boards in the exchange, there is a directory number “7870 Reset Board Error “ (feature code 66) which resets the NVRAM tables so that all faulty/missing boards positions are marked “never used”.

Stations

In NVRAM there is also a table with status per station line. The statuses are:

• Line faulty
• Line OK

This table is autoloaded to “line faulty” for all stations. Immediately after reset the line boards will test each line, and those OK will change status to ”line OK”. As there is no general reporting (mail or log) when stations become OK, this causes no massive mail/log operations during the startup of the exchange.

Lines that start as faulty are not reported as faulty if they’re not OK during system startup. This mechanisms avoids error reports on stations never connected.

Event Handling

Events are not re-generated after reset. This means that e.g. a RCO used to switch a line over to standby PA will be in normal position again after a reset.

Segmented reporting

Sometimes the customer want to divide an exchange into segments where error reports are sent to the closest guard only. This way the guard is responsible for call handling for his “own” stations, and will be informed if there is problems with these stations.

The exchange reports station line errors two places, one on the system level “Faulty Line” (RCI menu), and one per station “Faulty Station Line” (Event Handler). The system level reporting is intended for general error reporting, while the per station report is primarily intended when each station needs specialized handling like switching a PA zone to a standby amplifier.

You can mix these two reporting methods, so that all errors are reported to a Building Maintenance office which are responsible for service. In addition, stations related to zones can in be reported to local guards so that they know if they must take special care e.g. if a door station leading into their zone is faulty.

External Features

To implement a segment feature, you must use the Event Handler and UDP groups.

UDP groups allows you to define up to 8 custom properties for stations. In this case, we can divide the exchange in up to 8 segments that shall be handled the same way.

This example shows other uses of UDP group also, so you must plan all desired functionality before deciding how many segments are possible.

When you have defined the zones, you must go through the exchange station by station and assign it to a zone.

Event Handler

In the Event Handler you can set up one action per segment, thus creating unique handling for the segment. Note that you need only ONE event entry to handle ALL stations in the zone.

Send mail

The event “owner” is an UDP group, i.e. read as “when any station in zone A gets a line error, send a mail to station phys.no 50”. Note “when change to” ON, as this event will go ON and OFF with the error status.

The example shows a free text mail. (Note that the MST action, mail-id 28 will not work here, it’s meant for system-level use in RCI menu only).

MST 50 %1.PHY() "Line err: %1.DIR() %1.NAM()"

Explanation of parameter fields:

%1.PHY() - faulty station’s physical number.

%1.DIR() - faulty station’s directory number

%1.NAM() - faulty station’s name (will be shown only partially)

You can create any text you want, using these three pieces of information.

Removal of mail

Note also that the mail will not be removed when the station becomes OK. The guard must accept the error mail using 70 + 0. It’s possible to check the station by dialing 70 +8 (call back), but it will NOT remove the mail.

If you want automatic removal, you can set up similar events for “when change to” OFF, and use action $CANM N%1.PHY() N50 NM255 U255

Note: This does not work in X07.60due to a bug - please contact Product Support in Trondheim for details!6.3

Segmented logging to printer

You can use the same configuration method to have local printers for each guard, which loggs only calls related to that zone.

Event Faulty station line, when change to Always, Action string:

$LOG 1 “Station line %3.CHG(error,OK ): %1.DIR() %1.NAM()”

%3.chg is the event’s change information (ON/OFF), where you can put your own on-text and off-text. The

The action string above would come on the exchange’s log port. It’s possible to set up RIOs with software 02.12 (in multidrop mode) as log printer devices, then using an address like this:

@0101 $LOG 1 “Station line %3.CHG(error,OK ): %1.DIR() %1.NAM()”

@0102 $LOG 1 “Station line %3.CHG(error,OK ): %1.DIR() %1.NAM()”

to log to device 1, 2 etc.

ATLB subscriber lines

You can activate line monitoring of (modified) telephones in AlphaPro per physical number. It’s possible to select the limit for the current, which is necessary to handle various line voltages and line lengths.

Telephone with parallel resistor

• An on-hook telephone draws very little current. To be able to detect a wire break, it’s necessary to connect a resistor in parallel close to (or inside) the telephone.
• An off-hook telephone draws a lot of current which is not possible to separate from short-circuit, and is reported if the handset is off for more than a one hour and no dialling takes place.

ATLB Error Codes

Currently, ATLB reports identically to ASLT. (As there is little information in that, this may be changed in the future to the 8-bit line current value which is compared to the value entered in AlphaPro as monitoring limit).

40 (0100 0000) = AB Open