XBUS_SPECIFICATION_EN

Protocol Specification Overview <Ver.1.3.2>

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 unsigned 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.

0x0000 800uSec
0x1249 900uSec （-60°、-75°、or -90°）
0x7FFF 1500uSec （0°）
0xEDB6 2100uSec （+60°、+75°、or +90°）
0xFFFF 2200uSec

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 calculation range is from the beginning of the packet to just before the CRC frame.

The CRC polynomial applied to this packet is as follows:

X8 + X5 + X4 + 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.

< Caution >

When executing ID change or reset orders with a channel ID of 0x00 while multiple XBUS servos are connected,all XBUS servos will end up having the same channel ID.

Subsequently, when sending command data packets specifying the channel ID,

each servo will respond almost simultaneously, causing bus congestion.

Please be cautious of this situation.

< Explanation 3 > About Order, Data

The roles and details regarding orders and data are as follows. In this packet, please note that some orders may not have Data2 to Data4, which can cause a change in the overall packet byte size. Unless specified otherwise, for two-byte data, Data1 represents the higher byte, and Data2 represents the lower byte. Additionally, data is generally treated as signed data. For unsigned data, it will be indicated as "unsigned" in the remarks.

For three-byte and four-byte data, the handling varies depending on the order.
With the exception of some orders, all orders generally operate in the Operate Mode described below, and once the instruction is successful, it is immediately reflected in the operation.

Unless a Parameter Write command is sent, parameters are not stored in the ROM area.
However, please be aware that some operations are exceptions and are immediately written as described below.

In addition, XBUS servos up to version 7 will function with regular PWM signals;
however, in such cases, the settings configured with the following order will not be reflected.

Reverse, Neutral, Travel High, Travel Low, Limit High, Limit Low

These settings will be reflected after version 8

< Table 1> Index in Parameter Reset and Parameter Write

< Table 2> Response Values / List of Model Names in Product

■ JR PROPO / DFA model [ Response Value / Model Name ]

[0x02A5/S89CYC][0x02A4/S87CYC][0x021A/E555XBUS] [0x02A3/S8477BL] [0x0297/S8911BL-2K] [0x0295/S8955SS-2K] [0x029C/S8944] [0x0293/S8912SHV-2K] [0x0299/S8914SHV-2K] [0x292/S3911-2K] [0x028A/S3411-2K] [0x029D/S3415-2K] [0x029B/S1855-2K]

■ OLD JR PROPO model [ Response Value / Model Name ]

[0x0200/NX8921] [0x0201/NX3421] [0x0202/NX588] [0x0203/NX8925] [0x0204/NX3425] [0x0205/NX6421] [0x0206/NXR89] [0x0207/NXR34] [0x0208/NXB8921] [0x0209/NXB8925] [0x020A/NXB89G] [0x020B/NX8931] [0x020C/NX8935] [0x020E/NX35G] [0x020F/NX396] [0x0210/NX319] [0x0211/NX189]

< Explanation 4 > About CRC8

The CRC calculation range is from the beginning of the packet to just before the CRC frame.

The CRC method applied to this packet is the same as in the previous section, as follows.
The range of CRC is all bytes from the beginning of the packet to just before the CRC.
A sample source code is provided at the end of this document for your reference.

X8 + X5 + X4 + 1

Performing CRC checks for all packets is an important point to consider when writing code on the host side.

< Regarding packet transmission intervals >

Normally, in the case of an XBUS RC receiver, these packets are transmitted at intervals of 14ms. As a general rule, this interval is considered standard for packet transmission.
However, it is possible to achieve even tighter transmission intervals for XBUS servos,
depending on their performance capabilities.

It should be noted that the extent to which the intervals can be tightened may vary depending on the model, so the guaranteed interval for the foreseeable future will remain at 14ms.

This issue is particularly important when it comes to channel data packets.
If you expect a fast response from XBUS servos, it is necessary to increase the pace at which command values are output.

The amount that the intervals can be tightened also depends on the number
of channels worth of data that are included and transmitted in a single packet.
If there are fewer channels, the processing time required for a single packet becomes shorter.

