______________________

ODIN Intercom Firmware
______________________

These are the release notes for the firmware for the ODIN intercom.

The firmware consists of the following files:

  - ODIN-Firmware.mot      - Downloadable from AZedit
  - ODIN-Firmware.capfw    - Downloadable from FWUT (Firmware Upload Tool)

The firmware files consist of several individual firmware components
(e.g. Bootloader, Main Application, FPGA). The versions of these individual
firmware components can be viewed in the front panel menu under
Status | System | ODIN Versions and also in AZedit under
Status | ODIN Hardware | Component Versions.

The firmware can be updated with AZedit or the FWUT, with one exception.
The Audio FPGA is only included in the .capfw files, and must be
downloaded using the FWUT.

The firmware files in this release include the following firmware components:

  - Main Application:  2.4.0
  - RVON Application:  2.4.0
  - Bootloader:        1.1.3
  - Main FPGA:         0.9.4
  - Audio FPGA:        2026.702.1003 (.capfw files only)
  - FP Application:    2.2.0
  - FP FPGA:           0.3.0

Resources (icons, bitmaps, etc.) are packaged separately, in the file
ODIN-Resources.mot. This file must be downloaded via AZedit.


Known Update Issues
===================

* Updating the Audio FPGA

  If ODIN is running version 1.1.2 or earlier, and the Firmware Upload Tool
  is used to update just the Audio FPGA (i.e. by uploading
  Odin-Firmware-Audinate_vxxx.capfw), the frame does not reboot at
  the end of the procedure, and so the Audio FPGA is not updated. It is
  necessary to cycle power to the frame to force it to load the new version.

  This issue is fixed with ODIN version 1.1.3.

* Updating the Main FPGA
  
  If ODIN has version 1.1.0 or earlier of the Bootloader, and the Firmware
  Upload Tool is used to download new firmware that includes a new version
  of the Main FPGA, the FPGA image in flash is updated. However, after it
  finishes updating the flash and restarts, the FPGA is not reloaded with
  the new image, and continues to report the old version. In this case it
  is necessary to cycle power to the frame to force it to load the new version.

  This issue is fixed with Bootloader version 1.1.2.

* Intercom setup isn't preserved

  If you download new firmware (ODIN-Firmware.mot) via AZedit, and the layout
  of the intercom setup has changed (e.g. because of a new intercom feature),
  the intercom will automatically try to preserve the setup. It does this by
  rewriting the setup in a generic format before restarting; then, when it
  restarts, it converts the generic format back to the native format required
  for operation.

  However, this mechanism is not available in either of the following cases
   - If you update the firmware via the FWUT (Firmware Upload Tool)
   - If you restart the frame in Boot Loader mode, and then download new firmware

  If you want the intercom setup to be preserved, it is recommended that you
  update the frame as follows:
    1. Use the FWUT to update *only* the Audio FPGA
    2. Download the firmware package from AZedit
    3. Download the resources package from AZedit (if required)

  Firmware versions that only differ in the last digit (e.g. 1.4.0 to 1.4.1)
  use the same layout for the intercom setup. Firmware versions that differ
  in the first or second digit (e.g. 1.3.0 to 1.4.0) have different layouts
  for the intercom setup.

* Downgrading the firmware

  If downgrading from version 1.8.0 or later to version 1.7.2 or earlier,
  the system size will be reset to the default (1 frame).

  In some instances, when downgrading to an earlier version, the intercom
  will continually reset a few seconds after it completes initialization.
  In this case, press and hold the right-hand shaft encoder while the frame
  reboots, until the frame reports that it is running the Boot Loader.
  Then wait for 30 seconds, and then repower the frame; this time, it should
  start up normally.


______________

Change History
______________


Version 2.4.0
=============

* Add support for RTS Edge

  This version allows connections from RTS Edge - either from a Web browser,
  or via the RTS Edge app running on a mobile device. Both G.711 and G.722
  codecs are supported.

  WebRTC connections are licensed. For each connected WebRTC channel, ODIN
  must have a valid WebRTC license.

  Channels are configured for WebRTC via the Port Allocation Table.


