To: All Concerned Fr: On Air USA Dt: 27 February 2002 Re: UDS II environmental variables The purpose of this document is to encapsulate information about UDS II environmental variables into one textfile. References in this document to "ENV" mean "environmental variable". An environmental variable is a convenient way to cause a program, such as the UDS II, to behave differently based upon the setting of that variable. In most cases, an "ENV" is a "set once and forget" operation. In all cases, it allows runtime behavior to be modified without the added overhead of an interactive configuration menu or picklist (such as found in the UDS II's F8 window). In all cases, an "ENV" persists only in RAM (in a region reserved for "the environment") and is destroyed after a reboot. Resultantly, it is customary to set an "ENV" in the AUTOEXEC.BAT file located in the C:\ directory. This means those variables will be re-established with each reboot of the computer. (Perhaps the best known of an environmental variable is the one that sets the "PATH"). The default value of the environment's size is 256 bytes. If, after addition of "ENVs", the message "environment too large" appears, the user should add the /E:nnnn (where nnnn is a number in bytes) option to the SHELL= line in CONFIG.SYS to "upsize" the environment. 27 February 2002 ---------------- On behalf of client WZRU in Roanoke Rapids, NC, Ed Dravecky has demonstrated an additional value for DCS_HALT_PRIOR (and its equivalent, RSHD_HALT_PRIOR). * This new value is 9 (with 8 being reserved for possible future use). It is available as of UDS II version 2.35k. In short terms, setting either DCS_HALT_PRIOR or RSHD_HALT_PRIOR to a value of 9 is "sure kill" of the prior non-music digital audio item. This means that regardless of the next source...and regardless of what triggers the segue, there will be no overlap of audio. * Refer to the section below designated with II, which contains documentation of all digital audio-related ENV user-configurable parameters. 21 January 2002 --------------- As of version 00.27a of the RS-HD's ``oad-main'' application, a change made in the QUEUE CART response has an impact on the behavior of the RSHD_CUT_INFO environmental variable. * Refer to the section below designated with II, which contains documentation of all digital audio-related ENV user-configurable parameters. In short terms, all non-music (MOHD) carts will now have the cut number revealed even if there is only one cut (or "subcart") associated with the cart. 14 December 2001 ---------------- As of version 2.34z of the UDS II (DPMI or otherwise), the range of allowable IRQs and addreses for UDS II's "Primary" and "Secondary" serial devices has been expanded to encompass the entire spectrum. * The following environmental variables are impacted by this modification: ENV Description --- ----------- UDS2_RS232_IRQ Primary serial IRQ UDS2_RS232_ADR Primary serial port address UDS2_RS232_2ND_IRQ Secondary serial IRQ UDS2_RS232_2ND_ADR Secondary serial port address 1). For either device, the allowable IRQs are: 3 4 5 9 10 11 12 13 15 2). For either device, the allowable port addresses are: $2E8 $2F8 $3E8 $3F8 Also be sure to consult the notes in this document for section IV, which summarizes all of the hardware-related ENVs. Given that a number of serial devices can be used by the UDS II, it is imperative that the IRQ and port addresses don't conflict with other UDS II devices. Furthermore, measures must be taken to avoid possible device contention with external hardware such as a modem or a mouse. 19 November 2001 ---------------- Throughout this document, reference is made to setting environmental variables in the C:\AUTOEXEC.BAT file. On a DOS-based system hosting the UDS II, that is the preferred place to set these ENVs so that the values persists across reboots. - However, if using a DPMI flavor of the UDS II on a Windows platform, the preferred location for UDS II-specific environmental variables is C:\UDS2\UDS2CONF.BAT. This fully-annonated file is run just prior to launching the UDS II binary, canonically C:\UDS2\UDS2.EXE, by one of three PIF files supplied with UDS II when it detected a Windows platform. 13 November 2001 ---------------- As of version 2.34u of the UDS II (DPMI versions only), the environmental variable, UDS2_OAD_MIXER, was changed from a boolean to one permitting a range of values. As of this date and UDS II version, the allowable range is either 1 or 2. - If set to a value of 1, RS-422 commands that are intended to manipulate an audio mixer (such as the A-4000 or SM-05) are instead redirected out the RS-232 serial port where they are eligible for the control of sound card levels. When set to 1, an RS-422 card is still expected to be present, affording the ability to manipulate relays and respond to contact closures. * When UDS2_OAD_MIXER is set to a value of 1 in the environment, the following informative entries are written to the current DIALOG and UDS2BOOT.LOG files: "OAD_MIXER = 1: RS-422 mixer control disabled" "OAD_MIXER = 1: relays and contact closures enabled" - Likewise, if set to a value of 2, RS-422 commands that are intended to manipulate an audio mixer (such as the A-4000 or SM-05) are instead redirected out the RS-232 serial port where they are eligible for the control of sound card levels. However, when set to 2, an RS-422 card is NOT expected to be present. Consequently, the UDS II has no ability to either manipulate relays nor is it capable of responding to contact closures. * When UDS2_OAD_MIXER is set to a value of 2 in the environment, the following informational lines are written to the current DIALOG and UDS2BOOT.LOG files: "OAD_MIXER = 2: RS-422 mixer control disabled" "OAD_MIXER = 2: relays and contact closures disabled" 13 October 2001 --------------- As of version 2.34m of the UDS II (DPMI versions only), there is support for a boolean environmental variable, UDS2_OAD_MIXER. - If set to a value of 1, RS-422 commands that are intended to manipulate an audio mixer (such as the A-4000 or SM-05) are instead redirected out the RS-232 serial port where they are eligible for the control of sound card levels. 11 October 2001 --------------- Throughout this document, there are references to environmental variables with the prefix of ``DCS_''. An example of such is ``DCS_SS_FADE''. Note that, at the preference of the user, such environmental variables may use ``RSHD_'' as a prefix rather than ``DCS_''. Note that "RSHD_" in this context does not have a dash. - In the case of DCS_SS_FADE, the name would then become RSHD_SS_FADE. 10 July 2001 ------------ As of UDS II version 2.33s, a new environmental variable was added for a specific type of RBDS encoder, the Inovonics Radio Data Encoder Model 711. * The means by which to configure a UDS II system to support this encoder is to set the following in the environment: UDS2_RBDS=INOVONICS_711 * Note that the value is case-sensitive, requiring use of uppercase. Also, the underscore is required prior to the "711" designation. Refer to the notes in section III. below for additional details on this and other RBDS-related environmental variables. 26 June 2001 ------------ A new environmental variable is supported for all five types of RBDS units available to the UDS II: UDS2_RBDS_SPEED Refer to the notes in section III. below for additional details on this and other RBDS-related environmental variables. 11 June 2001 ------------ - As of version 2.33eN, currently an internal release version, a new value may be used for UDS2_RBDS: STREAMAUDIO Note that the value is case sensitive and is used without any form of punctuation or separator between the characters spelling the word. Although the StreamAudio system (intended for use by Cox Broadcasting in Miami) is not technically an RBDS utilization, it is still classifed as RBDS-like for the purpose of this document. As a consequence, refer to section III. below for additional details on this and other RBDS-related environmental variables. 7 June 2001 ----------- Note that environmental variables can be considered as "key/value" pairs with the string to the left of the assignment operator serving as the KEY and the string to the right as the VALUE, viz., KEY=VALUE 1). There must be no whitespace on either side of the assignment operator (equal sign). 2). There must be no trailing whitespace after the VALUE. This aspect is a bit difficult to track down since trailing whitespace is very hard to spot in most editors. One technique to find it is to locate the end of the line. If the cursor lands in a region beyond the VALUE, there may be whitespace. If the "vi" editor can be used on the file providing UDS II enviromental variable key/values, use the ":%list" command which will unambiguously show any stray whitespace in the file. 3). The KEY portion of an environmental variable is NOT case sensitive. Convention, inherited from MS-DOS, is to use all uppercase letters for the KEY portion. Although not required, adherence to this custom is strongly recommended. 4). On the other hand, the VALUE portion _is_ case sensitive, unless otherwise noted. For example: UDS2_RBDS=ASCII [Correct] uds2_RBDS=ASCII [Correct, not recommended] UDS2_RBDS=Ascii [Incorrect, value not "ASCII"] 8 March 2001 ------------ While on site at WVRU in Radford, VA performing an upgrade to RS-HD/UDS II, Ed Dravecky posed the following question via e-mail: > One point of confusion on my end: The UDS2.!!! files clearly shows > that environmental variables such as UDS2_8255_ADR and UDS2_RS232_ADR i > should be set to values like "380" but the UDS2_ENV.TXT files shows > values like "$380" just as clearly. Which is correct? (Are both > correct in this context?) Both are correct. The ``$'' symbol is used (in a Pascalian sense) to explictly state that the value is hexadecimal. However, it can be dropped since the UDS II's internal parser recognizes that the value is going to be hexadecimal, with of without the leading currency symbol. Consequently, either of the following yield the identical results: UDS2_8255_ADR=380 UDS2_8255_ADR=$380 - This optional eliding of the leading ``$'' applies to any environmental variable using a hexadecimal value. 26 October 2000 --------------- As of version 2.31c of the UDS II, IRQ 5 was added to the list of allowed values for UDS2_RS232_3RD_IRQ. Consequently, the complete list of valid values is: 3 4 5 9 10 11 12 13 15 Remember that there is no default value. 24 October 2000 --------------- As of version 2.30y of the UDS II, the following environmental variable may optionally be used to force the system to associate a utility relay with a simple network record enable command -- even when the UDS II is configured with a serially-controlled external switcher, currently one of the 6x1 or the 10x1 units from Broadcast Tools. This is a boolean ENV and must be set to a value of 1 for it to be in effect. UDS2_RECORDING_RELAY When set to a value of 1, a system command on source 80 imported via a breaknote such as the following will cause relay #2 to fire in spite of serial control of the switcher being available: ^80 [2] {REC0} Refer to the notes in section IV of this document for more details regarding the syntax of this environmental variable. 20 October 2000 --------------- As of version 2.30q of the UDS II, the following environmental variable is supported to enable serial control of an external Broadcast Tools Switcher/Router (currently either the 6x1 or the 10x1). UDS2_SWITCHER - The value must be set to one of BT6X1 or BT10X1. Refer to section IV in this document for additional information and further details. * Note that there is a mutual relationship between all three of these recently introduced ENVs: UDS2_SWITCHER UDS2_RS232_3RD_IRQ UDS2_RS232_3RD_ADR Every one of them must be set to a valid value in order to enable serial control of one of the two aforementioned Broadcast Tools Switcher/Routers. 19 October 2000 --------------- As of version 2.30n of the UDS II, the following two environmental variables are supported: UDS2_RS232_3RD_IRQ UDS2_RS232_3RD_ADR The support for these is limited to a DPMI flavor of the UDS II and is intended, as of this writing, for serial control of a Broadcast Tools Switcher/Router. Because control of a Broadcast Tools Switcher/Router is currently the sole purpose of this RS-232 serial communications link, the baud rate is fixed at 2400 BPS. The "3RD" in the name of the ENV is intended to clearly convey that it is for the parameters of the UDS II's notion of a third instance of serial port, not necessarily COM3 nor even the third use of serial port from the end user's standpoint. * The name "3RD" was chosen since it is generic, thus extensible for possible uses of a serial port for communications of devices other than the immediate needs of controlling the Broadcast Tools Switcher/Router. - For instance, in an RS-HD only setting, the first serial port (COM1) may be used to control the Broadcast Tools Switcher/Router and the second serial port (COM2) may be used to comunicate with the RS-HD. In such a scenario, the settings, for example, would be as follows: UDS2_RS232_IRQ=3 (COM2 -> RS-HD) UDS2_RS232_ADR=$2F8 UDS2_RS232_3RD_IRQ=4 (COM1 -> BT Switcher/Router) UDS2_RS232_3RD_ADR=$3F8 NOTE: There are no default values defined for either the IRQ or the port address. The user must explicitly set both of these values in order for the third instance of an RS-232 serial communications link to become active. Furthermore, it is the user's reponsbility to ensure that the selection of an IRQ and address does not conflict with any other device, such as another serial port or a network adapter. 16 October 2000 --------------- ============================================================== In order to take advantage of this enhancment, the user must be operating a system with UDS II version 2.30i (or greater) along with RS-HD version 00.12f (or greater). ============================================================== The maximum allowed value of UDS2_HD_BAUD is now 115200 as of version 2.30i of the UDS II. This is applicable only for an RS-HD RS-232 serial connection to RS-HD version 00.12f or greater. The default speed remains at 38400 unless overridden by setting this ENV. Also see the notes dated 9 October 2000 in this document. 9 October 2000 -------------- ============================================================== In order to take advantage of this enhancment, the user must be operating a system with UDS II version 2.30g (or greater) along with RS-HD version 00.11t (or greater). ============================================================== The maximum allowed value of UDS2_HD_BAUD is now 57600 as of version 2.30g of the UDS II. This is applicable only for an RS-HD RS-232 serial connection to RS-HD version 00.11t or greater. The default speed remains at 38400 unless overridden by setting this ENV. 26 September 2000 ----------------- Support for a newly-added environmental variable is present in yet-to-be-released UDS II version 2.29l. This requires that an RS-HD unit be in use as a digital audio server, which implies that this ENV is supported only by DPMI flavors of the software. The basic syntax is as follows: RSHD_TIME_SYNC= - or - RSHD_TIME_SYNC=FALSE|NO|OFF The user can tune this ENV to govern how the UDS II will attempt to synchronize its notion of the current time of day relative to the RS-HD/Linux box. Refer to section II below for additional details on this and other RS-HD-related environmental variables. 7 August 2000 ------------- Support for an environmental variable, "UDS2_EAS_SOURCE", is now available as of version 2.28e of the UDS II. This ENV uses a pair of values to determine the EAS source and the contact closure pin to insert the EAS source. Refer to the notes in section VI of this document for more details regarding the syntax of this environmental variable. 19 June 2000 ------------ This document was spell-checked today. In addition, its syntax was also scanned and the content validated for correctness. 9 June 2000 ----------- As of version 2.26a of the UDS II, the following two environmental variables are supported: UDS2_RS232_2ND_IRQ UDS2_RS232_2ND_ADR The support for these is limited to a DPMI flavor of the UDS II with dual digital audio support of both a DCS and RS-HD. The "2ND" in the name of the ENV is intended to clearly convey that it is for the parameters of the second serial port. Given a UDS II dual digital audio system, with both DCS and RS-HD: - The primary serial port is reserved for RS-HD. By default, it operates, at a speed of 38400 BPS on COM1 (IRQ4 0x3F8). Because of its speed, a 16550AFN buffered UART is required. These two ENVs can be tuned to select another port: UDS2_RS232_IRQ and UDS2_RS232_ADR. Refer to the notes in Section IV, below pertaining to "hardware-related ENVs" for more details on what values are permitted. The baud rate is configurable by adjusting the value of UDS2_HD_BAUD. - Given a "Dual DigAudio" configuration, the second serial port is reserved for DCS. By default, it is mapped to COM2 (IRQ3 2F8) at a speed of 2400 BPS. Although a buffered UART is very highly recommended, it is not an absolute necessity given the slower speed and lower volume of traffic between the DCS and UDS II. Finding anything other than a 16650AFN in the current era will be difficult, fortunately. The parameters on the second serial port can be changed as explained in Section IV, below. Note that the baud rate is fixed at 2400 and cannot be changed. Since the only purpose for the second serial port is for DCS communications, there's no need to change the speed to anything other than 2400. * In most cases, though, the defaults will be precisely what is desired. 20 March 2000 ------------- The following boolean environmental variable is available only with DPMI-enabled UDS II systems, version 2.24c or greater: UDS2_TIME_COMP_LOG Setting this causes the UDS II to log verbose diagnostic information to the DIALOG file when a time compare segue occurs. Refer to Section VI below for more information on this and a variety of other environmental variables. 15 March 2000 ------------- This document was updated to explicitly state that the voice track feature is also available with the RS-HD as well as the DCS. In addition, corrections were made in the description to clarify that the "ramp up" of audio occurs when the EOF (not to be confused with the EOM or "AUX mark") is detected. 13 March 2000 ------------- The following boolean environmental variable is available only with UDS II systems, version 2.23m or greater, equipped with RS-HD version 00.05t or greater: RSHD_CUT_INFO Setting this causes the UDS II to "reveal" the cut numbers for RS-HD sourced non-music carts. Refer to section II below for additional details on this and other RS-HD-related environmental variables. 18 February 2000 ---------------- 1). As of version 2.22w of the UDS II, the following new environmental variables are optionally available (only in the DPMI flavor of the software). Setting any of these instantiates the special enhanced EOM handling feature of UDS II. UDS2_PIN2_EOM UDS2_PIN3_EOM UDS2_PIN4_EOM UDS2_PIN5_EOM Refer to the description in Section VI below for more details. 2). As of version 2.22v of the UDS II, a new environmental variable, HD_CATASTROPHIC_REF, determines whether failure to load ("queue") a cart will increment the "catastrophic" failure counter. Read more about this (and other hard drive related) variables in section II, below. 28 December 1999 ---------------- Starting with version 00.02d of the UDS II (equipped with RS-HD, which implies a DPMI flavor), there's support for the following boolean environmental variable: RSHD_IGNORE_STOP_SIGNAL Setting this causes the UDS II to ignore a termination signal from RS-HD and not enter emergency stop mode. Refer to section II below for this and other RS-HD as well as DCS-related environmental variables. 13 December 1999 ---------------- As of version 2.21k or greater (in the DPMI flavor of UDS II), there's support for a new environmental variable: UDS2_TIME_UPDATE_OLD_SKDS Setting this will allow time update commands to work on expired schedules, that is schedules whose dates do not match the current calendar date. Refer to Section VI below for more information on this and a variety of other environmental variables. 4 November 1999 --------------- As of version 2.20x of the UDS II (DPMI only), there's support for a new environmental variable: UDS2_ALT_GREY_PLUS. Setting this will enable the Alt-Grey-Plus key to perform a PrtScr-style segue. Refer to Section VI below for more information on this and a variety of other environmental variables. 22 July 1999 ------------ Note that all applicable DCS-related environmental variables have an equivalent name for On Air's "Radio Suite Hard Drive". Substitute "DCS" with "RSHD" in the text string. 14 May 1999 ----------- As of version 2.18gà of the UDS II, there's support for a new environmental variable: HD_CATASTROPHIC_FAIL. It performs a role similar to CDK3600_LOAD_FAIL in that it keeps track of failures involving either the DCS or RS-HD digital audio playback units. The intent is to avoid removing an excessive number of events in the schedule due to a consecutive sequence of "catastrophic" errors involving the hard drive system. Read more about this variable in section II, below. 5 May 1999 ---------- As of version 2.18cà, which is still currently an internal release version, the following DCS-specific boolean environmental variable is supported: DCS_AUX_MARK_TIME It addresses a situation involving runtime resolution from the DCS, allowing the AUX mark time to prevail for screen display upon playback. Refer to section II below for this and other DCS-related environmental variables. 18 March 1999 ------------- As of version 2.16yà, which is currently an internal release version, the following DCS-specific boolean environmental variable is supported: DCS_0_DURATION_FAIL It addresses a very specific condition involving "date challenge" with rotating carts. Refer to section II below for this and other DCS-related environmental variables. 4 December 1998 --------------- - As of version 2.14e, an internal release version, as of this writing, a new value may be used for UDS2_RBDS: ASCII - If using UDS2_RBDS=ASCII, an additional environmental variable can optionally be set, UDS2_RBDS_MIN_LENGTH. Refer to section III. below for additional details on these and other RBDS-related environmental variables. 26 October 1998 --------------- As of version 2.12z, if using an RBDS-capable version of the UDS II equipped with a Flash Comm RBDS device and a DCS unit for digital audio, the cart identifier assigned to UDS2_RBDS_TA_CART is now supported via the "hotkey" window. Refer to section III, below for more details on RBDS-related environmental variables. 22 September 1998 ----------------- As of UDS II version 2.12a, UDS2_DENON_VERBOSE is no longer a boolean (on or off) value. Instead, it sets a "verbosity" level to determine what will be written to a diagnostic file. Refer to section V below where details CD player-related environmental variables are fully explained. 18 September 1998 ----------------- - Revised the allowable range of UDS2_DENON_WAIT_BEFORE_LOAD from 0 to 500 ticks to 180 to 500 ticks. - As of UDS II version 2.11s, a new Denon-related environmental was introduced: UDS2_DENON_LOAD_FAIL_RESET. Refer to section V below where details of these and other CD player-related environmental variables are explained. 2 September 1998 ---------------- As of UDS II version 2.10x, the user may now optionally specify a Denon-related environmental variable, UDS2_DENON_NO_D1_STOP. This determines how the UDS II will handle a stop command. This ENV, specific to a protected mode UDS II equipped with Denon 1400 support, is explained fully in section V below where details of this and other CD player-related environmental variables are found. - NOTE: UDS2_DENON_NO_D1_STOP is available for diagnostic purposes only. This should NEVER be set by the user unless instructed by On Air USA. 28 August 1998 -------------- As of version 2.10u of the UDS II software, the user may govern the "wait time" between the occurrence of a segue to when a DCS "queue cart" command is issued. Details on the newly introduced environmental variable DCS_QUEUE_WAIT are found in section II below where this and other DCS-related environmental variables are explained. 14 August 1998 -------------- As of version 2.09v of the UDS II software, the environmental variable UDS2_DENON_NO_D1_RELOAD was added. This determine what action UDS II will take during an unexpected response during a Denon 1400 load process. This ENV, specific to a protected mode UDS II equipped with Denon 1400 support, is explained more fully in section V below where details of all CD player-related environmental variables are found. 13 August 1998 -------------- As of version 2.09t of the UDS II software, support for a new environmental variable was added: UDS2_UPDATE_90_FLIP will determine how the UDS II (operating in a UDS-HD context) will handle a situation wherein the target of a Time Update 90 is a DCS source conflicting with the source number of the airing backfill cart. See section II below for a details on this and other DCS-related environmental variables. 11 August 1998 -------------- Note that the purpose of environmental variables is to modify the behavior of the UDS II for special needs. The default actions of the UDS II will generally "do the right thing". In particular, there's no need for explicitly setting any DCS-related ENVs for using either: Time Update 90 UDS-HD This is not to imply that the user is prohibited from tuning the operation of the system via environmental variables -- only that, in the majority of the cases, there's no need to do so. 14 July 1998 ------------ A new environmental variable was introduced with the advent of UDS II version 2.08p (DPMI version only). Read more about UDS2_NO_VOICETRACK_REMOVAL in Section VI below. 10 July 1998 ------------ Two new environmental variables are present in the UDS II with a version of 2.08j (or greater). Both of these environmental variables deal with the new "Auto-Route" feature: UDS2_AUTO_ROUTE UDS2_AUTO_ROUTE_FADE Refer to the notes in Section VI below for the complete details on each of these new ENVs. 6 July 1998 ----------- - As of version 2.07x of the UDS II software (DPMI only with an equipment file specifying a UDS-HD configuration), the user may optionally set UDS2_DCS_PRIMARY_SOURCE to specify the source that will be used for hotkeys and other non-music items from the DCS unit. Refer to section II (below) for more details on this and other ENVs relating to the DCS. - As of version 2.07v of the UDS II software (DPMI or otherwise), the system behaves as though the value for UDS2_TRACK_CHANGE_TIME were set to 3. This decreases the possibility of a premature segue caused by the errant receipt of a track change indicator. Note that the user may now explicitly set this value to 0 to cause the UDS II to behave as it did prior to the change made in version 2.07v. 26 June 1998 ------------ As of version 2.07f of the UDS II (DPMI or otherwise), the user may optionally set the following boolean environmental variable: UDS2_NO_ALARM. This ENV, explained more fully in Section VI below, disables the audio mixer alarm for conditions other than silence sense. 25 June 1998 ------------ The relationship between DCS_STREAMS and DCS_NEW_VERSION merits disambiguation. The only DCS unit capable of three "playback resources" (or "streams", to use the Computer Concepts term) is one that is hosted on a 486 platform. The 286-based DCS units have only two such playback resources. Setting DCS_STREAMS=3 tells the UDS II that there are three playback "streams" available from the DCS. Because this number of streams is available only on a 486-based DCS, it _ALSO_ performs the side-effect of causing the UDS II to behave *as if* DCS_NEW_VERSION=1 was set. Of course, it doesn't actually go out to the environment and set this value...because it happens internally within the UDS II. It's a matter of applying some boolean logic: - All DCS units with three streams set are 486-based units. - Not all 486-based DCS units, though, need to have three streams set (from the standpoint of the UDS II). This begs the question of what exactly these two environmental variables do. Here's a brief summary (with more details found in the UDS2_ENV.TXT sections dealing with each ENV): 1). DCS_NEW_VERSION: In a nutshell, when a halt command is sent to the DCS, a response is expected back from the DCS confirming that the cart was, in fact, halted. However, the 286-based DCS units do NOT respond with such a "halt confirmation". As a result, the UDS II must make a presumption that the cart was halted. The 486-based DCS does confirm that a halt was successful. So, the UDS II behaves differently after a halt when the user asserts that a 486-based DCS is in use via DCS_NEW_VERSION. It doesn't have to perform some software "kludges" based on a lack of data coming back from the DCS. - Note that as of version 2.09k of the UDS II software, the _equivalent_ of setting DCS_NEW_VERSION=1 automatically occurs if the equipment file shows UDS-HD sources. This is because a UDS-HD requires a 486-based platform. 2). DCS_STREAMS: Briefly, the UDS II presumes that a maximum of two playback resources are available from a DCS unit. Prior to airing a cart, the UDS II does a check of an internal array to determine if a playback resource is available. By default, this array is based on the assumption that two carts airing at the same time means that the DCS is busy. If the user asserts that DCS_STREAMS=3, then the UDS II will only act as if the DCS is busy when it determines that there are three carts airing at the same time. - Note that as of version 2.09k of the UDS II software, the _equivalent_ of setting DCS_STREAMS=3 automatically occurs if the equipment file shows UDS-HD sources. This is because a UDS-HD requires that there be three playback resources available from the DCS unit. 9 June 1998 ----------- As of version 2.05u of the UDS II, with support for the Denon 1400 (this implies DPMI), the user may optionally "tune" the environmental variable: UDS2_DENON_D1_COUNT. This ENV is explained more fully in section V below where details of this and other CD player-related environmental variables are found. 4 June 1998 ----------- References throughout this document referring to "Denon 1400F" or "DN1400F" were modified to show "Denon 1400". 29 May 1998 ----------- As of version 2.04x of the UDS II -- all "flavors", DPMI or otherwise -- the user may optionally set UDS2_AUDIO_MIXERS to a value of between 1 and 7. This allows "virtual sources" to be used (without being under the control of an A4000 audio mixer). Refer to the notes in Section VI of this file to learn more about this feature and why it might be helpful. 22 May 1998 ----------- As of version 2.04t of the UDS II (DPMI version only), the user may optionally set UDS2_AUTO_UPDATE to cause a periodic automatic recalculation of "scheduled at" start times. Refer to the notes in Section VI of this file to learn more about this enhancement. 13 May 1998 ----------- As of version 2.04l of the UDS II (all versions), the user may now optionally set an environmental variable to determine at what point in time a "CD track change detection" is considered to be valid. This ENV (UDS2_TRACK_CHANGE_TIME) is explained more fully in section V below where details of this and other CD player-related environmental variables are found. 20 April 1998 ------------- a). As of version 2.02u of the UDS II (presuming a DPMI version, which is capable of handling Time Update 90), there is no longer a need to set the two DCS-related environmental variables (explained in the 9 April 1998 notes). When processing "Time Update 90", the segue code 008 emitted by the update itself (after a backfill substitution has been successfully performed) will lead to a fade and/or a halt. The notes of 9 April 1998 have been left in place for archival purposes only. Note that there are still reasons why either (or both) of the environmental variables (DCS_HALT_PRIOR and DCS_83_FADE) may still be set by the user. However, the setting (or lack thereof) of either (or both) no longer has any bearing on the behavior of "Time Update 90" (after a backfill substitution has been performed). b). The environmental variable DCS_HALT_PRIOR was modified as of UDS II version 2.02v. This change is not limited to the DPMI release, impacting all UDS II versions supporting a DCS unit. Please refer to the revised detailed explanation in Section VI later in this document. In a nutshell, the value of DCS_HALT_PRIOR can be thought in terms of a DIP switch model, with positions 0, 1 and 2 as follows: 0: Halt prior DCS cart on receipt of segue code 001 or 007. 1: Halt prior DCS cart on receipt of any segue code _other_ than 001, 007 or 008. 2: Halt prior DCS cart on receipt of segue code 008. In reality, there's not a DIP switch -- but a binary "bit vector" that gets set via the environmental variable. - For instance, if a user wants a halt command to be sent to a prior airing DCS event on segue codes 001, 007 or 008, bit 0 (with a value of 1) and bit 2 (with a value of 4) would be "turned on". The total value would then be 5. - Presuming the user wants to only halt a previously playing cart (DCS or RS-HD) when either time update 81 or 90 occurs, the setting of the value would be 4. This causes a halt to be sent upon receipt of segue code 008 (trigged by either update 81 or 90). If the airing event is an MOHD event, a smooth fade occurs prior to the halt, otherwise the cart is halted upon the start of the next event. - As another example, if a user wishes a halt command to be sent to the prior airing DCS cart on all segue codes except 001 and 007, bit 1 (with a value of 2) and bit 2 (with a value of 4) would be "turned on". The total value would then be 6. 16 April 1998 ------------- - As of UDS II version 2.02q, a DPMI instance of the software with the capability of the "enhanced voice track" feature now behaves as though UDS2_VOICETRACK_FADE were set to -0.1. This default behavior causes a rapid "fade up" of the music playing under a DCS voice track cart upon detection of the EOF from the DCS unit. If this default behavior is not desired, the environmental variable can be set to another value as described in Section VI below. 15 April 1998 ------------- - As of UDS II version 2.02p, a DPMI instance of the software, which has the "enhanced voice track" feature available now extends the functionality of the UDS2_VOICETRACK_FADE ENV. Unlike, the real mode versions of the UDS II, the DPMI version allows both negative and fractional (non-integral) values for this environmental variable. Refer to the notes in Section VI of this file to learn more about the enhanced functionality now afforded with UDS2_VOICETRACK_FADE. 9 April 1998 ------------ - As of UDS II version 2.02g, a DPMI instance of the software with a DCS unit as part of the equipment provides support for "Time Update 90". This permits a list of backfill carts to be allocated by the user. Upon encountering a time update with source 90, the UDS II is capable of substituting an event within a "backfill window" to a DCS cart of an appropriate length. In order for this function to work properly, here are two already existing environmental variables that must be set as follows: "DCS_HALT_PRIOR=3" -or- "DCS_HALT_PRIOR=13" "DCS_83_FADE=1" Note that although DCS_83_FADE contains the string "83", it also applies to time update source 90. (In most respects, time update 90 mimics the behavior of time update 83, with the notable exception of providing backfill capability). For more information on the operation of "Time Update 90", refer to UDS II printed documentation or the "README" file supplied with the distribution software. 31 March 1998 ------------- - As of UDS II version 2.01u, support for the UDS2_DENON_TC_STUCK environmental variable was added. Setting this to a legal value governs how the UDS II will respond to "repeated" time code from a Denon 1400 CD player. This ENV is explained more fully in section V below where details of this and other CD player-related environmental variables are found. 20 March 1998 ------------- - As of UDS II version 2.01i, support for the UDS2_DENON_WAIT_BEFORE_LOAD environmental variable was introduced. Setting this to a valid value determines the wait time between the receipt of a stop acknowledgment from a Denon 1400 CD player and the initiation of a load sequence. This ENV is explained more fully in section V below where details of this and other CD player-related environmental variables are found. 2 March 1998 ------------ - As of UDS II version 1.99k, UDS2_NO_MUSIC_CLOSURE was introduced as a new environmental variable. Setting this causes the UDS II to ignore "contact closures" (external print screen) when non-contact closures events are airing. This ENV is explained more fully in section VI below where *all other* environmental variables are explained in detail. 25 February 1998 ---------------- - As of UDS II version 1.99g, UDS2_DENON_VERBOSE was introduced as a new environmental variable. Setting this causes the UDS II to write diagnostic logging information to the DENON.DRB file in the current working directory. See section V below for details on this and other CD player-related environmental variables. 2 February 1998 --------------- - As of UDS II version 1.96w, UDS2_TRACK_ZERO was introduced as a new environmental variable. Setting this allows the UDS II to accept a music database entry with a track of 0. This ENV (and the reason for its introduction) is explained more fully in section VI below where *all other* environmental variables are explained in detail. 15 January 1998 --------------- - As of UDS II version 1.95h, UDS2_STUDIO_OFF_AT_SEGUE was introduced as a new environmental variable. Setting this causes the UDS II to fade the live studio source when a segue occurs. This ENV is explained more fully in section VI below where *all other* environmental variables are explained in detail. - As of UDS II version 1.95g, a new environmental variable was added so that the user can set a threshold value to allow the line printer to begin printing. This ENV is explained more fully in section VI below where *all other* environmental variables are explained in detail. This new variable is UDS2_PRINTER_DELAY. 13 January 1998 --------------- As of UDS II version 1.95a, a new environmental variable, UDS2_LOAD_PROTECT, has been introduced to "fine tune" the error handling of UDS II when a CD player is unable to load a disc. Refer to Section V for the details included in the summary of all ENVs relating to CD players. 9 January 1998 -------------- As of UDS II version 1.94s, a new environmental variable has been introduced to work in conjunction with UDS2_UPDATE_81. This new variable is UDS2_UPDATE_MUSIC. Read the detailed explanation in Section VI (following the explanation of UDS2_UPDATE_81). 2 December 1997 --------------- As of UDS II version 1.92sà, a new environmental variable has been added: UDS2_NO_RELOAD_WARN. This suppresses the normal F4 editor warning message: "Insufficient time to reload, proceed anyway?" This ENV is explained more fully in section VI below where *all other* environmental variables are explained in detail. 26 November 1997 ---------------- As of UDS II version 1.92oà, a new environmental variable has been added: UDS2_NAK_TIMEOUT. This determines how the UDS II will handle a condition involving a series of NAK responses while a Sony CDK-006, NSM3101AC or Denon 1400 CD player is airing a compact disc event. See section V below for details on this and other CD player-related environmental variables. 14 November 1997 ---------------- Added information about the Ctrl-F9 key to select a playback channel on the DCS unit. 12 November 1997 ---------------- As of UDS II version 1.91n, a new environmental variable has been added: UDS2_NO_IMPORT_WARN. This determines how the UDS II will react at import time if a schedule is to be loaded with an ending event prior to the 11:00 PM (or 23:00) hour. Refer to the more detailed notes in section VI below where *all other* environmental variables are explained. 2 October 1997 -------------- As of UDS II version 1.89t, a new environmental variable has been added: DCS_PLAYOUTDATE. This determines how the UDS II will handle a cart reported as "outdated" by the DCS. See section II below for details on this and other DCS-related environmental variables. 24 September 1997 ----------------- As of UDS II version 1.89e, a new environmental variable has been added: DCS_83_FADE. This determines how the UDS II will handle DCS audio in the event of a time update 83 occurring when a DCS channel is airing. See section II below for details on this and other DCS-related environmental variables. 18 September 1997 ----------------- As of UDS II version 1.88z, a new environmental variable has been added: DCS_SS_FADE. This determines how the UDS II will handle DCS audio in the event of a silence sense. See section II below for more details on this and other DCS-related environmental variables. 16 September 1997 ----------------- Two new environmental variables were introduced with UDS II v1.88w: UDS2_RS422_XMIT_TIME UDS2_RS422_RCV_TIME Both of these permit the user to "tweak" timeout values associated with RS422 communications. Refer to section IV (hardware-related ENVs) for more details on these items. 4 September 1997 ---------------- If DCS_CHANNEL is set to -1, the F6 information display for the "Channel" field now properly shows "-1". See the notes below for additional details. 28 August 1997 -------------- The DCS platform and version are logged to the DIALOG file as part of the DCS operating parameters as of UDS II version 1.87w. - If DCS_STREAMS is set to 3 or DCS_NEW_VERSION is defined, then the following message is logged: "DCS platform: 486/version 2.5 or later" - Otherwise, the following message is logged: "DCS platform: 286/version 2.35 or earlier" 27 August 1997 -------------- The newly introduced ENV, DCS_NEW_VERSION was added to the list of environmental variables supported by the UDS II as of version 1.87u. 26 August 1997 -------------- The newly introduced ENV, DCS_NO_HALT_HOTKEY was added to the list of environmental variables supported by the UDS II as of version 1.87t. 25 August 1997 -------------- The newly introduced ENV, DCS_STREAMS was added to the list of environmental variables supported by the UDS II as of version 1.87s. 22 August 1997 -------------- The ENV, DCS_HALT_PRIOR was expanded to accept values of 11, 12 and 13 as well as 1, 2 and 3. 21 August 1997 -------------- The newly introduced ENV, DCS_STOP_EXIT was added to the list of environmental variables supported by the UDS II as of version 1.87p. 19 August 1997 -------------- The newly introduced ENV, DCS_HALT_PRIOR was added to the list of environmental variables supported by the UDS II as of version 1.87l. 21 July 1997 ------------ The newly introduced ENV, DCS_CHANNEL was added to the list of environmental variables supported by the UDS II as of version 1.86d. 14 May 1997 ----------- The newly introduced ENV, UDS2_UPDATE_81 was added to the list of environmental variables supported by the UDS II as of version 1.85h. 12 May 1997 ----------- The newly introduced ENV, UDS2_DBASE_VERBOSE was added to the list of environmental variables supported by the UDS II as of production release DPMI version 1.85g. 9 May 1997 ---------- The newly introduced ENV, UDS2_NO_FAIL_SAFE was added to the list of environmental variables supported by the UDS II as of production release version 1.85e. 16 April 1997 ------------- The newly introduced ENV, UDS2_NO_F3_SEGUE_REFRESH was added to the list of environmental variables supported by the UDS II as of version 1.84sá. 26 March 1997 ------------- The new ENV, CDK3600_VERBOSE was added to the list of environmental variables supported by the UDS II as of version 1.83zá. 21 March 1997 ------------- This file was reorganized today. There's now an entire section dedicated to environmental variables associated with the Sony CDK-3600 player. Note also that the maximum allowable value for CDK3600_TRACK_RETRY is now 25 (it was 15). 20 March 1997 ------------- The new ENV, CDK3600_TRACK_RETRY was added to the list of environmental variables supported by the UDS II as of version 1.83pá. 12 March 1997 ------------- The new ENV, CDK3600_TC_RETRY was added to the list of environmental variables supported by the UDS II as of version 1.82wá. 28 February 1997 ---------------- - Spell checking and reformatting completed as well as a thorough review for informational accuracy. - The name of the file was changed from UDS2_ENV.!!! to UDS2_ENV.TXT. 5 February 1997 --------------- The newly introduced ENV, UDS2_PREVIEW_RESPONSE was added to this list of environmental variables supported by the UDS II as of version 1.80zá. Note that this ENV is entirely different from both DCS_EXIT_PREVIEW and DCS_HALT_PREVIEW. Unlike the former, it does not depend upon the setting of any other ENV to take effect. 29 January 1997 --------------- The new ENV, DCS_EXIT_PREVIEW was added to the list of environmental variables supported by the UDS II as of version 1.80vá. Note that this ENV is different from DCS_HALT_PREVIEW but is dependent upon the latter ENV being set. 26 November 1996 ---------------- The new ENV, DCS_HALT_PREVIEW was added to the list of environmental variables supported by the UDS II as of version 1.78bà. 1 November 1996 --------------- The new ENV, UDS2_VOICETRACK_FADE was added to the list of environmental variables supported by the UDS II as of version 1.76ià. 11 July 1996 ------------ The new ENV, UDS2_ROOT was added to the list of environmental variables supported by the UDS II as of version 1.72fà. 26 June 1996 ------------ The new ENV, CDK3600_LOAD_FAIL, was added to the list of environmental variables supported by the UDS II as of version 1.71là. 20 May 1996 ----------- NOTE: In this text, "ENV" is commonly used as an abbreviation for the full expression of "environmental variable". The charts below are organized so that ENV Name is the variable to set in the user's environment. The environment is set using the command SET = where is one of the strings shown in the charts below, is one of the numbers or strings shown in the charts below. An explanation of the role of each is included in the chart, prepended with a '-' and indented one tab stop in the first line following the . - Both ENV_NAME and VALUE are case insensitive for the purposes employed by the UDS II. By convention, upper-case is generally used in the MS-DOS environment for setting of ENVs. - There must be NO space in the string. - There must be NO space on either side of the '=' assignment operator. - A BOOLEAN type simply indicates whether the ENV is set or not. By convention, a VALUE of 1 is typically used to set a BOOLEAN. Note that setting a BOOLEAN ENV to a value of "0" does NOT unset the ENV...it simply sets it to the value of "0". Under a stock version of MS-DOS' COMMAND.COM, the *only* portable way to unset an ENV is to use the following: SET = Setting an to the empty string (without any trailing whitespace after the '=' assignment operator) will remove the from the environment. ==================================================================== I. Here is a summary of ALL current AV100-related ENV user-configurable parameters: ------------------------------------------------------------ ENV NAME VALUE Default Units ------------------------------------------------------------ AV_RS422_TIMER 7-60 37 Ticks - Number of ticks elapsed, while awaiting a character, before RS422 routines error out. AV_LOAD 0.5-12.0 1.5 Seconds - Amount of time that elapses between the start of a cart and the load command issued for the next. AV_LOAD_VERIFY 0.5-12.0 1.5 Seconds - Amount of time that elapses between the load request and the first polling attempt to determine if the load was successful. AV_LOAD_FAIL 1-35 10 Iterations - Number of attempts that the UDS II will continue to poll the AV100 (when a load error is returned) until finally deciding that the cart can't be loaded and then fail it. AV_PLAY_FAIL 1-35 10 Iterations - A counter is incremented each 1/10 of a second if a failure is noted while checking the running status of the cart. If this counter is exceeded, the cart fails with segue code 10 (Digital Audio playback failure). AV_QUERY 1-10 3 Iterations - Number of iterations the UDS2 must attempt an AV100 "general hardware query" before presuming that AV100 is, in fact, dead. AV_PLAYOUTDATE BOOLEAN UNSET - Forces UDS2 to accept an outdated cart as suitable for loading. AV_FORCE_PINGPONG BOOLEAN UNSET - A deprecated ENV, support for which, may be withdrawn in future versions. At present, it forces each instance of an AV100 deck search routine to alternate from the deck most recently loaded. (Much of its functionality is now built into the code). AV_CLEAR_DECK BOOLEAN UNSET - Upon receipt of an EOF from a deck where a load is attempted while a cart is still playing, an explicit stop command is sent by the UDS II to the AV100. This allows the deck to be loaded without failure when running, for instance, a long traffic bed into a spotset -- requiring that the deck playing the long traffic bed be loaded while the first spot is playing. AV_CONFIRM_EOF BOOLEAN UNSET - Forces the UDS2 to first checks to ensure than an EOF was received on a deck before attempting to issue a load request to that deck. (This ENV does not behave well with firmware version 1.05). AV_LOAD_E6 BOOLEAN UNSET - After a load command is transmitted to the AV100 and if an E6 is returned by the AV100, a reload of that cart occurs rather than a continued re-polling of the AV100. It is presumed that an E6 error is errant in this context -- since it is not one of the errors associated with a load failure. This approach has the blessing of Broadcast Electronics. AV_WAIT_AX BOOLEAN UNSET - Polling continues on the AV100 deck even after EOF is received until an "A" (deck available) response is received. (This ENV does not behave well with firmware version 1.05). AV100_DEBUG BOOLEAN UNSET - Forces an EXTREMELY verbose diagnostic dribble file (AV_BUG.DRB) to be written to the CWD. WARNING: this dribble file can easily consume a typical Z-4000 computer's hard drive space in a matter of 2 days of dribbling. It should only be enabled per the instructions of On Air USA and the file should be unlinked as soon as possible. > NOTE: As of v1.80cà, the creation of dribble files is supported *only* with the protected (DPMI) version of the software. In all other versions, this environmental variable does nothing. ==================================================================== II. Here is a summary of ALL current digital audio-related ENV user-configurable parameters: ------------------------------------------------------------ ENV NAME VALUE Default Units ------------------------------------------------------------ DCS_DEBUG BOOLEAN UNSET - Enables a diagnostic dribble file (DCS_BUG.DRB) to be written to the CWD, showing the state of all DCS-related variables when each message is transmitted and received from the DCS via the RS-232 port. This produces a reasonably large file but it is not nearly as huge as the AV_BUG.DRB diagnostic dribble file. > NOTE: As of v1.80cà, the creation of dribble files is supported *only* with the protected (DPMI) version of the software. In all other versions, this environmental variable does nothing. If this variable is set and the DPMI version is in use, the following message gets logged upon program invocation in the DIALOG file: "DCS diagnostic file: ON" If unset and the DPMI version is in use, the message shows: "DCS diagnostic file: OFF" DCS_NO_HALT_CART BOOLEAN UNSET - Not to be confused with DCS_NO_HALT_EXTERN. The normal behavior is to permit the PrtScr key to be pressed even while all DCS channels are busy. By default, the least recently accessed DCS element is then halted -- and the current DCS element begins playing immediately. If DCS_NO_HALT_CART is set, then the least recently accessed DCS element continues to play and results in a "channel busy" situation. If properly set in the environment, the following message appears in the DIALOG file along with other DCS parameters: "UDS originated carts will be halted to avoid channel busy" DCS_NO_HALT_EXTERN BOOLEAN UNSET - The normal mode of operation (presuming a DCS with two playback channels) is to halt a non-UDS originated cart when the UDS II is playing a DCS element. This default behavior is designed to avoid a "channel busy" situation. If this ENV is set, the UDS II does not attempt to halt an externally playing cart, such as a cart being auditioned in a production environment. If set in the environment, this message gets written to the DIALOG file upon program invocation: "Non-UDS originated carts will NOT be halted on playback" DCS_HALT_PREVIEW 1-30 0 Seconds - Because there is some latency involved between halting a cart played from the hotkey window in preview mode and starting one for airing, the user may optionally set this value to halt such a previewed cart at a defined time *prior* to segue to a DCS event. If this ENV is set, the DIALOG file shows this value via the following message: "DCS previewed carts halted within seconds of segue" where is the setting of DCS_HALT_PREVIEW. At runtime -- if this value is set -- and a DCS cart is being previewed, when the currently airing event's backtime counter is less than the user-defined value (and a DCS event is next), the previewed element is halted and the following message appears on the UDS II's main screen and is written to the DIALOG file: "Halting preview cart: " DCS_EXIT_PREVIEW BOOLEAN UNSET - This variable _only_ becomes active if DCS_HALT_PREVIEW is set to a valid value, (see above). If DCS_EXIT_PREVIEW is set in the environment and the user is previewing a DCS cart and the threshold (as set by DCS_HALT_PREVIEW) of a pending scheduled DCS event is reached, the hotkey window is automatically closed. This is designed to avoid accidentally playing a hotkey on the air. (If preview mode is halted, per DCS_HALT_PREVIEW, the hotkey window reverts to non-preview mode. All subsequent keypresses then lead to a cart airing as a hotkey). If this variable is set, the following message gets logged upon program invocation in the DIALOG file (under the message for DCS_HALT_PREVIEW): "* DCS hotkey window closed if preview active at this time" NOTE: The phrase "at this time" refers to the threshold of "within seconds of segue" as described in the DCS_HALT_PREVIEW section. DCS_CHANNEL -1 to 1 0 Channel Number This may be set to any of the following three values: -1, 0 or 1. Setting DCS_CHANNEL to either 0 or 1 establishes the playback channel selected for all UDS-originated events on the DCS unit. Note that the default remains channel 0, which appears as the top channel line on the DCS unit. (If this environmental variable is unset, the default of channel 0 will be selected for playback). The DCS playback channel is now also logged to both the DIALOG and UDS2BOOT.LOG as part of the "Computer Concepts DCS parameters" stanza, either: "Audio channel: 0" or "Audio channel: 1". If set to -1, the designated playback channel is considered to be "undefined". This means that the channel selected for active playback on the DCS unit will be used. (This may be useful for clients wishing to manually alternate between playback channels on the DCS unit). In the absence of a mouse or trackball connected to the DCS unit, one may select the output channel by pressing Ctrl-F9. Note that this keystroke is NOT supported in satellite mode -- but is available in source mode. This does lead to a bit of a problem, though, because only satellite mode provides a display indication of the current mode (via the smiley face in the upper left-corner of the DCS screen). If DCS_CHANNEL is set to -1, the following is logged to both the DIALOG and UDS2BOOT.LOG as part of the "Computer Concepts DCS parameters" stanza: "Audio channel: UNDEFINED". IMPORTANT: The equipment window (accessed via F6 or Alt-E) will show "-1" if the ENV DCS_CHANNEL is set to -1. This is normal. Since the setting of DCS_CHANNEL=-1 via the environmental variable takes precedence over the F6 setting, that "Channel" field may no longer be modified by the F6 equipment window. If an explicit channel setting is desired via F6, the DCS_CHANNEL environmental variable must be unset. DCS_HALT_PRIOR 1 through 9 UNSET 11 through 17 This optional environmental variable may be used to cause the UDS II to halt the play of a previously airing DCS cart when the "next to air" DCS event moves to "on the air" and begins to play. The normal behavior of the UDS II relative to DCS events is to allow each DCS event to play fully to conclusion "over" the next DCS event...thus permitting DCS events to overlap. This environmental variable may be "tuned" (by using a value of 1 through 7 or 11 through 17, inclusive) in accord with the specific needs of the user as follows: 1: Halts the prior DCS event *only* if the "next to air" DCS cart is started by explicit operator intervention, eg., press of the PrtScr key or press of an external push button. These correspond to segue codes 001 and 007. 2: Halts the prior DCS event *only* if the "next to air" DCS cart is started by something *other* than explicit operator intervention. Typically, a DCS to DCS segue occurs upon receipt of the "EOM/AUX" mark, which is segue code 012. Segue code 008 (from either time update 83 or 90) is excluded. 3: Halts the prior DCS event regardless of the type of segue that occurs so long as it is a segue code other than 008, which is emitted by either time update 83 or 90. 4: Halts the prior DCS event *only* if the "next to air" DCS cart is started by a time update 83 or 90 yielding a segue code of 008. 5: Halts the prior DCS event if the "next to air" DCS cart is started by explicit operator intervention, eg., press of the PrtScr key or press of an external push button. These correspond to segue codes 001 and 007. It also halts the prior DCS event if the "next to air" DCS cart is started by a time update 83 or 90 yielding a segue code of 008. 6: Halts the prior DCS event if the "next to air" DCS cart is started by something *other* than explicit operator intervention. Typically, a DCS to DCS segue occurs upon receipt of the "EOM/AUX" mark, which is segue code 012. It also halts the prior DCS event if the "next to air" DCS cart is started by a time update 83 or 90 yielding a segue code of 008. 7: Halts the prior DCS event if the "next to air" DCS cart for any and all segue codes. 8: RESERVED 9: Halts the prior DCS (or RS-HD) event regardless of what the next to air event is. This is an extention of setting 7 (as described above) in that, for any and all segue codes, the currently airing non-music cart is halted -- regardless of the type of "next to air" source. - Note that although the prior DCS cart isn't halted until the "next to air" cart has begun airing, there is still the potential for a "choppy" segue since there is no fading of the prior halted event. When a DCS event is halted, it simply stops the cart. - If set to a value of 11, 12, 13, 14, 15 or 16, the "halt" behavior is more aggressive: 11 corresponds to 1 (as explained above) 12 corresponds to 2 (as explained above) 13 corresponds to 3 (as explained above) 14 corresponds to 4 (as explained above) 15 corresponds to 5 (as explained above) 16 corresponds to 6 (as explained above) 17 corresponds to 7 (as explained above) The difference in all of these cases (11 through 17) is that the UDS II *FIRST* halts the prior scheduled cart if a "DCS channels busy" condition is detected *BEFORE* it plays the "next" DCS cart. - The setting of this optional environmental variable is logged to the DIALOG file as follows: "DCS_HALT_PRIOR set: " where is either 1 through 7 or 11 through 17. DCS_STOP_EXIT 1, 2 or 3 UNSET This optional environmental variable may be used to cause the UDS II to stop a playing DCS event when exiting the program or when changing to STOP mode. Normally the UDS II does not explicitly stop a DCS cart under either circumstance. This environmental variable may be "tuned" (by using a value of either 1, 2 or 3) in accord with the specific needs of the user as follows: 1: Stops a playing DCS cart *only* when successfully exiting the UDS II via the "Alt-X" keystroke. 2: Stops a playing DCS cart *only* if the mode was successfully changed to STOP via the "Alt-F2" keystroke. 3: Stops a playing DCS cart regardless of whether the program was exited via Alt-X or the mode was changed via Alt-F2. - The setting of this optional environmental variable is logged to the DIALOG file as follows: "DCS_STOP_EXIT set: " where is either 1, 2 or 3. DCS_STREAMS 2 or 3 2 This optional environmental variable may be used to set the number of available "DCS playback streams". DCS "control room" software (CMCR.EXE) versions in the 2.5 series running on the 486 platform use a dynamic "3 plus zero" method, which means that up to three playback "streams" are available (if one "stream" is not already occupied with recording). Setting this value to 3 enables the UDS II to permit the playback of up to three simultaneous DCS items at once, presuming that the a record line is not in use or that the DCS isn't already using a playback resource, such as playback of a cart through the audition channel. This value should NOT be set unless necessary and it should absolutely NOT be set for a DCS running on a 286 platform with a version of DCS software prior to 2.5. NOTE 1: Setting this value to 3 will automatically cause the equivalent of DCS_NEW_VERSION to be set. It doesn't mean that DCS_NEW_VERSION is mysteriously set in the environment. Instead, it means that the UDS II behaves *as if* DCS_NEW_VERSION were set. (See the notes below for more details regarding DCS_NEW_VERSION). NOTE 2: If DCS_NEW_VERSION is set, DCS_STREAMS still defaults to 2. Merely setting DCS_NEW_VERSION does not coerce the use of three streams. In fact, for users with a DCS 486-based platform, DCS_NEW_VERSION=1 is probably the preferred configuration. It essentially forces the UDS II to behave in the most conservative manner possible with regard to the DCS. DCS_NO_HALT_HOTKEY BOOLEAN UNSET - Not to be confused with DCS_NO_HALT_EXTERN or DCS_NO_HALT_CART, the normal behavior of the UDS II is to allow scheduled carts to always take precedence over hotkey carts. This means that if the UDS II determines the DCS is in an "all channel busy" situation when a cart is to be aired by schedule, it will halt a hotkey cart to free up a channel. Because it is so vital to permit scheduled carts to air, it is strongly recommended that this variable remain unset. DCS_NEW_VERSION BOOLEAN UNSET - If the user's DCS platform is a 486 or better and the DCS control room (CMCR.EXE) software is version 2.35 or greater, this ENV should be set. There is a significant difference in the behavior of DCS systems running on a 286 and those on a 486 or greater. In particular, a "halt cart" command does not result in an EOM/EOF message back from the DCS. As a result, the UDS II must perform a workaround to behave as if this EOM were received. Similarly, there are cases when the DCS properly responds with an EOM (AUX mark) response...but does not follow up with an expected EOF response. Again, the UDS II attempts to workaround this by fabricating a an EOF response. Because the DCS software designed for the 486 is much more reliable in these responses, it is STRONGLY recommended that the user set this variable to bypass the workarounds now in place to deal with the DCS software for the 286 platform. NOTE 1: Setting DCS_STREAMS to 3 will automatically cause the *equivalent* of DCS_NEW_VERSION to be set. It does not actually set that environmental variable -- but causes the UDS II to act as though it were set. (See the notes above for more details regarding DCS_STREAMS.) NOTE 2: If DCS_NEW_VERSION is set, DCS_STREAMS still defaults to 2. Merely setting DCS_NEW_VERSION does not coerce the use of three streams. In fact, for users with a DCS 486-based platform, DCS_NEW_VERSION=1 is the preferred configuration. It essentially forces the UDS II to behave in the most conservative manner possible with regard to the DCS. DCS_SS_FADE BOOLEAN UNSET - If set in the environment to a value of 1, the UDS II will fade and then turn off the DCS channel on the audio controller in the event of a silence sense leading to a segue of a non-DCS event. The normal behavior of the UDS II is not to fade the DCS channel until an EOM is received from the DCS, even in a silence-sense situation. If this variable is set, the following message is logged to the DIALOG file: "Channel will fade on silence sense" ...otherwise, the default message is: "Channel will not fade on silence sense" NOTE: The "DCS Fade Time" *MUST* be set to a non-zero value for this "fade out" behavior to occur! This may be set in the F6 equipment window corresponding to the DCS source number. DCS_83_FADE BOOLEAN UNSET - If set in the environment to a value of 1, the UDS II will fade and then turn off the DCS channel on the audio controller in the event of a time update 83 occurring which then leads into a segue of a non-DCS event. The normal behavior of the UDS II is not to fade the DCS channel until an EOM is received from the DCS, even in a silence-sense situation. If this variable is set, the following message is logged to the DIALOG file: "Channel will fade on time update 83" ...otherwise, the default message is: "Channel will not fade on time update 83" NOTE: The "DCS Fade Time" *MUST* be set to a non-zero value for this "fade out" behavior to occur! This may be set in the F6 equipment window corresponding to the DCS source number. DCS_PLAYOUTDATE BOOLEAN UNSET - Forces UDS2 to accept an outdated cart as suitable for loading and airing. In spite of turning off "date challenge", the DCS still reports to the UDS2 that carts are outdated, this ENV will force the cart to be queued and then be eligible for airing. If an "outdated" cart is encountered, the UDS2 displays this message on the screen and in the DIALOG file upon queuing the cart: "Cart outdated, will play anyway" Note that when such a reported "outdated" cart is queued, the runtime returned to the UDS2 by the DCS *may* be zero seconds. Thus, the display will show "0:00" for the duration of the cart. However, once the cart begins to play, the UDS2 again probes the DCS for the actual runtime. At the instance the cart starting play, the runtime is then readjusted to the proper value and displayed as such. If this value is set in the environment, the DIALOG file shows: "Outdated carts will play" The default message (without DCS_PLAYOUTDATE set) is: "Outdated carts will not play" UDS2_DCS_PRIMARY_SOURCE 1-30 Highest DCS channel By default, the "Primary Digital Audio Source" in a UDS-HD environment will default to the "highest" of the UDS-HD sources. Given the typical example of "07", "08" and "09", source 9 will be the one chosen for non-music elements, most notably hotkeys. However, should the user have a need to specify a source other than the "highest" as the "Primary Digital Audio Source", the environmental variable UDS2_DCS_PRIMARY_SOURCE may be set to a value ranging from 1 through 30, inclusive. In all cases with a UDS II equipped as a UDS-HD system, the following message is written to DIALOG and UDS2BOOT.LOG: "UDS-HD primary (and hotkey) DCS source: " UDS2_UPDATE_90_FLIP BOOLEAN UNSET - The user may optionally set this environmental variable to cause the UDS II (in a UDS-HD context only) to "flip" the DCS playback channel to a non-conflicting source number when Time Update 90 advances to the target of the update -- and that target item is a DCS source. Consider the following sequence: Src Event Status --- ----- ------ 09 BACKFILL CART On the air 90 TIME UPDATE @59:59 09 LEGAL ID Next to air As of UDS II version 2.09t, the "LEGAL ID" cart will play from channel 9 (which is defined, in this example, as the "Primary Digital Audio Source" from which non-music items (spots, hotkeys and backfill carts) will air. The result, when the segue occurs, is that "LEGAL ID" will start airing at 59:59 past the hour. Shortly thereafter (about 0.5 seconds), a halt command will be sent to the DCS to stop "BACKFILL CART". In most cases, this will be acceptable on the air since the "LEGAL ID" will "squash" the "BACKFILL CART" due to audio processing. However, there may be a desire to have the backfill cart do a fade in the event of a DCS to DCS transition. To make this happen, set the environmental variable UDS2_UPDATE_90_FLIP to 1. If thusly set, the DIALOG (and UDS2BOOT.LOG) will show the following in the startup stanza: "Time update 90 will flip conflicting DCS channels" At runtime, the above sequence of events will look like this: Src Event Status --- ----- ------ 09 BACKFILL CART On the air 90 TIME UPDATE @59:59 07 LEGAL ID Next to air Note that "LEGAL ID" was "flipped" to channel 07. Normally designated as a UDS-HD music channel, this is one occasion wherein a non-music element will play through that channel. The result on the air will be that "LEGAL ID" will air at 59:59 past the hour...and that "BACKFILL CART" will smoothly fade out (and thereafter be halted). The fade rate will be 1.5 seconds if the DCS channel's "Fade Time" is 0.0 (as set in the F6 equipment information window), or whatever the value of the user-defined "DCS Fade Time", up to a maximum of 3.5 seconds. DCS_QUEUE_WAIT 0.5-10 Seconds The user may now optionally set this environmental variable to govern an aspect of the UDS II's operation with the DCS. Setting DCS_QUEUE_WAIT to a floating-point value ranging from 0.5 to 10.0 determines how long the UDS II will wait (in seconds) to transmit a "queue cart" command to the DCS after a segue. The default value is 0.5 seconds. A "queue cart" command is performed by the UDS II to resolve the DCS item's title and duration and to pre-validate the cart's validity prior to play. - Note that a "queue cart" is not absolutely necessary to play a DCS cart. For instance, hotkeys are aired without first issuing such a queue. There are also situations where an extremely short DCS-to-DCS transition segue precludes such a queue. If a queue can't be done, the UDS II still attempts to play the cart anyway. There's a mechanism in place to handle the play of a non-existent cart. See the UDS II notes for version 2.08q for additional information. Each time a segue occurs, the UDS II evaluates the event in the "Next to air" position. If that event is a DCS item that hasn't already been "queued", the "queue cart" command is sent exactly 0.5 seconds after the segue (responsible for moving the DCS event into the "Next to Air" position) has occurred. However, there may be situations where such a rapid attempt to "queue a cart" after a segue isn't warranted. In that case, the user may govern the wait time by setting DCS_QUEUE_WAIT to values within the range enumerated above. NOTE: This user-defined wait time is applicable ONLY if a DCS event or Live Studio (on source 10) is not currently airing. The theory is that, for instance, a defined 3.5-second DCS_QUEUE_WAIT value is too long to allow a quick DCS-sourced legal ID (under 3.5 seconds) to permit a queue of the following DCS event to get queued. Also, there may be instances where the user pops in a quick live studio event between two DCS events and quickly advances through the live studio. In these cases, the default of 0.5 seconds is used. For all events other than a DCS or Live Studio, the value set via DCS_QUEUE_WAIT prevails. The "Computer Concepts DCS parameters" stanza of both DIALOG and UDS2BOOT.LOG show the current value of DCS_QUEUE_WAIT (regardless of whether the user explicit set it or not) as follows: "DCS Queue wait time: " where is a floating-point value between 0.5 and 10.0, inclusive. DCS_0_DURATION_FAIL BOOLEAN UNSET The user may now optionally set this environmental variable to govern an aspect of the UDS II's operation with the DCS in terms of handling a very narrow set of conditions involving date challenge with rotating carts. This has only been tested with with DCS version 2.6e. It's behavior with 286-based DCS units or other version is not currently known. Consider the following scenario, with the presumption that the current date is 18 March 1999. CART Date Range (Start/End) ------- --------------------------- 1202-01 1 March 1999-15 March 1999 1202-02 20 March 1999-31 March 1999 When the UDS II queries the DCS to determine if the cart is valid (during the QUEUE cart process), the DCS reports back "SQ001L00:00". The "001L" means that the cart exists and has no "date challenge" problem, in spite of the fact that there is no currently valid cart in the rotation. - The only hint that the UDS II has that something is amiss is the duration being reported as "00:00". Everything else is reported as OK by the DCS. In order to address the problem, if the user sets DCS_0_DURATION_FAIL to a value of 1, the cart will be rejected during the "queue cart" process with the following error message logged to the screen and to DIALOG: "Cart can't play, possibly outdated" * By the way, note that also setting DCS_PLAYOUTDATE to 1 results in the following message: "Cart possibly outdated, will play anyway" * This environmental variable is a UDS II workaround to addresses a flaw in the DCS (at least evident in version 2.6e). If both carts (in a rotating series) are expired, the DCS correctly reports back an "E01" so that the UDS II knows that the cart is outdated. Likewise, if both carts have only future dates, the DCS also reports an "E01" as part of the queue cart process. * Caution is advised in setting this environmental variable. Any cart will be rejected for play if the duration is reported as "00:00". This could encompass very short "shotgun jingles" or voice tracks. If this environmental variable is set, the following message is logged to both DIALOG and UDS2BOOT.LOG as part of the hard drive stanza: "0-second carts will be presumed outdated" Contrast this with the default message: "0-second carts will not be presumed outdated" DCS_AUX_MARK_TIME BOOLEAN UNSET As of version 2.18cà, the user may set this environmental variable to cause the AUX mark time to prevail when the UDS II attempts to resolve a cart's runtime. When the UDS II requests the duration of a cart from the DCS, during the QUEUE CART process, the DCS returns a runtime based on the AUX mark value. When that cart actually airs, the UDS II again gets a duration from the DCS as part of the response to the PLAY CART command. However, this value is the "absolute" runtime of the cart (to the end of the file) which may differ substantially from the AUX mark value. Normally, the UDS II resets the cart's duration based on this latter value. Setting this environmental variable to 1 causes the UDS II to allow the AUX mark duration to prevail, ignoring the "absolute" duration returned by the DCS when the cart begins to play. Note that if a cart does not go through the normal QUEUE CART procedure, perhaps due to an ultra-fast edit, the duration returned by the PLAY CART response is used regardless of the setting of this environmental variable. If this environmental variable is set, the following message is written to the DCS stanza of the DIALOG file: "Cart duration at playback based on AUX mark time" If unset, the default message is: "Cart duration at playback based on absolute time" HD_CATASTROPHIC_FAIL 1-100 (NONE) Failure count - If using a DPMI version of the software, the user may now set this environmental variable to a value between 1 and 100, inclusive. If there are that many instances of *consecutive* load or playback failures from the hard drive device, either the DCS or RS-HD, the UDS II goes into emergency stop mode. This avoids the unfortunate situation of all of the events in a schedule (or schedules) being deleted in the wake of this type of failure. If a successful load and playback occurs, the internal counter is reset to 0. It is important to note that this catastrophic handler only functions when in AutoSegue mode. If the system is in Live Control, the presumption is that an operator is present to deal with the situation. Consequently, heroic measures on the part of the UDS II are not called for. This handler is available only on DPMI versions. The reason is because there's a lot of code involved. Likewise, the situations where an entire schedule consists only of hard-drive based items is not likely to occur in a non-DPMI setting. Also, there's no support for this handler with the AudioVault. The user is alerted to such a condition by noting that the system automatically went into STOP mode and is accompanied by an on-screen flashing yellow on red message: "EMERGENCY: * Hard drive fail count exceeded, stopping UDS2 *" Once the problem with the hard drive unit is resolved, the user can return to normal operation by pressing the F2 key twice to return to AutoSegue mode. By default, the environmental variable is unset. If it remains unset, the following message is logged to the hard drive stanza of the DIALOG and UDS2BOOT.LOG files: "Stop mode not entered on catastrophic errors" On the other hand, if the user sets the value (shown below as "") to one within the range of 1 through 100, inclusive, the following informational message is written: "Stop mode entered on catastrophic error(s)" HD_CATASTROPHIC_REF BOOLEAN UNSET - If using a DPMI version (2.22v or greater) of the UDS II software, the user may optionally set this environmental variable to a value of 1. If thusly set, each consecutive failure to load a cart results in the incrementing of an internal "catastrophic" failure counter. Setting this variable is directly dependent upon HD_CATASTROPHIC_FAIL also being set. In other words, this ENV does nothing unless HD_CATASTROPHIC_FAIL is set to an allowable value. The intent is to guard against "chewing through" a schedule caused by consecutive failures to load carts, much like CDK3600_LOAD_FAIL will force the system into emergency stop mode when there are consecutive load failures. - The default behavior is not to "count" a cart load failure as a catastrophic error. Consequently, the following is logged to both DIALOG and UDS2BOOT.LOG: "Missing carts will NOT increment catastrophic failure counter" - However, if HD_CATASTROPHIC_REF is set to a value of 1, the following message is logged in the hard drive stanza of the aforementioned files: "Missing carts will increment catastrophic failure counter" - If HD_CATASTROPHIC_FAIL is unset, neither message appears because of the ENV dependency. RSHD_IGNORE_STOP_SIGNAL BOOLEAN UNSET The user may now optionally set this environmental variable to control an aspect of the UDS II's failure handling system when used with RS-HD. If unset (the default case), UDS II will immediately enter emergency stop mode when it receives a "termination" signal from RS-HD. This happens regardless of what event is currently airing. Setting this ENV disables this behavior. Upon receipt of such a termination signal, UDS II will continue to attempt to run in spite of RS-HD being down. It is strongly suggested that this variable not be set in order to take advantage of the protection it gives. If the user insists on leaving this unset, it is suggested that HD_CATASTROPHIC_FAIL be set to a reasonable value as a safety net. The state of the environmental variable is logged to DIALOG and to UDS2BOOT.LOG and is shown by one of the following messages: "Stop mode entered on RS-HD termination signal" <- default "Stop mode NOT entered on RS-HD termination signal" RSHD_CUT_INFO BOOLEAN UNSET The UDS II now "reveals" that cart number in the following ways (presuming this environmental variable is set to a value of 1): 1). On the UDS II's main screen, in the On Air, Next to Air or Next to Follow box. The 4-character cart identifier is appended with a dash followed by the zero-padded two-digit cut number. 2). In the F4 editor. The 4-character cart identifier is also appended with a dash followed by the zero-padded two-digit cut number. 3). In the following logging files: UDSLOG and AFFIDAV. There are a several caveats that must be noted: a). The cut number is "revealed" only when the cart has been resolved by the QUEUE CART routine. This means that that cut number will only be shown (for 1 and 2, above) when the cart is in a "ready to play" state. b). The "revealing" of the cut number is not applicable to "first class" music (MOHD) items. This is not a severe limitation since the primary intent of using rotating carts (known also as subcarts) is for commercials, liners, jingles and other non-music items. c). The format of the AFFIDAV (affidavit log) now becomes incompatible with all prior versions if this feature is enabled. The reason is that the fixed-column format of the affidavit report was originally designed for a cart identifier of exactly 4 characters. The addition of a cut number now slides everything over by 3 characters to include the dash and the zero-padded 2-digit cut number. This is a factor that automated reconciliation parsers will have to take into account. d). This display of the cut number is "read-only". The fact that it shows up in the F4 editor does not mean that one may explicitly alter the rotation scheme of a multiple cut cart. For the sake of backward compatibility and due to prior art the default is to not "reveal" this cut information. Resultantly, the following message is normally logged to the RS-HD stanza of the DIALOG and UDS2BOOT.LOG files: "Cut info will NOT be displayed for rotating carts" However, if the user has set RSHD_CUT_INFO to a value of 1 in the environment, the following message is written to the files: "Cut info will be displayed for rotating carts" RSHD_TIME_SYNC BOOLEAN UNSET Explicit false RSHD_TIME_SYNC UNSET Minute offsets - This environmental variable, available only on DPMI flavors of the UDS II version 2.29l or greater, equipped with RS-HD, will govern how the UDS II will attempt to set its time of day clock relative to that of the Linux-based RS-HD computer. - In the absence of any setting whatsoever of RSHD_TIME_SYNC, the UDS II will query the RS-HD at a compiled in default time offset starting at 25 minutes past every hour. - If the value of RSHD_TIME_SYNC is set to any of the following boolean false values (without regard to case), any attempt by the UDS II to adjust to or from the time of the RS-HD box will not occur: FALSE, NO, OFF. (In reality, any value assigned to this ENV that is non-numeric will equate to a boolean false in this context. It is recommended, though, that the user restrict the setting to one of the three shown above to better document what is going on). - On the other hand, a list of up to 5 comma separated values will cause the UDS II to attempt to synchronize its time of day clock at the minute specified by each of the values. Consider the following example: RSHD_TIME_SYNC=10,30,50 This will cause the UDS II to communicate with the RS-HD each hour at 10, 30 and 50 minutes past the hour, every hour in order to synchronize the time. * Since there is the potential for a lot of serial communication between the UDS II and RS-HD (particularly while handling QUEUE cart commands), the UDS II will wait for an opportune time to sync the clock after reaching the specified minute offset. That "opportune time" is defined as a window spanning at least 5 seconds into the currently airing event and with at least 10 seconds remaining on that airing event. This window spanning is performed only if the airing or next to air event is from an RS-HD source. This means, for example, that a synchronization specified at 10 minutes past the hour may be deferred until until some opportune moment past that specified the user. * The syntax of the comma-separated list is very strict. 1). There is to be no whitespace whatsover in the list. 2). When using this ENV to specify such minute offsets, valid characters consist solely of digits and commas. No alpha characters are permitted. 3). A trailing comma is not permittted. 4). The offsets specified must be within the range of 0-55 [sic], inclusive. 5). Furthermore, there must be more than a 5 minute separation between each sync time. 6). No more than 5 values can be specified. Anything after the fifth one will be ignored. - Here are valid examples of the syntax: RSHD_TIME_SYNC=10,30,50 RSHD_TIME_SYNC=5,35,45,55 RSHD_TIME_SYNC=05,25,45,55 RSHD_TIME_SYNC=10,20,30,40,50 RSHD_TIME_SYNC=15,45 RSHD_TIME_SYNC=30 - Here are valid examples of the syntax: RSHD_TIME_SYNC= 10,30,50 [ leading space ] RSHD_TIME_SYNC=5, 25, 45 [ embedded spaces ] RSHD_TIME_SYNC=5,25,95 [ obvious invalid value ] RSHD_TIME_SYNC=5,25,59 [ subtle invalid value ] RSHD_TIME_SYNC=5,25,45, [ trailing comma ] RSHD_TIME_SYNC=5 25 45 [ not comma delimited ] RSHD_TIME_SYNC="5,25,45" [ quoted list is invalid ] RSHD_TIME_SYNC=5,10,15,20 [ separation not sufficicient ] RSHD_TIME_SYNC=5,15,25,35,45,55 [ too many items ] ==================================================================== III. Here is a summary of ENVs dealing with RBDS: ------------------------------------------------------------ ENV NAME VALUE Default Units ------------------------------------------------------------ UDS2_RBDS DCI_BROADCAST (None) Text string FLASHCOMM (None) Text string LA_BELLE_SIGN (None) Text string ASCII (None) Text string STREAMAUDIO (None) Text string INOVONICS_711 (None) Text string - MUST BE SET TO EXACTLY ONE OF THE SIX (6) VALUES SHOWN ABOVE. This setting determines which one of the RBDS units is in use. This value portion of the string *is* case-sensitive, so that, for example, "ASCII" is correct but "Ascii" is not. Likewise, "STREAMAUDIO" is correct but "StreamAudio" is incorrect. * Although there are "standards" for the various types of RBDS units, the adherence (or lack thereof) to the standards is such that each individual unit requires an explicit environmental variable specific to that unit. - Note that support for the "INOVONICS_711" type is supported for versions of the UDS II starting with 2.33sN or later. It is a DPMI-only feature. As is the case with all RBDS-related types, the serial port is hard-coded as COM1 (IRQ 4, address 0x3f8). The output speed is hard-coded at 9600 bps. The speed can be adjusted via the UDS2_RBDS_SPEED environmental variable, which is explained below. - Note that support for the "STREAMAUDIO" type is supported for versions of the UDS II starting with 2.33eN or later. It is a DPMI-only feature. As is the case with all RBDS-related types, the serial port is hard-coded as COM1 (IRQ 4, address 0x3f8). The output speed is hard-coded at 2400 bps. Just millseconds after each new events starts (at segue time), the following text string is written to the serial port: "Title Info\fArtist Info\fMMM:SS\fCart and Cut #\fT\r\n" * A formfeed character delimits each field. * A carriage return/newline pair delimits each packet. * The duration of the event is represented as a zero-padded value using MMM:SS notation. * The "T" element shown above is either 'M' for music or 'C' for anything else. - Note that support for the "ASCII" type is, as of this writing on 4 December 1998, available only as an internal release. It has not been tested by anyone other than the developer. Applicable only to DPMI versions of the software, if UDS2_RBDS is set to ASCII (case-sensitive), the format of the data transmitted to COM PORT 1 (at 9600, N/8/1) conforms to the "Generic RDS/DAB output" style specified by On Air's Bernhard Dreyer in e-mail directed to JFS dated 27 November 1998. Specifically, there is a trio of double-quote-delimited, comma-separated strings following this format: "","",""\r\n ...where is the user defined text (up to 70 characters) in the F8 "System Info/RBDS" window. ...where is the artist followed by an ellipsis and the title of the event in the "On Air Box". ...where is the artist followed by an ellipsis and the title of the event generally in the "Next to Air Box". Also note the reference (below) to UDS2_RBDS_MIN_LENGTH, which determines the minimum length an event must be in order to qualify as either the or . a). The maximum length of the RS-232 string is 250 characters, including the terminating "\r\n" sequence. Longer strings are simply truncated (but do include the "\r\n" terminator). b). The string are transmitted at the default of 16-second intervals or at the first opportune time after a segue has occurred. "Opportune time" means that a string will be transmitted 1.5 seconds after a segue...so long as a previous string wasn't transmitted within 1.5 seconds. The interval between transmission of the data can be set to a value other than 16 seconds by adjusting the UDS2_RBDS_DELAY environmental variable. c). The two meta-characters (double-quote and comma) are escaped with a backslash if they are part of the ordinary text. All other characters are transmitted without alteration. d). Unlike the DCI Broadcast, FlashComm and LaBelle sign devices, the UDS II does not restrict its transmissions to "music-only" information. The text of all airable (non-system) events is transmitted to the serial port, as long as the duration (length) of that event is greater than or equal to that specified by UDS2_RBDS_MIN_LENGTH. e). If the user has set UDS2_RBDS=ASCII, the "RBDS parameters" stanza of both the DIALOG and UDS2BOOT.LOG files will show a line resembling this: "4:18:11 PM Unit: Generic RDS/DAB (ASCII)" UDS2_RBDS_SPEED 1200-19200 (Varies) BPS Presuming that the UDS II version is 2.33p or greater, the value for UDS2_RBDS_SPEED can be set to any of these numbers: 1200, 2400, 4800, 9600 or 19200 In the absence of this environmental being set, the following defaults prevail: RBDS Type COM port speed (bps) --------- -------------------- DCI_BROADCAST 9600 FLASHCOMM 9600 LA_BELLE_SIGN 9600 ASCII 9600 STREAMAUDIO 2400 INOVONICS_711 9600 * Note: If UDS2_RBDS_SPEED is set to a value other than 1200, 2400, 4800, 9600 or 19200, the default value for the RBDS type will be used. Regardless of whether the COM port speed is set by default or explicitly by UDS2_RBDS_SPEED, a message such as the following is written to both the DIALOG and UDS2BOOT.LOG files: 4:17:49 PM RBDS parameters: [...] 4:17:49 PM IRQ $04, Address: $03F8 4:17:49 PM Communications speed: 2400 bps UDS2_RBDS_DELAY 1-5000 16 Seconds (DCI) 16 Seconds (FlashComm) 16 Seconds (ASCII) 3 Ticks (LaBelle) - Amount of time to delay between transmission to the RBDS unit, expressed as a length (in ticks) between characters for the LaBelle "Info Express" sign or a delay time (in seconds) between each full message for either the DCI Broadcast or FlashComm units. UDS2_RBDS_PI 1-FFFF (None) Hex string - MUST BE SET FOR DCI_BROADCAST! Although a probable obsolescent feature, the PI setting must be set for DCI Broadcast. If in doubt about the PI setting, set it to 2020. It is ignored if UDS2_RBDS is set to either FLASHCOMM or LA_BELLE_SIGN. UDS2_RBDS_UP_NEXT 1-5000 55 Seconds - Amount of "countback time" before the "COMING UP NEXT" message is transmitted. A reasonable non-default value might be 160 which means that 2:40 from the end of the current on-air event, the "COMING UP NEXT" message will be interleaved with the standard RBDS text rotation. UDS2_RBDS_PADCHAR (Character) ASCII Character : This applies ONLY to the DCI Broadcast unit. The LaBelle "Info Express" sign's space pad character is a hard-coded value. There is no padding required for the FlashComm unit. : Refer to text below for default pad characters. - Character to be prepended and appended as fill character to "center" the text to be transmitted to the RBDS unit. For instance, in the case of the 64-byte buffer employed by DCI Broadcast, an appropriate number of these fill characters will surround the text to ensure that it is exactly 64 characters in length. As noted above, the default character is a space ( ) for the LaBelle sign and a dot (.) for the DCI Broadcast unit. As UDS II version 1.75i, the padding environmental variable may now optionally be set using single-quote-style notation. This permits the user of a DCI Broadcast unit to explicitly set the pad character to a single space (as opposed to the default of a dot) via the following command: SET UDS2_RBDS_PADCHAR=' ' Note that for any other character, this form of quoting is not necessary. UDS2_RBDS_TA_CART (Characters) 4 character ASCII string - Available only if the Flash Comm or Inovonics 711 device is used (as set by UDS2_RBDS=FLASHCOMM or UDS2_RBDS=INOVONICS_711. This setting enables support for "traffic announce" carts. The user should set UDS2_RBDS_TA_CART= where is a case-sensitive four character cart identifier conforming to a DCS, RS-HD or AV100 cart naming convention. If thusly set, each time that cart begins airing, the UDS II will transmit the string, "TA=ON" to the appropriate RBDS unit. After that cart finishes, the string "TA=OFF" will be transmitted. During the airing of that designated "TA" cart, the "radio text" cycle still continues. This means that the rotation between "COMING UP NEXT:" and the user-defined RBDS logo will be transmitted if time permits (as set by the user via UDS2_RBDS_DELAY). As of UDS II version 2.12z, if a DCS unit is used for digital audio, a cart identifier corresponding to that of UDS2_RBDS_TA_CART will also send "TA=ON" to the Flash Comm or Inovonics 711 RBDS unit if played from the "hotkey window". The string "TA=OFF" will be transmitted when an "EE" (EOF) is received from the RS-HD or DCS or when the user explicit halts that cart from the "hotkey" window. UDS2_RBDS_MIN_LENGTH 1-3600 10 Seconds - Available only if the DPMI version of the UDS II is configured to use the "ASCII" style RBDS output, this value determines the minimum length (duration) that an event must be in order to qualify as either or . If a has a duration less than this value, it causes a deferral of a transmission until a segue occurs with an event's duration >= UDS2_RBDS_MIN_LENGTH. In the case of , UDS II's internal array of airable events is scanned from the next to air position until 30 events ahead of currency until a event is found with a duration >= UDS2_RBDS_MIN_LENGTH. This allows the user to specify a "cutoff length" that results in the UDS II bypassing the transmission of text for short jingles, for instance. The value for this variable is logged to both the DIALOG and UDS2BOOT.LOG file (in the "RBDS parameters" stanza) as per this example: "4:18:11 PM RBDS event minimum length: 32 seconds(s)" ==================================================================== IV. Here is a summary of hardware-related ENVs. WARNING: These are not recommended to be changed unless instructed by On Air USA: ------------------------------------------------------------ ENV NAME VALUE (Default preceded with *) ------------------------------------------------------------ UDS2_SWITCHER BT6X1 BT10X1 - Specifies type of switcher/router used by the UDS II, RS-232 serially controlled (which requires setting both of the ENVs: UDS2_RS232_3RD_IRQ and UDS2_RS232_3RD_ADR). There is no default value and the internal string validation is done without regard to case, although there must be no whitespace in the value string. BT6X1 - specifies Broadcast Tools 6x1 Passive Switcher/Router BT10X1 - specifies Broadcast Tools 10x1 Passive Switcher/Router - If one of the above two values is correctly specified by the ENV, the following behavior results: 1). A check is then made to ensure that both UDS2_RS232_3RD_IRQ and UDS2_RS232_3RD_ADR are set to accepted values. If not, nothing further happens. Otherwise, the following items prevail: 2). Sources 71 and 72 are accepted as bonafide system commands both within the context of the UDS II F4 editor and as schedule import items. - If BT6X1 is set, the following numbers are allowed for input channel enable values: 1, 2, 3, 4, 5 and 6. - If BT10X1 is set, the following numbers are allowed for input channel enable values: 1, 2, 3, 4, 5, 6, 7, 8, 9 and 10. * In both cases (BT6X1 and BT10X1), the character 'm' or 'M' is accepted as a global mute command. 3). The optional number specified as part of the "simple network recording" system command (source 80) is treated as an input channel to turn on (rather than as a relay to fire). 4). One of the following message is written to both the DIALOG and UDS2BOOT log files, depending upon the value set by the user for UDS2_SWITCHER: UDS II switcher info: Broadcast Tools 6x1 Switcher/Router [Serial params text] UDS II switcher info: Broadcast Tools 10x1 Switcher/Router [Serial params text] 5). The UDS II communications speed is fixed at 2400 bps. This can't be adjusted on the UDS II side. Depending upon the age of the Broadcast Tools switcher, it may require setting a dip switch to force the speed to 2400 bps. UDS2_RECORDING_RELAY UNSET BOOLEAN - When set to a value of 1, this forces a utility relay to be associated with the "simple network recording" command even if the system is otherwise configured to take advantage of the more flexible means of controlling an external audio switcher/router via serial control. If set, the following line appears in the "UDS II switcher info" stanza of the DIALOG and UDS2BOOT logging files: "Recording command 80 uses switcher: NO" If unset, and a switcher is properly configured, the following is the default message: "Recording command 80 uses switcher: YES" Note that this enviromental variable is only meaningful when the UDS II is configured to use an external switcher. If this environmental variable is set without such an external switcher being configured, it is ignored. UDS2_RS422_IRQ 2 3 4 5 *7 10 11 12 15 - RS-422 IRQ in decimal. UDS2_RS422_ADR $238 *$278 $2B8 $2F8 $338 $378 $3B8 $3F8 - RS-422 port base address in hex. UDS2_RS422_XMIT_TIME 2 *3 4 5 6 - This value, expressed in timer ticks, determines how long the UDS II will wait for confirmation of transmission of characters via RS422 before timing out. Note that the default value is 3 ticks...but there may be circumstances where this value should be incrementally adjusted upward. Please do not change this value unless there are frequent instances of error messages containing the text: "...timeout (Xmit422)-..." or "...timeout (XmitChar)..." If a Denon CD player is detected in the equipment file during UDS II startup, the default transmit time value increases to 4 ticks (instead of 3). UDS2_RS422_RCV_TIME 5 6 *7 8 9 10 11 12 - This value, also expressed in timer ticks, determines how long the UDS II will wait for receipt of a reply via RS422 before timing out. Note that the default value is 7 ticks...but there may be circumstances where this value should be incrementally adjusted upward. Please do not change this value unless there are frequent instances of error messages containing the text: "...timeout (Xmit422)-..." or "...timeout (XmitChar)..." - Note that the current values of both UDS2_RS422_XMIT_TIME and UDS2_RS422_RCV_TIME are logged to the DIALOG and UDS2BOOT.LOG files as follows: "RS422 Xmit Time: 3, Rcv Time: 7" - Also note that user-defined value outside of the range indicated above causes the default value to go into effect. If a Denon CD player is detected in the equipment file during UDS II startup, the default transmit time value increases to 10 ticks (instead of 7). UDS2_RS232_IRQ *3 4 5 9 10 11 12 13 15 - RS-232 IRQ in decimal. If used in a "Dual DigAudio" setting, this sets the IRQ for serial communications with the RS-HD. The default IRQ then becomes 4 instead of 3. UDS2_RS232_ADR $2E8 *$2F8 $3E8 $3F8 - RS-232 port base address in hex. If used in a "Dual DigAudio" setting, this sets the IRQ for serial communications with the RS-HD. The default address then becomes $3F8 rather than $2F8. UDS2_RS232_2ND_IRQ *3 4 5 9 10 11 12 13 15 - RS-232 IRQ for second serial port in decimal. This sets the serial communications address for a DCS when used in a "Dual DigAudio" environment. UDS2_RS232_2ND_ADR $2E8 *$2F8 $3E8 $3F8 - RS-232 port base address for second serial port in hex. This sets the serial communications address for a DCS when used in a "Dual DigAudio" environment. UDS2_RS232_3RD_IRQ 3 4 5 9 10 11 12 13 15 - RS-232 IRQ for "third" serial port in decimal. At present, this sets the serial communications address for a Broadcast Tools Switcher/Router. Note that no values are assigned by default. * The communications speed is fixed at 2400 bps and can't be altered on the UDS II side. UDS2_RS232_3RD_ADR $2E8 $2F8 $3E8 $3F8 - RS-232 port base address for "third" serial port in hex. At present, this sets the serial communications address for a Broadcast Tools Switcher/Router. Note that no values are assigned by default. * The communications speed is fixed at 2400 bps and can't be altered on the UDS II side. UDS2_HD_BAUD 1200 2400 4800 9600 19200 *38400 57600 115200 - RS-232 baud rate for RS-HD only, defaulting to 38400. * Support for 57600 is available only with RS-HD version 00.11t or greater with UDS II version 2.30g or greater. * Support for 115200 is available only with RS-HD version 00.12f or greater with UDS II version 2.30i or greater. UDS2_EPROM_ADR $238 $278 *$2B8 $2F8 $338 $378 $3B8 $3F8 - UDS2's EPROM base address in hex. UDS2_8255_ADR $200 $210 *$300 $310 $380 $390 - 8255 PPI chip's base address in hex. UDS2_8255_OFF *$0 $4 $8 $C - 8255 PPI chip's offset from base address in hex (see above). ==================================================================== V. Here is a summary of all ENVs that are related to tunable parameters for any UDS II supported CD player: ------------------------------------------------------------ ENV NAME VALUE Default Units ------------------------------------------------------------ CDK3600_LOAD_FAIL 1-50 (NONE) Failure count - If CDK3600_LOAD_FAIL is set to an allowed value, the system will go into an "EMERGENCY STOP" condition once the number of CDK-3600 deleted events exceeds the user-defined value as set in the ENV. The user is alerted to such a condition by noting that the system automatically went into STOP mode and is accompanied by an on-screen flashing yellow on red message: "EMERGENCY: * CDK-3600 load fail exceeded, stopping UDS2 *" Once the problem with the Sony CDK-3600 is rectified, the user can return to normal operation by pressing the F2 key twice to resume AutoSegue mode. CDK3600_TC_RETRY 1-25 1 No time code retry count - When CDK3600_TC_RETRY (the "TC" stands for "time code") is set to a value greater than the default of 1, a segue code of 31 will *not* be issued until the number of consecutive instances of a "no time code" failure is met or exceeded. Presuming this value is set to, say, 5, here's a scenario of what would happen at runtime on any given compact disc playing from a Sony CDK-3600 unit: * Upon encountering the first failure of "no time code", an internal counter is set to 1. At this point, the system continues to air that CD, but issues the following example "warning" level message to the screen and to the DIALOG file: "6:43:02 PM [1/5] CDK-3600 no time code: 1163-04 ($00)" a). "6:43:02 PM": the time of the incident b). "[1/5]": '1' is the *current* count of "no time code" failures and '5' is the value set by CDK3600_TC_RETRY. c). "1163-04" is the CD disc and track d). "($00)" is a hexadecimal response code from the CDK-3600 unit. The number may be something other than $00 and is of value only for On Air USA diagnostic purposes. * Each subsequent consecutive "no time code" failure increments an internal counter. When (and if) that counter meets or exceeds the value specified by CDK3600_TC_RETRY, the system then emits a segue code of 31 to attempt to play the next event. This is accompanied by the following "error" level message shown on the screen and written to DIALOG: "6:43:20 PM ERROR: 31 [5/5] CDK-3600 no time code: 1163-04 ($00)" The individual elements of the message are the same but, in this case, since a segue was forced by the system -- it is accompanied by ERROR 31 (the same value of the segue code). Also note that "[5/5]" indicates that there have been 5 consecutive failures of 5 permitted. * IMPORTANT: The "no time code" failure counter is not accumulated over the span of a given event's play. Instead, once valid time code information is re-established, the counter is reset to 0. Thus in the example case wherein CDK3600_TC_RETRY was set to 5, a segue will occur only when there have been 5 (or greater) cases of a "no time code" returned by the CDK-3600 in succession. In other words, over the course a song with a runtime of 3:30, there can be 5 such instances of "no time code" failures spread out over the duration of the song. As long as the "no time code" condition is not pathological, the song will continue to air -- but each case of a "no time code" failure will be logged for informational purposes. If this value is set to greater than 5, much debugging information will be written to the DIALOG file whenever an invalid time code string is returned. This information shows the length of the reply buffer and the full time code string. An invalid time code string is one with a length of less than 9 characters or with the status byte other than 0xF0 or 0xF1. CDK3600_TRACK_RETRY 1-25 1 Track change indicator count - When CDK3600_TRACK_RETRY is set to a value greater than the default of 1, a segue code of 32 will *not* be issued until the number of consecutive instances of a track change indicator is met or exceeded. Presuming this value is set to, say, 3, here's a scenario of what would happen at runtime on any given compact disc playing from a Sony CDK-3600 unit: * Upon encountering the first indication of track change, an internal counter is set to 1. At this point, the system still continues to air that CD, but issues the following example "warning" level message to the screen and to the DIALOG file: "6:43:02 PM [1/3] CDK-3600 track change: 1163-04" a). "6:43:02 PM": the time of the incident b). "[1/5]": '1' is the *current* count of the track change indicator and '3' is the value set by CDK3600_TRACK_RETRY. c). "1163-04" is the CD disc and track * Each subsequent consecutive track change indicator increments an internal counter. When (and if) that counter meets or exceeds the value specified by CDK3600_TRACK_RETRY, the system then emits a segue code of 32 to attempt to play the next event. This is accompanied by the following "error" level message shown on the screen and written to DIALOG: "6:43:20 PM ERROR: 32 [3/3] CDK-3600 track change: 1163-04" The individual elements of the message are the same but, in this case, since a segue was forced by the system -- it is accompanied by ERROR 32 (the same value of the segue code). Also note that "[3/3]" indicates that there have been 3 consecutive failures of 3 permitted. * IMPORTANT: The track change indicator counter is not accumulated over the span of a given event's play. Instead, once valid time code information corresponding to the currently airing track is received, the counter is reset to 0. Thus in the example case wherein CDK3600_TRACK_RETRY was set to 3, a segue will occur only when there have been 3 (or greater) cases of track change indicators returned by the CDK-3600 in succession. In other words, over the course a song with a runtime of 3:30, there can be 3 such instances spread out over the duration of the song. As long as the track change indicator condition is not pathological, the song will continue to air -- but each case of this track change indicator will be logged for informational purposes. (Not logged to screen, but written to the DIALOG file for diagnostic purposes is the complete time code string assembled by the Sony CDK-3600 handler. Although its value is primarily for On Air USA technicians, a "short" string containing fewer then the expected characters is of great help in isolating CD player problems). Much like CDK3600_TC_RETRY, if this value is set to greater than 5, much debugging information will be written to the DIALOG file whenever an invalid time code string is returned. This information shows the length of the reply buffer and the full time code string. An invalid time code string is one with a length of less than 9 characters or with the status byte other than 0xF0 or 0xF1. (Note that *either* of the retry values set to greater than 5 iterations will cause the extensive logging). CDK3600_VERBOSE BOOLEAN UNSET - When CDK3600_VERBOSE is set, much detailed diagnostic information is written to the DIALOG file. The state of the RS422 is written as well as certain status bytes values returned by the CDK-3600 player. Because this information can consume a lot of lines in the DIALOG file, it should remain unset unless directed otherwise by On Air USA. The content of the data has little value for most clients and is intended for analysis by authorized On Air USA personnel. UDS2_NAK_TIMEOUT 1-600 10 Seconds before segue - Note that the default value is 10 seconds, but that it may be set to anywhere within the range of 1 through 600 seconds (10 minutes). If the value set by the user is outside of this range, the default of 10 seconds is used. This variable governs at what point a segue code 33 will be issued by the UDS II when a series of NAK responses if received while a Sony CDK-006, NSM3101AC or Denon 1400 CD player is airing a compact disc. If such a series of NAKs (not acknowledge) responses is received and the current elapsed time is UDS2_NAK_TIMEOUT greater than the database time for the currently airing CD event, a segue code 33 is issued. Along with this "failsafe" segue comes the following error message, displayed on the main screen and also written to DIALOG: "CD Player # NAK segue on " It likely means that the error condition is unrecoverable and, as a result, a segue is forced to avoid possible dead air. This segue code only occurs with the Sony CDK-006, NSM3101AC and Denon 1400 units. UDS2_LOAD_PROTECT 1-10 UNSET "Look around" count - NOTE: This value, if set, is active only during the time that UDS II is operating in "Auto Segue" mode. The presumption is that if the system is in "Live Control" mode, an operator is on hand to deal with CD player load errors. - Normally, the UDS II deals with a CD player load error by: a). Removing the errant event from the schedule. b). It then looks at the source number of the event now occupying the position of the failed event. c). Then it compares that source number with the event immediately before the event it found in step b). d). If there is a source conflict (that would lead to back-to-back play), the UDS II removes that event (the one found by b) as well as the one it was unable to load. Note that the UDS II does not do any "look around" to determine if there are intervening non-music events that still may lead to an "indirect" back-to-back situation. - Setting UDS2_LOAD_PROTECT to a value between 1 and 10 (inclusive) means that the UDS II will scan up to that many events to determine if a conflict will arise. During the scan, it keeps track of the accumulated runtime of intervening non-music events. 1). If the accumulated runtime is sufficient to permit an otherwise "conflicting" CD player to reload, nothing else is done (beside removing the unloadable CD disc from the schedule). 2). If the accumulated runtime is not sufficient to permit a CD reload to occur, the CD discs that would lead to the conflict is also removed from the schedule. This is logged to DIALOG as per this example: "Loading error removed 2018-99 and 226-11" The first CD identifier is the "unloadable disc" and the second is the one that was removed to resolve a potential back-to-back conflict. The latter CD is also logged to the DROPSONG file along with the message "Back-to-back conflict". UDS2_DENON_VERBOSE 1-2 UNSET LEVEL - When UDS2_DENON_VERBOSE is set, much detailed diagnostic information is written to a file named DENONDRB. (where is the zero-padded monthday) in the UDS II's logging directory, generally C:\UDS2\LOGGING. The file contains a log of RS-422 traffic flowing between the UDS II and the Denon 1400 interface. Because this file can grow to a multi-megabyte size very quickly, it is suggested that this variable only be enabled at the explicit direction of On Air USA. As of UDS II version 2.12a, the "verbosity" of the diagnostic information can be currently be set to a level of from 1 to 2. If UDS2_DENON_VERBOSE=2, all RS-422 communication between the UDS II and the Denon is logged. However, if the user sets UDS2_DENON_VERBOSE=1, time code data is not written to the diagnostic file. If this environmental variable is not set, no such diagnostic information is written at all. Note that, even without the logging of time code data, the files can grow to a large size (depending upon the amount of traffic flowing on the RS-422 line). As a result, the diagnostic information is written only if the UDS II detects that there's at least 15 mB free prior to each write. The status of UDS2_DENON_VERBOSE is logged to the Denon stanza of the DIALOG and UDS2BOOT.LOG files as one of the following: "Verbose logging: enabled at level: 1" "Verbose logging: enabled at level: 2" "Verbose logging: disabled" UDS2_DENON_WAIT_BEFORE_LOAD 180-500 275 TICKS Setting UDS2_DENON_WAIT_BEFORE_LOAD to a value between 180 and 500 (inclusive) determines at what point the load sequence will be initiated for a Denon 1400 CD player after a stop command was successfully sent. The UDS II's loading sequence for a Denon 1400 always begins with a stop command (to ensure that player to be loaded will be "free and clear" of a mounted disc). Once the stop command has been accepted, a timer is set within the UDS II to create a lag between the receipt of the stop acknowledgment and when the load sequence can occur. This value's rather high default of 275 ticks (which is about 15 seconds) will cause the load initiation to be deferred until the stop has likely been carried out to completion. - Note that the number of seconds for a tick value can be determined by dividing by 18.2 (because PC's produce that many ticks each second). Therefore, the permissible wait time range is from 10 seconds to about 27 seconds. - It is strongly suggested that this setting not be changed unless explicitly advised to do so by On Air USA. - If the variable is set to an "out of range" value, the default of 275 ticks (15 seconds) is used. UDS2_DENON_TC_STUCK 0-200 30 "Time code" count Setting UDS2_DENON_TC_STUCK to a value between 1 and 200 (inclusive) determines how many consecutive instances of repeated time code strings will be accepted before a segue 042 is issued by the UDS II. If a CD player time code value stays constant over a period of repeated polling, it likely means that the disc is, in fact, "stuck". Because there are occasions when the CD player may not actually be sticking (but the time code value doesn't increment), the user is given the opportunity to adjust this threshold value to a range between 1 and 200. The default value of 30 means that if there are 31 consecutive instances of the same time code string returned when the player is queried, a segue code of 42 will be issued to advance to the next event. Setting this value to 0 is a special case. It means that the user elects to ignore any and all instances of such repeated time code values. Caveat emptor. If set to 0, the UDS II may allow a disc that is legitimately stuck to continue to play for an undetermined amount of time. The current value of this variable is logged to both DIALOG and UDS2BOOT.LOG as per the following example: "Denon1400 stuck count threshold: " UDS2_TRACK_CHANGE_TIME 0-59 3 Time (in seconds) Setting UDS2_TRACK_CHANGE_TIME to a value between 1 and 59 (inclusive) causes the UDS II to ignore a possibly suspect "track change" if it occurs within the timespan set by the user. - Note that setting it explicitly to a value of 0 make the UDS II act immediately on a track change indication, even if it occurs right after the song started. - As of version 2.07v of the UDS II software, the default value (as shown above) was changed from 0 to 3, to decrease the possibility of premature segues caused by what, in fact, may be errant track change indicators. For example, if a "track change" indication occurs when a given CD song has been playing for 15 seconds but the user has set UDS2_TRACK_CHANGE_TIME to 20, the "track change" indication will simply be ignored. If a "track change" indication is received by the UDS II after the song in question has been playing for more than 20 seconds, a segue code 32 will be issued by the system because the elapsed time is beyond the threshold value. It is recommended that this value be set to the lowest possible yet realistic value. The receipt of a "track change" may be valid (perhaps because a badly skipping CD). However, it's apparent that a "track change" indication that occurs within a few seconds of the start of a CD is likely in error. A suggested value for this variable is 15. This means that a "track change" indicator will be acted on only after the song has played for at least 15 seconds. If UDS2_TRACK_CHANGE is set to a valid value (1 through 59 seconds), the following message is written to the DIALOG file's startup stanza: "CD player track change threshold time: seconds(s)" UDS2_DENON_D1_COUNT 1-20 5 Iterations For path