If the packet transmission intervals are set too short, there is a possibility that subsequent packets may arrive before the processing of the preceding packet is completed.
In such cases, the subsequent packet will be lost, but please note that in order to resume packet acquisition, after the completion of the lost packet transmission, a minimum of at least one byte or more of idle time is required.

As a reference example, there have been instances where current models have successfully operated with a packet carrying data for 4 channels at a transmission pace of approximately 1.5ms.
In this case, the theoretical time for each packet would be 0.84ms, resulting in a packet interval of 0.66ms.

Similarly, if a channel data packet carrying data for 50 channels is considered, the theoretical time for the packet would be 8.2ms.
Assuming operation at 60 frames per second, the frame rate would be 16.67ms.
Therefore, the calculation is sufficient to accommodate general motion operations with ample time.

Indeed, these theoretical values assume the most efficient transmission from the host UART in terms of bit-level density.
However, it is important to note that the actual performance may vary depending on the programming of the host UART.
There is a possibility that gaps may occur between bytes, resulting in lower-than-expected performance.

Please note that the control cycle for current models of XBUS servos is 1ms or 0.5ms (for 2K models).
Therefore, there is no practical benefit in shortening the packet transmission intervals beyond these values.
However, this may not be the case for future models.

■ XBUS Configuration Tool - Expert Mode Manual

Here, we will explain the Expert Mode of the XBUS Configuration Tool.

・How to Activate Expert Mode

Power on the XBUS configurator,while holding down the bottom button, and it will enter Expert mode. Immediately after starting, there won't be any noticeable differences, but the number of functions has significantly increased, and more configurable items have been added.

・Using Expert Mode

The usual usage method is unchanged. However, the number of configurable items has increased, it is now possible to set them all according to the aforementioned order.

■ Reference

・Here's a sample source code for calculating CRC8

・Procedure to change the channel ID

Regarding the change of the channel ID,in order to minimize unforeseen issues, it has been set up so that the following procedure must be followed for the change to take effect.

Simply submitting an ID order will not result in the change, so please be aware of that.

Send a Mode order to the XBUS servo to transition it to ID Setting Mode.
Send an ID order to the XBUS servo to change its ID. At this stage,
it will automatically return to the original mode.

・Regarding the XBUS ports of the receiver.

If you are using our XBUS-compatible transmitter and receiver, once you set the XBUS mode to Mode A, the commands mentioned in this document will be sent from the XBUS port of the receiver according to the operation of the transmitter.

Basically, channel data packets are continuously transmitted at a 14mSec interval, and if parameter adjustments are made from the transmitter to the XBUS-compatible servo,
command data packets are sent.

During this process, please be aware of the following points when using the XBUS port on the receiver:

he channel data packets have a maximum capacity of only 16 channels.
For transmitters with more than 16 channels, such as 17 channels or more,
the data for the last 4 channels, for example, may be alternately swapped with different channels.
Always make sure to verify the data intended for each ID and avoid relying on the data's position for identification.
Depending on the model of the receiver or remote antenna, there might be two bytes of dummy data inserted before the CRC at the end of the packet.
This data is unnecessary and can be ignored.
Even for receivers with a smaller number of channels, the XBUS packet transmits the data directly from the transmitter without any modification.
In the transmitter (proportional controller), the default for stick operations and similar controls is set to ±100%.
In terms of servo operation, this corresponds to ±40 degrees (for 120-degree operation) or ±60 degrees (for 180-degree operation).
If you require maximum servo movement, you can set it to ±150%,
which allows you to move the servo up to ±60 degrees (for 120-degree operation) or ±90 degrees (for 180-degree operation).
To do this, you may need to adjust the travel adjustment on your transmitter accordingly.
Sometimes, within the channel data packets, there are instances where the CH-Function has a flag of 0x80 set. This flag represents fail-safe information, and you should ignore this particular channel data. There are also cases where the flag is set to 0x40, but you can disregard this flag as well. Naturally, if the flag is set to 0xC0, it means you should ignore the entire channel data.

■ Regarding Old XBUS Converter

If you want to use conventional PWM servos alongside XBUS servos, our company provides a converter. However, please note that the converter has limited functionality and only the following features will operate:

