 |
QUESTIONS:
1) Why don't I get a serial port response?
2) How should I set the port settings for proper operation?
3) Why do I get inconsistent operation or only certain commands work?
4) How do I send a proper command when checksums are required?
5) What type of serial cable should be used?
QUESTIONS AND ANSWERS:
1) Why don't I get a serial port response?
RS-232C connections are sometimes overlooked as the cause of basic communication failure. The standard pins of 2=TxD, 3=RxD and 5 for signal common (S-GND) are used on our products. However pin 1 main ground (GND) is sometimes overlooked and may also need to be connected to the D-Sub 9's outer shield so that a complete main ground (GND) is established between the two products being connected.
back to top
2) How should I set the port settings for proper operation?
The protocol manual for any device should always be checked for exact port setup. Unless otherwise specified in our protocol documents for consumer home audio products, the basic RS-232C port setup is:
- Communication System = Half-duplex communication
- Synchronous System / Data Transfer Mode = Tone Step Synchronization (AVR) Start Stop Synchronization (DVD)
- Transfer Rate = 9600bps
- Start Bit = 1
- Data Bit = 8
- Stop Bit = 1
- Parity = None (AVR) or Even (DVD)
- Transfer Data = ASCII
- Communication Procedure = Non Procedural (AVR)
- Communication Data Length = 135 Characters Max. (AVR)
- Control Characters (DVD) = STX (02h), ETX (03h), ETB (17h), NAK (15h), ACK (06h)
back to top
3) Why do I get inconsistent operation or only certain commands work?
Assuming everything else is connected and setup properly, the most common reason for inconsistent port communication is that parity was set incorrectly. This is easily corrected in the port's configuration menu.
back to top
4) How do I send a proper command when checksums are required?
Commands with checksums are calculated and sent in the following manner. For this example we will use the Play command from one of our DVD players and provide the basic command string information need to implement the command. The Play command is a hex 40 otherwise written as 40h or an ASCII "@" sign. Please note, in our protocol document commands in quotes (' ') are ASCII characters. To send this command and activate Play on our DVD player, the complete hex string would look like 02 40 00 00 00 00 03 34 33 as indicated in the protocol document. Now let's explain how we got there. The 02h starts the transmission, 40h is the play command itself, 00h 00h 00h 00h are four reserved bytes and must be sent (placeholders), the 03h is the end of transmission, and the 34h and the 33h bytes are the high (BCCH) and low (BCCL) checksums respectively. To calculate the checksums, you must add from the command byte through the end of transmission byte, omitting the start byte. For this Play command we add in hex 40h 00h 00h 00h 00h and 03h. This equals 43h. It is suggested that you use a hex calculator as not to make a mistake. The Windows calculator has a setting for hex which makes this easy to do. Do not add these numbers in standard decimal format with a regular calculator as this will not work. Once the string has been added, in this case a 43h, we can generate the checksums. To do this, the tens place number "4" is used for calculating the high checksum and the ones place "3" is used for calculating the low checksum. Treat both numbers as ASCII characters and convert them into hex. A "4" equals 34 and a "3" equals 33, therefore the high low checksums are 34h 33h which is added to the end of the command string. Final note, if your added string has a value with a hundreds place, ignore the hundreds place when calculating the checksums.
back to top
5) What type of serial cable should be used?
Unless otherwise specified in our protocol documents, the proper cable to use is a pin to pin shielded cable and not a cross connect or null modem cable.
back to top
|
|
|
