Tandberg C series duet module polling problem

myer0244

Hello all,
I am having an issue with the Tandberg C series duet module.... Once I uploaded a basic program onto the central controller and turned on the Codec, the device "Online/Offline" feedback channel wouldn't change corresponding to the actual status of the device (always showing the device as "Offline" even though the Tandberg was on).

- I checked the serial led indicators on the front of the central controller to make sure data was being sent/received from the Tandberg (which it was).

- Next, I disconnected the serial cable from the back of the Tandberg and attached it to my laptop and opened a terminal to see what the Tandberg was seeing. This is a screenshot of my terminal window after toying around with it for a while:


- Each time the duet module polled the Tandberg for it's online state, it sent a " ♦ " symbol instead of an actual command.
- I Checked the baud rates and everything was set as they were supposed to be.

- To test the communication link between the duet module and the terminal window, I added a button event to send a "PASSTHRU-Hiya There!!!" command to the vdv associated, resulting in a correct display in my terminal window (shown above). This means the module is connected correctly and is actually sending a " ♦ " to the Tandberg which I doubt it can understand... (hence the feedback channel never coming online)

Am I missing something here? or is there something wrong with Tandberg's duet module polling sequence? Any thoughts, suggestions, or work-arounds?

Auser

Are you 1000% sure that the control system is communicating at the baud rate that the Tandberg is configured to communicate at? (Just a thought).

myer0244

Checked about 5 times that both sides were 38400. Also, if the baud rate was incorrect, the "PASSTHRU-Hiya There!!!" shouldn't have shown up.

DHawthorne

myer0244 wrote: »

Checked about 5 times that both sides were 38400. Also, if the baud rate was incorrect, the "PASSTHRU-Hiya There!!!" shouldn't have shown up.

That depends if that is being echoed by the Tandberg or by the module itself.

myer0244

DHawthorne wrote: »

That depends if that is being echoed by the Tandberg or by the module itself.

I disconnected the serial cable from the Tandberg and connected it directly to my computer serial port. So what you see in the terminal window above is exactly what the module sending. Unless I am mistaken on my logic

myer0244

The Tandberg's baud rate is set as 38400.
Here are the relevant pieces of my code on the central controller:

DEFINE_DEVICE
dvCodec = 5001:1:0  // RS232 port 1 real device
dvTP = 10001:1:0  // Touch Panel

vdvTandberg = 41001:1:0  // Duet device


DEFINE_START
DEFINE_MODULE 'TANDBERG_TC_COMM_dr1_0_0' COMM1(vdvTandberg, dvCodec)


DEFINE_EVENT
DATA_EVENT[vdvTandberg]
{
    ONLINE:
    {
		// Set the RS-232 baud rate (default=38400)
		send_command vdvTandberg,'PROPERTY-Baud_Rate,38400'
		send_command vdvTandberg, 'PROPERTY-Poll_Time,15000'  // sets Poll_Time to 15 seconds
		
		// Re-initialize the module for the properties to take place
		send_command vdvTandberg,'REINIT'
    }
}

BUTTON_EVENT[dvTP,1]
{
    PUSH:
    {
	send_command vdvTandberg,'PASSTHRU-Hiya there!!!'
    }
}

DEFINE_PROGRAM

[dvTP,2] = [vdvTandberg,251]  //sets TP button 2 to the Tandberg's online state

bmitchell

Which codec are you trying to connect to?


Regards,

Bryan

myer0244

Which codec are you trying to connect to?

Tandberg C40

bmitchell

I tested the duet module (v1_2_0) with my C40 codec (TC3.1.0.215436) and there was no issue with the comms.

Could your RS232 cable be plugged into the Camera RS232 port of the Codec instead of the COM RS232 port?


Regards,

Bryan

bmitchell

In addition:

I was able to reproduce you terminal screen with the black diamond shape character. The module will send out the following $0A$04 until proper comms is established with the codec and module.

Have you tested the COM port on the codec with your terminal progam to verify functionality of the codec?

myer0244

bmitchell wrote: »

In addition:

I was able to reproduce you terminal screen with the black diamond shape character. The module will send out the following $0A$04 until proper comms is established with the codec and module.

Have you tested the COM port on the codec with your terminal progam to verify functionality of the codec?

