Your Universal Remote Control Center
RemoteCentral.com
Philips Pronto Professional Forum - View Post
Previous section Next section Up level
Up level
The following page was printed from RemoteCentral.com:

Login:
Pass:
 
 

Topic:
RFX9600 serial port 4
This thread has 14 replies. Displaying all posts.
Post 1 made on Monday March 15, 2010 at 05:14
brasch
Long Time Member
Joined:
Posts:
December 2008
87
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?
Post 2 made on Monday March 15, 2010 at 14:03
BluPhenix
Long Time Member
Joined:
Posts:
December 2008
371
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.
Post 3 made on Monday March 15, 2010 at 20:43
Lyndel McGee
RC Moderator
Joined:
Posts:
August 2001
12,764
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.
Lyndel McGee
Philips Pronto Addict/Beta Tester
Post 4 made on Tuesday March 16, 2010 at 13:48
BluPhenix
Long Time Member
Joined:
Posts:
December 2008
371
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 ...
Post 5 made on Tuesday March 16, 2010 at 20:14
pnnielsen
Long Time Member
Joined:
Posts:
February 2010
37
On March 15, 2010 at 20:43, Lyndel McGee said...
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! 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
Post 6 made on Tuesday March 16, 2010 at 21:25
Lyndel McGee
RC Moderator
Joined:
Posts:
August 2001
12,764
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.

Last edited by Lyndel McGee on March 17, 2010 01:35.
Lyndel McGee
Philips Pronto Addict/Beta Tester
Post 7 made on Tuesday March 16, 2010 at 21:26
Lyndel McGee
RC Moderator
Joined:
Posts:
August 2001
12,764
On March 16, 2010 at 13:48, BluPhenix said...
Wow, Lyndel, is that about port 4 right?

Yes.
Lyndel McGee
Philips Pronto Addict/Beta Tester
Post 8 made on Wednesday March 17, 2010 at 01:27
Barry Gordon
Founding Member
Joined:
Posts:
August 2001
2,153
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
Post 9 made on Wednesday March 17, 2010 at 11:16
pnnielsen
Long Time Member
Joined:
Posts:
February 2010
37
On March 16, 2010 at 21:25, Lyndel McGee said...
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.

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!
Post 10 made on Wednesday March 17, 2010 at 11:35
BluPhenix
Long Time Member
Joined:
Posts:
December 2008
371
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.
Post 11 made on Thursday March 18, 2010 at 02:25
Lyndel McGee
RC Moderator
Joined:
Posts:
August 2001
12,764
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]
Lyndel McGee
Philips Pronto Addict/Beta Tester
Post 12 made on Thursday March 18, 2010 at 11:32
Barry Gordon
Founding Member
Joined:
Posts:
August 2001
2,153
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.
Post 13 made on Thursday March 18, 2010 at 12:01
BluPhenix
Long Time Member
Joined:
Posts:
December 2008
371
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.
Post 14 made on Thursday March 18, 2010 at 20:53
pnnielsen
Long Time Member
Joined:
Posts:
February 2010
37
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.

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.
Post 15 made on Thursday March 18, 2010 at 23:03
Lyndel McGee
RC Moderator
Joined:
Posts:
August 2001
12,764
No problem. Did not know if you were aware of this behavior.
Lyndel McGee
Philips Pronto Addict/Beta Tester


Jump to


Protected Feature Before you can reply to a message...
You must first register for a Remote Central user account - it's fast and free! Or, if you already have an account, please login now.

Please read the following: Unsolicited commercial advertisements are absolutely not permitted on this forum. Other private buy & sell messages should be posted to our Marketplace. For information on how to advertise your service or product click here. Remote Central reserves the right to remove or modify any post that is deemed inappropriate.

Hosting Services by ipHouse