Version 2.3.0
=============

* Add support for ST-2110-30 SSM (Source-Specific Multicast) streams


Version 2.2.2
=============

* Fixed noise problem on AIO ports

  In prior versions of v2.x.x, audio noise could occur on odd-numbered
  AIO channels. Fixed.

* Added back tone generator for CALL signalling

  The tone generator can be used for generating CALL signalling tones to
  third-party Dante devices connected to ports 1 through 4. This generator
  was removed in v2.0.0 because of resource limits. The generator has now
  been added back in. (Tone detection on these ports has been permanently
  removed.)

* IPedit could not show the status for RVON Bridge channels if the ODIN frame
  was sized for 48 or fewer ports. Fixed.

* Support RVON partner type of "ODIN-HC".

  In prior versions of v2.x.x, if the partner type was set to ODIN-HC, the
  RVON connection wouldn't come up - you had to set the partner type to
  ODIN-R64. Fixed.

* Fixed issue with audio not being set up correctly for an RVON trunk.

  Further details are included in the description for version 2.1.4.


Version 2.2.1
=============

* Integrate ST-2110 support with support for 64 RVON channels

  This version combines the features of v1.9.0 and v2.1.0 (see their
  separate descriptions below).

* Add support for Nomad devices (wireless Access Points + Beltpacks)

* Fixed IFB listen volume issue

  In certain instances, if a panel listened to an IFB mix via a listen key
  (not via AT) and the IFB was configured to dim the program input rather
  than interrupt it, the program input listen level would be dimmed when
  the IFB was interrupted, but it was not restored when the IFB was released.

* In a redundant system, the Audio device on a standby frame would reset
  every 30 seconds. Fixed. (This issue affects version 1.9.0 but not
  version 2.1.x.)

* In version 2.1.x, a Call signal (e.g. from a DBP) could result in the
  audio being locked (no further crosspoint changes could be made, requiring
  the ODIN to be reset). Fixed.


Version 2.1.4
=============

* In rare circumstances, a trunk connected to an RVON port on the ODIN
  could end up with "one-way audio", e.g. where audio being received on
  the trunk was handled properly, but the ODIN was not sending audio
  down the trunk. Fixed.


Version 2.1.3
=============

* In a Hybrid system, if the number of RVON Bridge connections for an ODIN
  frame was changed, the frame had to be rebooted for the changes to take
  effect. Fixed.

* In a Hybrid system, if an ODIN frame was configured for 16 ports, the
  number of RVON Bridge connections could be changed from AZedit - but the
  changes would be lost if the frame restarted. Fixed.


Version 2.1.2
=============

* Support legacy RVON keypanel devices

  Added support for legacy keypanels with RVON-KP daughter-cards in them,
  such as the KP-32 (with an RVON-1) and the RP-1000 (with an RVON-2).

* In version 2.1.0, in a system with redundant ODIN frames, an active ODIN frame
  could reset if party line changes were made from AZedit. Fixed.

* In version 2.1.0, if the codec settings for an RVON Bridge channel
  (such as the codec or the packet size) wa changed, the changes would not
  take effect until the ODIN frame was reset. Fixed.

* In a Hybrid system with redundant ODIN frames, the standby frames would
  generate an alarm indicating that it had no audio from the RVOC Engine
  frame. Fixed.

* In version 2.1.0, panels could not be connected to AIO channel #8
  (the audio was fine, but there would be no data connection), nor could
  GPIO-16 / PAP-32 / LCP-102 panels be connected. Fixed.


Version 2.1.0
=============

* Support for up to 64 RVON ports

  ODIN now supports up to 64 RVON ports (e.g. KP-Series RVON keypanels,
  DBP-R, and RVON trunks).

  An ODIN frame supports 16 RVON ports without a license. A license is required
  to enable additional RVON ports beyond 16.

  Note that RVON channels 33-64 are limited to G.711.

* Support connections to RVON keypanels that are behind a NAT Router

  This requires KP-Series RVON firmware v1.8.1 or later.