I have. I am able to fully control the codec from my terminal with xcommands.
Also to note, the Tandberg's software version is TC3.1.0.215436

Upon further testing, when I connected the central controller back to the C40, I was able to send PASSTHRU-xCommands from button events to the module. But the polling still didnt work and channel 251 on the vdev was still showing up as off

myer0244

Also a couple more things to add:
- I swapped out the central controller for a different one with no luck.
- I also hooked up an MXP-3000 and uploaded it's duet module which worked flawlessly.
- No luck with the C series duet module however.


And by the way, thanks for all the help it is greatly appreciated!

Hedberg

I had a problem trying to use an AMX Tandberg module a couple years ago. Same sort of symptoms. My conclusion was that the Tandberg's response to the AMX module's query was not exactly right. You might check to see if the Tandberg's firmware is up to date. If so, you might try to contact the AMX programmer responsible for the module and find out if the software version response from the Tandberg that you are receiving will be properly parsed by the module.

In other words, the AMX module won't properly control the Tandberg until it receives a particular string from the Tandberg and recognizes it as connected. The response string that the Tandberg sends does not meet expectations because of a different firmware version than was coded into the module.

Of course, I don't know that this is what's going on and it seems that writing a string handler that wouldn't adapt to changing firmware is, how shall I say, a suboptimal programming strategy. But, we've all seen weirder things.

myer0244

When consoled into the C40 and send "?" there is a feature called "echo" which allows you to turn either off or on. Think this might be the culprit? Will find out shortly

myer0244

nope, wasn't it. However, I did send the "0A,04" hex directly from my terminal to see what the C40 responds. C40's response was:

Welcome to UMN
TANDBERG Codec Release TC3.1.0.215436
SW Release Date: 2010-05-10

Going to take your advice Hedberg and see if this is the correct response for the module.

bmitchell

