Home AMX User Forum AMX General Discussion
Options

Tandberg Edge 85

I have a new project that is utilizing a Tandberg Edge 85. I have never worked with the Edge series. All of the documentation I have found says control wise, I use the same protocols that I would use for a 6000MXP. However, I was told by another AMX programmer that wanted to "save me from headaches," the Edge series codecs do not provide any serial feedback other than an "ACK" for a command recieved. I can't find any documentation that supports this rumor. Has anyone worked with the Edge series codecs? Do they really not provide any sort of status feedback?

Comments

  • Options
    HARMAN_ChrisHARMAN_Chris Posts: 598
    Jeff,
    Sadly, Tandberg will tell you that the Edge95 was not intended to be integrated. However, they did make it compatible with the MXP protocol. We have at least one major project using over 100 of these devices, so it can be done. In general, the device does not provide unsolicited feedback, but it does respond to polling. The only unsolicited message you will receive is the RING notification for an incoming call.

    Here is what we do.
    1) The Tandberg provided Duet Module is not used for this device, we use our own Netlinx module because the manufacturer supplied module does not poll for data in the manner that the Edge95 needs to be polled.

    2) Two polling timelines - one for when the device is in standby, and one for when it is "ON" (screensaver status = False).
    a. When we suspect the device is in standby, we hit it with a poll for screensaver status every three seconds. Every thirty, we ask it the device version number (the standard heartbeat poll for Tandberg).
    b. When the screensaver status is false, the on screen menu for the device is visible and the device is considered to be "ON". In this state, we poll for roughly 10 data points to include call status and a multitude of points to meet the end user RMS requirements. One of the points is screensaver status. Should the value turn to TRUE, we know the unit has gone into standby and should be considered OFF thus changing the polling behavior.

    3) In some applications we encounter, the end user has access to the Tandberg remote. When the device is in standby, it will come out of standby if the user presses a remote control button - the end user wants to start the room if this happens, so again - the standby status serves as a good point to track and the frequency that we poll for it is dictated by the need for the room to turn ON should the codec come out of standby.
    4) If the codec receives an inbound call, it again will come out of standby - but you at least receive the instant RING notification that should allow you to then initiate an immediate action like turning the room on and switch polling timelines.

    Ultimately the end user requirements will dictate the complexity of your program, but know that this device is able to integrate if you understand its limitations. While our experience is with the Edge95, the 85 most likely behaves in the same manner.
  • Options
    I have a new project that is utilizing a Tandberg Edge 85. I have never worked with the Edge series. All of the documentation I have found says control wise, I use the same protocols that I would use for a 6000MXP. However, I was told by another AMX programmer that wanted to "save me from headaches," the Edge series codecs do not provide any serial feedback other than an "ACK" for a command recieved. I can't find any documentation that supports this rumor. Has anyone worked with the Edge series codecs? Do they really not provide any sort of status feedback?

    A couple of ways to test this. First, connect to the EDGE85 via telnet and send the commands you are going to be sending, whether the x commands or the legacy commands. The response you get will be the response that gets back to your AMX master, whether you are sending the command via RS-232 or an IP connection from the master.

    Second, verify that the device will communicate over the RS-232 port. I've heard a couple of different times from a couple of different people, that the EDGE series doesn't communicate via the RS-232 port at all. However, in a recent job with an EDGE95, I discovered that this was not true. It did communicate via the RS-232 port. But I tried the same thing with the EDGE85 that I have in the office and it wouldn't communicate via the RS-232 port at all. I would try it and see what happens.

    Finally, keep in mind that if you are in an environment where the codec is likely to be password protected for access to the webpage setup, you can be screwed if you are controlling the device over IP and someone decides to change the password. The same password that applies for the webpage control also controls the telnet access.

    Hope that helps.
  • Options
    HARMAN_ChrisHARMAN_Chris Posts: 598
    Like Andrew points out, ensure that the device is configured to communicate over the comm port. This setting is under the Network Settings in the MXP and the port should be set to CONTROL.
  • Options
    staticatticstaticattic Posts: 200
    Thanks for the replies. As soon as I can get my hands on the EDGE, I plan on running with it to see what it can and can't do. Right now, I am putting together their GUI for the TP. If it does not provide staus feedback, that is going to change the design of my GUI somewhat.

    Basically then, what you guys are telling me, the EDGE95 will reply with more then just an "ACK." So if I send it a "Mic On" command, it will at least reply back with, "OK, the mic is on." The EDGE85 in question is currently being serially controlled via an NI-700. So, I at least know it will accept commands serially. What I don't understand, some of the commands are sent via the Tandberg MXP Duet module and others are sent directly to the codec in a CLI format. I don't understand the point of using a Duet module if the control system is going to continue sending commands directly to the device. I would think it should be one or the other, but not both.

    In either case, they are adding new equipment to the room which requires new functionality of the TP so I am redesigning that and reverse engineering the source code to integrate the new devices. It's almost easier just to start from scratch rather than trying to decipher the thought processes of the other guy. I am trying to figure out why he did what he did, and the new info you guys provided about the EDGE codecs clears the fog a bit. Thanks.
Sign In or Register to comment.