Home AMX User Forum NetLinx Studio

IR - Serial data - Netlinx Studio reporting question

I'm using a IR port - with 'SET MODE DATA', communicating with a Tandberg 6000. The speed is set @ 9600, 8, N, 1 with ' 485 DISABLE'". The NS notification messages shows a command to the device with 2 lines.

Line 41 (16:51:52.953):: String To [5001:9:1]-[xcommand pipshow virtualmonitor: 1 picture: localmain position: ]
Line 42 (16:51:52.953):: String To [5001:9:1]-[Top Right$0D]

1) It appears that the string is sent in 2 chuncks, and I just wanted to know if it's really going out like this or if it's just a Notification quirk?

2) The same command works from a RS232 port just fine, but the IR port isn't. Also other commands I send to the port work fine. I've added delays between commands without any difference in results, so I'm looking for other differences that I'm just not thinking about. Any Ideas?

Comments

  • DiogoDiogo Posts: 65
    Hi Roo


    The right command you should do is
    SEND_COMMAND device, "'SET MODE SERIAL'"

    I've used this in the past and everything worked well.
    Just to make sure, confirm if you are using set mode serial. If not work it can be the cabling, don't forget using the IR port for serial communications, you just have the TX and Ground to use.
  • @ Diogo:
    I beg to differ. SET MODE DATA is correct. Please review TN#394

    @ ROO
    Showing the notification strings in one,two, three rows should make no difference. This is subject to the refresh timing of the buffer. As far as the controlled device, your string will be one row until the terminator, in your case $0D.
  • DiogoDiogo Posts: 65
    felix,

    Interesting, I believe it now both work, because the technote says for axcess system, and I saw Set mode serial in the PI.

    The problem must be some other thing.
  • ROOROO Posts: 46
    Is there a difference between IR & RS232 sizes or timings that I'm missing

    I appreciate the feedback!

    Since this is the longest command I'm sending, I'm thinking that I've reached a limit, and need to break the command down into 2 halves or something along those lines. I won't have access to the Tandberg again for a couple of weeks, or I could just experiment.

    Is there a hardware limitation between string lengths sent through an IR port as serial data and the RS232?

    With the IR set as a serial data port, should I try sending a Stack Pulse, or change the CHARD ? Would that have any affect on the Serial data port?

    Thanks
    ROO
  • ericmedleyericmedley Posts: 4,177
    I suppose I'll bite...

    Is there a reason your not choosing to use an rs232 port? If you're out, you might consider hitting ebay and getting an old AXB-232 box. It'll do fine and you can get feedback back to your master.

    Just a thought...
  • ROOROO Posts: 46
    ericmedley wrote: »
    I suppose I'll bite...

    Is there a reason your not choosing to use an rs232 port? If you're out, you might consider hitting ebay and getting an old AXB-232 box. It'll do fine and you can get feedback back to your master.

    Just a thought...

    Hi Eric,
    Sorry for not including the information. We have a secure/ non-secure environment and they wanted to make sure that we aren't getting secure information back from the Tandberg into the Netlinx (keeping the cross-over of secure and Non-secure information completely separate). We chose to use the IR controls since it's a one-way transmition, and there isn't any doubt of cross-contamination. I do have the RS232 ports available, so life would be much simpler. They just don't want me to have an easy day!
    ROO
  • Joe HebertJoe Hebert Posts: 2,159
    ROO wrote: »
    We have a secure/ non-secure environment and they wanted to make sure that we aren't getting secure information back from the Tandberg into the Netlinx (keeping the cross-over of secure and Non-secure information completely separate). We chose to use the IR controls since it's a one-way transmition, and there isn't any doubt of cross-contamination. I do have the RS232 ports available, so life would be much simpler.
    RS-232 is also one-way if you only use 2 wires.
  • ROOROO Posts: 46
    Joe Hebert wrote: »
    RS-232 is also one-way if you only use 2 wires.

    That's a better option then trying to prove the program isn't looking at the data, but we'd still end up needing to prove it. The system designer wanted to eliminate the question all together, since the Netlinx states it's a one-way communications. At least I'll have a fall-back position if I can't resolve the IR communications issue, so I appreciate the input. Our designer likely broached this approach, but I hadn't thought of it. Thanks.

    So the question is still, are there any differences between the IR and RS232 transmitions? Limitations I should avoid?...

    Thanks
    ROO
  • Joe HebertJoe Hebert Posts: 2,159
    ROO wrote:
    That's a better option then trying to prove the program isn't looking at the data, but we'd still end up needing to prove it. The system designer wanted to eliminate the question all together
    If there is no wire physically connected to the receive pin of the RS-232 port then it?s impossible to receive data. Physics and the Laws of Nature will back you up.
    ROO wrote:
    So the question is still, are there any differences between the IR and RS232 transmitions? Limitations I should avoid?...
    Sorry, can?t help you there. I?ve never driven down that road so I don?t know what (if any) potholes there are.
  • Joe HebertJoe Hebert Posts: 2,159
    ROO wrote:
    Line 41 (16:51:52.953):: String To [5001:9:1]-[xcommand pipshow virtualmonitor: 1 picture: localmain position: ]
    Line 42 (16:51:52.953):: String To [5001:9:1]-[Top Right$0D]

    1) It appears that the string is sent in 2 chuncks, and I just wanted to know if it's really going out like this or if it's just a Notification quirk?
    I believe it?s really going out like that as two separate transmissions and that really shouldn?t matter to the device on the other end since it?s just waiting to see the carriage return. If I?m counting correctly Line 41 shows 64 characters sent which may be the max length for that device in that mode. Tech note 156 http://amx.com/techsupport/techNote.asp?id=156 shows 64 bytes as the max for most of the serial devices.
    ROO wrote:
    2) The same command works from a RS232 port just fine, but the IR port isn't. Also other commands I send to the port work fine.

    Too verify that both strings are really getting sent, I suggest that you disconnect the cable that is plugged into Tandberg and plug it into your laptop (you may need a null modem adaptor) and verify that the entire message is sent. If you only see the first string then I suggest you break up the command as two separate SEND_STRINGs and see where that gets you.

    HTH
  • IR vs. RS232 port
    ROO wrote: »
    So the question is still, are there any differences between the IR and RS232 transmitions? Limitations I should avoid?...
    ROO

    Without getting too technical, there are electrical differences between the RS232 port and a serial configruration of an IR port. Successful use depends on the port sensitivity of the controlled component.

    Good advice would be to always test compatibility before using in an actual installation.
  • ROOROO Posts: 46
    B_Clements wrote: »
    Without getting too technical, their are electrical differences between the RS232 port and a serial configruration of an IR port. Successful use depends on the port sensitivity of the controlled component.

    Good advice would be to always test compatibility before using in an actual installation.

    Actually at this point - a good technical explaination would be great. As I've said, the IR port works great for all the xcommand and xconfiguration command I've been using, except the one I originally posted. The command the I posted, has also been sent to another Tandberg over a RS232 line, without issue. I've implemented all the Tandberg remote commands plus a coupld dozen that I needed that weren't on the remote, so I was surprised when this one didn't work over the IR port.

    The 2 variables in the equation are: 1) different Tandberg, - The Tandberg I was controlling is connected to a secure line 2) We're controlling the IR port as an RS232 versus just using the RS232. I won't have access to another Tandberg for a couple of weeks, so I was hoping to find eliminate the 2nd variable (IR port).

    If IR data transmission is the same as the RS232 in operation, then #1 is my issue. If not, and I can change the program to fix my mistaken assumption, that would be great. The length of the string may be a problem for the IR port, (like Eric suggested), so I might need to break up the line, and send it in 2 chunks. I just hate not having the answer...:^(

    Regards
    ROO
  • IR vs. RS232 port, part 2
    ROO wrote: »
    Actually at this point - a good technical explaination would be great...
    ROO
    Okay, I will make an attempt, but it would be much better to show you on an oscilloscope.

    For IR think of the electrical signal needed to turn an LED on and off. Of course IR does not produce visible light so we can?t really see its output without some sort of detector. All things being equal, data, whether RS232 or IR is represented by a series of zeros and ones (the term serial data) switching extremely fast between zero (LED off) and one (LED on.)

    With IR data you electrically need a voltage of approximately 3.5-5 volts to turn the LED on (one) and 0 volts to turn the LED off (zero.) This voltage is in reference to ground or the negative terminal on the IR output port.

    With RS232 data you electrically need a voltage difference of approximately 10-15 volts to produce the same on and off condition of a one and zero. The big difference is that an off (zero) is approximately -7 volts when referenced to ground and on (one) is approximately +7 volts when referenced to ground. (It has been awhile so I could have this backwards.)

    Unfortunately, the voltage swings are so fast that you cannot see the changes with a standard voltage meter. An oscilloscope or data monitor comes in really handy at this point.

    Again, the receiving component RS232 receive pin may be sensitive enough to decode a data stream with just a 5 volt swing and many, but not all do.

    If all of this goes over your head, no problem. The best thing to do is attend a basic digital electronics class.

    PS. If I had some pictures, this would make a good tech note.
  • ROOROO Posts: 46
    B_Clements wrote: »
    Okay, I will make an attempt, but it would be much better to show you on an oscilloscope.

    For IR think of the electrical signal needed to turn an LED on and off. Of course IR does not produce visible light so we can?t really see its output without some sort of detector. All things being equal, data, whether RS232 or IR is represented by a series of zeros and ones (the term serial data) switching extremely fast between zero (LED off) and one (LED on.)

    With IR data you electrically need a voltage of approximately 3.5-5 volts to turn the LED on (one) and 0 volts to turn the LED off (zero.) This voltage is in reference to ground or the negative terminal on the IR output port.

    With RS232 data you electrically need a voltage difference of approximately 10-15 volts to produce the same on and off condition of a one and zero. The big difference is that an off (zero) is approximately -7 volts when referenced to ground and on (one) is approximately +7 volts when referenced to ground. (It has been awhile so I could have this backwards.)

    Unfortunately, the voltage swings are so fast that you cannot see the changes with a standard voltage meter. An oscilloscope or data monitor comes in really handy at this point.

    Again, the receiving component RS232 receive pin may be sensitive enough to decode a data stream with just a 5 volt swing and many, but not all do.

    If all of this goes over your head, no problem. The best thing to do is attend a basic digital electronics class.

    PS. If I had some pictures, this would make a good tech note.

    IR waveforms can be displayed in IREdit - with VIEW--> WAVEFORM (Cntrl-W) and you get additional information on the Carrier Frequency, pulse time etc. It is a very handy tool for dealing with IR files, and transmition of IR file data. IREdit is an excellent tool, and ability to activate a pulse or verify an IR file on the Netlinx is hard to beat for those of you that haven't used it much.

    http://en.wikipedia.org/wiki/RS232 - has a good electrical descritpion of the RS232 spec, and gives several waveform examples if anyone is intersted. It's been around as long as I have...:^)

    The voltage level differences would affect the distances and speed that a device is operate. Voltage drops across a long lines can cause really strange results. Keeping the distances between the Netlinx and the EUT within the spec helps insure that voltage drops and noise levels don't affect the transmission of the signals. Since my issue was only with one command, and many others are working at a relatively low transmition speed (9600 baud) and short distances, I just don't expect voltage drops to be an issue.

    I'll give Joe's suggestion a try when I get the device in. It's likely that I'm working down the wrong path given the feedback I've gotten. I'll post here if the length of string solves the problem.
    Thanks for all your input!

    ROO
  • ROO wrote: »
    Hi Eric,
    Sorry for not including the information. We have a secure/ non-secure environment and they wanted to make sure that we aren't getting secure information back from the Tandberg into the Netlinx (keeping the cross-over of secure and Non-secure information completely separate). We chose to use the IR controls since it's a one-way transmition, and there isn't any doubt of cross-contamination. I do have the RS232 ports available, so life would be much simpler. They just don't want me to have an easy day!
    ROO

    Is that a local rule? I work in secure environments as well and I control all of my Tandbergs serially.
  • ROOROO Posts: 46
    No this isn't a local policy.
    Is that a local rule? I work in secure environments as well and I control all of my Tandbergs serially.

    This isn't a local policy. In secure environments equipment with storage capabilities that connect to a secure network, are controlled to that level of security. The STIG (DISA Video Tele-Conference Security Technical Implementation Guide) and other documents that may apply were developed by DISA for the DoD and is the authority, so please refer to it for your situation. http://iase.disa.mil/stigs/stig.

    A Tandberg that connects to a secure network obtains the security level of the connection. Since a Netlinx RS232 port can obtain the secure information from the Tandberg through the RS232 connection, the Netlinx also obtains the security. That is all well and good as long as the equipment remains in that classification. If the intent is to utilize the controller in Classified and Unclassified situations, then we have a potential issue.

    Example: In the case of a PC that is connected to the SIPRNET (Classified network), the PC?s classification is classified, and it can?t be reconnected to the NIPRNET (unclassified network), without being cleansed of potential classified information. To resolve the issue, most people have separate NIPR and SIPR computers that stay on their designated networks.

    In the case of a TANDBERG, and therefore Netlinx, the same situation exists. In our design, the Tandberg is treated just like the PCs in my example, and remain on the SIPR/NIPR they are assigned.
    If we eliminate the Netlinx from receiving any information from the classified TANDBERG, then the control system has no issues changing classification environments since it can?t obtain the classified information maintained in the CODEC. So our choice to use IR communications insures it by design.

    The Designated Approval Authority (DAA) ultimately needs to evaluate the risks, and make the determination for approval of a system. The better they understand the issues, the better they do their jobs. The better we understand the requirements, the less problems we?ll have, with them doing a good job.

    Other approaches are also out there, but we found this to be best for our customers. What is everyone else doing in this realm?

    ROO

    BTW: My FSO wrote me back with a more complete response that I?d be glad to share if anyone is interested. Just send me a note, and I?ll send it to you..
Sign In or Register to comment.