Your Universal Remote Control Center
Philips Pronto Professional Forum - View Post
Up level
Up level
The following page was printed from


Original thread:
Post 3 made on Wednesday September 22, 2010 at 21:29
Lyndel McGee
RC Moderator
August 2001
Yes, the command protocol is the same for either 232 or for TCP/IP.

It is the asynchronous coding that differs. For 232, you will be doing serial.send/serial.match() and supporting async data in OnData callback of serial port.

For TCP/IP, you will be doing TCP.send and then getting data in the OnData call.

Note that with 232 OnData callback, you are passed a parameter with the data. for TCP OnData callback, you must call inside from inside the callback function to pull data from the socket.

WARNING - Caveat Emptor

232 via RFX9600 is not truly full-duplex in that each send/match clears any existing data that might be in the UART's receive buffer. This becomes VERY problematic when doing channel volumes.

It is for this exact reason that most of us programming custom modules steer clear of any type of 232 programming where equipment can send multi-line response or sends asynchronous messages as to handle this, you code must be smart enough to receive/match multiple lines and know when it is safe to send command. You do not have this specific issue with TCP/IP.

Channel Volume example:

You send:
CVC 50\r to set Center volume to 0db

Denon will return a multi-line response containing levels of ALL channels. So, if you are using match and send another command immediately after processing the first response line, you can potentially corrupt the remaining data in the buffer such that you might see:

CVFL 54\r (match returns this value)
CVFR 54\r (Denon continues sending)
CVmissing character54\r (Denon was sending the 'C' which was removed from buffer as you sent next command of MV?\r)

This has been discussed several times in this forum. If you'd like to read more about this, search for UART.

The other thing to be aware of is that ONLY 1 remote can connect to Denon AVR via TCP/IP at any time. Other connections will be refused.

You should also write your code such that you await a response from the Denon otherwise, you can blow the TCP/IP stack on the Denon and then have to hard reset the unit. The time specifications such as wait 7 seconds after sending PWON should be honored as well as the wait of 150/200ms after sending a command prior to sending next one. However, if the Denon is in the process of sending a response, you can likely safely send the command.

Note that there is a free version of a Denon TCP module designed for TSU9400 available from
Lyndel McGee
Philips Pronto Addict/Beta Tester

Hosting Services by ipHouse