The converter supports the full functionality of channel data packets, but only up to 16 channels.
The following is the order of command data packets:
>>> Mode, ID, Version, Unsupported, Parameter Reset, Parameter Write,
Reverse, Neutral, Travel High, Travel Low

In addition, in the case of a 4-port converter, immediately after performing the initial state or resetting the channel IDs, all servo IDs are set to 1, and the sub IDs are set to values ranging from 0 to 3, respectively.

Please note that the PWM waveform output by the converter is fixed at intervals of 20ms. Therefore, even if you send packets at a faster rate, it cannot accommodate them.
We kindly request that you use it at intervals of approximately 14ms at the fastest.

■ Regarding NEW XBUS Converter

If you want to use conventional PWM servos alongside XBUS servos, our company provides a converter. However, please note that the converter has limited compatibility and can only operate the following functions:

The full functionality of the Channel Data Packet
The following is the order of command data packets:
>>> Mode, ID, Version, Unsupported, Parameter Reset, Parameter Write,
Reverse, Neutral, Travel High, Travel Low

Please note that the PWM waveform output by the converter is designed to generate a single pulse upon the arrival of an XBUS packet. Normally, this pulse occurs at intervals of 14 milliseconds.

■ When constructing a single joint using multiple XBUS servos

When constructing a leg with a link-shaped structure, commonly seen in certain parts of a bipedal walking robot (referred to as a "link leg" below), or when interlinking multiple servos for torque enhancement in cases like the ROLL axis of the shoulder, using XBUS servos makes the setup process remarkably simple.

With XBUS servos, it is possible to interlink up to four XBUS servos using sub-IDs.
Therefore, it is recommended to equip different sub-ID XBUS servos with the same servo ID on each axis of the link leg, for example.

During the assembly of the frame, by setting the reverse, neutral position, and maximum angle (travel) for each XBUS servo and adjusting any discrepancies in individual XBUS servos, they will generally operate in sync. Once these adjustment values are sent as write commands, each XBUS servo will store them internally and remember them even when the power is turned off.
Therefore, once you have made the initial settings, there is no need to reconfigure them unless you need to readjust during maintenance or other purposes.

During motion transmission, it is sufficient to send data with a single channel ID set to zero for the servo ID + sub-ID in question.
It is possible to drive up to four servos with the same servo ID simultaneously.
This reduces the burden of generating channel data packets and alleviates the data-related workload during motion creation.

■ Regarding the use of only the TX (transmit) of the host UART.

The XBUS servo system is originally designed for half-duplex communication, which requires switching between transmit (TX) and receive (RX) lines.
In some cases, external circuitry may be necessary for this purpose.
However, if the following conditions are met, it is possible to operate the system using only the TX line of the host UART, without the need for a switching circuit or utilizing the RX line

During operation, there is no need to monitor the status of the XBUS servos at all.
When configuring the XBUS servos, each servo is connected individually.
In the case where multiple XBUS servos are connected, no command data packets are sent at all.

If you have completed the configuration of all XBUS servos in advance, and you don't need to use the RX line for the channel data packets, you can operate them using only the TX line. This is recommended for simplified operation.

■ Regarding the microcontroller used for the XBUS servos

Currently, the XBUS servos are being driven and controlled using NXP (formerly Freescale) MKL16 series microcontrollers running at 48MHz.
For precise information regarding voltage levels and other specifications of each port,
We recommend referring to the relevant manual for the specific microcontroller model.

However, please note that for future products, the microcontroller used may differ,
and thus relying heavily on specific voltage levels may not be recommended.
It is always advisable to refer to the documentation and specifications provided for the particular microcontroller being used in each case.

The firmware of the MKL16 microcontroller is protected by security measures.
If you attempt to read it without proper authorization,
the chip's specifications dictate that the entire internal content will be cleared.
It is important to exercise caution in this regard, as once cleared, the microcontroller will cease to function.
Restoring its functionality would require firmware reprogramming or repair.

During the repair process, if it becomes necessary, please be sure to declare that the firmware has been cleared. Failure to do so may result in the assumption of a board malfunction, leading to the replacement of the entire board, which can be costly.
Please keep this in mind and take appropriate precautions.

For reference, We will provide a schematic diagram of the signal input section of the microcontroller.