Line 1 (14:04:49):: String To [5001:1:3]-[$0A$04]
Line 2 (14:04:49):: String From [5001:1:3]-[$0D$0A]
Line 3 (14:04:49):: String From [5001:1:3]-[Welcome to $0D$0ATANDBERG Codec Release TC3.1.0.215436$0D$0ASW Release D]
Line 4 (14:04:49):: String From [5001:1:3]-[ate: 2010-05-10$0D$0A$0D$0AOK$0D$0A$0D$0A]
Line 5 (14:04:49):: String To [5001:1:3]-[echo off$0D$0A]
Line 6 (14:04:49):: String To [5001:1:3]-[xpreferences outputmode xml$0D$0A]
Line 7 (14:04:49):: String To [5001:1:3]-[xfeedback register /Status/Call$0D$0A]
Line 8 (14:04:49):: String To [5001:1:3]-[xfeedback register /Status/Video/Input$0D$0A]
Line 9 (14:04:49):: String To [5001:1:3]-[xfeedback register /Status/Conference$0D$0A]
Line 10 (14:04:49):: String To [5001:1:3]-[xfeedback register /Status/Standby/Active$0D$0A]
Line 11 (14:04:49):: String To [5001:1:3]-[xfeedback register /Status/Audio/Microphones/Mute$0D$0A]
Line 12 (14:04:49):: String To [5001:1:3]-[xfeedback register /Status/Camera/Model$0D$0A]
Line 13 (14:04:49):: String To [5001:1:3]-[xfeedback register /Status/Camera/Position$0D$0A]
Line 14 (14:04:49):: String To [5001:1:3]-[xfeedback register /Configuration$0D$0A]
Line 15 (14:04:49):: String To [5001:1:3]-[xfeedback register /Event/IncomingCallIndication$0D$0A]
Line 16 (14:04:49):: String To [5001:1:3]-[xfeedback register /Event/OutgoingCallIndication$0D$0A]
Line 17 (14:04:49):: String To [5001:1:3]-[xfeedback register /Event/TString$0D$0A]
Line 18 (14:04:49):: String To [5001:1:3]-[xfeedback register /Event/SString$0D$0A]
Line 19 (14:04:49):: String To [5001:1:3]-[xfeedback register /Event/Message$0D$0A]
Line 20 (14:04:49):: String To [5001:1:3]-[xgetxml /Configuration/Audio/Volume | resultId="9a"$0D$0A]
Line 21 (14:04:49):: String To [5001:1:3]-[xgetxml /Status/Standby/Active | resultId="9b"$0D$0A]
Line 22 (14:04:49):: String To [5001:1:3]-[xgetxml /Status/Audio/Microphones/Mute | resultId="9c"$0D$0A]
Line 23 (14:04:49):: String To [5001:1:3]-[xgetxml /Configuration/Audio/SoundsAndAlerts/RingVolume | result]
Line 24 (14:04:49):: String To [5001:1:3]-[Id="9d"$0D$0A]
Line 25 (14:04:49):: String To [5001:1:3]-[xgetxml /Configuration/Conference/AutoAnswer/Mode | resultId="9e]
Line 26 (14:04:49):: String To [5001:1:3]-["$0D$0A]


-- That is the response I receive when the $0A,$04 is sent.
-- What version of Firmware is running on your NetLinx, I am running v3.50.430
-- If you run the Notifications for the RS232 port and select the "Strings From Device" what is coming back from the codec to the NetLinx


Bryan

Hedberg

Sure looks like the response from a working installation is the same so my guess is probably wrong. Bryan is correct -- you should be getting that response into Netlinx diagnostics. Are you sure that the Tandberg is giving a good response when connected to the master? No cabling/null modem or baud rate issues?

myer0244

Hedberg wrote: »

No cabling/null modem or baud rate issues?

I don't believe so. I am able to send commands and get feedback, without error, both through the module and directly from the codec via:
- send_command vdev,'PASSTHRU-xcommand yada-yada'
and
- send_string dv,"'xcommand yada-yada',13"

All except the polling sequence. ( [vdev,251] comes back 0 )


When I get into the office tomorrow, I will go through the netlinx diagnostics and post them here. ( in meetings the rest of the day =/ )

MarshallPomeroy

I have been have the same issue. Very frustrating. Please post any findings.

myer0244

Hello all,
I have found my issue. I after I initiated notifications of strings sent to and from the codec, this is what I saw:
(only posting relevant pieces)

(12:04:35):: String To [5001:1:3]-[$0A$04]
(12:04:35):: String From [5001:1:3]-[$0D$0A]
(12:04:35):: String From [5001:1:3]-[Wel$o%e @o $0D$0ATANDBERG Codec Release TC3.1.0.215436$0D$0ASW Release D]

(12:05:05):: String To [5001:1:3]-[$0A$04]
(12:05:05):: String From [5001:1:3]-[$0D$0A]
(12:05:05):: String From [5001:1:3]-[@elc&me to $0D$0ATANDBERG Codec Release TC3.1.0.215436$0D$0ASW Release D]

The central controller was sending the data just fine, however the data was coming back was partly garbled, which means the cable was going bad.

All I did was make a brand new cable and attached it. Works perfect now =D

I really appreciate all of the help and input from you all! Thanks very much!

CASE SOLVED!

Jorde_V

myer0244 wrote: »

Hello all,
I have found my issue. I after I initiated notifications of strings sent to and from the codec, this is what I saw:
(only posting relevant pieces)

(12:04:35):: String To [5001:1:3]-[$0A$04]
(12:04:35):: String From [5001:1:3]-[$0D$0A]
(12:04:35):: String From [5001:1:3]-[Wel$o%e @o $0D$0ATANDBERG Codec Release TC3.1.0.215436$0D$0ASW Release D]

(12:05:05):: String To [5001:1:3]-[$0A$04]
(12:05:05):: String From [5001:1:3]-[$0D$0A]
(12:05:05):: String From [5001:1:3]-[@elc&me to $0D$0ATANDBERG Codec Release TC3.1.0.215436$0D$0ASW Release D]

The central controller was sending the data just fine, however the data was coming back was partly garbled, which means the cable was going bad.

All I did was make a brand new cable and attached it. Works perfect now =D

I really appreciate all of the help and input from you all! Thanks very much!

CASE SOLVED!

If you're getting weird responses the first thing to do is check your settings, if those are correct check your cable , check if it's in the right ports. Finally check your program again, this way you exclude looking for hours into a problem that can't be fixed through programming. Also try not to facepalm yourself if it does turn out to be something in your code, it hurts.