* Support for RVON ports in Hybrid intercom

  This version of firmware can be used for a pure ODIN system
  (single-frame intercom, or up to 8 frames of ODIN) or for a
  Hybrid intercom (1 to 8 frames of ODIN plus one frame of RVOC Engine).
  
  Within a Hybrid system, the 64 RVON channels within each ODIN frame
  can be apportioned between RVON ports and RVON Bridge connections.

  RVON Bridge connections do not require a license.


Version 2.0.0
=============

* Support for Hybrid intercom (ODIN + RVOC Engine)

  This firmware allows for systems of up to 9 frames (8 ODIN frames plus
  one RVOC Engine frame), with up to 2400 ports in total. 64 channels of
  RVON audio are used as tie lines between each ODIN frame and RVOC Engine.

  Note the following limitations:
   
   - All RVON channels are reserved for use as RVON Bridge connections.
     If an RVON port connection is required, it must be via RVOC Engine.
   - RVON Bridge connections do not require a license.
   - G.729 is no longer supported.
   - G.722 is only available for RVON Bridge channels 1-32. RVON Bridge
     channels 33-64 always use G.711.
   - The 2-wire interfaces are no longer supported.


Version 1.9.0
=============

* Added support for ST-2110-30 Unicast Audio

  Any ODIN channel can be set to ST-2110 Unicast mode for audio and data
  transmission to KP-Series keypanels via IPedit. Glitch-Free ST-2110-30 
  Unicast connections are supported.

* Added support for Glitch Free ST-2110-30 Multicast Audio

  ODIN can now transmit and receive ST-2110-30 Multicast audio on both its Primary 
  and Secondary interfaces for seamless failover. Glitch Free must be enabled, and 
  the device mode must be set to ST-2110-30.

* Extended ST-2110-30 Multicast IP address range

  ODIN now supports transmitting and receiving ST-2110-30 Multicast audio on
  any Multicast IP address in the range 224.1.0.0 to 239.255.255.255.
  Previously, all ST-2110-30 Multicast IP addresses had to follow the "Receive 
  Prefix" setting in IPedit or Dante controller. 

* Added option to disable the PTPv1 clock

  The device mode must be set to ST-2110-30. OMNEO audio does not function when
  PTPv1 is disabled.


Version 1.8.6
=============

* Fix: In some instances, network errors could cause a memory corruption
  which led to the ODIN rebooting randomly.

* Fix: In some instances, network security port scannnig on TCP port 80
  could cause a memory corruption which led to ODIN rebooting randomly.


Version 1.8.5
=============

* Fix: If the OMNEO connection for a keypanel is reconfigured to a different
  port, in some cases the keypanel would not reconnect.

* Fix: In systems with a high number of Glitch Free keypanels connected,
  ODIN could lose all its keypanel connections.
 

Version 1.8.4
=============

* Fix: In some instances, the OMNEO Control Ethernet interface could stop
  functioning. Additionally, in some of these cases, the Control (AZedit)
  interface was also affected.


Version 1.8.3
=============

* On a factory reset, timeouts for Display Dim (including activating the
  screen saver) are disabled.

* IPedit could show a negative duration for certain OMNEO channels. Fixed.

* On a transfer of control, the newly-active frame might not resolve OMNEO
  device names. Fixed.


Version 1.8.1
=============

* ODIN now supports 128 Tx flows and 128 Rx flows in glich-free mode.

  This is available for OMNEO, Dante, AES-67, and ST-2110.

* If external word clock was removed, there would be no PTP clock available,
  and audio would be muted. Fixed.


Version 1.8.0
=============

* Added NMOS support

  ODIN now supports NMOS IS-04, IS-05, and IS-08 protocols via the
  RTS NMOS Proxy, which is a separate Windows application.
  
* Added support for configurable receive latency for ST2110-Rx Flows
  (2ms, 5ms, 10ms, 15ms, 20ms)
  
* Added support for creating empty slots while creating ST2110-Tx Flows
  
* Added support for a channel to be part of multiple ST2110-Tx Flows 

* Added support for Call functionality for DBPs (Digital Beltpacks)
  and DSPK (Digital Speaker Station)

