SVSI Experiences
Danny Campbell
Posts: 311
in AMX Hardware
I wanted to relate my experiences with a recent project that used 10 SVSI encoders, 3 decoders, and a windows processor. This was a remote support job where I developed the code offsite and then worked with the integrator?s techs via a remote-control program.
The firmware on each of the devices had been updated to the current production versions as of mid-August 2017. Everything was configured to work in NetLinx mode, IP addresses were all static, Device IDs were unique, and the Stream IDs were all static as well.
The first issue that I found was with the NMX-DEC-N1211 decoder. The Netlinx commands for selecting the stream to decode worked as advertised. One of the three decoders in use was feeding the projector and I tried to pass the RS-232 control commands to the projector through the decoder. My understanding was that a NetLinx SEND_STRING command would pass through everything through the serial port that in this case was defined as 8100:3:1. This did not work. At first, we assumed that it was some setting that we missed with the Epson projector. We could not find any setting that were wrong. Next, I connected TX and RX on the back of the decoder to each other and could see a send and receive with each NetLinx command that I sent. I connected the laptop directly to the projector and had control. We finally decided to just run a serial cable back to the NX-2200 and are now controlling the projector from the NX-2200.
The second issue was with the window processor. This is the NMX-WP-N1512. Again, the standard stream control commands "CO", "CI", and "CA" all worked well. Trying to send the preset string using the SEND_STRING passthrough commands that we discussed below did not work at all. After fighting with this for most of a day, I finally decided to open an IP connection using port 50002 to the device and sending the strings that way. For some reason, I had decided that the preset command just would not work and used the log entry from the web interface to capture all of the commands shown and convert them to NetLinx SEND_STRING commands via IP. This naturally worked like a champ. After doing this for both layouts I had a good night's sleep and decided that this was probably wasted time and I should try the preset commands. As expected sending the preset command to the device vie IP works well.
One thing that I did not like about recalling the preset was that the preset creation process saves a stream number as the source for each window. I didn?t have a lot of time to play with N-Able to see if this could be defeated or if it would accept 0 as the stream number. Since I wanted to allow the user to select from the 10 available input streams to use in the four windows, I edited the commands that I captured from the N-Able logs and did not select the source streams when I built the layout. Since I wasn?t there to see what was happening on the screen I just stuck with the build-on-the-fly method of getting the windows on the screen. The system only required that I have a two and four window layout for the window processor. For full screen I just grab the stream directly at the projector?s decoder.
So both devices show the same kind of behavior. The commands shown in the documentation addendum file as Native Port 1 commands work properly. The passthrough commands do not work for me. This included trying to send device control commands through the on-board serial port to the projector for the decoder and sending passthrough commands to the port 1 device for layout control on the window processor.
I see the cause of this as one of three things. 1. The passthrough commands just do not work. 2. I did not understand the documentation. Or 3. I understood the documentation and it is wrong.
The firmware on each of the devices had been updated to the current production versions as of mid-August 2017. Everything was configured to work in NetLinx mode, IP addresses were all static, Device IDs were unique, and the Stream IDs were all static as well.
The first issue that I found was with the NMX-DEC-N1211 decoder. The Netlinx commands for selecting the stream to decode worked as advertised. One of the three decoders in use was feeding the projector and I tried to pass the RS-232 control commands to the projector through the decoder. My understanding was that a NetLinx SEND_STRING command would pass through everything through the serial port that in this case was defined as 8100:3:1. This did not work. At first, we assumed that it was some setting that we missed with the Epson projector. We could not find any setting that were wrong. Next, I connected TX and RX on the back of the decoder to each other and could see a send and receive with each NetLinx command that I sent. I connected the laptop directly to the projector and had control. We finally decided to just run a serial cable back to the NX-2200 and are now controlling the projector from the NX-2200.
The second issue was with the window processor. This is the NMX-WP-N1512. Again, the standard stream control commands "CO", "CI", and "CA" all worked well. Trying to send the preset string using the SEND_STRING passthrough commands that we discussed below did not work at all. After fighting with this for most of a day, I finally decided to open an IP connection using port 50002 to the device and sending the strings that way. For some reason, I had decided that the preset command just would not work and used the log entry from the web interface to capture all of the commands shown and convert them to NetLinx SEND_STRING commands via IP. This naturally worked like a champ. After doing this for both layouts I had a good night's sleep and decided that this was probably wasted time and I should try the preset commands. As expected sending the preset command to the device vie IP works well.
One thing that I did not like about recalling the preset was that the preset creation process saves a stream number as the source for each window. I didn?t have a lot of time to play with N-Able to see if this could be defeated or if it would accept 0 as the stream number. Since I wanted to allow the user to select from the 10 available input streams to use in the four windows, I edited the commands that I captured from the N-Able logs and did not select the source streams when I built the layout. Since I wasn?t there to see what was happening on the screen I just stuck with the build-on-the-fly method of getting the windows on the screen. The system only required that I have a two and four window layout for the window processor. For full screen I just grab the stream directly at the projector?s decoder.
So both devices show the same kind of behavior. The commands shown in the documentation addendum file as Native Port 1 commands work properly. The passthrough commands do not work for me. This included trying to send device control commands through the on-board serial port to the projector for the decoder and sending passthrough commands to the port 1 device for layout control on the window processor.
I see the cause of this as one of three things. 1. The passthrough commands just do not work. 2. I did not understand the documentation. Or 3. I understood the documentation and it is wrong.
0
Comments
I have used it a lot and the serial part worked for me, I used my own modules and they work to the serial port of a SVSI decoder the same as to a processor port so not sure why it was not working for you.
I have also used the pass-thru command on SVSI decoders/encoders ( but not the window processor) on multiple systems with no problems either. One thing to check is that is case sensitive and needs to as the following: SEND_STRING dev,'preset:1'
It sounds like it was what you were doing so unsure... but just thought i would let you know that I have had it working.
Cheers Rob
I can pile on the conversation about issues with the way SVSi chooses to set up their network, however. This issue has occured at every single site I've worked on since starting with it. I 'get' why SVSi chooses to just let all the boxes come up on the network local host (for those who may not know - the boxes are setup DHCP but the network they run on deliberately has no DHCP server. So the boxes give themselves a random 169.254.xxx.xxx address with a subnet mask of 255.255.0.0 So, the IP address of the box is not important as they all run around and look for each other and find themselves.) and all that. But, in each case I've been in installs where they have a pretty tight lock on their network for security - I spend an awful lot of time dealing with confused and angry IT people who don't like the idea of boxes sitting on the network this way, even if it's not their network. I think AMX m ight be missing a little item that in many cases just throwing up your hands and saying the networks aren't connected is not enough to satisfy the networking people. They don't like the idea of switches in racks they know nothing about. And no amount of me explaining their rationale of choosing a completely unmanaged ad hoc network calms them down.
The obvious major issues for why SVSi doesn't live on the corporate network are bandwidth and the need to deal with routing between network segments and all that. I don't relish the idea of dealing with that either and have enough of it already with large AMX control systems on corporate/govt/military networks. But at least there is eventually a somewhat cautious cease fire that settles over the situation once you get through it. With the SVSi rig I still get calls about some such thing happinging that goofed everything up when a technician plugged something into on of the switches meant for AV and if ONLY they had been able to manage the switch THEY could have figured it out in minutes instead of hours, blah blah blah.
I'm not saying there is anything wrong with the way SVSi does things on a micro scale. In fact, it's obviously the best way. But on a larger scale its kind of an outlier. Not to mention that when you do need to get on the corporate network as well as the SVSi network (I have a situation with lots of Enzos and Click-Shares connected directly to the TVs and the same Netlinx master needs to talk to them plus an SVSi box for AV switching. The corporate people want zero connection between the networks. So I've had to create a serial interface between two MX masters for communication across them.)
This bug seemed to occur in about 4 or 5 of the 30 decoders being used in the job, and I only had to do this trick once to reset them. It may have been a bug that happens only right after updating the firmware, since that was the previous thing we did before this problem happened.