_____________________________________________

ADAM MCII-e Master Controller - Version 3.0.4
_____________________________________________

Code image CRC
  Standard: f2a6
  Japanese: 2989

Files:

MCII-e.hex  - Motorola S-record file for downloading to the MCII-e board
              flash via an  AZedit connection to the MCII-e board. The
              MCII-e board must already be running a version of either
              the single frame MCII-e Master Controller or the
              multi-frame MCII-e Peripheral Controller firmware.

MCII-e.srec - Motorola S-record file for downloading to MCII-e RAM using
              the Altera GERMs monitor and the Altera "nios-run" utility.
              (used for installing on a new MCII-e card without any
              existing firmware).

______________________

Supported System Sizes
______________________

This firmware supports the following configurations:

- Single frame
- Non-redundant multi-frame systems:
    - 2 to 8 frames (mesh wiring only)
- Redundant multi-frame systems:
    - 2 to 6 frames (mesh wiring)
    - 2 to 9 frames (ring wiring)

The largest system size supported is 880 ports.

_____________

Compatibility
_____________

This version of firmware supports single and multi-frame configurations.
Multi-frame communications requires MCII-e controllers (with identical
firmware) in each frame, and Tri-Bus Expanders for passing audio between
frames.

MCII-e Master Controller
  Requires MCII-e version 3.0.x in all frames, for both active and standby
  controllers. See the following section for details.

  The MCII-e will come up with a blank setup when upgrading from
  version 2.9.x or earlier, but will remember the system size.

  If the MCII-e is upgraded from v2.6.3 or earlier, it will forget any saved
  system size, and will restart with the default system size (single frame,
  272 ports).

  NOTE: The MCII-e will preserve the frame mapping table when upgrading from
  an earlier version. However, if the firmware version is downgraded to
  version 2.7.0 or earlier, the system will lose its frame mapping table; it
  will restart with a default frame mapping table (the controller will restart
  as frame 1; the remaining entries of the frame mapping table will be empty;
  and the frame will not have any links to other frames).

AZedit:
  Requires AZedit v3.6.2 or later.
  Requires AZedit v4.4.0 or later when configured for ring wiring.
  Requires AZedit v4.5.0 or later for OMNEO support.
  Requires AZedit v4.6.0 or later for support of trunking more than 31 intercoms.

AIO-8 Card:
  Requires v10.3.0 or later.
  Requires v10.3.6 or later for support for KP 32 CLD colors.
  Requires v10.4.0 for support for KP 32 CLD panels with a separate
  call-waiting window.
  Requires v10.5.0 for support for Unicode Alphas in non-Japanese builds.
  Requires v10.6.0 for support for more than 64 keys per port.

AIO-16 Card:
  Requires v1.1.0 or later.
  Requires v1.1.1 or later for Kanji support.
  Requires v1.1.4 for multi-frame systems larger than 864 ports
  Requires v1.2.0 for support for KP 32 CLD panels with a separate
  call-waiting window.
  Requires v1.3.0 for support for Unicode Alphas in non-Japanese builds.
  Requires v1.4.0 for support for more than 64 keys per port.
  Requires v1.4.0 for support for trunking more than 31 intercoms.

RVON-8 / RVON-16 Card:
  Will work with any version of the RVON-8 or RVON-16 firmware.
  Requires v2.1.6 for multi-frame systems larger than 864 ports
  Requires v2.2.0 for support for KP 32 CLD panels with a separate
  call-waiting window.
  Requires v2.3.0 for support for more than 64 keys per port.
  Requires v2.4.0 for support for trunking more than 31 intercoms.

MADI Card:
  Requires v1.0.0 or later.

Tri-Bus Expander:
  Requires v1.0.0 or later if configured for mesh wiring.
  Requires v1.1.0 or later if configured for ring wiring.

UIO-256:
  Requires v2.0 (checksum 78b5), with the UIO-256 configured in
  multi-drop mode (DIP switch S1 position 2 closed, and with the RS-485
  data going to J2 of each unit).

GPIO-16:
  Requires v0.0.3 or later.

PAP-940/951/952:
  Requires v7.3.x or later.

PAP-32:
  Requires v0.0.3 or later.

ARP-32:
  Will work with any version of the ARP-32.
  ARP-32 panels are only supported in single-frame configurations.

TM-2000:
  Requires v7.3.0 or later.
  Requires v8.6.0 for support of IFB Special Lists across trunking.
  Requires v8.8.0 for support of more than 120 resources (other than ports)
  across trunking.
  Requires v8.9.1 for MC/TM communications via Ethernet.
  Requires v9.0.0 for support of IFB tallies across trunking.
  Requires v9.0.0 for full support of 2 TMs
  Requires v9.1.0 for support of IFB-SL tallies across trunking.
  Requires v9.1.0 to support taking trunks out of service.

TM-10K:
  Requires v10.0.0 for trunking of more than 31 intercoms.

Standard Master Controller:
  Not supported.

Single Bus Expanders:
  Not supported. 

Dual Bus Expanders:
  Not supported.

_____________________________

Upgrading Multi-Frame Systems
_____________________________

For normal operation, all controllers in the system must be running
version 3.0.x.

