Protocol Specification Overview <Ver.1.3.0>
Thank you for your interest in the XBUS Servo motor manufactured by JR PROPO.
We appreciate it. The XBUS Servo Protocol Specification Overview has been created with the purpose of making the protocol accessible to be used with the XBUS Servo not only for RC purposes but also for various hobby applications.
By making the protocol public, we aim to provide convenience for users in different hobby scenarios.
In the future, we plan to release XBUS Servos in various shapes and forms.
However, these servos are designed to operate with a unified protocol, allowing you to select them based on your specific application requirements.
This means that regardless of the servo's shape or form, they will be compatible and able to work with the same protocol.
We believe this will provide you with flexibility and options to choose the suitable servo for your needs.
We share your enthusiasm for utilizing state-of-the-art microcontroller boards and connecting multiple XBUS Servos to create a wide range of innovative projects.
By harnessing the power of these high-performance components, we hope to see the birth of many creative and exciting creations.
The possibilities are vast, and we look forward to witnessing the amazing works that will emerge as a result.
< Important Notes >
This document provides an overview of the protocol specifications for XBUS Servos.
Regarding, parts not covered in this document, please note that all aspects are currently reserved due to potential future expansions. (fix)
This document may be subject to changes without prior notice for product improvements, document enhancements, or other reasons.
This document may become non-disclosed depending on the circumstances.
Unauthorized reproduction of this document often hinders the dissemination of the latest information.
Therefore, please refrain from unauthorized reproduction.
However, it is absolutely acceptable to publish explanations or materials based on this document, as long as proper citation is provided.
In fact, we welcome such initiatives. If possible, we would appreciate it if you could include a link to our company's website as a reference.
We would like to clarify that our company assumes no responsibility for any troubles or issues related to this document.
If repairs or any assistance regarding the product are required, please contact our service department for regular repair procedures,
and we will promptly assist you accordingly.
< XBUS Servo Specifications Supplement >
Please refer to our company's website and catalogs for general product specifications of each XBUS servo.
Here, I will provide explanations for aspects that are not covered in those catalogs.
XBUS servos perform internal initialization immediately upon power-up. However, they will not supply power to the motor until one of the following conditions is met:
When a correct serial command is received and a position instruction is given.
When a certain number of consecutive correct RC-style PWM signals (referred to as PWM signals) are received (currently, 50 pulses or more).
Once an XBUS servo receives a serial command and starts operating, it will continue to operate based on serial commands until the power is turned off.
It will no longer accept PWM signals during this time. Similarly, if the servo is started with PWM signals, it will continue to operate based on PWM signals until the power is turned off, and it will no longer accept serial commands.
In other words, the servo will maintain its operating mode (serial or PWM) until the power is disconnected, regardless of the type of input it initially received.
If the XBUS servo has started operating and there is a interruption in either the serial commands or PWM signals while power is still supplied,
the servo will enter a neutral state (neutral position) after approximately 1.5 seconds.
However, please note that this setting can be modified, and it is possible to configure the servo to not enter the neutral state (i.e., remain powered and holding its position) even if there is an interruption in the input signals.
In summary, by default, if there is no input signal for approximately 1.5 seconds, the servo will enter a neutral state, but this behavior can be adjusted according to specific requirements.
Furthermore, if you wish to immediately put the servo into a neutral state, you can achieve this by sending a serial command that instructs a position angle of 0.
By specifying a position angle of 0, the servo will promptly enter the neutral state and release any applied force.
< XBUS Servo Bug Information, Improvement Information >
Here is an explanation regarding currently known bugs.
If you encounter any issues with the bugs in the previous version, we sincerely apologize for the inconvenience.
Please kindly email us at the dedicated XBUS servo email address mentioned earlier, and we will address the problem.
The currently known bug information and improvement information are as follows:
< Regarding Hardware >
< Serial Bus related Specifications >
For driving XBUS servos using the host UART (such as a microcontroller),
It is a 1.5-wire half-duplex configuration, and other than that,
it uses a standard TTL serial signal.
3.3V TTL level
1-wire half-duplex communication (the host UART is typically in TX mode)
8 bits of data per transmission, 1 start bit and 1 stop bit, No parity,
Least Significant Bit (LSB) is transmitted first
Idle state is a high-level signal
The communication speed is 250 kbps, The Bit Error Rate (BER) is below 1%
< The signal cable specifications for the new JR PROPO specification are as follows: >
The signal cable used is the same as the one used for regular RC servos, with the same wiring roles.
The connector used is also the same as the one used for regular RC servos.
< Important Note >
It is desirable to include a protection resistor of approximately 100Ω to 1kΩ in series with the signal in the output of the host UART used for packet transmission and reception, in preparation for any unforeseen circumstances.
However, if the floating capacitance of the signal line is large, it is important to use a smaller protection resistor.
Otherwise, the waveform may distort, resulting in packet loss or operational stoppage (such as fatigue due to the absence of normal packets arriving).
Please take note of this.
Depending on the situation, it may be more stable to install a pull-up resistor of around 100kΩ on the host UART.
This is particularly recommended when there is a risk of the bus voltage becoming ambiguous during the switching of TX and RX, as it helps maintain a stable voltage level.
If the host UART signal line has a protection resistor, it is possible to receive a 5V output serial signal.
However, it is not highly recommended for the XBUS servo side, as it involves a clamping effect due to the protection resistor and protection diode.
Additionally, even in that case, the signals returned from the XBUS servo will be in the form of 3.3V serial signals.
Due to the relatively high-speed nature of the serial bus, the use of filters involving capacitors is strictly prohibited.
The use of open-drain and open-collector configurations is also not recommended.
Even capacitance in the pF range can have an impact, so please be cautious when it comes to wiring.
If long-distance transmission is required, it is advisable to install bidirectional buffers or similar components as needed to ensure proper signal integrity.
The determination of whether it is idle or not is made when the signal remains high for 10 bits after the start bit generation.
The regular signal consists of 8 bits without parity and one stop bit.
Therefore, when transmitting 0xFF, if the start bit of the next byte is delayed by approximately 0.5 bits or more, it will be identified as an idle state, and there is a possibility of failed packet reception. Please be cautious of this possibility. To prepare for a communication break, a system has been implemented to detect when the signal line enters an idle state and initiate recovery.
< Regarding Software >
< Overview >
This protocol is a system that communicates using packets primarily formed by byte sequences.
Depending on the content of the packet, there are packets that receive a response from the XBUS servo and those that do not.
All packets have a CRC (Cyclic Redundancy Check) set at the end, ensuring their integrity.
Within the XBUS servo, packets with CRC errors are discarded.
It is also desirable for the host to verify the CRC of the received packets.
Each XBUS servo can be configured with a channel ID using the method described below.
The channel IDs must be unique within a series of connected XBUS devices.
It is recommended to connect individually to the host UART in advance for setting the channel IDs to avoid issues.
There are two main types of packets: channel data packets used for specifying the angle of the XBUS servo,
and command data packets used for various other settings.
Command data packets further have several types.
In regular usage, the host UART should be set to TX mode, and channel data packets are sent intermittently to the XBUS servo, similar to PWM signals.
The XBUS servo will continue to follow the continuously sent angle instructions.
Connecting multiple XBUS servos with the same channel ID on the same bus can cause issues in the protocol and is generally prohibited.
However, it is possible to synchronize up to four XBUS servos with different channel IDs using the sub-ID mentioned below.
By using command data packets, you can generally modify the settings of any XBUS servo at any timing (with some exceptions).
You can also check the status of any servo at arbitrary timings.
However, please note that it operates on a half-duplex communication, so careful bus management is necessary.
< Channel Data Packets>
We will provide angle instructions to the XBUS servo. The byte sequence for this packet is as follows:
Furthermore, there will be no response packet from the XBUS servo for this packet
, so the host UART can remain in the TX state even after packet transmission.
In general, angle commands for all connected XBUS servos are included in a single packet and transmitted collectively.
However, even if the XBUS servo does not have any data addressed to itself in this packet,it will not consider it an error.
Therefore, it is possible, for example, to include angle commands with different channel IDs in separate packets and send them in a divided manner.
< Explanation 1> About Channel ID
Each XBUS servo is assigned a unique 8-bit channel ID, and its structure is as follows:
In the channel data packet, only the servo ID can be specified, and the sub ID is set to 0.
When an XBUS servo receives a channel data packet, it will follow the instructions based on the servo ID, regardless of the value specified for the servo's sub ID.
The various settings for each individual XBUS servo, which will be discussed later,
operate based on the matching of the channel ID, including the sub-ID.
This allows up to a maximum of four XBUS servos to operate synchronously
using the same servo ID.
The channel ID at the time of product shipment is 0x01.
< Explanation 2 > Regarding the setpoint value
Position control is performed using a 2-byte value in the form of High-Low.
This value follows the concept of traditional PWM signals and is used to indicate the position in a signed, value-based format. XBUS servos typically operate within a range of 850-2150µs.
Any angle specification outside this range will be ignored, and the servo will remain idle or unengaged.
0x1249 900uSec （-60°、-75°、or -90°）
0x7FFF 1500uSec （0°）
0xEDB6 2100uSec （+60°、+75°、or +90°）
However, if limit values are set, any instructions outside of those limits will be clipped
and the servo will stop at the limit position instead of remaining idle.
Currently, the limit values are set to 800-2200 at the time of factory shipment, rendering them effectively invalid.
< Explanation 3 > About Repetition
This packet is of variable length and can be sent as a single packet containing data for the number of channels required by the user.
However, since the same servo ID cannot be specified multiple times,
the maximum limit is the number of servo IDs (50 IDs).
In the case of repetition, the 4-byte block of the fourth term is repeated as a unit,
and the channel ID and instruction value are represented in a repetitive manner.
Within this packet, the channel IDs can be consecutive or non-consecutive,
and there are no specific restrictions on the order of the channel IDs.
<< An Example >
In the case of XBUS servos, they generally search for their own servo ID sequentially from the beginning of the packet.
Therefore, in the case of a long packet, there may be a millisecond-level timing difference between the beginning and the end.
If a packet is sent that exceeds the buffer size of the XBUS servo itself, even if the CRC is correct, it will result in an error.
As a result, the packet will be ignored, and the servo will go back to waiting for the next packet.
Please note that no specific status will be returned in this case.
Each XBUS device generally has a buffer capable of receiving data for at least 16 items.
In the case of XBUS servos, they have a buffer capable of receiving data for 50 items as a standard.
< Explanation 4 > About CRC8
The CRC polynomial applied to this packet is as follows:
X^8 + X^5 + X^4 + 1
The CRC calculation is performed on all bytes from the beginning of the packet up to the byte before the CRC itself.
It is important to note that CRC checking is performed on all packets,
so it becomes a crucial point when writing code on the host side.
For reference, a sample source code is provided at the end of this document.
< Command Data Packet >
We will perform various settings for the XBUS servo. The byte sequence of this packet is as follows.
Please note that for this packet, except for certain exceptions mentioned later,
a response packet will generally be generated from the XBUS servo using the Status Command mentioned later.
Therefore, after completing the packet transmission, promptly (within a few microseconds) release the TX and switch to RX to prepare for receiving the Status Command packet.
However, if the host UART has a transmission buffer internally, make sure to confirm that the byte sequence of the packet has been completely transmitted before switching.
Otherwise, the XBUS servo may not receive all the packets and an error may occur.
At this point, there is no specific timeout set, but if there is no response within 14 milliseconds at the latest, you can consider it as a failure.
< Explanation 1 > About Commands
The following three commands are applicable to this packet:
0x20 Set Command
> The command to set values according to the order mentioned later.
0x21 Get Command
> The command to read values according to the order mentioned later.
0x22 Status Command
> The command used for responses (not available for user use).
When the host sends a Set Command or Get Command,
the XBUS servo performs operations according to the order mentioned later.
As a result, it typically responds with a Status Command of the same order and the same number of bytes.
The Status Command sent from XBUS servo usually returns the current value regarding the respective order.
In the case of a response to a Set Command, depending on the situation,
the returned value may be clipped to the limit value on the XBUS servo side instead of the intended value that was set.
If the order is unsupported by the XBUS servo, a Status Command is returned
,which has been changed to "Unsupported Order" as mentioned below.
In this case, Data2 does not exist, so please be aware that depending on the original order, the returned size may be one byte smaller.
Therefore, the packet size of the Status Command may vary, so please always determine the received length by judging the second byte during reception.
< Explanation 2 > About Channel ID
The channel ID mentioned earlier remains the same in this case, but here the sub-ID is also applied.
Therefore, it is possible to communicate with up to 200 XBUS servos, and this command assumes a response, requiring one packet per XBUS servo each time.
Regarding the Set Command, if you specify 0x00 here, it will have an effect on XBUS servos with all channel IDs. In this specific case, no response packet using the Status Command will be generated.
However, please note that if you accidentally specify 0x00 for the Get Command, there will be no response.