Serial Controlled Tandbergs and Duet Module
staticattic Posts: 200
Working with 3000 and 6000 Tandberg MXP's, I started using the pre-packaged AMX Duet module. I made my own UI to go along with the module and everything works great except for one thing. If the Tandberg reboots, the module still acts like it is connected. When the Tandberg comes back online, I can move the camera, but I have no control of the mic on/off functions. I can use the remote to toggle the mic, but I no longer get feedback on my TP. The only way to get everything back is to reboot the master. I'm only using pins 2, 3, and 5. Without any control leads, I don't see how I can monitor everytime the Tandberg goes off or online. Am I missing something somewhere or is this just something I am going to have to accept the way it is?
I was fortunate last year to get access to one of the protocol authors for an afternoon. When the Tandberg boots up, it sends a slew of info out the com port. I look for the string 'Hardware Serial', which indicates that it is nearing the end of the boot process. Once I receive that string, I send it the following:
'ATE0',13,10 // this turns the echo off
'FEEDBACK ON',13,10 // this turns feedback on
You can tie these 2 commands to a button press or send them when you start the system. Once the Tandberg registers these commands, you can look for feedback indicating mute status:
'*P mic on' // indicates that privacy is off
'*P mic on' // indicates that privacy is on
Other commands I use:
'*S screensaver on' // codec went to sleep, so you can send the blackburst generator to the Samsung monitors that display BLUE when no signal is present (sorry, probably uncalled for...)
'*S duovideo open' // duo video was started remotely
Hope this helps. If you need anymore info, please email me.
The only issue I had with the pre-packaged Tandberg module, was if the Tandberg ever rebooted, it seems like the module doesn't reconnect with it once the Tandberg comes back online. I have camera PTZ functions, but no mic control. Since I am controlling it serially and only using pins 2, 3, and 5, I have no control signals available to monitor if the Tandberg is actually there or not. That issue may not be a problem if I were controlling it via Ethernet, but unfortunatly that is not an option. Joe gave me an idea that I had not tried. Searching for the string 'Hardware Serial', and then manipulating the module so that it "REINIT"'s upon finding that string, will probably solve my issues. However, given the limited amount of functionality that our users are capable of using, I am at the crossroads. Is it worth my time to get the pre-packaged module to reconnect automagically, or should I quit messing with it and go back to string manipulation directly from the Tandberg? Given the small amount of functions they actually use, I am thinking it would be faster and easier just to create a function, poll data from the Tandberg buffer, and continue on from there.
Sorry if I caused any confusion.
well that solves that. Thanks Joe.
Just for grins and giggles, I have the program do a
SEND_COMMAND vdvTandberg_MXP_Serial, " 'PROPERTY-Baud_Rate, 9600' "
SEND_COMMAND vdvTandberg_MXP_Serial, 'REINIT'
when the Tandberg comes back online.
That took care of the problem. Now if you have an suggestions on how I could email myself over to Iraq so I can fix other AMX issues, yet still be home by dinner, that would be perfect. I had thought of teleporation, but after watching "The Fly", I am not too sure I want to try that...
I've just started work with the mxp6000 using the duet module and have had this same issue, even using the passthru and xcommand's or regular keypad presses, the module pulses in sets of three; has this ever been resolved or an answer to why it does it?
I can telnet in and send it a command and that works great. I'm really hoping this is a simple fix because i have most everything working through the module, but the customer wants everything on screen and not discrete only with touch panel buttons and displays.
Any insight would be great!
To solve my own problem, I just initiated the module 1 time and setup my virtual device once and when I need to use a different port on the virutal device, I use that port explicitly. ie
instead of vdvCodec_1 = 41001:1:0, vdvCodec_2 = 41001:2:0, and so on...
I just use a single vdvCodec_1, and then 41001:2:0 for the second port and so on...
Works perfect. The module loads ports 1 through 14 by default; for every virtual device you create for the module, it will send that many calls when you pulse something. In my case I would get 3 pulses of any given channel because I had 3 virtual devices setup. Someone else was getting 2 pulses for a channel, I'm going to go on a limb and say they had 2 virtual devices setup.
Problem solved, just initiate 1 virtual device and call other ports via their respective D:P:S
EXAMPLE: (this is for adding a duo source if a call has been initiated and in duo mode already, duo source selection is done on the 2nd virtual port)
If anyone else has problems let me know, ive found other little quarks... BTW the netlinx module is available still and seems to work without any problems, but I wasnt willing to start from scratch to accomdate its differences.
interesting issue and resolution, thanks.