Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 

Has there been an API change during startup between TC6.x and TC7.x - C Series CODECs

Hi All,

We recently upgraded some of our C40 unit from the TC6.3.1 line to TC7.1.1, but have run into a problem.

Our Extron integrated classroom using C40 seem to no longer what to start up properly when an incoming call is received. By this I mean that the Extron control system monitors the C40, and when it detects that an in inbound call has been received, it will initiate a start up of all the ancillary equipment (such as screens, audio, PC etc) - not that the C40 itself don't start up properly. Of course, this means the that users have no idea that they are in a videoconference - they seen no image and hear no audio. Downgrading back to TC6.3.1 resolves the issue.

The Extron system can be woken up manually through the user pressing a touch screen, and once awake the control system does control various other aspects of the C40 via RS232, such as audio volume, microphone mute, camera control, presentation control, disconnect etc.

I heave had a quick search through the release notes for the TC7.x line, but was unable to find anything.

 

Any ideas,

Chris

Everyone's tags (1)
9 REPLIES
New Member

Check the serial port config.

Check the serial port config....  Login required should likely be NO

We have seen this on several systems... the new default in Yes, but most AMX/Crestrons are not designed to login on serial ports and I believe the old default was no

 

VIP Purple

The serial port login

The serial port login required was a change back in TC5.x software.

Hi Juriss,The first thing we

Hi Juriss,

The first thing we looked at when this happened was if somehow the Logon password was reset, however, this hasn't happened.

I also outlined that other RS232 commands and feedback DO work between the control system and the CODEC thereby indicating that RS232 control is still working. It is simply the call feedback that isn't. I must admit though that I was not the one that programmed this so I do not know specifically what the Extron system polls in order to determine if a call is incoming, but I will have to find that out tomorrow.

Cheers

Chris

Hey all,Just as further info,

Hey all,

Just as further info, we have noted that Extron have released a newer driver than the one that we are using (released in March 2014), so we are going to have a go with that but we can't tell exactly what the Extron Controller and driver is actually doing.

In the GC3 Extron software, you have the option of adding a "monitor", and can check various statuses - such as the Call Connection status (which could be things like 'Idle', 'Connected, 'Ringing' etc). I'm guessing (stress guessing) that the driver is issueing something like an:

xstatus call status

command, and the response is read back and analysed, but I don't know absolutely.

Still, something must have change from TC6 to TC7 for this to stop working?

 

Cheers

Chris

 

 

Cisco Employee

It's pretty hopeless to debug

It's pretty hopeless to debug if you don't know what your software is doing.

If it's call status, it's unlikely manually polling for status (else it would always be delayed) but should be registering feedback so the system tells it when things change.

But without knowing what it's looking it, its fruitless to try to find what changed that wasn't documented.  It's much more direct to debug the controller and see what it's attempting to send, and what it's looking for

 

I agree with Steve. What I

I agree with Steve.

 

What I would try is to downgrade the system, use some thing to sniff on the serial connection when it works and then compare it to the failing one.

 

Besides that, maybe some others with issues report here as well and besides

that crestron or the ones who programmed it for you could be the ones to ask

as well

Please remember to rate helpful responses and identify

I've gotta say, I have never

I've gotta say, I have never sniffed a serial interface. Whilst this is common in networking, I do not know how to achieve this on RS232. I don't even know if we would have any equipment (or what that equipment might be) to allow us to achieve this.

TBH, I the number of times I have connected to the serial interface on a C series CODEC I can probably count on one hand, and even then it is only for basic diagnostics, The vast majority of the time, I would use a Network protocol. Can I assume that on the RS232 connection, the C series (much like the MXP) outputs status codes/text when thing happen (such as in bound call, ringing etc? Is there any way to echo these to an SSH terminal  - if only to see what the CODEC might be outputting?

My colleague has gone back to Extron with regard to understanding the driver. Unfortunately, the driver file is a binary, and whilst there is some human readable text, there is not enough info to determine what is going on.

My hope was that in posting that :

  1. Cisco could identify anything that might have changed between TC6 and TC7 that has not be identified in the release notes.
  2. As Martin mentions above - Any others that might have encountered similar issues.

I will post back if we get an update from Extron.

Cheers

Chris

Just as a follow up to this

Just as a follow up to this post, Extron did indeed release a new driver for their control system for the TC7.x firmware that fixes the issues mentioned.

 

Cheers

Chris

 

Hi All,A further follow up on

Hi All,

A further follow up on this.

It appears that Cisco have once again made a change to the TC code and not made any reference to it in the release notes.We recently upgraded a couple of our C40/Extron controlled rooms to test TC 7.2.1 and found that once again, the Extron control did not wake up the reset of the system when a call was received by the C40. Downgrading to TC7.1.4 resolved the issue.

However, in a moment of inspiration (!), I asked our Extron developer to change the C40 driver that had been added to the control code after the last Cisco change to original TC7 release, and swap back to the original Tandberg driver - and everything started working again as expected!!!

It would certainly be nice to know what changes were made by Cisco to cause this issue, and it would be great if they could reference them in the release notes.

 

Cheers

Chris

240
Views
5
Helpful
9
Replies
CreatePlease to create content