© 2012 Yamaha Corporation All Rights Reserved.
YNCA Protocol Specification
Applicable Models: RX-V673, RX-A720, RX-V773, HTR-7065, RX-A820, RX-A1020, RX-A2020 and RX-A3020
Product Region: USA
$Date: 2012-05-16 08:54:14 +0900#$
$Revision: 3980 $
Table of Contents
1 Preface(Back To Index)
This document describes the specifications of Yamaha Network Command Alias (YNCA) protocol.
1.1 Applicable Models(Back To Index)
As of June 2012, this document is applicable with Yamaha AV Receivers of RX-V673, RX-A720, RX-V773, HTR-7065, RX-A820, RX-A1020, RX-A2020 and RX-A3020,
1.2 Outline(Back To Index)
YNCA protocol is designed to provide a simple structure of controlling commands for Yamaha AV products. The "YNCA" derives from the fact that all its commands are the aliases of YNC (Yamaha Network Command) protocol.
YNCA command set is a reduced one of YNC’s but still offering powerful functionalities for operating Yamaha AV products.
1.3 Features(Back To Index)
- Text based, simple and well-unified commands
- Same syntaxes with any connections: RS-232C and Ethernet
- Auto feedback for status updates
2.1.1 Connection(Back To Index)
- DB-9 pin female terminal
- Using Inter-link (Cross) cable is assumed
- Actual contacts that are used for the communication are as shown below.
Slave (the Product) | | | | Master (the Controller) |
TxD (Pin 3) | | ----> | | RxD (Pin 2) |
RxD (Pin 2) | | <---- | | TxD (Pin 3) |
GND (Pin 5) | | <---> | | GND (Pin 5) |
2.1.2 Port Settings(Back To Index)
Baud rate | : | | | 9600 |
Data bits | : | | | 8 |
Parity | : | | | No |
Stop bit | : | | | 1 bit |
Handshaking | : | | | None |
|
2.2.1 Connection(Back To Index)
- RJ45 Network connector
- IEEE802.3 100BASE-TX/10BASE-T
- Full duplex communication
2.2.2 Port Settings(Back To Index)
Default network port number | : | | | 50000/TCP |
Variable range | : | | | 50000 to 65535 |
2.2.3 Simultaneous Connection(Back To Index)
Maximum Number of Simultaneous TCP Connection: 1
3 Protocols(Back To Index)
YNCA protocol is created to provide simple command structure by assigning alias commands to YNC protocol.
3.1 Syntax(Back To Index)
This syntax form shown below must always be kept in both executing commands and getting responses except in case of
Error Responses.
@ | SUBUNIT | : | FUNCNAME | = | Parameter | [CR/LF] |
[1] | [2] | [3] | [4] | [5] | [6] | [7] |
[1] | Start Delimiter (@) | : | The beginning of a command |
[2] | Sub Unit Name | : | Indicating whether the command is for System, any zones or any internal input sources as Tuner, SERVER, and NET RADIO etc |
[3] | Command Delimiter (:) | : | Sub Unit Name and Function name are separated by this delimiter |
[4] | Function Name | : | Specifying actual operations, some of them are abbreviated |
[5] | Parameter Delimiter (=) | : | Separating the Function Name and its Parameter (Value) |
[6] | Parameter | : | Showing a parameter value of the command |
[7] | End Delimiter | : | The end of a command, Carriage Return (CR) and Line Feed (LF), always necessary |
The syntax has no spaces. Example looks like there are spaces in between, but there shouldn’t be.
3.2 Command Types (from the Controller)(Back To Index)
"Command" is an order for the Controller to send to the Product. Command types are defined as follows.
3.2.1 PUT Command(Back To Index)
This is to change conditions or status of functions/settings of the Product like Power, Input and Volume etc.
<Example>
@MAIN:PWR=On[CR/LF] ("PUT" from the Controller to the Product)
3.2.2 GET Command(Back To Index)
This is to check conditions or status of functions/settings of the Product. Power, Input, Volume and so on. The form of GET command is almost the same as PUT command, but the only difference is that its parameter is specified as “?”.
<Example>
@MAIN:PWR=?[CR/LF] ("GET" from the Controller to the Product)
–> @MAIN:PWR=On[CR/LF] ("Response" from the Product to the Controller)
The Response command from the Product has the exact same Sub Unit and Function names as specified in the GET command. The Parameter is just updated with the latest condition or status.
The only one character of question mark (“?”) will never be used as a parameter of PUT commands since it is always recognized as a GET command.
3.3 Response Types (from the Product)(Back To Index)
"Response" is a feedback sent from the Product to the Controller. Response types are defined as follows.
3.3.1 Normal Response(Back To Index)
This is a normal way to respond to the GET command from the Controller. It has the exact same Sub Unit and Function names as what are specified in the GET command. The parameter in the response indicates the current condition or state of functions or settings on the Product.
<Example>
@MAIN:PWR=?[CR/LF] ("GET" from the Controller to the Product)
–> @MAIN:PWR=On[CR/LF] ("Response" from the Product to the Controller)
3.3.2 Auto Feedback Response(Back To Index)
This is to automatically notify the Controller that a condition or a status has been changed by some operations (for example, YNCA PUT Commands, IR remote control, Key operations on the Front Panel and so on) or by the update of metadata information in playback etc. In the response, corresponding Sub Unit, Function names and the updated Parameter are specified. Its syntax is just the same as the one of the Normal Response.
<Example>
When the Main Power is turned on by the front panel key
–> @MAIN:PWR=On[CR/LF] ("Auto Feedback Response" from the Product to the Controller)
<Example>
When the song title is changed in playing NET RADIO
–> @NETRADIO:SONG=Something New[CR/LF] ("Auto Feedback Response" from the Product to the Controller)
Auto Feedback won’t happen when the same condition or state as the current one is specified by a PUT command (in other words, sending PUT commands should not always expect to get Auto Feedback Response from the Product).
Regarding “Initial Auto Feedback”;
Auto Feedback occurs only when the status change is detected by the Product’s system, which is based on the fact that a Sub Unit (a zone or an internal source) is ready for use. So especially at the moment when a Sub Unit is turned on (or gets ready to be used), some status are initially fed back to the Controller at a time, which is called as “Initial Auto Feedback” in YNCA protocol. Not all commands are applicable for this feature. To know which commands are enabled with Initial Auto Feedback, refer to “YNCA Command List” document and find commands that are noted with commentary like “Initial Auto Feedback is available”.
3.3.3 Error Responses(Back To Index)
In case that the Product cannot handle with commands from the Controller for some reason, it will return Error Responses with keywords that imply why it wasn’t processed properly as follows;
3.3.3.1 UNDEFINED
It will be returned the keyword when the command was undefined.
<Example>
–> @UNDEFINED[CR/LF] ("Error Response" from the Product to the Controller)
3.3.3.2 RESTRICTED
It will be returned the keyword when the command couldn't be executed on the Product for some reason.
<Example>
–> @RESTRICTED[CR/LF] ("Error Response" from the Product to the Controller)
4 Other Rules(Back To Index)
4.1.1 Command Interval(Back To Index)
When putting commands to the Product, minimum 200 milliseconds of time interval between the previous command and the next one shall be placed.
4.1.2 RS-232C Standby(Back To Index)
Every command from YNCA controllers will always be possible to be received by sending the following command.
@SYS:RS232CSTANDBY=On[CR/LF]
On the default setting, the Product will be the low-power mode(RS-232C sleep) when the Product is the power standby and could receive no command for 10 seconds. Then it needs to be sent one command to wake up the system at first.
4.2.1 Command Interval(Back To Index)
When putting commands to the Product, minimum 200 milliseconds of time interval between the previous command and the next one shall be placed.
4.2.2 Connection & Disconnection(Back To Index)
TCP/IP Connection is only required (no negotiation at the higher network layers is necessary). Similarly disconnection can by done only at the TCP/IP level.
4.2.2.1 Auto Disconnection / Keep Alive
The Product will automatically disconnect TCP/IP connection in about 40 seconds with no reception of commands or no status change (meaning no Auto Feedback happens) while TCP/IP connection is alive. Therefore some commands have to be issued periodically (within 40 seconds) in order to keep TCP/IP connection alive.
The following is recommended to use as a keep-alive command;
@SYS:MODELNAME=?[CR/LF]
4.2.2.2 Necessity of keeping alive the connection
With YNCA control on Ethernet, although it is basically assumed that TCP/IP port be kept alive, it can be once disconnected and re-connected as needed basis of sending commands unless Auto Feedback is required in the control system that you’re building. In other words, keep alive has to be done if Auto Feedback status update is a must.
4.2.3 Port Number Change(Back To Index)
The network port number is set as 50000 by default and normally it is not necessary to be changed. But if it is required to change its setting due to issues like port-filtering or something in the network environment that you’re handling with, the procedures is as following;
1. Set the new port number by @SYS:YNCAPORT=nnnnn[CR/LF] command (nnnnn: port number, ranging from 50000 to 65535).
2. Power cycle the Product once and the new setting will be effective (meaning that it is not changed by just sending the command).
In using the command shown above to change the port number via Ethernet, the default number 50000 must be used at the very first time or when it is factory-default. If it is not possible for to use port #50000 even at the timing of initial setup, the alternative choices are to send that command via RS-232C or to use the command defined as YNC protocol (refer to the document separately provided) which can be done with port #80.
4.2.4 MAC address filter(Back To Index)
It is possible to restrict the accesses of YNCA controllers to the Product via the Ethernet by setting up the MAC address filter properly.
MAC address filter setting also can be done via the Product’s menu. Refer to the owner’s manual of the Product in use.
4.2.5 Network Standby(Back To Index)
It is always possible to receive the command from YNCA controllers via the Ethernet by setting "Network Standby" to "On".
"Network Standby" setting also can be done via the Product’s menu. Refer to the owner’s manual of the Product in use.
5 Appendix(Back To Index)
YNCA protocol has a command that allows to operate the Product by sending an IR command code as a parameter of @SYS:REMOTECODE=xxxxxxxx[CR/LF] command. (xxxxxxxx: IR code, 8 characters)
See "REMOTECODE" command description and also find the link to the IR code list available with the Product.
Sequence diagrams are given below to help understanding what the communication should be like case by case.
Note: To control the Product via Ethernet being in standby mode, remember to set "Network Standby" to "On" through the setup menu of the Product.(
Refer to 4.2.5)
- Connection
The Product The Controller
(YNCA Server) (YNCA Client)
| |
| SYN to destination port 50000 |
|<---------------------------------------| Start TCP connection
| SYN/ACK | *In case of establishing a connection to # 50000/TCP.
|--------------------------------------->|
| ACK |
|<---------------------------------------| Connection completed
| |
- Main Power On
The Product The Controller
(YNCA Server) (YNCA Client)
| |
| @MAIN:PWR=On[CR/LF] |
|<---------------------------------------| Send Power On command
| |
- Volume Change (Direct)
The Product The Controller
(YNCA Server) (YNCA Client)
| |
| @MAIN:VOL=-60.5[CR/LF] |
|<---------------------------------------| Send Volume command
| |
- Volume Change (Up/Down)
The Product The Controller
(YNCA Server) (YNCA Client)
| |
| @MAIN:VOL=Up[CR/LF] |
|<---------------------------------------| Send Volume command
| | *In case of "Down" : @MAIN:VOL=Down[CR/LF]
- Keep Alive *In case of polling the connection state (i.e. Keep Alive)
The Product The Controller
(YNCA Server) (YNCA Client)
| |
| @SYS:MODELNAME=?[CR/LF] |
|<---------------------------------------| Send any command
| |
| @SYS:MODELNAME=RX-XXXXX[CR/LF] |
|--------------------------------------->| Receive response
| |
- Volume Check
The Product The Controller
(YNCA Server) (YNCA Client)
| |
| @MAIN:VOL=?[CR/LF] |
|<---------------------------------------| Send Volume check command
| @MAIN:VOL=-60.5[CR/LF] |
|--------------------------------------->| Receive response
| |
- Disconnection
The Product The Controller
(YNCA Server) (YNCA Client)
| |
| FIN/ACK |
|<---------------------------------------| Quit TCP connection
| ACK |
|--------------------------------------->|
| FIN/ACK |
|--------------------------------------->|
| ACK |
|<---------------------------------------| Connection terminated
| |
- Main Power On
The Product The Controller
(YNCA Server) (YNCA Client)
| |
| @MAIN:PWR=On[CR/LF] |
|<---------------------------------------| Send Power On command
| @MAIN:PWR=On[CR/LF] |
|<---------------------------------------| Send Power On command twice (Refer to 4.1.2)
| |
- Volume Change (Direct)
The Product The Controller
(YNCA Server) (YNCA Client)
| |
| @MAIN:VOL=-60.5[CR/LF] |
|<---------------------------------------| Send Volume command
| |
- Volume Change (Up/Down)
The Product The Controller
(YNCA Server) (YNCA Client)
| |
| @MAIN:VOL=Up[CR/LF] |
|<---------------------------------------| Send Volume command
| | *In case of "Down" : @MAIN:VOL=Down[CR/LF]
YNCA protocol is designed to provide a simple structure of controlling commands for Yamaha AV products. The "YNCA" derives from the fact that all its commands are the aliases of YNC (Yamaha Network Command) protocol. YNCA command set is a reduced one of YNC’s but still offering powerful functionalities for operating Yamaha AV products. This information is intended to provide clarifications on differences between YNCA and YNC protocols hoping that would help you to choose the right protocol which suits your application best.
- YNCA Features
- Simple: No ACK/NAK handshaking
- Short texts and simple syntax: Complicated/heavy parser module as XML not required
- Common protocol for both Network(Ethernet) and RS-232C connections: Easy to port each other
- Peer-to-peer connection: Not necessary for multi-connection management
- Auto feedback: Status changes are always pushed out, requires no polling
- Sufficient command set: For complete daily operations and for some settings
- YNC Features * Please see the accompanying file for details.
- Standard XML format: Parsers from standard libraries can be used
- HTTP: Used widespread as a standard method for multi-client control environment
- Covering all YNCA command sets: Sufficient enough for daily use operations
- Detailed command sets available: for DSP/PEQ parameters, Video Adjustments and so on
- Protocol Layers
- Features List
Connection Features |
YNC |
YNCA |
Network |
Network |
RS-232C |
Simultaneous Connection |
4 |
1 |
--- |
Security |
✔(MAC Address Filter) |
✔(MAC Address Filter) |
--- |
Port Number Change |
--- |
✔(50000-65535) |
--- |
Network Command Standby |
✔ |
✔ |
--- |
RS-232C Command Standby |
--- |
--- |
✔ |
Protocol Features |
YNC |
YNCA |
Network |
Network |
RS-232C |
XML Type |
✔ |
--- |
--- |
Simple Type |
--- |
✔ |
✔ |
Auto Feedback Response with Value |
--- |
✔(For All Commands) |
✔(For All Commands) |
Event Notice |
✔(UDP Multicast) |
--- |
--- |
IR Code Command |
✔ |
✔ |
✔ |
Daily Operation Command |
✔ |
✔ |
✔ |
Detailed Setting Command |
✔ |
--- |
--- |
AMX DDDD Protocol |
--- |
✔ |
✔ |
© 2012 Yamaha Corporation All Rights Reserved.