* Added support for 3rd party (non-RTS) Dante call light indicators on channels 1-4

  Note that this feature requires that the Main FPGA be updated to
  version 4.1.0.

* Fixed ST-2110 data replication issue

  In some instances, ST-2110 Rx and Tx configuration might not be replicated 
  in standby frames.

* Fixed an audio device connection issue for frames that support Glitch
  Free Audio only.


Version 1.7.2
=============

* Added support for Glitch Free

  ODIN audio and data connections to KP-Series keypanels can now seamlessly
  failover to a redundant network/VLAN on its Primary and Secondary
  interfaces. Glitch Free must be enabled on both devices, and is only
  supported on devices manufactured after a certain date. Devices can be
  upgraded by Bosch After Sales Service.

  Known issue: When setting the secondary interface's gateway address, the
  configuration succeeds, however IPedit and the front panel menu will always
  show the address as 0.0.0.0

  For more information, refer to the product documentation.

* Added support for connections to DSPK-4 Digital Speaker Station

* In rare instances, AZedit and the front panel menu could display an
  incorrect OMNEO audio static IP address.


Version 1.7.1
=============

* In some instances with many OMNEO routes to other ODIN / OMI devices, not
  all the routes would come up after power-up. Fixed.

* In version 1.7.0, audio-only OMNEO connections to another device
  (e.g. an AP-1800 Access Point with no beltpack connected) would be
  torn down repeatedly. Fixed.

* Fixed an issue with setting up and removing ST-2110 Rx flows

* In a multi-frame system, the ST-2110 mode setting for a frame could be
  lost. Fixed.


Version 1.7.0
=============

* Added support for ST-2110-30

  ODIN now has native support for ST-2110-30. Previously, ST-2110-30 support
  required the use of Dante Domain Manager.

* Device mode can be configured from IPedit

  IPedit allows the device mode to be set to ST-2110-30, AES-67, or <none>.


Version 1.6.8
=============

* SNMP Enhancements

  Added SNMP support for monitoring ODIN hardware: Cooling fan status,
  temperature sensors, redundant power supplies, and power rails
  (voltage and current).

  Added SNMP support for monitoring multi-frame status (audio received from
  other frames; Ethernet links to other frames).

  New SNMP traps defined that are generated for the following conditions:
   - A hardware fault occurs
   - Audio from another frame is lost
   - An Ethernet link to another frame is lost
   - The frame transitions from standby to active.

  Updated MIB files that define these new capabilities are available from
  RTS Intercom Systems.


Version 1.6.7
=============

* Fixed device name handling in systems with Dante Domain Manager

  For redundant systems, the frame's device name is changed when the frame
  becomes active. However, if the system was using DDM, the device name change
  could fail; as a result, OMNEO connections would not come up.

* Fixed audio issues for multi-frame Group operation (Japanese variant)

  For the Japanese variant, a Group page call might not be routed to all
  members of the group. This only affected multi-frame systems, and only
  when the calling panel was not a member of any group.


Version 1.6.6
=============

* In some instances, ODIN would establish audio links to certain DBPs,
  but the DBPs wouldn't power up (the display would remain at stars). Fixed.

* If the ODIN device name was changed, other devices would be unable to
  resolve/discover the new name until the device was changed. Fixed. (Problem
  introduced in version 1.6.3.)

* In rare instances, OMNEO links to other ODIN frames would fail to come up.
  Fixed.


Version 1.6.5
=============

* Added IPedit support for ODIN redundancy

  IPedit version 3.7.4 or later will now detect if a Redundant ODIN frame has
  gone active to replace a Core frame, and will display a prompt asking
  whether it should be added to the catalog.

* Wait-for-talk didn't work for 4-wire ports

  If the Trunking option "Wait for Talk Key" is enabled, a request to listen
  to a remote assignment doesn't go active (and use up a trunk) unless there
  is something to listen to (e.g. the target panel has a talk key on).
  However, this was broken for 4-wire ports in version 1.6.x. (Requests to
  listen to a port should always go active if there isn't a keypanel
  connected to the port.)

* Invalid ICMP Redirect packets could disable the default gateway

