We thank you for your kind interest at JR PROPO’s XBus servo’s protocol.
We intend to provide this protocol information not only for the Radio Control hobby use, to be use on other various needs for convenience.
We plan to release more XBus servos in different configurations for future.
Fundamentally, we will be standardized XBus protocol as a platform to operate the servo. It would be favorable to use our protocol depending on your own use in future.
There are many high performance micro computer chip available in the market nowadays, we are very excited and thrilled to see those new servo coming out in future using our XBus Protocols.
This document is short summary on the XBus Servo’s protocol specifications.
There might some portion that is not included in this document however, in future considering the extensibility of the system, it shall be included therefore,Any related items shall be reserved under our rights.
This document shall be modified or revised due to improvement of the system or device without any notice in advance.
This document shall become no-disclosure depending on the certain circumstances.
Please do not copy the content to any other media or on any website, SNS etc.
Because it may become a confusion and obstruction for latest data’s
Short summary on the XBus Servo’s protocol specifications.
improvement. Except the proper introduction or proper explanation of this protocol specifications. It is welcome to introduce our specifications. It is suggested to put the link as reference please.
We shall be not responsible for any trouble or accident for using this protocol specifications for any reasons.
JR PROPO products (i.e. transmitter, receiver or servo) can be repaired through our service department. Please consult with our service department Currently exist in Australia, Japan and U.S.A.
●XBUS servo specifications revisions
Kindly refer to our web site or catalog for general information concerning the XBus servos. Here is the additional explanation which are not described in those information.
XBus servo shall be initialize after power has be turned on however, if following two items are not established, there will be no supply of electric input to the motor.
1. Correct serial commend has been receipt and being located on the position 2. Correct PWM signal has been successfully receipt at continuous pulse output.
(i.e. Currently more than 50Pulse or more)
Once the XBus servo has been successfully established with Serial command in active, it will only follow the serial commend not with PWM signal until power has been shut off. And, same situation for PWM signal, once the PWM signal has been established, XBus servo shall not be active under Serial command until power being shut off.
After the power has been turned on under the Serial commend or PWM signal, if the signal being cut off, servo shall become loose after 1.5seconds. This is under the default setting and capable to change the setting not become loose.
If the Serial command has been set as “0 Degree” servo could become loose immediately after the signal being cut off.
XBus Servo Software bug Information and revision information.
Here we would like to explain about software bugs, if you are facing a problem with Software bugs on previous JR XBus servos, kindly contact our service repair department for update. We shall comply to your request to fix with latest software.
Here under below is the list of the bugs that we have found so far….
●Concerning the hardware
・Specification on Serial Bus related
In case the XBus servo to be activate with Host Micro Computer via UART, (Host UART)here are the condition.
One requirement is One wire half duplex, other than that is ordinal TTL Serial signal.
3.3V TTL One wire half duplex, (Host UART should be with TX Mode)
8bit, 1 start bit, 1stop bit, non Parity, LSB first Idle Hi Level 250kbps BER under 1%
・Specification on Signal wire
Signal cable is as same type as Model RC Servo configuration, and each harness employ as same also for the connectors.
It is highly recommended to place the resistor of 100ohm to 1Kohm resistor in series as a protection in order to achieve packet to send or receive for host UART output. However, Be sure to select the proper resister value if there is a stray capacitance are in large capacity. Choose the smaller resister value in order not to distort waveform nor packet loss nor disactivate of the unit due to not having enough packet and become loose.
Depending on the situation, it may be ideal to attach to the Host UART only with 100kohm resister to pull up. This method may be possible to stabilize the condition. Especially when you are making a change between TX and RX, Bus voltage may become poor, therefore it is suggested to place a pull up resistor.
When the Host UART is having a protection resister in line, It is possible to receive 5.0V signal however at the XBUS servo side, protection resister nor protection capacitor become as a clamp, therefore we suggest not to arrange this setup. At the same time, the return signal voltage shall be as 3.3V serial signal.
It is relatively a high speed serial bus therefore, we strictly prohibit to arrange filtering by using the capacitors. Do not use Open drain, Open collector either. It affect the signal even with pF unit capacity therefore, be extra cautious on this wiring. If require a long distance wiring to transmit the signals, it is ideal to arrange a proper bidirectional buffer in place.
In case the communication signal become ruptured, and become idle, There is a system provided in the circuit to detect the rupture to recover from the idle. To judge the idle state, When a signal remains a high for 10 bits after start bit generation, it judge that is on idle state. The regular signal is 1 stop bit that there is 8bit without parity. Therefore, when transmitting the 0xFF, the next 1Byte start bit generation delays within 0.5bit then, it judge as idle state and may fail in the reception of the packet so be cautious on this set up.
This protocol is based on the system communicating using a packet formed of a byte line. By the contents of the packet, there is a packet reply comes back or Short summary on the XBus Servo’s protocol specifications.
does not comeback from XBus servo.
All of the Packets are set with CRC at the end, and legitimacy is secured.
Internally on the XBUS servo, all the packets that has a CRC error will be abort.
In addition, it is suggested that packets which has been receive on the Host should be confirm on the CRC at the host side.
Each XBus servo can be set with channel ID, method of settings shall be explained as follows. The channel ID must be all one and only in the connection of a series of XBus. To avoid possible corruption of this arrangement, channel ID to host UART must perform individually before setting the channel ID. There are two kind of packets are available, First one is to command the angle of the XBUS servo operation and the second one is to commend the data packet which relate with various setting of XBus servo. There are some more kind of command data packet are available as well. Normally, Set the host UART as TX mode and set the commend just like a PWM signal intermittently to the XBus servo with channel data packet. The XBUS servo continues obeying the angle instructions that are coming. Basically, Due to Protocol allowance, It is prohibited to have several XBus servos to be connect within the same channel ID to the same serial bus. However, it is possible to connect the four (4) XBus servo link with channel ID , utilizing the sub ID.
It is possible to change the setting for any XBUS servo as a general rule in any timing by using command data packet (Note: There are some exceptions). In addition, XBus servo can confirm any status in the same way in any timing. But carefully note that this is under the One wire half duplex, therefore, management of the bus is quite essential.
・Channel Data Packet
Short summary on the XBus Servo’s protocol specifications.
Note that this packet would have no packet response from XBus servo , host UART shall be set as TX state after the packet transmission.
Basically, all of the connected XBus servo’s angle instruction are embedded in one packet and transmitted. However, XBus servo shall not judge as an error with this packet even though it does not include own data. As an example, It is possible to transmit in divided packets with angle instructions of separate channel ID on the number of packets to the XBus Servos.
Channel Data Packet can be only designated by Servo ID and Sub ID is set as “0”. Upon receipt of channel Data Packet, XBus servo shall follow the operation which designated by Servo ID, no matter if the XBus servo is programmed with certain Sub ID numbers.
Some detail on XBus servo’s programming shall be explain it later.
XBus servo shall operate based on designated SERVO ID as well as same Sub ID, at maximum number of 4pcs of XBus servos simultaneously. As a default, all of the XBus servo is set as Channel ID: 0x01
Instruction value Instruction value shall be done by 2Byte of high & low, The concept of the value is based on conventional PWM signals. XBus servo is capable to operate within 850micro sec to 2150microsec. Other than these angle instruction value, XBus servo shall be loosened.
Following chart shows the value.
In case the limit value has been set, the value outside of such limitation shall be clipped, XBus servo shall not be loosened and stops at the point of limitation.
(Note: Depending on the setting XBus servo may be loosened) As a default, XBus servo has been set between 800microsec to 2200microsec therefore, limit value is being void.
This packet is set as undefined length, therefore all of the channel data which required by user has been embedded to one complete packet for transmission.
However, since it is not possible to designate multiple number of the same exact Servo ID, so the number of Servo ID is limited to 50pcs.
In order to make repetition, it is essential to make 4term of 4bytes as one complete mass to keep repeating so that each channel ID and instruction value shall be repeatedly written. Within this packets, Channel ID is not necessary be
in series. Also it does not have to be in sequence order. There is no limitation on this regard.
Basically, XBus servo shall read the packet from very beginning in sequence, therefore if there was a long packet, there may be a difference may appear within millimeters second level in timing at beginning and at the end. When a packet size are more than the buffer size of XBUS servo transmission, it becomes as an error even if CRC is normal. As a result, all of the packet be ignored, and it return to the mode where waiting for the packet to come in. Please be careful on this occasion because there will be no such status will not have any feedback. Basically, Each XBus device has the buffer which allow to receive at least of 16datas. In the XBus servo, normally, it has least 50 of the buffer which can be receivable.
Concerning the CRC8
This packet allows following CRC formula. CRC range is at beginning of the packet till the Byte before CRC, these are the all of them. As a reference, we have made the sample source at last page, please refer this as an example.
Every packet shall be checked on the CRC, it is very important point to create a source at the side of Host.
・Command data packet
On this packet, except the few exceptions, basically there are some response packet generated by using status command , So that host UART should be open the TX immediately (Few micro sec measure) after packet transmission completion, and, also be prepare for the Status Command packet reception.
However, internal Host UART has transmission buffer, Byte sequence for Packet must be completed and confirmed beforehand otherwise, transmission error may cause with incomplete receptance of the XBus packet.
At present, there is no clear statement of time-out is being set, but you may consider that transmission is failed within any of the reaction for 14mSec.
Concerning the “Command”
This packets are applied for following three(3) command
0x20 Set Command: Command to set a value along the order. Explanation
0x21 Get Command: Commend to set a value to read the value along the order.
0x22 Status Command: Command used for response (Not applicable for user)
When a host transmits “Set Command” or “Get Command”, the XBus servo perform to operate along the order and, as a result, Essentially, replies in Status Command which is the same order, same number of bytes.
Status Command transmitted by XBUS servo generally reply a present value with such order. In case of a reply from Set Command, depending on the situation, It does not reply the set value, it may be modified as a clipped value which were limited by the XBUS servo. .
If the order cannot be accepted by the XBus servo, Status Command shall be returns as modified value of Unsupported Order. In this case there is no Data2, therefore, be cautious that that size of order shall be one (1)byte smaller than
As described, there is a possibility of variation in Status Command ‘s Packet size so, be sure to judge the packet by 2 nd Byte to set the receiving length.
Concerning the Channel ID
In previous section, we have described about Channel ID, and is same specifications. At this point, it also applies with Sub ID. Thus, By using the SUB ID, it is possible to operate the XBus servo maximum of 200pcs. This Command is based on the premise of response therefore, it is essential to employ one single packet per one XBus servo.
On Set Command, by designating the “0x00” it effect with all the XBus servos which has all Channel ID. Only at this case, there will be no generation of the response packet on Status Command. Also, note that if you accidentally designate the 0x00 on GET COMMAND, there will be no response. So be careful on this setting.
Several XBus servo being connected to the host, and designate “0x00” when carry out ID change and/or the reset, All of the XBus servos become as same Channel ID. Later Data Command Packet shall operate all at same Channel ID’s XBus servos at same time and causes the confusion at the bus, therefore becareful to avoid this.
Concerning the Order and Data.
Following items explains Order and Data. In this packet, depending on the order, there will be no Data2 available and All of the packet’s Byte shall vary therefore, please be careful. 2Byte data unless otherwise specified, Data 1 become as Upper Byte, Data 2 become as lower byte. And it should be utilize as signed data.
Except the certain order, All order works basically in Operate Mode, it reflects the operation immediately when instruction succeed.
The parameter is not recorded basically in the ROM domain unless it transmit P arameter Write command. But, please be careful on the exceptional cases, it write the data immediately.
In addition, the XBUS servo works with the conventional PWM signal, but the following contents shall not be reflected.
Concerning the CRC8
This packet allows following CRC formula as previously described. CRC range is at beginning of the packet till the Byte before CRC, these are the all of them. As a reference, we have made the sample source at last page, please refer this as an example.
・Concerning the Interval between Packet transmission
Normally, on RC XBus receiver is sending out the packet in every 14mSec. This is a standard for the transmission interval between the packets, However, It is possible to shorter the interval considering the actual performance value of the XBus servo.
But In reality, it may be depend on the model so, presently, would like to state that 14msec is the guarantee value for transmission intervals including future developments. This issue becomes particularly important in channel data packet. When it expects a high-speed response action to XBUS servo, it is essential to speed up the pace for output instructions. It also vary the interval spacing depend on the volume of the packet how many of the channel being gathered for one packet. Smaller the channel makes the shorter the processing time for one packet.
However, please note in advance that If the transmission interval became too short, previous packet may be not processed fast enough to accept coming latest packet for process. In this case, subsequent packet become lost, so please take careful note that to retrieve the data packet, it is required to take least minimum amount of 1 Byte or more to be in an idle state.
As an example, based on the current models, upon actual testing, we have succeeded to receive the data packet within 1.5micro sec. amount with 4channel data. At this case, logical time on the packet is 0.84micro sec. and interval shall be as 0.66microsec. As well as the data packet amount of 50channels, theoretically, time frame on the packet would be as 8.2microsec.packet, Say operate this within 60frame per second, Frame rate shall be as 16.67msec, Generally speaking, Per calculation, this would be
enough duration for motion movement.
Note that this theoretical value is calculated when the bit series are precisely transmitted from host UART, and not calculated if the data has certain gaps between the Byte, so it may not perform as theory.
Also note that it is meaning less to shorter the Pulse Cycle width less than 1microsec. Because the XBus servo is operating on 1microsec.
But, in future, this may not apply.
In addition, it does not have a meaning to shorten than 1mSec because the XBUS servo control period of the current model is 1mSec. But for future models, it may not be limited.
●XBus Servo Programmer
Special programming mode “Expert Mode” manual instruction
Here are the explanation concerning the Expert Mode on XBUS Servo Programmer.
・Method , How to be in the Expert mode start
When turn on the XBus Servo Programmer, press the “down “ button simultaneously when apply the power. There will be no difference than normal power turning “ON” However there are significant number of difference in the function menu.
・To use the Expert mode,
As explained above, there is no difference than using standard mode however, all of the above
explanation with precise setting can be achievable with this extra functions.
【Products name】name] XBUS servo programmer price: MAP US$ 99.99
・Method of changing the channel ID
We do recommend not to change the channel ID as it may cause fatal trouble upon operation.
So Here below is the method to change, Channel ID shall not be change unless follow these steps. It does not apply to change the channel ID by sending the ID order. So Please take a careful steps to arrange the change of channel ID change.
1. Transmit Mode order to XBUS servo and transfer it in ID Setting Mode
2. Transmit ID order to XBUS servo and change ID (It return to an original mode automatically at this stage)
・Concerning the XBUS port on the receiver
Upon using JR PROPO’s DMSS transmitter and receiver system, Go to transmitter setting on XBUS. Change the XBus mode as “A” Command shall be transmitted through XBus receiver through JR DMSS transmitter according to the control as described above.
Basically, Channel data packet continues being sent out in an interval of 14mSec, and command data packet shall be sending out while adjusting the XBus servo’s parameter adjustments through transmitter. There are few items that you make a special attention while operating through XBus receiver’s port.
● The channel data packet has only for 16 channels as maximum frame. In case of using the transmitter which has more than 17 channels, the latter 4channels tends to change the characteristic of the data between lower channel data without your setting. Please do not judge only by the position of data. Be sure to check which ID are being used.
● Depending on the model of a receiver and/or the remote receiver, dummy data of 2 bytes may be inserted in the last of the packet just before CRC. This is useless data, so please ignore it.
● Even if it is indicated with a smaller (PWM use) number of channel on any XBus receivers, the XBUS packet just sending out the data from a transmitter normally without any shortage of data. XBus receiver will correspond to the transmitter channel not by the PWM indicated number of channels.
● The defaults value of the stick operation on transmitter is set as ±100%, and this means ±40 degrees (Travel angle of 120 degrees) or ±60 degrees (Travel angle of 180 degrees) in the servo. If you would like to set more these values, arrange the Travel adjust on the transmitter with ±150%, to be ±60degree. (on 120degree movement) or set as ±90degree(180degree movement) Please arrange necessary adjustment to suit with your desired servo moving angles by using travel adjustment on transmitter.
・Concerning the XBUS Converter,
Concerning the XBus Converter, If you wish to use PWM servo combined with XBus servos, there is XBus converter available. However, XBus converter limits the function of the servo and following are the only function available with.
● All of the transmitter function ‘s channel data packet (but only within 16 channels)
● Command data packet with following order.
Also note that 4port XBus converter is already allocated with Servo ID as “1”, and Sub ID as value of “0” “1” “2” “3” as default value. When you made a reset, please be sure to input the proper ID as desired.
Kindly note in advance that all of the XBus converter is fixed with PWM pulse width as 20microsec, therefore, it is meaning less to set the High speed packet on this converter setting. As a maximum extent, 14micro sec as fastest value.
・To structure the robot’s single joint with multiple XBus servo
Some of the bipedal walking robot’s employ with multiple number of the servo on one single joint. Link structured legs, (the following, link leg). In order to structure this movement on shoulder, roll axis, or coupled servo to strength the torque, etc. XBus servo be the best solution to program these movement.
It can be done very easily to set these movements by using SERVO ID, and different SUB ID. During the frame structure, Each XBus servo to be set with the Reverse, Neutral position, Maximum throw angle(travel), by making a precise adjustment on misalignment then robot should be operational mostly.
This adjustment value can be programmed once it is written as writing order then each XBus servo shall be memorized internally with settings. Even though it has been switched off, all the program has been memorized in the XBus servo. So it is very handy to use these XBus servo for robotic use. It probably need some tweak adjustment for time to time for maintenance.
During the motion transmission, each Servo ID +Sub ID gathered as Zero with in one single channel ID is useful. So same Servo ID maximum of four can be driven as a one complete mass. By using the XBus servo, It is possible to reduce the burden of the channel data packet generation, or motion making data.
・Concerning the HOST UART to be use only with TX.
The XBUS servo is originally designed to communicate by using in 1 line half duplex. Therefore, a transmission and reception requires the changes for half duplex communication for host UART, and an outside circuit may be required as well. However, if the following condition is acceptable, host UART can be operational without RX. Will not be necessary to provide outside switch circuit either.
● In operation, no need to check the situation of the XBUS servo at all.
● When perform the setting of the XBUS servo, should be connected individually.
● When multiple XBUS servos were connected, no need to transmit anycommand data packet at all.
In another words, if the XBus servo has been set and pre-programmed, RX does not use any channel data packet so, TX can be individually operational. It is recommended to use this method for easier use.
・Concerning the Micro Computer on XBUS servo
Currently, we are employing NXP(former company name Freescale) Micro Computer MKL16series, to driven with 48MHz. Therefore, if you require specific detail on voltage requirement, Port requirement, please refer with their instruction manual for further detail and information. For future, we are not certain if we continue to use, therefore, we cannot recommend to operate
within strict voltage level or other complex settings.
Also note in advance that MKL16 microcomputer has security program installed, therefore, enforcing the Micro Computer to readout, may clear all the internal program or memories. Upon such reset, it will be malfunction completely so, please be careful. It is require to make a necessary repair by re-write the program firmware. If there is no declaration upon repair request that you have clear the program, we will simply judge that Servo PCB unit has faulty circuit so, repair cost shall be quite expensive. So, be cautious on handling.
For your information as per below is the schematics sketch of the Signal input on the micro computer.。
（Copyright JR PROPO all rights reserved.）