Product(s) affected: DCN-CCU, DCN-WCCU, (not DCN-CCU2)
Version(s): all versions
Downloading firmware over the serial cable can be tricky, this document gives further information on the required equipment and settings for the serial connection and the system.
The following are a list of potential solutions when connecting to the CCU or WCCU to upgrade the system firmware:
Cable from the PC to the CCU/WCCU must be a 9 pin DB9 null cable. A three pin only cable (2,3,5) will not work.
Check your serial comm port setting on your pc and compare it to the comm port setting on the Download and Licensing Tool (DLT). Communication port settings must match.
Make sure the switch settings (S500) for the CCU/WCCU are set to default (Full) for RS232 port 1. S500 switch 1=On, 2=Off, 3=On, 4=On, (5-8 are set for RS232 port 2).
If the system is communicating on the RS232 port and the CCU/WCCU is freezing up (failing) during a download, then try the following switch setting.
To force a firmware download to the CCU/WCCU, set switch S600-8 = On. This will put the CCU/WCCU in boot mode and enables a new firmware upload (in case a download failed). Once the firmware download is complete, change the switch S600-8 to Off.
Note: Refer to the manual (IUI_DCN_en.pdf) for version 3.1x for details where to find the DIP switches mentione din this artcile. The manual is found on the DCN-NG software ISO.
... View more
Version(s): all versions
Audio is disrupted in a multi-CCU system, most likely after first install, re-install or reset of a multi-CCU system.
Audio can be disrupted if CCU’s do not have a unique slave ID assigned, but instead have no number assigned (--) or a duplicate.
In order to do this, select menu 8J CCU Mode on the slave CCU, choose Multi CCU and assign an unused slave ID.
Use Standalone for systems with only one DCN-CCU2.
Use Single mode if one of the DCN-CCU2’s needs to be (temporarily) isolated from the optical network.
Use Multi mode for a multi-CCU system with more than two DCN-CCU2’s.
Notice! For DCN-CCUB2, the 8J CCU mode is not selectable.
For more details on how to set-up a multi-CCU system, please refer to the DCN-NG Operation Manual.
... View more
Product(s) affected: DCN-NG integration
Source: DCN-NG training
In order to integrate 3 rd party software with the DCN-NG system, there are 3 different integration options:
Open Interface (OI)
Application Programming Interface (API)
Streaming Meeting Data (SMD)
Also called LBB4187 or DDTK
The DCN-NG Open Interface software allows remote control of selected DCN-NG functions via third party equipment and control software. Both status and control is in the open interface. Almost every function that is available in DCN-SW is also available in OI. There is no delegate database access available with OI. OI can run in stand-alone and can be combined with DCN-SW.
A hardware synoptic panel is required, this can be done with the open interface, since both control and status updates are possible with the open interface. If a delegate engages his microphone, this can be notified by OI and an LED could light up. If the chairman pushes the button of the same delegate on the synoptic panel, his mic will be turned off by OI.
Application Programming Interface
DCN‑SWAPI is deployed as Microsoft.Net components to be used by 3rd party applications to modify, add, remove and update a subset in the DCN‑SW database.
Functions available in this API are:
Add/remove delegates to the system
Update delegate information
Encode delegate ID-card
Assign/remove delegates from a meeting
Add/remove votes to a meeting
A program that couples the building management system to the DCN system, by a click of the mouse the delegate information could be set from the BMS to the DCN system. Or more sophisticated: by using RF ID card delegates could be added to the meeting when entering the room.
Streaming Meeting Data
Conference Software Streaming Meeting Data unlike other modules does not require any user interaction of an operator; it consists of a software interface from the DCN Server to any number of custom-made PC software Clients.
The interface consists of streams containing meeting data in XML format. Every time an activity (e.g. microphone on/off, start/stop vote) takes place data is send over the XML stream.
Some applications that could be made around this module are:
Video client: displaying meeting information (e.g. voting results, active speakers etc.)
Logging client: log every event from the meeting in a file.
Reporter: generates a meeting report with e.g. voting results and speaker lists.
... View more
Product(s) affected: DCN-NG systems with master & slave CCU set-up
A DCN-NG system will be installed in a building which uses different VLANs for different floors in the building. They want to be able to have interpreters on one floor (in one VLAN) and the rest of the system on another floor (in another VLAN). To this end they have connected their Master CCU to another VLAN than their Slave CCU. This set-up does not work.
Question is; should this work and if not, why not?
This cannot work in a DCN-NG system because of the way the system is designed.
The communication between the CCU’s, at start-up of the system, uses broadcast messages which are not routed by network devices. These messages have a time-to-live (TTL) of 1, which means that once they attempt to cross into another (V)LAN, the messages are not propagated by the routing (L3) switch.
The reason is that the TTL of the packet is decreased every time it traverses from one network to another. When the TTL’s value reaches 0, the packet is dropped by the routing device.
Therefore, the broadcast packet will never reach the other CCU, resulting in error messages like “No Master CCU” on the Slave CCU.
Therefore the system should be installed on the same (V)LAN. This usually does not pose any technical problems as (V)LANs can be distributed over multiple network devices without issue, it’s just that the predictability of where a device is physically located is less in this instance.
... View more
Product(s) affected: DCN-SW, DCN-CCU2, DCN-CCUB2
Version(s): All versions
Symptoms: When a meeting is recorded and the recording software (either Meeting Recorder or Open Interface connection) is shut down, the microphone control mode switches to "Open", independent of what it was before.
Tested this with MR set to DCN-SWSMD -> this does not occur, only when connected directly to the CCU2
If the MR is running on a different PC, this also occurs.
For Open Interface integration: After testing with MR and DDTK found that the system switches to "Open" mode when the "mm_c_start_mon_mm" command is sent, but no stop command is sent before disconnecting the application.
Therefore, adding this command will solve the problem for integration software using Open Interface.
For MR: when the mode changes to 'open' after shutting down the MR, it needs to manually be changed back to 'operator' (or whichever desired mode). The CCU2 will not reflect this change in its menu, but the mode will in fact be changed.
The latter workaround was added to the DCN-NG Release Notes in September 2017, as follows:
There's information added on page 16;
DCN-MR DCN-CCU(B)2 goes to Open mode after closing DCN-MR application.
In a system where:
The DCN-CCU(B)2 is connected to DCN-SW or DCN-SWSMV and
Connected to DCN-MR via Open Interface and
The CCU is in Operator mode.
It will go to Open mode if:
It loses connection with DCN-MR (e.g. the application is stopped)
To restore the microphone mode to Open mode, the microphone mode needs to be set to Open mode via DCN-SW or DCN-SWSMV.
Note: it will also go to Open mode if it loses connection with DCN-SW or DCN-SWSMV. So that the meeting can still continue.
... View more