Home› AMX User Forum› NetLinx Modules & Duet Modules

Serial Controlled Tandbergs and Duet Module

staticatticstaticattic Posts: 200
in NetLinx Modules & Duet Modules
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?

Comments

  • JoeJoe Posts: 99
    Hi Jeff,
    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.

    Joe
  • staticatticstaticattic Posts: 200
    Thanks for the assistance. The sad part is, that is pretty similar to what I had been doing before I decided to use the pre-packaged module. I wrote my own UI to go with said module. The only Tandberg functions our users can use are the camera PTZ controls, mic on/off, and switching sources between camera, pc, or dvd. The only "hard" part was getting the Tandberg to automatically start duo video when PC was selected, if it were in a call. I had been taking care of that through string manipulations from the Tandberg buffer. Then one day, I decided to try the pre-packaged module. There is nothing wrong with the pre-packaged module itself, and if our users had access to every function available on the Tandberg, I would certainly continue to use it. In hind site, it took more work to get rid of all of the extra stuff than what I was currently doing with string manipulation. I am thinking what I should do at this time, since I have a little free time, is ditch the pre-packaged module, write my own, and go back to direct string manipulation from the buffer. That worked well in the past, so I guess the lesson I should learn here is, "Don't fix what ain't broke." Thanks again for your help. I'll dink with it today and let you know the outcome...
  • Spire_JeffSpire_Jeff Posts: 1,917
    The Senior Systems Developer was in Programmer 3 with me. I have his email address and I will try to forward this information to him. We talked and they seemed like they were very interested in hearing about problems so they could address them.

    Jeff
  • JoeJoe Posts: 99
    Glad to help. I'm using the 'other company' to control about 30 of these. Their module didn't address everything either, so I scrapped it and wrote my own. I find that I'm doing very little with the Tandberg compared to what it is capable of.

    Joe
  • staticatticstaticattic Posts: 200
    Just to make sure I am making sense, when I say our users only have access to limited Tandberg functions, it is not an issue with the module. It is that the guys that actually control all VTC's, lock down the codec's once they are set up. The end user has no access to any of the Tandberg functionality other than the basic stuff. The calls are automatically dialed for them, the settings are set by the engineers and locked, and the duo selection source is also set and locked. I just wanted to make sure I didn't word something incorrectly to make it seem the pre-packaged Tandberg module was not working. Our users simply aren't allowed to dial, use any of the phone book functions, or any of the other fancy Tandberg options.

    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.
  • staticatticstaticattic Posts: 200
    Thanks Joe

    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... ;)
  • sepulvelsepulvel Posts: 4
    I've been using the MXP Duet module but I have some issues with it. When I try to use the keypad the module sends twice the pulses. (I even tried it with the controller emulator to send independent pulses with the same result) Basically If I press a number on the panel I get twice the number in the codec... has anyone else seen this?
  • rrdbstudiosrrdbstudios Posts: 160
    MXP duet pulsing commands 3 times... ??
    sepulvel wrote: »
    I've been using the MXP Duet module but I have some issues with it. When I try to use the keypad the module sends twice the pulses. (I even tried it with the controller emulator to send independent pulses with the same result) Basically If I press a number on the panel I get twice the number in the codec... has anyone else seen this?

    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!
    -Paul
  • rrdbstudiosrrdbstudios Posts: 160
    Well being that no one responded, maybe no one else has come across this problem...

    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 (![vdvCodec_SIPR_1,309])
		{
		    SEND_COMMAND vdvCodec_SIPR_1,'INPUT-DVI,1'
		}
		ELSE
		{
		    SEND_COMMAND 41005:2:2022/*vdvCodec_SIPR_2*/,'INPUT-DVI,1'
		}

    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.
  • RichardHamiltonRichardHamilton Posts: 58
    nice trick there rrdb :)

    interesting issue and resolution, thanks.
Sign In or Register to comment.