If the active controller in one frame is v3.0.x, and the active controller
in another frame is v2.2.x (or older), the controllers will communicate with
each other, and transfer the configuration between them; a lot of the intercom
operation will appear to work. However, some information (e.g. keypresses)
might not be forwarded between frames, and hence normal inter-frame
communications may not be possible.

If the active controller in one frame is v3.0.x, and the active controller in
another frame is v2.4.0 (or older), most trunking data will not be transferred
between frames.

___________________

DIP Switch Settings
___________________

Position	Description
--------	-----------
   1		Must be open (closed => boot to GERMS monitor)
   2		AZedit (J1) baud rate: open=9600, closed=38400
   3		Should be open (reserved)
   4		Should be open (reserved)
   5		Should be open (reserved)
   6		Must be open (closed => don't reprogram flash after download)
   7		Should be open (reserved)
   8		Must be open (closed => enter test mode)

____________

Installation
____________

If the MCII-e board is already running MCII-e firmware, the "MCII-e.hex"
file can be downloaded to the card via AZedit. Otherwise, the
Nios_Loader utility can be used to download a new image and copy
it to flash.

______________________________________

TM Connections for Multi-Frame Systems
______________________________________

For a multi-frame Tri-Bus system, only the lowest-numbered frame (the
"primary") frame connects to the Trunk Master. This would typically be
frame #1.

If frame #2 does not have an Ethernet link to frame #1, it will try to
establish its own connection to the Trunk Master. When the intercom
is configured to use a network connection to the TM, the behavior
is determined by the check-box labeled "Autonomous frames connect as
distinct intercoms" on the Trunk Master Communications dialog in AZedit.

If this box is not checked, then frame #2 will try to connect to the
TM in place of frame #1. If successful, everything looks the same, except
that the TM is now communicating with frame #2 instead of frame #1.

If this box is checked, then frame #2 will try to connect as its own
distinct intercom. For this to work, the Trunk Master would have to
have the IP addresses for the frame 1 controllers associated with one matrix,
and the IP addresses for the frame 2 controllers associated with a
second matrix.

This could be used to set up a disaster recovery scenario. Two frames would
normally operate as a single intercom. However, if the fiber links between
them were lost, they could fall back to operating as 2 distinct intercoms,
each with its own connection to a Trunk Master, using pre-defined trunks
between the frames (using a different transport mechanism, such as RVON).
To be effective, this would require the configuration option "Force
Autonomous Mode when no audio links up" to be enabled.

______________

Change History
______________


New in version 3.0.4
--------------------

* Fixed memory corruption problem with enhanced trunking

  If a connection was defined to a second trunk master (via
  "Trunk Master Connection #2" in the Options | Trunk Master Communications
  dialog), the program input for IFB #1 would be deleted whenever
  communications was established to the second Trunk Master. Fixed.


New in version 3.0.3
--------------------

* Fixed handling of intercom groups when connected to TM-2000

  In versions 3.0.0 through 3.0.2, the MCII-e did not handle intercom group
  information correctly when connected to a TM-2000. (There was no issue
  when connected to a TM-10K.) As a result, keypanels might not be able
  to access remote scroll lists for certain intercoms.


New in version 3.0.2
--------------------

* Improved IFB response time for multi-frame systems

  In multi-frame systems with large numbers of keypanels connected, IFB
  response time (from when the talk key is pressed until when the keypanel's
  audio is present on the IFB output) could be slow when the IFB output was
  in a different frame than the interrupting keypanel. Fixed.

* Stuck CWW audio for multi-frame systems

  In multi-frame systems, it was possible for keypanel audio to get stuck
  on, when using the call-waiting window key to talk to a port in a different
  frame. Fixed.

  (This problem affected KP-32 keypanels, but not CLD panels.)

* MCII-e resets during initialization on very large systems

  If the system was reconfigured for 880 ports and 13 (or more) setup pages,
  the MCII-e would continually reset during initialization, making the card
  unusable. Fixed.

* On start-up, corrupted configuration is not discarded

  When the card is reset or powered up, it searches for a saved setup in
  configuration flash and loads it. It then performs validity checks on
  the saved setup.

  Previously, if any of the validity checks failed, the saved setup would
  be discarded and the MCII-e would start up with a blank setup.

  This no longer occurs. Any corruptions are fixed (e.g. crosspoint volumes
  that are out of range are reset to unity), and then initialization
  continues with the saved setup.

  It is conceivable (but highly unlikely) that this could result in a setup
  that causes the MCII-e to crash. If this happens, reset the MCII-e while
  holding in both pushbuttons, and keep holding the pushbuttons until all the
  red LEDs turn off at the end of initialization. This will cause the MCII-e
  to discard the saved configuration and start with a blank setup. (Holding
  in both pushbuttons has no effect unless the saved setup file fails one or
  more of the validation checks.)


New in version 3.0.1
--------------------

* Fixed trunk tally problems in multi-frame systems

  For multi-frame systems, it was possible for panels in slave frames to
  incorrectly generate "busy" tallies for keys with remote assignments. Fixed.

* Fixed UPL problem in J6 systems

  For Japanese systems only, when communications with a Trunk Master was
  established, it was possible for UPL statements to execute incorrectly;
  it was also possible for the controller to reset. Fixed.


New in version 3.0.0
--------------------

* Added support for trunking of up to 255 intercoms

  When used in conjunction with a TM-10K Trunk Master, up to 255 intercoms can
  be trunked together.

* Added support for new keypanel protocol

  New keypanel protocol is required for full support of intercoms #32 and above.
  When using new keypanel protocol, firmware download times are cut in half.
  Existing keypanels are fully supported, although they will not be able to
  access scroll lists for intercoms 32 and above.

* Added new alarm: Alpha pool exhausted

  If the Trunk Master sends more alphas to the intercom than it can store, an
  alarm is generated. The number of remote alphas sent to the intercom can be
  reduced through the use of intercom groups (configured via Trunk Edit).
  Intercom X only receives the alphas for intercom Y if there is at least one
  intercom group which has both X and Y as members.

* Extended Command-Line Protocol

  The following commands and queries have been added:
      UE?<list>           - Query which UPL statements are enabled
      UE { <val> <+/~> }* - Enable / disable UPL statements
      US?<list>           - Query which UPL statements are currently asserted

  The following stored query has been added, allowing an application to
  asynchronously monitor the status of a UPL statement:
      US?<val>


New in version 2.9.2
--------------------

* Added support for OMNEO devices

  The intercom now supports OMNEO devices (OMI-16, OMI-32, OMI-48, and OMI-64
  OMNEO Matrix Interface I/O cards; OKI-1 and OKI-2 OMNEO Keypanel Interface
  cards).

  Support for OMNEO devices is similar to that for RVON devices; however,
  OMNEO devices have more configurable options:
    - device name (used for DNS)
    - whether to use static IP settings or DHCP
    - DNS addresses
    - DNS search domain

* Added DHCP server

  The MCII-e now includes a DHCP server. The active and standby controllers in
  a given frame act as redundant servers (only the active controller responds
  to DHCP requests). For a multi-frame system, the controllers in each frame
  are independent, and DHCP servers can be individually enabled within each
  frame.

  Each controller can support up to 8 separate DHCP allocation ranges (in
  the same or differing networks). For each controller, the total number of IP
  addresses in all ranges must not exceed 1024.

  NOTE: At start-up, the MCII-e checks all of the IP addresses in its DHCP
  table, to see which (if any) are currently in use. If DHCP Relay is being
  used, the MCII-e must be able to ping any such device that might request
  a DHCP address. 


New in version 2.8.1
--------------------

* Added support for ring wiring

  The Intercom Reconfiguration Wizard in AZedit now allows a multi-frame
  intercom to be configured for either mesh wiring (supported previously)
  or ring wiring (new).

  There is no change in operation when configured for mesh wiring.

  When configured for ring wiring:

    - Redundant audio is automatically selected.

    - Each frame requires exactly 2 Tri-Bus cards (in slots 8 and 9).

    - The system can be configured for up to 9 frames.

    - A frame can contain up to 768 local ports, subject to the following
      limitations:

        - The intercom is still limited to a maximum of 880 ports.

        - Let 'MIN' denote the number of ports in the smallest frame (the
          frame with the fewest number of ports). Then the maximum system
          size is (768 + 'MIN') ports.

    - The Tri-Bus cards are wired as follows:

        - In each frame, one Tri-Bus card must have all of its links wired to
          one of the Tri-Bus cards in the next-lower-numbered frame; the
          other Tri-Bus card must have all of its links wired to one of the
          Tri-Bus cards in the next-higher-numbered frame.

        - To complete the ring, one of the cards in frame 1 must have all of
          its links wired to one of the cards in the highest-numbered frame.

        - In some configurations, only 1 or 2 Tri-Bus links may be necessary
          between a given pair of frames. (The intercom will generate an
          alarm if there are too few links between a given pair of frames.)

* Changing the color of the null assignment didn't work properly

  If AZedit was used to change the color of the null assignment, but no
  other color changes were made, the intercom made the change, but did not
  forward it to panels. (If a KP 32 CLD was then repowered, it would show
  the new color.) Fixed.

* Performance improvements for large systems

  Various changes have been made to improve the performance of large
  systems, especially those with larger numbers of frames. These changes
  also reduce the instances of AZedit disconnecting, e.g. when a frame
  is powered off.

* Fixed problem in Group Call handling (Japanese systems only)

  See the description of v2.6.3 for futher details.


New in version 2.7.0
--------------------

* Added support for Panel Party Lines

  The PPL (Panel Party Line) assignment provides a way for one keypanel to
  dynamically create a party line.

  When panel X turns on a PPL key, it dynamically creates a party line as
  follows:
    - Any panel T which X is hearing via a P-P (i.e. T has a P-P talk key
      for X turned on, or X has a P-P listen key for T turned on) becomes
      a talker on the PPL
    - Any panel L which is hearing X via a P-P becomes a listener on the PPL

  As with standard party lines, a port which is both a talker and a listener
  on the PPL does not hear itself.

  The PPL is maintained as long as the PPL key is on. (A port continues to
  participate in the PPL, even if it stops talking or listening to the
  keypanel that created the PPL.)

  If a keypanel has multiple keys with the PPL assignment, whenever any PPL
  talk key is turned on or off, the PPL is updated, based on the current set
  of talkers and listeners. Once the panel turns off all its PPL talk keys,
  the PPL is destroyed.

  Each keypanel can form a PPL, independent of any PPLs created by any other
  panels. A port can particpate in multiple PPLs (i.e. PPLs created by 2 or
  more other ports) at once.

  Limitations:

  - A PPL can have at most 16 talkers and 16 listeners. If a keypanel is
    talking / listening to more than 16 other ports, only the first 16
    become members of the PPL. (Ports that are PPL talkers are given
    priority as listeners. In other words, if port X is a PPL talker, and
    the creator of the PPL is also talking to X, then X is guaranteed to
    become a PPL listener.)

  - At most 10 PPLs can be active simultaneously. If 10 PPLs are active,
    and another panel tries to create a PPL, that panel will get a "busy"
    tally. If a PPL becomes available, it will automatically be used to
    satisfy an outstanding PPL request, if any.

  - PPLI (Panel Party Line Inhibit) is not supported. (PPLI is similar to
    PPL; however, in addition to creating the PPL, any crosspoint from
    a port that is not a member of the PPL to a port that is a member of
    the PPL is inhibited.)

  - The creator of a PPL is never a talker or listener on the PPL, even if
    it has a P-P crosspoint to itself.

  - A trunk port is not allowed to participate in a PPL.

* Fixed possible UPL problem in slave frames

  In a multi-frame Tri-Bus system, it was possible for a slave frame to
  ignore some or all UPL statements. Fixed.

  The problem would occur at system start-up or after a transfer of
  control. A newly-defined UPL statement would always work; however,
  it might stop working on a transfer of control in the slave frame.

  A UPL statement could be affected if it involved a condition that
  can only be tested in the affected frame (e.g. crosspoint closed;
  vox audio present) or an action that can only be executed in the
  affected frame (e.g. close crosspoint; set headset transfer state).
  

New in version 2.6.3
--------------------

* Fixed problem in Group Call handling (Japanese systems only)

  If the "Merge Callers" option is not set, it was possible to get incorrect
  crosspoints (spurious audio, or no audio) for Group Calls. Fixed.
  (This problem also exists in v2.7.0.)

* Changing the color of the null assignment didn't work properly

  If AZedit was used to change the color of the null assignment, but no
  other color changes were made, the intercom made the change, but did not
  forward it to panels. (If a KP 32 CLD was then repowered, it would show
  the new color.) Fixed. (This problem also exists in v2.7.0.)


New in version 2.6.2
--------------------

* Fixed Ethernet communications problem

  The MCII-e maintains the following Ethernet connections:

    - Connections with every other frame (for a multi-frame Tri-Bus system)
    - A connection with the TM-2000 (if communicating via Ethernet)

  In rare circumstances, communications across one of these links could
  stall. In this case, the link would normally be torn down and
  re-established after a few seconds; however, for frame-to-frame
  links, other intercom activity could prevent that from occurring.
  (The typical symptom was that AZedit would continually lose contact
  with the intercom and then immediately reconnect.)

* Several alarms made persistent

  The following alarms should have been persistent, but were not:

    - Frame mapping tables do not agree: slot <x>, link <y>
    - System sizes differ: frame <x>, controller <y>
    - Frame IDs do not agree: slot <x>, link <y>

  These alarms are now persistent. (The only effect of this change is that
  unresolved instances of these alarms cannot be cleared; however, they
  can still be hidden.)


New in version 2.6.1
--------------------

* An AZedit session connected to a slave frame can now set the date/time

  The date and time are used for logging and as UPL conditions. In
  earlier versions, only an AZedit session connected to frame 1 could
  set the date and time. Now, an AZedit session connected to a slave
  frame can set the date and time.

  For an AZedit session to set the date and time, the following must
  be set in the Configure Logging dialog:

    - the AZedit session must be configured as the log destination, and
    - the "All frames" option must be selected

* Fixed trunk testing

  In versions 2.5.0 and 2.6.0, automated trunk testing (with Trunk Supervisor)
  would fail, with an indication that the loopback test on the test port
  had failed. Fixed.

* Fixed problem in flash handling

  It was possible to get a corrupted setup saved in flash. Fixed.

  This problem would typically occur if the configuration flash was in the
  middle of being updated because of recent changes, and then a change
  requiring a reboot was made to the frame mapping table or the port
  allocation table.

Note:
  The standard version of firmware reports its version as 2.6.0. The build
  date and checksum can be used to determine the actual version:
	Version 2.6.0: March 29, 2011, CRC=5b1f
	Version 2.6.1: May 16, 2011, CRC=be31
  The Japanese version of firmware reports its version correctly.


New in version 2.6.0
--------------------

* Unavailable trunks automatically taken out of service

  In a multi-frame system, if 1 or more frames are unavailable (powered off,
  or not communicating with the primary frame), any trunks which connect
  to unavailable frames are automatically taken out of service. When
  communications to a frame is restored, trunks connecting to that frame
  are restored to service.

  Taking a trunk out of service is similar to, but independent of, putting it
  into maintenance mode. The Trunk Master will not try to use a trunk if
  the trunk is either out of service or in maintenance mode.

  Trunk Supervisor v1.8.0 or later recognizes trunks that are out of service.
  Trunks that are out of service are not tested, since the test would almost
  certainly fail.

  Taking trunks out of service is only available when the intercom is
  communicating with the Trunk Master via Ethernet. (This does not include
  the situation where the intercom is communicating serially using RVON
  pass-through data.)

* Added IFB-SL tallies

  IFB Special Lists now tally, similarly to IFB tallies.

  A key with an IFB-SL assignment displays an in-use tally whenever
  anyone is talking to that IFB-SL, or whenever anyone is interrupting
  any of the IFBs which are a member of the IFB-SL.

  A key with an IFB-SL assignment displays a busy tally if the key is on,
  and either (a) the panel has an IFB priority of 0, which means the panel
  is not allowed to interrupt IFBs, or (b) another panel, with a higher
  IFB priority, is talking to the IFB-SL, or (c) another panel, with a
  higher IFB priority, is interrupting any of the IFBs which are a member
  of the IFB-SL.

* IFB-SL tallies are available across trunking

  IFB-SL tallies across trunking are handled like IFB tallies across
  trunking (see the description for this in the list of changes for
  version 2.5.0).

  Each IFB-SL has a remote tally enable flag associated with it; this flag
  must be checked in order for other intercoms to generate in-use and busy
  tallies for an IFB-SL.

* Support keypanels with up to 128 keys

  The intercom now supports panels with up to 128 keys (e.g. a KP 32 CLD or
  KP-32 Classic with 3 expansion panels).

  The default remains at 64 keys per port. The number of keys per port can
  be set when reconfiguring the intercom, by setting "Keys per port" to
  64, 96, or 128 on the Options tab of the Intercom Configuration
  dialog.

  In order for a keypanel to support more than 64 keys:
  - The intercom must be configured for 96 or 128 keys per port
  - The keypanel must be connected to an I/O card (AIO-8, AIO-16, or RVON)
    which supports more than 64 keys per port
  - The keypanel must be running firmware which supports more than 64 keys per
    port

  Support for keypanels with more than 64 keys has no impact whatsoever on
  trunking. An intercom with support for more than 64 keys per port can be
  trunked with other intercoms that only support 64 keys per port.

* Added support for adjusting IFB listen source levels

  From a keypanel, it is now possible to adjust the listen volume for
  an IFB with an AT assignment. This adjusts the volume of the crosspoint
  from the IFB's listen source to the keypanel's listen destination.

* Command-Line Protocol enhancements

  Command Line Protocol supports the following additional commands:
    - Query and set 6- and 8-character alphas and aliases
    - Query and set 8-Unicode alphas and aliases (if enabled in the intercom)
    - Query and set input alphas (all sizes) (if enabled in the intercom)
    - Query which ports have communicating keypanels (available as a normal
      status query and as a stored query)
    - Query and set the date and time
    - Support setup pages 10 and higher
  The CLP documentation has been revised to include descriptions of these
  revisions.

* CLP processing speed improved when making changes in large intercoms.

  In a multi-frame system, if certain changes were made via CLP in one frame,
  and that frame was currently resynchronizing with another frame (sending
  its current configuration to the other frame), the CLP changes might not
  be forwarded to the other frame. Fixed.

* Added new UPL condition: Is there a keypanel present on port X?

  
New in version 2.5.0
--------------------

* Added support for IFB tallies across trunking

  IFB interrupt status (and current interrupt priority) is now forwarded
  through the Trunk Master to all intercoms. This allows keypanels in
  intercom X to display the correct IFB status for IFBs in intercom Y
  (i.e. an in-use tally for an IFB which is being interrupted).

  To prevent a flood of IFB tally information from being generated, this
  feature is disabled by default. IFB tallies across trunking must be
  enabled individually for each IFB, via a new checkbox ("Remote Tallies")
  in the IFB edit dialog.

  In order for a keypanel in intercom X to display IFB interrupt status for
  IFB Z in intercom Y, the following conditions must all be met:
    - frames X and Y must both support IFB tallies across trunking
    - the TM-2000 must support IFB tallies across trunking
    - the "Remote Tallies" box for IFB Z must be checked

* Added support for 2 Trunk Masters

  The intercom can now be connected simultaneously to two independent
  Trunk Masters (where each independent Trunk Master can be a single
  stand-alone TM-2000, or an active/standby pair). This is configured via
  the Options | TM Communications menu item in AZedit.

  The two Trunk Masters operate independently. The intercom combines the
  data from both Trunk Masters, e.g. when selecting a remote key assignment,
  the key assignment grid shows a list of matrix names which combines
  the matrix names defined by each of the Trunk Masters.

  An intercom is told its own name by the Trunk Master. If the two Trunk
  Masters give the intercom different names, the intercom uses the name
  given it by Trunk Master #1 (as defined in the TM Communications dialog).

  Each intercom supports up to 31 remote intercoms. If the total number of
  intercoms defined by the two Trunk Masters exceeds this, one or more
  remote intercoms will be inaccessible. In this case, TrunkEdit will report
  the conflict when it detects this condition (and will warn the user if
  an attempt is made to define too many intercom names).

  Both AZedit and TrunkEdit will warn the user if both Trunk Masters attempt
  to define the same intercom port as a trunk port. In this case, each Trunk
  Master will force the conflicting trunk into maintenance mode.

  Red LED #18 is lit when the PeriphII-e is communicating with the first
  Trunk Master (no change). Red LED #17 is lit when the PeriphII-e is
  communicating with the second Trunk Master.

* I/O card error counters can be cleared for frames 2+

  In versions 2.3.0 and 2.4.0, clearing the error counters on the I/O card
  status screen would only clear the errors for cards in frame 1. Fixed.

* Clear I/O card type information if I/O card is removed

  If an I/O card is plugged into a slot for which no timeslots are allocated,
  the intercom remembers the I/O card type, for convenience when editing
  the Port Allocation Table. However, if the card was subsequently removed,
  the I/O card type information was not cleared. Fixed.

* Improved automatic updates to the frame mapping table
* Fixed AZedit disconnect problem
* Fixed processor reset problem

  See version 2.2.3 for a description of these changes.


New in version 2.4.0
--------------------

* Added support for Unicode alphas

  Unicode alphas were previously only available in Japanese builds.  Now,
  you can enable Unicode alphas as part of the intercom configuration using
  AZedit V4.0.0.  Using Unicode alphas allows alphas to contain characters
  beyond the basic ASCII, including Cyrillic, Greek, and Latin (most European
  accented letters). These character sets are supported on keypanels like 
  the KP 32 CLD, KP 12 CLD, KP812-U, and KP-12/4U (Cyrillic).

  Using Unicode alphas requires compatible AIO card firmware: AIO-8 V10.5.0
  and AIO-16 V1.3.0.  RVON-8 / RVON-16 firmware already support Unicode alphas.


New in version 2.3.0
--------------------

* Added support for a separate CWW key for the KP 32 CLD

  The KP 32 CLD supports up to 64 talk and 64 listen keys, plus a separate
  call-waiting window key. In earlier versions, key 16 was the CWW key, and
  these two keys operated in parallel. Starting with KP 32 CLD v1.2.0,
  the intercom now supports a separate CWW key, and key 16 is now a regular
  talk/listen key.

  Note that the I/O card firmware (and any RVON firmware, if applicable) must
  be updated to a version that supports a separate CWW key. If any one of the
  devices (intercom controller, I/O card, or keypanel) does not support
  a separate CWW key, the system will operate normally, but the KP 32 CLD
  will operate without a separate CWW key (i.e. key 16 will be the CWW key).

* Added full support for MADI-16+ cards

  Support for 16-channel MADI-16+ cards was added in v2.2.0. This version of
  firmware adds support for MADI-16+ cards with up to 64 channels of audio.

* Added Port Allocation Table

  The Port Allocation Table controls which ports are allocated to which
  I/O cards. This is necessary when using MADI-16+ cards with more than 16
  channels of audio.

* Added support for ADAM-M frames

* Resizing the intercom now provides information about remote alpha pool usage

  On the intercom reconfiguration dialog, when the Test button is pressed,
  information is now returned about the pool of memory used for remote alpha
  storage, including both the current usage and what the usage would be
  with the revised configuration.


New in version 2.2.3
--------------------

* Improved automatic updates to the frame mapping table

  Some updates to the frame mapping table happen automatically (e.g. if you
  swap out the standby controller in a frame, the frame mapping table in
  all frames should be updated to reflect the IP address and MAC address of
  the replacement card). These changes were not always being forwarded to
  all frames. Fixed.

* Fixed AZedit disconnect problem

  If a transfer of control occurred in a frame, AZedit sessions (connected
  either to that frame or to other frames) might disconnect and not be able
  to reconnect for an extended duration. Fixed.

* Fixed processor reset problem

  For very large 4-frame systems, the active controller in frame 1 could reset
  at times when it was very busy. Fixed.


New in version 2.2.2
--------------------

* Fixed handling of remote intercom listening to IFB via AT

  If a panel on another intercom is listening to an IFB on this intercom
  via AT, and then the trunk is reallocated so that the panel listens to a
  different IFB via AT, the audio might not be switched properly. In this
  case, the panel would continue to hear the original IFB listen source, and it
  would be difficult to clear, since that IFB assignment no longer appeared as
  a key assignment on the trunk port. (Also, the panel would have to toggle the
  IFB listen key off and on before it would start hearing the new IFB listen
  source.) Fixed.

  Note that this problem was not easy to generate. It would typically
  occur when changing setup pages (or sending a new AZedit setup file)
  that resulted in changing the IFB assignment of a talk key while the listen
  key (with an AT assignment) was already on.

* Remote alphas transferred properly to slave frames

  For large systems (larger than about 750 ports), slave frames could end
  up with incomplete remote scroll lists. Fixed.

  (The work-around was to go to Status | Ethernet Links | Frame-to-Frame, and
  then reset the links between the frame 1 active controller and the active
  controller in each of the other frames.)

* Fixed I/O card error counters

  The I/O card error counters shown in AZedit always reported as 0, for
  cards in any frame other than frame 1. Fixed.

* UPL force-key actions cannot touch trunk ports

  In previous versions, a UPL statement with an output action to force a
  key on or off could interfere with trunking operation. Fixed.


New in version 2.2.1
--------------------

* If one frame loses communications with another frame, keys for panels in
  the other frame used to be forced off after 60 seconds. Fixed. Now keys
  in the other frame are not forced off automatically. (They can be
  cleared via AZedit.)

* When starting a firmware download, AZedit now reports that the devices in a
  specific frame are unavailable for download if that frame is currently
  receiving the intercom configuration as part of the resynchronization process.

* In a system of 3 or more frames, if AZedit were connected to a frame other
  than frame 1, Status | Master Controller could show frame 1 as being
  up to date, even if it was receiving the intercom configuration from another
  frame as part of the resynchronization process. Fixed.

* Remote alphas were not always being transferred to the standby controller.
  Fixed.

* When two frames start communicating, they exchange configuration information,
  including which talk and listen keys are on. However, some key status
  information was not being handled properly, with the result that one frame
  might not show the correct talk or listen key status for panels in the
  other frame. (This was typically harmless. It would usually only be for
  higher-numbered listen keys, and would not result in any spurious audio.)
  Fixed.

* If a transfer of control occurred when the standby was not up to date,
  I/O card type information (e.g. is a card an RVON-8?) could be lost. Fixed.


New in version 2.2.0
--------------------

* Support for TM-2000 communications via Ethernet

  The intercom now supports communications with the TM-2000 via either
  serial or Ethernet. This can be configured from AZedit via
  Options | TM Communications.

  If serial communications is selected, the baud rate can be set from this
  dialog, rather than needing to reconfigure the intercom.

  If Ethernet communications is selected, you must specify the IP address
  of the TM-2000 (and also the IP address of the backup TM, if there is one).

* Support for MADI cards

  A new screen allows MADI cards to be configured. This screen has 3 tabs.
  One tab allows card attributes to be configured (pass-through data,
  reference clock, sampling rate, etc. Another tab controls the mapping
  between intercom channels and MADI channels. The third tab displays the
  status of the various MADI cards in the system.

* Full support for Command-Line Protocol

  In previous versions, only a subset of CLP requests were supported for
  multi-frame intercoms. Starting with v2.2.0, there is full support for CLP.

* Support for new frame-to-frame link status display

  This version supports a new AZedit screen, Ethernet Link Status. This
  screen shows, for the controller to which AZedit is connected, the
  status of the links to each other frame.

* Support indefinite tallies across frames

  When making a point-to-point call, indefinite tallies (i.e. tallying for
  as long as the caller's talk key is on) was only supported when both the
  caller and the target were in the same frame.

* Improved frame-to-frame communications

  It was possible to get into a state in which two frames were talking, but
  were not being synchronized; changes sent by AZedit connected to one of
  the frames would not be reproduced in the other frame. Fixed.

* Ensure RVON-IO gets local GPIO status

  If an RVON-8 or RVON-16 is reset or plugged in, and that RVON card has
  links to 1 or more RVON-IO cards, the RVON-IO card might not get the
  status of the local GPI outputs for its ports, if there is no keypanel
  attached. Fixed.

* AZedit could warn of configuration flash update failure

  When sending changes to the intercom, AZedit will generate a warning if
  the configuration was not properly saved to configuration flash (e.g. if
  there was a write failure to the device). However, it could sometimes
  generate this message just because the controller timed out waiting for
  access to the configuration flash (because another low-priority task was
  updating the flash already). Fixed. When activating changes, the intercom
  should always get access to the configuration flash.


New in version 2.1.2
--------------------

* Remote alphas scroll lists were sometimes not completely transferred
  to slave frames. In particular, the first 30 or so items would always
  be available, but higher-numbered items might not be available. (AZedit
  and keypanels connected to the slave frame would show a generic alpha,
  such as 285N.) However, key assignments could still be made from an AZedit
  session connected to frame 1. Fixed.

* On an incoming trunked call from a remote intercom, if the called panel
  was not in frame 1, it would not receive an incoming call tally. Fixed.

* If a key was reprogrammed at the panel using the keypad, and that key
  was on (e.g. because of an All-Call), other frames might not handle
  the audio switching properly. Fixed.

* When sending changes, AZedit would sometimes get stuck showing the
  "Activating changes" message, requiring that it be killed via the
  Task Manager. (It was possible to recover by disconnecting AZedit from
  the intercom, e.g. by disconnecting the computer's network cable until
  AZedit timed out.) Fixed.

* It was possible to get the system into a state where changes could
  not be sent to the intercom; AZedit would report that it could not
  obtain exclusive control. It would be necessary to force a transfer
  of control in one of the frames to recover. Fixed.

* In certain circumstances, the active controller in a frame could reset.
  Fixed.


New in version 2.1.1
--------------------

* Added support for configuring KP 32 CLD talk & listen indicator colors

  The KP 32 CLD now uses a bar at the bottom of a key to indicate that
  the talk key is on, and a bar at the top of a key to indicate that the
  listen key is on. These indicators are red and green, respectively, by
  default. AZedit allows the colors of these indicators to be configured.

* Remote alphas transferred to standby

  Remote alphas (received from the Trunk Master) are now transferred to the
  standby controller. In the event of a transfer of control, the intercom
  and the Trunk Master should resynchronize much more rapidly, since the
  Trunk Master no longer has to download all the alphas to the intercom.

* Added verification that I/O cards have the right crosspoints closed

  The MCII-e continually verifies that the I/O cards and the DBX agree on
  which crosspoints should be closed. This guards against stuck crosspoints
  in the event of a message delivery failure.

* Eliminate active/standby errors at start-up

  If both controllers in a frame were reset within a few seconds of each
  other, the active controller could record a burst of errors when the
  standby started communicating. Fixed.


New in version 2.1.0
--------------------

* Added support for KP 32 CLD color tables

  The intercom supports the following data:
    - default key assignment colors (per function type)
    - remote key assignment colors (per remote matrix + function type)
    - local key assignment colors (per local assignment)
  
* Added ARP-32 support (single-frame only)

  The ARP-32 is now supported when the intercom is configured as a
  single-frame system.

* Support for more resources across trunking

  Remote scroll lists of up to 1000 items are now supported.

* Support for more total resources

  In previous versions, an intercom was limited to approximately 2040
  total local scrollable resources (key assignments). This has been
  increased; now, the total number of resources is only limited by
  the available memory, although each scroll list (PL, IFB, etc.) is
  limited to a maximum of 1000 items.

* Fixed active/standby issues

  When a frame was powered up, the system could get into a state in
  which the active controller would not keep the standby controller
  up to date. Fixed.

* Improved frame-to-frame communications

  Various improvements have been made to frame-to-frame communications.

* Fixed AZedit query: Assignment Groups - "Members Only" flags

  AZedit could sometimes display the wrong value for the "Members Only"
  flag of an assignment group. Fixed.


New in version 2.0.5
--------------------

* Support for Arbitrary Crosspoints

  An optional crosspoint (input port and output port) can be associated
  with each UPL Resource. If a crosspoint is defined, then that crosspoint
  is closed whenever any panel is talking or listening to that UR assignment.

  There is also a Reciprocal flag. If this flag is checked, then the
  reciprocal crosspoint (from the output port to the input port) is also
  closed.

  If a user at a keypanel tries to adjust the volume of a UPL Resource, it
  adjusts the volume of the crosspoint (if it is defined). The volume of
  the reciprocal crosspoint is not affected.

* Improved frame-to-frame synchronization

  When two frames start communicating, one frame will resend its
  configuration to the other, to ensure they have the identical setup.
  AZedit could briefly disconnect from the intercom while the frames were
  synchronizing. Fixed.

* Fixed search-and-replace problem

  In certain circumstances, performing a search-and-replace could cause
  the controller to reset, if the assignment being searched for was
  replaced by itself.

* Fixed controller reset problems

  Certain error conditions could erroneously cause the controller to reset.
  Fixed.

* Improved handling of frame mapping tables

  When two frames start communicating, they compare their frame mapping
  tables, and merge them if possible. In rare cases, this could result
  in the same entry appearing multiple times. Fixed.


New in version 2.0.4
--------------------

* Support for autonomous frame operation in multi-frame systems

  This firmware is based on version 1.6.2 of the ADAM MCII-e. However,
  it supports both single-frame and multi-frame systems.

  In a multi-frame system, the firmware supports autonomous operation:
  If any frame is disconnected, the other frames continue to work without
  interruption.

  Further details of autonomous frame operation are included in a separate
  document.

* Automatic fail-over on loss of Ethernet

  If the active controller loses all of its Ethernet links to controllers
  in other frames, but the standby still has Ethernet connectivity, an
  automatic transfer of control is performed.

* Force autonomous mode if no Tri-Bus audio links (option)

  As part of the intercom reconfiguration dialog, a new option allows the
  intercom to be configured so that a frame automatically enters autonomous
  mode if it has no audio links to other frames. In this case, it ignores
  the other frames (even if it has Ethernet connectivity to them) and
  operates in stand-alone mode.

* Support for Centralized Auto-Dials

  The intercom supports up to 999 centralized auto-dials. Associated with
  each auto-dial is an alpha, a scroll restrict flag, and a telephone number.

  Auto-dial number NNN can be accessed by dialing the sequence
	#NNN

  (Dial "##" to generate a single "#" DTMF tone.)

  Centralized auto-dial numbers can also be accessed via the TIF dial menus
  in the KP32 and the KP32CLD, for keys which have an assignment for which
  the "Port is a TIF" flag is set. This requires the following minimum
  versions:
	- KP32 v2.1.1
	- KP32CLD v1.0.4

* Support for Enhanced Assignment Groups

  Associated with each Assignment Group is a new checkbox, "Members Only".
  If this box is checked, then only keypanels that are members of the
  assignment group can access the assignment group. If the box is not checked,
  any keypanel can access the assignment group.

* Support for Alarms

  The intercom automatically logs various error and alarm conditions
  (e.g. loss of communications with the Trunk Master; no backplane clock;
  no audio between a pair of frames). These alarms can be viewed from
  AZedit via the menu option Status|Alarms. A new pane in the AZedit status
  bar shows how many alarms are outstanding, and is highlighted whenever a
  new alarm occurs.

* Support for Uploading Debug Information to AZedit

  In the event of a controller failure, information about the failure is
  recorded in flash memory. In this case, the AZedit menu item
  Options|Upload Debug Information is highlighted. Selecting this item
  allows the debug information to be uploaded and saved to file; it
  can then be provided to Telex to determine the cause of the problem.

* Support for Logging in any frame

  Each frame generates log information independently. Enabling or disabling
  logging affects all frames. However, when configuring the log destination
  (which AZedit session receives log information), each frame can be
  configured to send its logging information to a different AZedit session.
