Options
Interesting Serial port behavior
Darkside
Posts: 345
in AMX Hardware
We have now seen the following issue on 4 different sites, with different gear connected and in two instances, different cable types.
I went to site recently to commence code implementation and debug, and after I dumped the rev in, I started looking at the ports for responses from the various serial devices to help the site guys debug. Generally, no RX is a sign of a crossed cable...etc etc.
Well, in this latest situation, the code was polling the devices, however the two sony vps were not installed yet, but the RX light illuminated at every poll. I was on to it and suggested to the site guys that there could be a short in the cable somewhere...perhaps a solder dag on the connector.
The cable was checked, and there was no dag, no short at all. This cable, a 2 core shield was as clean as you like and every conductor tested to itself, and tested to each other for continuity. Clear.
So.
I started looking at the port and discovered a garbled version of the polling packet in the buffer.
Why is it so?.
I took that field cable and stuck it on a serial port assigned to the lightnig network, and the port behaved the same way.
So it is surely related to the cable...
Well, we have used this cable for years and have not had this problem.
Once the projectors were installed and the cable connected, the junk on the RX side stopped. This must have been due to loading of the port or grounding - although the vp was physically off.
The code runs the vp properly, so it is clearly related to the length/impedance of the cable, but why are the ports apparently so sensitive now?
In the studio, I built a 10m serial cable from the same stock and connected it to an NXI running the code from the site above. Nothing to be seen in the RX buffer - as expected.
I took this cable and connected it to an NI3000 and dumped the same code again to keep the test even, and the port behaves the same as it did on site on the NI4100. Junk all over the RX buffer.
Has anyone else seen this behavior?
I went to site recently to commence code implementation and debug, and after I dumped the rev in, I started looking at the ports for responses from the various serial devices to help the site guys debug. Generally, no RX is a sign of a crossed cable...etc etc.
Well, in this latest situation, the code was polling the devices, however the two sony vps were not installed yet, but the RX light illuminated at every poll. I was on to it and suggested to the site guys that there could be a short in the cable somewhere...perhaps a solder dag on the connector.
The cable was checked, and there was no dag, no short at all. This cable, a 2 core shield was as clean as you like and every conductor tested to itself, and tested to each other for continuity. Clear.
So.
I started looking at the port and discovered a garbled version of the polling packet in the buffer.
Why is it so?.
I took that field cable and stuck it on a serial port assigned to the lightnig network, and the port behaved the same way.
So it is surely related to the cable...
Well, we have used this cable for years and have not had this problem.
Once the projectors were installed and the cable connected, the junk on the RX side stopped. This must have been due to loading of the port or grounding - although the vp was physically off.
The code runs the vp properly, so it is clearly related to the length/impedance of the cable, but why are the ports apparently so sensitive now?
In the studio, I built a 10m serial cable from the same stock and connected it to an NXI running the code from the site above. Nothing to be seen in the RX buffer - as expected.
I took this cable and connected it to an NI3000 and dumped the same code again to keep the test even, and the port behaves the same as it did on site on the NI4100. Junk all over the RX buffer.
Has anyone else seen this behavior?
0
Comments
I made a change in the spec and asked that they start using shielded three conuctor. (It's actually installer grade audio microphone wire - 2 cond w/shield drain) They hate the stuff. It's much harder to pull. I find that using twisted pair doesn't provide enough noise shielding over long runs.
I credit this move to the fact that I can run Lutorn HomeWorks at 115Kbaud.
You didn't specify which wire you're using. However, I do find using CAT5 for serial runs to be pretty common. I've scoped a long run of CAT5 connected to serial ports and found that the noise levels can get pretty high at times. I haven't scoped the 2cond w/shield but I do notice a marked differnce in performance on higher baud rate stuff when we use the shielded wire.
Obviously, you have to get more conductors if the serial port requires more than GND,TX and RX. but the principle is still the same: X number of conductors and a shield.
While trying to figure out why I had no control of the projector I realised that what I was getting back resembled what I was sending out. When I got one of the installers to check whether there was a short at the projector end it turned out that the cable wasn't plugged in.
As in your case, once the cable was plugged in the behaviour disappeared.
I've had quite a few serial port issues in the last few months and they have been driving me nuts. For example, I had a Fujitsu plasma to which I could get no commas at all, when connected on a COM2 card in a NI4100. As soon as it was move to one of the main ports, it worked straight away - no one can give a reason why. I have also had situations where the outgoing string from the port is OK, but the return string can't be read; almost as though the baud rate on incoming and outgoing are different - really bizarre!
Most of the issues seem to be related to COM2 cards in combination with NI4100 controllers and it usually occurs with baud rates that have even or odd parity.
However, I can't say that I have seen the problem that you have had. So I guess this just digs a bigger hole. I must say, however, that this issue did not exist on the NI4000 units so it is something that has been introduced within the new designs and the issue is not consistent, it is random. Some units work fine, others most certainly do not!
There is inductive coupling between the TX and RX wires that are right next to each other inside the jacket. The pair of wires are acting as a tranformer of sorts. Because the AMX side RX wire is unterminated, the impedance of the line is very high, thus the very small amount of current that induces across the wires is able to maintain a high enough voltage to open the AMX receiver. By connecting the RX wire at at your device, the line is now terminted to a much lower impedance and the very small amount of current has somewhere to go and the voltage never develops.
To verify this, set up your long cable again. At the device end, put a 120 ohm resistor between ground at your device's TX (AMX RX) and I'll bet the garbage goes away.
Since this has been happening, I have spoke to some of my clients who run cables and install the gear and have pleaded with them to use a twisted shielded pair instead of the CAT5. The RS232 spec calls for a shield, and as it is an unbalanced signal, it is critically important that it has one. I guess the only thing going for the CAT5 is its twist ratio - as far as noise immunity goes.
Why this behavior is appearing lately I can only assume is related to the port design.
It has made me very wary when commissioning - tx and rx flashing used to be a great sign when you started, but now it may not necessarily be so!
Turniptruck, placing a 120R across I am certian, too, will tidy it up - for exactly the reasons you have explained...but I still wonder if the pcb revs have changed some of the spec to now cause this.
~~~~~~~~~
Perhaps partly related to this port issue, I was recently involved in a job using a Sanyo projector on a 4100, and I received no response from the polling sequence. It was responding to power and switching commands - but no response from the unit on the AMX serial port.
The cable - a 2 x twisted shielded pair in a single jacket was used (one tsp not used), and it was buzzed out for continuity. It was fine. This install used my Sanyo module which is installed now in plenty of places, and therefore I had absolutely no reason to suspect it was a code problem.
I tore my hair out completely. Faulty projector perhaps?
I then got laptop 2, and plugged up to the projector using the same cable now pulled out of the AMX serial port. Hyperterminal made it run, and there were responses. OK, so the vp is alive.
So. This had to be a cable/AMX port issue. The cable used was a Belden 2 x twisted shielded pair in one jacket. Foil and drain wire. 24AWG I think. I would consider it a good cable - although it is not what we normally use.
As a totally last resort, I got the site guys to double up the TX and RX using the spare conductors, plugged it up to the AMX and sure enough, full coms was established.
Maybe this is related to the serial port technical architecture also? Different drive/sensitivity specs than earlier devices perhaps?
Could it be that the V out from the port has been reduced to save on power consumption or maybe a different UART? May pay for someone to measure this with a CRO on an Axcent vs Netlinx and see if there is any difference.