* Dante subscriptions might not be replicated properly in standby frames

  In some cases, when a Dante subscription is removed, that information might
  not get forwarded to standby frames. If a transfer of control occurred,
  the now-active frame would then set up the Dante subscription again,
  even though it had been removed.


Version 1.6.4
=============

* Some changes weren't transferred to the standby controller

  In a single-frame redundant system (one frame plus one redundant frame),
  certain changes might not get transferred to the standby controller, and could
  get lost on a transfer of control. This includes key assignments and setup
  page changes made at a keypanel, and I/O gains made from a PAP-5032. Fixed.


Version 1.6.3
=============

* Standby frames now display the device name on the front panel

  The device name of a standby frame is the default hostname ("CAP6-xxyyzz")

* Improved redundancy failover mechanisms

* Fixed handling of redundancy in a DDM environment

  With v1.6.1, if a core frame failed, Dante Domain Manager would prevent the
  replacement frame from reusing the failed frame's device name. Version 1.6.3
  resolves this issue.

* Keypanel "set by user" types could get corrupted if the intercom was resized

  Normally, if the intercom is resized, ODIN will preserve the setup file
  before it reboots, and then restore the setup when it restarts. However,
  if the number of keys per port (64/96/128) was changed, some "set by user"
  keypanel types could be corrupted. (Saving the intercom setup in AZedit
  before resizing, and resending the setup after resizing, would fix the
  problem.) Fixed.

* When setting the device partner name of an OMNEO channel, certain malformed
  device names could cause the ODIN frame to reset. Fixed.


Version 1.6.1
=============

* Added support for redundancy
* Added support for Frame Swap
* Added support for Backup and Restore

  Details of these features are covered in a separate App Note.

* Firmware can be downloaded to standby frames

* Fixed problems editing the TM Communications parameters

  With Enhanced Trunking, if the TM Communications parameters were changed
  for both sets of Trunk Masters at the same time, communications with one
  of the TM's would hang. If the TM Communications parameters were changed
  again, communications with the other TM could also hang. Fixed.

* Keypanel "set by user" types could be corrupted when the intercom was resized

  By default, if the intercom is resized, the intercom setup (key assignments,
  alphas and descriptions, IFB definitions, etc.) are preserved. However, if
  the number of keys per port is changed, then some of the keypanel "set by user"
  types could be corrupted. Fixed.


Version 1.4.1
=============

* Fixed handling of preferred alpha size for multi-frame intercoms

  With version 1.4.0, in a multi-frame system, KP-series panels might power up
  repeatedly if the menu option Service | Alphas | Auto (From Intercom) was
  enabled.

* If IPedit was making changes via a connection through the RVON interface,
  and IPedit was abruptly disconnected (e.g. the PC rebooted), exclusive
  control might not get released. Fixed.


Version 1.4.0
=============

* Added support for connections to OMS intercoms and DBP Digital Beltpacks

* Preferred alpha size is now a single system-wide setting

  The preferred alpha size is used when displaying or editing the setup from the
  front panel. Previously, each frame could have its own alpha size.

  This setting is also used for any KP-Series keypanels that are configured to
  take the alpha size from the system.


Version 1.3.0
=============

* Support listen volume adjustment for remote assignments

  With ODIN v1.3.0 and TM-10K v10.1.0, it is now possible to control the
  volume at which a panel listens to remote P-P and PL assignments.

  The intercom must first be reconfigured to enable remote volume adjustment.
  The following items are configurable:
    - The maximum number of ports that have access to remote volume adjustment
    - The maximum number of (non-unity) remote volume settings per port
  This is similar to configuring support for key labels. Once the intercom
  has been configured to allow remote volume adjustment, it can be enabled
  on individual ports by going to the Keypanel view, clicking the Edit
  button, selecting the Advanced tab, and selecting "Allow Remote Volume
  Adjustment".

  Remote volume adjustment can be performed from AZedit or from the keypanel.
  In AZedit, a new view allows the configuration of remote volumes. For the
  keypanel, listen volume adjustment for remote assignments is exactly like
  listen volume adjustment for local assignments.

  If the remote intercom does not support remote volume adjustment, the
  intercom can still adjust remote volumes - but this will not work if the
  trunk is forked at the far end. In that case, the remote assignment will
  be heard at 0dB.

  Remote listen volume adjustment is a licensed feature.

