IR - Serial data - Netlinx Studio reporting question
ROO
Posts: 46
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?
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?
0
Comments
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.
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.
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.
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
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
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
Sorry, can?t help you there. I?ve never driven down that road so I don?t know what (if any) potholes there are.
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
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.
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
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
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..