When I Built my R2D2 replica, a need arose. There were DC motor controllers for wheel chairs and that was about it. The battle bots were not that common, so the myriad of speed controllers you find today, were not available. As a result, I decided to build my own. Many attempts later, the one that still works to this day, is the one detailed on this article.

Introduction:

Controlling a DC motor is no longer Extraterrestrial Science. There are two aspects two any DC motor controller: The controlling segment and the driver or power stage. You will find the driver to be almost the same deal on all occasions, an H Bridge driver of some sort. The H Bridge driver allows for speed control on both directions. This is highly desirable.

The control portion on the other hand, can be anything! A microcontroller, or a bunch of discrete components will do the job. I always prefer microcontrollers thanks to the flexibility they add. Even if they are more expensive, adding features later on proves so much easier.

In this application we will drive a 10A motor, so the driver has to be quite beefy. The motor will be controlled from an RC plane remote control, so the controller must receive this signal and then transform it to the signals needed by the H Bridge. Lets start the discussion!

The H Bridge Driver - TD340I from ST:

The driver is the electronic portion of the circuit capable of supplying large amounts of current to the motor. There is no way you can supply this current with a control chip. It is true, though, that some control chips have integrated drivers, but there is so much you can do. Per example, I have seen integrated control/driver chips capable of handling 3A motors. I want 10A! In order for a chip to supply 10A, the FET’s would have to be enormous. This would translate to a prohibitive cost. So it can be done, but I would like to see who on Earth will go through the trouble and waste said an implementation will cause.

NOTE Before somebody screams, large amperage can be done on chips if massive cooling is applied. Heck! This is not cheap either...

The solution? External FET’s and a predriver chip. FETs are rather cheap and can be mass produced in such a fashion that cost is not an issue. Of course, the control chip can not drive FETs easily either. Remember, it is a control chip. This is where the intelligence reside, not the power. The Pre Driver chip is then designed to take controller signals and polarize the motor accordingly. I chose the TD340I from ST for a few reasons:

1. I can add four FETs to control my DC motor. The FETs that I choose will determine how much current I can pass. The IRL520 will grant me up to 9.2A continuous. This is enough for me, but if not, I could choose any other stronger (and costlier) FET and have more current.
2. Control relies on two signals: DIRECTION and SPEED. We will talk about these signals, shortly ahead.
3. It provides a regulator for the microcontroller. My board now only needs one Power Supply input of 12V. The TD340I regulates this input down to 5V. Less components is always good!

There are some other signals the driver chip will work with such as the RESET, STANDBY and TEMP. They are useful to have implemented, but tying them to a logic level works too if you are not into switching the device off due to power saving modes and such.

The schematic below shows how to implement around the TD340I FET Driver chip. I recommend you also take a look at the TD340I’s datasheet which you can download HERE.

The Controller:

Often, I like to use the 20 pin microcontroller such as the AT90S2313/ATTIny2313. However, in this design there are far too many pins on said microcontrollers. This is when an 8 pin device comes in handy. You are talking about less space on the board, less signals to wire and less cost. You are also talking less memory space and less internal resources, but I assure you the ATTiny15 has more than we need for this application.

The ATtiny15 receives the RC signal and decodes the pulse width. In turn it provides two signals to the TD340I:

DIRECTION: This signal specifies the motor shaft rotation. When the pulse on the RC Signal is larger than 1.5 ms, this signal is HI and the motor rotates Clockwise (if wired properly). When the pulse on the RC signal is less than 1.5 ms, this signal is LO and the motor rotates Counter Clockwise.

SPEED: This signal specifies the motor speed. It is generated by means of the ATTiny15 Output Compare function working as a true PWM generator. The Duty Cycle on this PWM signal depends on the RC signal comming in. Signals close to 1.5 ms, will yield low duty cycle on the PWM. As the signal’s pulse width grows apart from 1.5 ms, so does the PWM duty cycle. Per example, a 1 ms input signal will yield a 100% Duty Cycle, but so will the 2 ms signal.

The table below offers a clearer example of what I mean:

RC Pulse Width DIRECTION SPEED (PWM Duty Cycle) 1.0 ms LO Full Speed Reverse - 100% Duty Cycle 1.25 ms LO Half Speed Reverse - 50% Duty Cycle 1.45 ms LO Lo Speed Reverse - ~10% Duty Cycle 1.5 ms Unknown, but Don’t Care No Motion - 0% Duty Cycle 1.55 ms HI Lo Speed Forward - ~10% Duty Cycle 1.75 ms HI Half Speed Forward - 50% Duty Cycle 2.0 ms HI Full Speed Forward - 100% Duty Cycle

It is important to understand the controller’s functionality. Since we have the versatility of the microcontroller, I was able to implement much more than just the two control signals:

1. The controller must decode the RC input signal into DIRECTION and SPEED
2. The controller will know when the RC input is present by monitoring the pulse width periodicity. If the RC Pulse is not present, the driver must be disabled.
3. The controller must eliminate noise from the RC signal when the Pulse is very close to the center position. This is very important because at 1.5 ms, any jitter on this pulse width would be toggling the direction on and on. Not that it is harmful, but more annoying, it is desirable to have it cleaned up.

The System:

The picture below shows the entire application as it was put together. CLICK on the schematic for a larger picture. CLICK HERE for PDF version download.

The Implementation:

Lucky for me, the Project Board I had designed for the 20 pin devices, also house an 8 pin device section. In fact, I could even have both microcontrollers running simultaneously if I wanted. In this case, all I needed was the ATTiny15 circuitry and access ports.

The picture below shows the prototype and the finished product. Notice on the prototype I had to use a SOIC to DIP converter. It would have been nice for the AT90SMiniPB board to have that socket, but then it would not have been general purpose, would it?

The bare board can be seen below. A few notes are in hand:

1. This application will work with up to 18V or so. This is because I am using the internal voltage regulator on the TD340I and the max voltage for this application is 18V. On my 24V design, I had to add an external regulator for the microcontroller, or simply supply the 5V or 3.3V externally.
2. The FETs were positioned standing up and close to each other. I am not happy with how this turned out to be. Although I have been placing a 12V fan which circulated air for the FETs to cool down, this implementation is not as clean as it should have been. If I were to redesign it, I would solder the FET backs into the boards with some PCB heat sinking. It would be a larger board, but then larger is better when dealing with thermal dissipation.
• I could have added metal heat sinks to the FETs but they are too close. I am certain that with proper machining the problem could be solved. But to be honest, why not solve it on the board? This is where the root cause really is!

The Firmware and Files:

This product was never featured on Avayan Electronics, as I never considered it a feasible product. Plus, the TD340I is not that easy to find. It is an automotive part and ST apparently does not want the device released to the public. Too bad, because it is really cool!