Bose product name
EX-1280C / ControlSpace Designer / Bose Driver for Crestron
Country
Sweden
Firmware / Software Versions
EX-1280C - Firmware: v2.290 / EQ: v1.001_build4
ControlSpace Designer - v5.8.2.32571
Bose Driver for Crestron - v2.7
(aka Bose_ControlSpace_xxxx_2.7.umc in Crestron Simpl Windows)
Detailed description of the issue and steps to reproduce
Se below.
When did you start to experience the issue? Did it work correctly previously?
Issue 1 occurs often, but not always with the same commands/responses.
Issue 2 is constant.
Any troubleshooting steps you took
Reboots, renaming labels, different delays between sent commands, opening and analyzing crestron drivers, etc.
Description
Crestron ControlSpace Driver-modules, v2.7.
The drivers incorrectly parses some serial responses.
This causes various feedback to be incorrectly displayed, such as Mics appearing muted after unmuting them.
Background
Crestron Drivers are split into several "modules".
This mainly consists of one Communications Manager-module, and several different modules for various types of DSP-blocks (CRR, AMM, Mixer-input, selectors, etc.).
The Communications Manager-module (ComManager) parses incoming data from the Bose DSP, via Serial/COM/RS232 or ethernet.
Using labels set in CSD, which are included in the DSP responses, the ComManager identifies which module to retransmit the data to.
Issue 1
- Sending multiple consecutive mute-commands to an AMM-block causes some feedback to be incorrectly parsed by the Communications Manager.
The highlighted serial signal is the data going from the ComManager-module to the AMM-module.
The first and third respsonses, mic 10 / 12 mute off, is correctly parsed and resent to the AMM-module.
The response for mic 11 is incorrectly parsed for unknown reason, and the ComManager disregards that data.
It is never forwarded to the AMM-module, and the mute-state of mic 11 in the Crestron processor is not updated.
Image 1 Toolbox
Crestron debugging tool showing serial communication.
Image notes
("DSP1_Serial_tx$" is serial data sent to the DSP.)
("DSP1_Serial_rx$" is serial data received from the DSP.)
1.1 Commands sent - set mic 10 mute, get mic 10 mute. (SA"#MicMixer-PostAEC">10>2=0\x0DGA"#MicMixer-PostAEC">10>2\x0D)
2.1 Ack-response of set-command. (\x06)
2.2 Reponse of get-command. (GA"#MicMixer-PostAEC">10>2=O;\x0D)
2.3 Automatic notification data of another AMM-block. ("#MicMixer-PreAEC">10>2=O;
3.1 Commands for mute on, followed by get mute
4.1 Ack, Get-response, and automatic notification data from PreAEC AMM
Issue 2
- Automatic notifications does not seem to be supported.
According to the ControlSpace Serial Control Protocol documentation, the DSP transmits any changes over the serial connection for modules starting with #.
The Crestron drivers does not parse those notifications.
Here the mute state of two AMMs are linked, meaning that when #MicMixer-TCCPost is muted, #MicMixer-TCCPre is also muted.
The serial feedback from the DSP indicates this is working correctly, but the Crestron drivers does not parse those responses, and does not forward that data to relevant modules.
Same issue occurs if changes are made using CSD while online to the DSP.
Image 2 Toolbox
Crestron debugging tool showing serial communication.
Image notes
1.1 Command sent to Post-AEC AMM - set mute, get mute.
2.1 Ack response (of set command).
2.2 Reponse of get-command.
3.1 Forwarded data from ComManager module to MicMixer-TCCPost module.
4.1 Automatic notification from #MicMixer-TCCPre block, which is never forwarded to MicMixer-TCCPre module.
Image 3 DSP sample
Example set up of above linked AMM modules of CSD modules.
Image 4 Crestron
Relevant parameters of Crestron Drivers / modules.
Happy to provide more information if needed.
//Joel
