Other Motor Control (PWM)

PWM Motor Control Using Other H-Bridges

This is how our next generation Motor Controller, based on PWM. developed from the original WiFi Motor Controller. Our son, Nick, developed it to remotely control his Lionel trains. Substitute remotely controlling our garden scale trains on the Barkyard and you have the motivation behind the next generation Motor Controller. The initial prototype is giving us fits trying to make sense of the results we're getting. They're outlined in the previous segment if you skipped ahead.

Where we left off was modifying the current sensing while waiting on the new H-Bridge components. These include an L298N BiPolar dual full H-Bridge module, a BTS7960B dual half H-Bridge module, and a VNH7019 Dual Full H-Bridge module. The L298N is ubiquitous, and therefore very inexpensive. We're talking 5 for under $15! Less than $3 each, but there's a reason for that. What's gained in price is traded for power handling, or lack thereof.

Many block detector circuits for use in smaller scales rely on back to back diodes, one for either current direction. The voltage drop across the diode is about seven tenths of a volt. Multiply that by the current to determine the power it must dissipate. At ten amps, that's seven watts, or about what a night light bulb consumes. While the bulbs don't get too hot, they still get warm. Resistors capable of withstanding five or ten watts are HUGE in comparison to the diodes. Either way, power is wasted.

While seven watts doesn't seem like much when we're talking about a nightlight bulb, it's a tremendous amount of heat for an integrated circuit chip to dissipate. Without a proper heatsink, the component will begin thermal limiting its performance before it fails outright. So if one H-Bridge circuit is heating up, then two of them on the same chip ought to be glowing red hot. There's a reason why the L298N is supplied with a HUGE heatsink... And it get's too hot to touch while operating even at low currents.

Add its 2A maximum current limit to the mix, and it's easy to see why we need to scratch it off the list. It was worth a shot to better characterize whether the issue is with the H-Bridge or PWM itself. So queue the BT7960B. It uses MOSFETs rather than bipolar transistors. Without going into too much detail, that simply means it has much better power handling characteristics. This unit is meant for automotive applications and will handle a peak current of 43A at 45V!

The trade off is greater expense for greater current handling. So only two for under $15. They also carry a HUGE heat sink, but it's unnecessary for the low currents we're controlling. Of note is even though this is a full H-bridge module, it employs two half bridge modules to accomplish that. Each half bridge is a module itself, made up of three different chips in the same package to optimize power handling and heat transfer. That's probably too much information, but felt it worth mentioning.

Also of note is this is really two half bridges, so the control interface is different than most full H-Bridges because of it. The PWM pin is still PWM, but rather than a single direction input, it has two enable inputs, one for each half bridge. In effect, only the half bridge that is enabled is connected to the supply voltage. The disabled half is connected to ground by default.

This required more software changes to account for the difference in control outputs. While it's similar to the L298N, it's different enough to warrant its own type when configuring the hardware at startup. THe VNH7019 is different still, and we still have yet to get to that one, but it seems prudent to have a handling for each type wrapped by a set of interface routines to handle all the functions.

In any case, we "accomplished" the characterization of the effects of PWM on our trains. Our findings? It's PWM itself that's causing problems with our DC equipment. The outcome is disappointing. It appears the only way to run our DC equipment is to supply DC power. There is still the possibility to embed the motor controller in the equipment itself, controlling the lighting independent of the motor. That way, we can use the higher frequency for the motor and avoid the directional lighting pitfalls. Even DCC, but more on that later.

Even more time was spent trying to analyze and solve the current sensor problem. And the MOSFET H-Bridges have built in current sensing, but it's different from the Hall Effect current sensors as well, meaning even more software changes. And this time it affects the user interface as well. Current readings are updated every tenth of a second and reported back to the user interface. It was all but useless trying to track those numbers flashing past faster than sense could be made of them.

The difficulty was overcome by adding a Data Driven Document (D3) component to visualize the data. Essentially javascript updates an SVG image in "real time". That's a gross oversimplification, but sums it up nicely. Each new current sample received updates the display. But that's not the end of the story. The javascript and D3 component was "optimized" for the crazy range of values described in the previous Cytron segment. Even a means of tracking the quiescent value was added to ensure more accurate readings.

This led to an attempt to make the readings interrupt driven, thinking that the value needed to be read exactly when the PWM signal changed. Both rising edge and falling edges were specified, but no matter what, the values were still all over the place. Senseless. Until the visualization of the data helped to make clear what was happening. It appears that until the PWM frequency reached 2.5KHz, the built in low pass filtering was inadequate to keep aliasing from occurring.

What'd he say? When sampling data, the input frequency range must be filtered to eliminate everything above half the sampling frequency. In this case, the PWM frequency. The data sheet of the hall effect sensor says the built in cutoff frequency is around 1.5KHz, meaning that until the PWM frequency is greater than 3KHz, the data is suspect. Without going into even more boring detail from sampled domain theory, suffice it to say that those hall effect sensors "function as designed".

While it became a moot point getting the VNH7019 integrated and operational, it was added to the mix for future use. Both the VNH7019 and the BTS7960B have built in current sensing. It's not like the hall effect sensor where the output adds to or subtracts from a quiescent value. These output a current proportional to the actual current flowing through the device, namely a ratio of 1 to 8000, or 1mA per every 8A. A suitable resistor is then chosen for a desired voltage proportional to the current.

Because this operates in a much different fashion, the javascript and data processing for the D3 component needed to know what motor controller was being used. That functionality did not exist and needed to be added before the D3 operation could be modified. Just another reason why it made sense to integrate the VNH7019 while we're at it. Two ways to test the new current sensing are better than one.

That leads us to the next logical step in our motor controller evolution, digitally controlled DC using a Digital to Analog Converter (DAC) to adjust the output of a buck converter. It took some doing to come up with a viable design, but it works like a charm! Follow along for the next step in our motor controller evolution...
See More...

PWM Motor Control Using Other H-Bridges

Join our newsletter!