RE: Half Duplex UART for TTL Commincation and Wiring w/ the HC126 and HC04

Sorry I am not Will :smiley:

But the TX_data, RX_data, and Direction_Port are three IO pins that are needed from your dev board or the like.

In particular the Dynamixel Servos use a Half duplex protocol, that is TTL data pin goes to you dynamixel servos and it carries the Serial data to and from all of the servos.

You need to have the direction port set to know which direction the data should be going. That is are you sending data from your host to the servos or receiving data form the servos.

Your controlling software needs to be knowledgeable enough to know when to set and clear this IO signal. Most of the time the code will do something like:

digitalWrite(Direction_Port, HIGH); // assumes HIGH is for TX, may be low
<Do Serial.writes to output your packet>
DynamixelSerial.flush(); // make sure the TX fully completes 
digitalWrite(Direction_Port, LOW); // go to RX mode. 

And you need to make sure to not do this when you are expecting a servo to respond, or your packet will collide with the data the servo is trying to send.

Hope that helps

Hello @Kurt,

Seth here. Thank you for this explanation. I have not exactly found time to promote more findings in this dept. so far.

I should be able to find more time next weekend or this week. Times are odd and tasks are heavy now.


P.S. I will update you as soon as I get this entire circuit up and running w/ the servo, a power supply, and the BBB (3.3v logic board).

@silver2row Sorry for the late reply. I just came back to work from unusual serial holidays + weekend.
Like @Kurt mentioned above, TX_Data, RX_Data, Direction_Port supposed to be connected to the Uart TX pin, Uart RX pin, one of GPIO pins in your MCU or the “BBB” respectively.
Since you are using 3.3V logic board, you need to pull up the DYNAMIXEL TTL Data pin to 5V across the 10kohm resistor.
You could try skipping this 5V and pull up resistor, but the communication could be very unstable.

From the suggested schematic that I posted in the above, it looks like the 5V pull up on TTL data pin is not working well.
Though 3.3V will be still considered as HIGH for 5V TTL, this will be very vulnerable to a signal noise.
Instead of using 5V pull up across the 10Kohm resistor, it will be better to use buffers on the TTL bus as Kurt suggested.
Thank you.


@Kurt and @ROBOTIS-Will

You guys…thank you again for adding more support to this cause. I tried to make some circuitry. I failed so far but I think I figured out how to make an amplifier out of the HC04 and HC126. I tested the circuit instead of directly plugging it in to the BBB or Servo. Phew. I need to configure things more before I can understand what it is that needs to happen.

On the HC126, I think I misread what exactly I need to do to conform to its standard and the instructions for that specific chip. Dodged another bullet. Phew. So, my chips are still intact and the Servo/MCU is not damaged either.


P.S. I will keep plugging at it to see if I can alter things within the chip with source and/or how to communicate with both chips in @ROBOTIS-Will diagram. Anyway, I am playing it safe for now. I only have so many boards to damage before opting to purchase new ones. So, safety freak I “be.”


I will make a schematic soon of what I have done to see if this schematic is of any use for this particular AX-12A.


P.S. Sir, is the Direction_PORT on the sample.png schematic a GPIO pin on my board?

Hello Sir,

I compiled the SDK on my linux host SBC. The python3 scripts work but I am receiving an error.

Succeeded to open the port
Succeeded to change the baudrate
[TxRxResult] There is no status packet!

What is the status packet?



Sir, is the Direction_Port a GPIO or PWM pin? I can use either but I am unaware of what Direction_Port means.


P.S. I have the communication down pat but the Direction_Port is the missing link so far on my end. The AX-12A turns on for a bit but then the LED fades out. I tried 9v and 12v. I am getting close. Anyway, I will produce a schematic when it is all done and completed.


The DIRECTION_PORT should be connected to a GPIO pin so that it can control the Input / Output direction of data from the buffers.
[TxRxResult] There is no status packet! error means that your program failed to receive the status packet from DYNAMIXEL.
Please refer eManual for more information about the status packet.
You should set up a correct direction control in order to communicate with DYNAMIXEL.

If you are using an SBC with available USB port, you could simply use U2D2 + U2D2 PHB to control DYNAMIXEL.

Thank you.


Okay. No issue. Thank you.




I finally got connected via the Wizard. I am not sure how to use it just yet but I will find the manual and figure it out.


P.S. Does the Wizard work with 64-bit machines or does it only work with 32-bit machines?

Glad that you figured out the connection and successful communication.
DYNAMIXEL Wizard 2.0 supports 3 major OS so please refer to the eManual below.
If you are using 32bit Windows, the software should work on your machine.


Sir…w/ the SDK, can I run as python3 and receive feedback via the console or should I type up my own source from your SDK?


P.S. I installed dynamixel_helper via pip and I am trying it now. I have failed so far but I think I need to alter the source of the DynamixelSDK to suit my needs.


The codes in the tests directory is written to be run under Linux.
I’d recommend to check if a correct data is transmitted from the port on the control board before getting the response from DYNAMIXEL. will work as is if you are running Protocol 2.0 DYNAMIXEL with the factory default setting on Linux.
Below products will work with example on Linux :

  • XL430-W250-T
  • All XM/XH430 series
  • All XM/XH540 series

Hello Sir,

@ROBOTIS-Will the UART channel and GPIO onboard my SBC works. I have tested it. I need to use Protocol 1 b/c I have an AX-12A only. I have two of them.

Should work under Linux with Protocol 1?



My bad, let me rephrase my last comment.
The test codes under the Protocol2_0 directory is written for Protocol 2, and you can use test codes under Protocol1_0 for your AX-12A.
If you haven’t change any setting on AX-12A, the code should work on your Linux without any change.
If you are using an embedded controller, this python code may not work as the port defined by DEVICENAME will work differently.
For more accurate information, please describe your development environment with more details such as SBC product name, OS, version, which port name your UART is assigned at, and etc.
Thank you.

Hello Sir,

Okay. No issue. I understand that I was not giving the entire view. So…

I am using a BBB (BeagleBone Black), Linux Debian 10, kernel 4.19.x, and DEVICENAME is equal to “/dev/ttyS2”.

"/dev/ttyS2" is my UART Ports onboard the BBB.

I have been running through the DynamixelSDK to change some things under silver2row on This way, when I clone it, I can then use sudo python3 install to get things working properly.

I know I do not know a bunch about you all’s SDK so far.


P.S. My GPIO pin is P9.12 and I have it setup as GPIO. I can add a library in the source to make it so I can control the GPIO with code.

Thank you for additional information.
It looks like you haven’t modified the writePort function in the which will control your GPIO pin for direction control.
If you take a look at the writePort function in port_handler_arduino.cpp, you’ll see setTxEnable() and setTxDisable(). These functions control the GPIO pin of the Arduino related boards in their HAL layer. You should do the same for your python code in order to make your code work correctly when sending or receiving data.
Thank you.


Hello. Okay, you rule. I will test this later. I was not even aware of this .cpp file called port_handler_arduino.cpp and I must have gotten mixed up in the Python source thinking that I could do everything w/ Python. Oops.

Again, and I repeat, you rule!


My pleasure!
Please let me know how it works as your case can be an important reference for other users as well.
I’m considering creating a tutorial for a similar case like this.