* Fixed background noise problem when Comfort Noise Generator (CNG) was
  active for the G.722 codec


Version 1.2.1
=============

* Fix handling of SIP Server phone line status

  After power-on or a reset, ODIN would communicate with a SIP server but
  would ignore the phone line status received from the SIP server. (One
  symptom of this is that SIP line alphas would change when an autodial
  number was selected, but would not revert when the SIP call was dropped.)
  The problem would persist until the SIP phone line mapping was edited
  in AZedit. Fixed.


Version 1.2.0
=============

* Added support for ST2110-30 audio

* In rare instances, removing the OMNEO configuration for a channel could cause
  the frame to reset. Fixed.

* In a multi-frame system, a frame could erroneously report "Dante route
  detected on a trunk port" for a non-trunk port. Fixed.

* In rare instances, the frame and a keypanel could disagree on the state of
  a key (e.g. the frame thinks a key is on even though it has been turned
  off at the keypanel). Fixed.


Version 1.1.3
=============

* When resizing system, frame could have stuck message "System is rebooting"

  In a multi-frame system, depending on the intercom configuration, if you go
  to Options | Intercom Configuration and then Test and then Apply the settings
  (without actually changing anything), the frames would display the message
  "Please wait. The intercom is rebooting." However, the frames would end up
  not rebooting, but leaving the message stuck on the display. (If a screen
  saver was enabled, the message would be cleared when the screen saver
  kicked in.) Fixed.

  Related to this, in other configurations the frames would reboot even when
  it was not necessary. Fixed.

* Handle Trunk Master communications for Ethernet links with high latency

  If the Ethernet link to the Trunk Master has a high round-trip latency, then
  the communications would not be reliable:

    - The link might not come up for a long time

    - The link might come up, but then get torn down in the middle of
      transferring data

  Fixed. Note that resolving the second issue requires upgrading the TM-10K
  to version 10.0.3 or later. With this change, trunking can be carried on
  circuits where the round-trip delay is upwards of 800 mSec.

* Panels connected via RVON might not get all scroll list updates. Fixed.

* Force a restart after updating the Audio FPGA

  If the Firmware Upload Tool is used to update just the Audio FPGA, the
  Audio FPGA would not get reloaded, and would continue to run the older
  version, until the user cycled power or forced a restart. Fixed.


Version 1.1.2
=============

* Added new IPedit command: Reset authentication

  If a user (logged in with Admin permissions) holds down Shift+Ctrl while
  right-clicking the ODIN OMNEO device in the catalog on the left-hand side,
  the pop-up context menu now includes the item "Reset Authentication Table".

  This command requires IPedit v3.6.2 or later.

* Added security for various commands

  The following operations have been re-implemented so that they are more
  secure, and difficult to spoof:
    - Clear channel statistics
    - Tear down channel(s)

  These commands now require IPedit v3.6.2 or later.

* Added security features for compliance with California Senate Bill 327

  For new devices, authentication must now be configured when first connecting
  to the device. This is necessary for compliance with California Law, 
  re: SB327: An act to add Title 1.81.26 (commencing with Section 1798.91.04) 
  to Part 4 of Division 3 of the California Civil Code, relating to information 
  privacy.

  No change needs to be made to existing devices when this version of firmware
  is downloaded; however, if the authentication table is reset, or a factory
  reset is performed on the device, it will then enter the state where it
  requires authentication to be configured.

  AZedit:

  With AZedit v5.4.2 or later, AZedit will display a message notifying the
  user of this requirement, and prompting them to set up authentication.
  (Authentication can also be disabled, although this is not recommended.)
  Until authentication has been configured, the intercom will not allow
  changes to be made; and AZedit (v5.4.2 or later) will be in View (read-only)
  mode, where the various edit controls are all disabled, and most edit
  fields are shown with a pink background.

  With earlier versions of AZedit, no notification will be displayed, but
  the intercom will refuse to accept any changes until authentication has
  been configured (via the Authentication | Configuration menu option).

  IPedit:

  With IPedit v3.6.2 or later, IPedit will switch to the Authentication tab,
  and display a message notifying the user of this requirement. Until
  authentication has been configured, the device will not allow any
  changes to be made; and IPedit (v3.6.2 or later) will switch to
  read-only mode.

  With earlier versions of IPedit, no notification will be displayed, but
  the device will still refuse to accept any changes until authentication has
  been configured.

