I need to connect all 4 serial ports on my RFX. Port 4 will be connected to a Toshiba HD-XE1 HD DVD player. From what I understand it need pins 2, 3 and 5 to work. I just opened the cable I used for testing the codes on another port with the player and I see that pin 5 isn't connected inside the cable. Does that mean I don't have to connect the ground for it to work?

Isn't connected? Strange.

It usually servers as a ground, or more as a screen schield. If you have very long lines of serial cable, absolutely use all of the thre pins.

BluPhenix's approach is correct. You will need to connect shield to the cable that would normally be connected to RFX9600 DB9-Pin5 or Phoenix Connector Pin3 (3 is ground IIRC).

If you are planning on using both Ports 3 and 4, you should be aware of this:

[Link: remotecentral.com]

Search this forum for UART for more hits.

Wow, Lyndel, is that about port 4 right?

Damn i'm using all 4 of the ports in an installation and I'm having some minor problems with the plasma connected to the 4th port. The problem is that i need 4 full 2-was ports. Oh well ... damn it.

I must say this is strange. Well, then i should complete my rs232 expander (1 > 1 to n serial ports) as soon as possible ...

Wow! Very useful info.

I've noticed another oddity: When doing 2-way communication, the RFX9600 seems to be very "slow" when it comes to receiving data. I'm using a 57400 connection. The pre-pro I'm using (TacT TCS Mk III) has an RS-232 command for emulating a prolonged press of volume up/down (i.e. repeat) so that the volume can be raised/lowered the same way as over IR. Interestingly TacT has implemented this for the "inexperienced programmer", so the way it works is the processor delays responding to the send until it's ready for the next repeat. Anyway, the process of incrementing volume from 0 to 100 takes 20 seconds on the Pronto. On a PC (and via IR) it takes only 15 seconds. I have implemented my own "replica" of the TacT algorithm that only sends data, and it's able to do the job right. However, I'm puzzled why the receives are so sluggish and why a PC can do it right....

Lyndel, do you have any experience/insight in slow data reception of the 9600? (i.e. the time between when data is received on the port to the time it takes for the "receive" command to see the data. I've tried both regular expressions and simply wait for number of bytes received, and both are just as slow).

Thanks,
Peter

Peter,

I've done some timings of serial.receive() in the past.
For me, each round-trip to poll for received data takes approximately 40 milliseconds (you should add your own logging to test the timing). It is the nature of the beast. Also, serial.send/match is explicit and sends string every time. Whereas, a repeating one-way 232 action, I suspect,(you'll need to do testing with Wireshark) sends the first string down and then for repeat, says repeat last string sent (latch repeat) until I tell you not to do so. Then, when button is released, the latch repeat is cancelled.

Your advanced algorithm is likley the only way to make the ramp on RFX as fast as it is on the PC.

Yes.

The cable shield only has to be connected at one end point to ground for it to act as a zero potential shield. There must however by a ground path for the signal. In many RS232 systems the shell which is often connected to the cable shield is also connected to ground at each end. That is actually a bad practice as it can introduce loops and noise.

The proper (best) practice IIRC is the shield is connected only at one end, and the signal ground is connected at both ends (pin 5) and not connected to the shield. This isolates the signal ground from the chassis which is often connected to the connector shell.

When I build an RS232 cable I use cat5 wire with RJ45 to DB9 adapters. In that situation there is no shield, the shells are not connected together, and there is a true signal ground between the two devices. The component should manage multiple ground returns from multiple connectors correctly. A shielded cable has more capacitance per running foot than an unshielded cable, hence it causes more signal degradation while supplying greater noise immunity.

All of the above is academic as I have never used an RFX unit. It is correct from an electronic circuit perspective if I remember my electrical engineering AC circuit courses

That's probably it. While 40ms does not sound too bad per se, it will add up. If 100 command pairs are transferred in 15 seconds this actually adds a whole 4 seconds, so it sure sounds like this is exactly what I'm seeing. I will add some logging to see exactly how much data is transferred to be sure...

Any way, thanks for the 40ms figure. Very good info!

Barry, using CAT5 cable is quite common practice for RS232. However an absence of shield can be critical in some cases, ie. when you can not avoit of running signal and communication cables side by side on a long distance. RS-232 works with 10V levels, and can induce quite some unwanted noise currents in paralel signal cabling.

pnnielsen, maybe the communication was too fast, and data got lost. RS232 (at least in my experience) is transmitted rarely at higher speeds than 19200 baud (which is the official standard upper speed). Those higher baud rates were developed for modems etc, and are not really standard.

Peter,

This could also be the cause of some of your issues as well. What you may think is slow response/garbled data may be caused by fact that Serial Communications on RFX9600 with current ProntoScript implementation has a limitation. You cannot send without clearing the receive buffer on the UART.

See this post please.

[Link: remotecentral.com]

BluPhenix, In thoery I agree with you but in practice my experience is quite different. As long as the RS232 speed is 56K or less I have never seen issues with noise pickup using unshielded cable. As a common practice I have run phone and LAN in the same cat 5 cable (100 base T service) and suspect I could have run LAN and RS232 with no issues but have never had a need to do so. I have run LAN and IR many many times with no issues and IR runs a ~40khz carrier at 5-12 volts.

Barry, I was talking more about audio signals of low amplitude (like PC's or MP3 players output). We've had slight problems sometimes, when the rs-232 communication was really intensive. The problem was: no whielding in rs-232 comm, and (we found out later) low quality coaxial sudio cables, made in china, which instead of a shield had just a couple of shielding copper hairs runninr along the signal wire.

With LAN networks it can be tricky to notice if the signal has been altered, as TCP/IP has data integrity check/management integrated in the protocol.

But my practical experience has to mostly agree with you, it's just that sometimes you hit a brick wall, and you can't get around it for some time, until you discover that you had crosstalk/induction problems.But i agree CAT5 is excellent for running rs-232, for moderate distancies.

I'm aware of that limitation, and I'm pretty convinced this is not the issue. After I do one send, I asynchronously wait for a full and complete response before I do the next send. I have tried with the timeout set to 5000 (5 seconds), so I know I am receiving all data. (If I were to lose data, the extreme timeout would make the dropouts obvious and easy humanly noticeable). I have also tried doing synchronous communication, but the result is the same.

No problem. Did not know if you were aware of this behavior.