Because RFL™ and Hubbell® have a policy of continuous product improvement, we reserve the right to change designs and specifications without notice.
Each of these timers can be independently set to be disabled (DISA) or can be set to any of the
following values: 0ms, 0.66ms, 1.3ms, 2.0ms, 2.7ms, 3.3ms, 4.0ms, 4.6ms, 5.3ms, 6.0ms, 6.6ms,
7.3ms, 8.0ms, 8.6ms and 9.3ms. Setting of 0ms denotes instant activation of timer (minimum delay).
To program the desired values of timers for data squelching, both pre- and post-squelch timers must be
set to a value that is not DISA (disabled). If either value is DISA, data squelch will not take place.
Debouncing of loss-of-sync and fallback is controlled only by post-squelch control; the same value
pertains to both data squelch and loss-of-sync debouncing. Pre-squelch setting has no effect on loss-of-
sync debouncing and may be left disabled if not needed for data squelch.
The interaction of both settings is shown in the chart below.
Table 4-9. Squelch Settings
Squelch Settings
POSQ
Post-Squelch
Data Squelch
Functionality
Debouncing
loss-of-sync
PRSQ
Pre-Squelch
DISA DISA
No data squelch No debouncing
(disabled) (disabled)
DISA
Set to a value 0ms
or higher
Signal debounced
No data squelch
(disabled) (extended)
Set to a value 0ms
or higher
Set to a value 0ms
or higher
Signal debounced
Data squelched
(extended)
No data squelch No debouncing
DISA
Set to a value 0ms
or higher (disabled)
RFL recommends a value of 2ms as an initial setting for both pre- and post-squelch timers for
multiplexers operating in terminal shelf configuration. Drop-and-Insert shelves require more attention
to debouncing of loss-of-sync and thus RFL recommends 2ms pre-squelch and 9.3ms post-squelch as
initial settings in Drop and Insert configurations.
The system engineer should review these settings with care, as they control the effect of disturbances
on system behavior.
In applications that check their own data integrity, such as digital data traffic, squelch timer values can
be shortened or even eliminated. In applications that use received data without any further checks, such
as voice traffic, delays should be extended to prevent noise from appearing as valid transmissions.
M-DACS-T1 RFL Electronics Inc.
July 18, 2008 4-20 (973) 334-3100