* Added Open Source software component information

  Open Source software information (OSS components used and the corresponding
  license text) can be uploaded by typing in the device's IP address in
  any browser such as Firefox, Chrome, or Edge.

* Allocation for port 1 of a different frame could be reported as "None"

  In a system of 3 frames or larger, AZedit could report that port 1 of one
  of the frames was unallocated. Fixed.

  This was an AZedit reporting instance. The unallocated port would always be
  in a frame different than the one to which AZedit was connected. The only
  consequence of this was that AZedit would be unable to configure the
  port-specific information (e.g. the OMNEO connection details, for an
  OMNEO). In this instance, the simple work-around was to have AZedit connect
  to the frame in which the port was located.

* Fixed handling of PAP-5032's in large systems

  When connected to a system with a large number of ports and/or IFBs, a
  PAP-5032 might not receive all of its data at power-up. It would
  typically show default alphas (e.g. N003, F129) rather than the correct
  alphas for some of its key assignments. Fixed.

* Channel might come up but pass no audio

  If a channel was up and passing audio, and then got torn down (e.g. partner
  device was reset, channel was reconfigured), when the channel next came up
  it was possible that it would not handle any inbound audio. (The DSP to Micro
  Overrun errors would count continuously.) Resetting the channel would not
  help; the only solution was to reset the card. Fixed.

* Fixed audio playout problems

  There could be occasional audio artefacts on one or more channels, accompanied
  by DSP to Micro Overrun errors (as shown in AZedit and IPedit). Fixed.

  Note that the main FPGA must be updated to version 3.0.1 (included as part of
  this release) to resolve this problem.

* Fixed possible reset problem

  If an RVON channel was connected to a device X, and device X tore down the
  link (e.g. because the link was reconfigured, or because IPedit connected
  to device X told it to tear down the link), in rare cases this could cause
  the RVON processor to reset. Fixed.

* RVON channel doesn't come up after changing the Port Allocation Map

  If the port mapping for a channel was changed (it becomes an RVON channel,
  or the RVON instance changes), and there was already a configuration defined
  for the channel, the channel wouldn't come up until the configuration was
  edited. Fixed.


Version 1.1.1
=============

* Links to RVON-16 / RVON-8 / RVON-C might not come up

  If the partner device for an ODIN RVON channel was a legacy RVON device
  (RVON-16, RVON-8, or RVON-C), the link would not come up if the IP address
  of one device was 128.0.0.0 or greater AND the IP address of the other
  device was 127.255.255.255 or less. Fixed.

* Report UPL IFB override to PAP-5032

  If an IFB program input is being set via a UPL statement, that information
  is now forwarded to any PAP-5032 panels. This matches the behavior of
  the LCP-102 and PAP-32.

* Unicode alphas were sometimes displayed incorrectly on the front panel. Fixed.

* UART communications errors were charged to the wrong keypanel

  UART overrun and framing errors for the AIO ports could be charged to the
  wrong keypanel - and they could be charged to a panel in a different frame,
  resulting in an alarm that couldn't be cleared. Fixed.

* Results of AZedit "clear remote alphas" request were garbled

  In AZedit, if you went to Status | Remote Intercoms and performed one of
  the Clear operations, the results (the number of remote assignments that
  were deleted, and the number of affected keypanels) might be reported
  incorrectly. Fixed.


Version 1.1.0
=============

* Added RVON support

  Each ODIN frame now supports up to 16 channels of RVON. Supported codecs are
  G.711A, G.711u, G.729AB, and G.722. (Currently, the G.722 codec can be used
  for connections to RVON+ cards and to other ODIN frames.) The Port Allocation
  Table is used to determine which ports are RVON ports, and the mapping
  between intercom ports and RVON channels.

  In IPedit, ODIN now appears as two separate devices: An OMNEO device and
  an RVON device.

  NOTE: RVON support requires version 3.0.0 of the main FPGA firmware. If the
  main FPGA version is 2.0.4 or earlier, AZedit will generate an alarm
  warning of this, and RVON connections will not be established. The main
  FPGA is automatically updated when the "ODIN-Firmware" package is
  downloaded. (It does not require the use of the Firmware Update Tool.)

* Added PAP-5032 support

  The intercom can be reconfigured to support up to 64 PAP-5032 panels.

  PAP-5032 panels connect to standard keypanel ports, via AIO, OMNEO, or RVON.
  The PAP-5032 Mapping Table (available under the Options menu in AZedit)
  must be edited to define which ports are PAP-5032 ports. The PAP-5032
  can be used as a standard PAP (to view and change which Program Inputs
  feed which IFBs); it can also be used to adjust program source and IFB
  output levels, and to monitor (listen to) program sources and IFBs.

* SNMP now implements the OMNEO and RVON MIBs

* OMNEO partner device type reported incorrectly

  In certain cases, after making configuration changes, IPedit would report
  a partner device type of "OTHER" rather than the correct value. Fixed.

* Fixed device resets

  Two situations have been identified which could lead to an ODIN frame resetting:

    - If any keypanels were connected via AIO (and powered up) to an ODIN frame,
      the ODIN frame could sporadically reset.

    - If IPedit requested that a channel be torn down, it could cause the ODIN
      frame to reset.

* OMNEO clock status reported incorrectly

  At start-up, the front panel's OMNEO clock status screen could show
  misleading information (e.g. good clock, even though no clock source
  is connected). Fixed.
 

Version 1.0.4
=============

* If an AIO port is unterminated, the polling data could be coupled to the
  audio input for that port (typically sounding like a ticking noise at
  approximately 4 Hz). To prevent this, polling of an AIO port is now disabled
  if the keypanel type for that port is set to any of the following:
    - Virtual
    - SSA-324 / 424
    - SSA-424A / DSI-2008
    - Camera Port
    - Non-Data Port
    - IFB Port
  Note that a keypanel connected to such a port will not power up until the
  keypanel type is set to something different.

* Fix: A large amount of Ethernet traffic could cause the frame to reset.
  (This issue was addressed in version 1.0.3, but different scenarios
  could still trigger the problem.)

* Fix: Changing the device name twice within a short time frame could cause
  the frame to reset.

* Fix: For the Japanese variant, using a "," in an auto-dial number would
  cause the keypanel to ignore the auto-dial number, and instead display
  the standard TIF dial menu. Fixed. Now a "," inserts a 1-second pause.


Version 1.0.3
=============

* Fix: A large amount of Ethernet traffic could cause the frame (or the
  FP Application) could reset after an extended period of time.

* Fix: If AZedit (connected via the Management Port) disables AZedit on the
  Management Port, then no further changes can be made (from any AZedit,
  IPedit, or Front Panel session) until the frame is restarted.


Version 1.0.2
=============

* Fix: In some cases, DHCP packets generated by other network devices could
  cause ODIN to reset, even if ODIN's DHCP server was disabled.

* Fix: In some cases, when making changes from IPedit, IPedit would fail
  with various errors (authentication failed, no response, etc.). Resending
  the changes would usually succeed.

* Fix: If the Firmware Upload Tool was used to update the firmware, the
  LEC Application would not get updated.


Version 1.0.1
=============

* Fix: In some cases, ODIN was unable to resolve the IP address of devices in a
  different subnet.

* Fix: In some cases, OMNEO audio routes were not established when trying to
  establish multiple audio channels to one device.

* Fix: If an OMNEO device changed its IP address twice, ODIN would not detect
  the second change. Furthermore, once this occurred, changing the Destination
  Device Name would cause ODIN to reset.

* Fix: When clearing or acknowledging many alarms consecutively in the front
  panel menu it possible to cause ODIN to reset.

  
Version 1.0.0
=============

* Initial release
