Designing my own H-bridge board, I've done the math that I believe is correct but its always nice to get a second pair of eyes.
The chip: SI4564DY (N + P mosfet array) Worse case calculations:
N-channel: 20 m-ohm Rds(on)
P-channel: 28 m-ohms Rds(on)
Chip is rated for 3.2W
Max current (stall) for motor is 5A @12V
Based on this, in the worse case scenario its ~1/3 its power rating, and would only get moderately hot.
Considering its on a PWM and not likely to stall while at 100% duty cycle, normal operation should see far lower temperatures.
When the chip is in a box, and the temperature inside the box is 50 degrees, the parameters change for the mosfets.
You calculate the power with the resistance of the mosfet, but you forget that during switching it will get hotter. I'm not sure, but I see 70ns rise time in certain conditions. Combined with the rise time of the Arduino and the signal from the Arduino to the gate...
That's hard to calculate, let's double your 1/3 into 2/3 and you are still fine.
Well the arudino PWM frequencies max out at 62.5KHz, which is 16nS. Perhaps a little faster would be better but it is what it is.
Right now my next biggest issue is power delivery from the battery.
The batter is 14.8V charged and 12.8V discharged, and the motor is 12V @5A.
I know the motor isn't going to blow up if you put 3 more volts on it but the proper way is to regulate. I'm going to have to heat sink the smitten out of a LM1084 (12V 5A) just to barely keep it in spec should a motor stall happen.
P.S This is going to be a open air board, at least in theory right now. Heat build up in ambient is a none issue.
harddrive123:
but the proper way is to regulate. I'm going to have to heat sink the smitten out of a LM1084 (12V 5A) just to barely keep it in spec should a motor stall happen.
Proper : regulate : motor supply? I disagree.
Anyway.
Don't worry about peak charge so much.
When the motor starts to do any work the battery will load down.
If a motor stall occurs then the deal is nothing but coil resistance (wire) - that'll load down your battery good.
Clearly Grumpy mike doesn't understand the concept of default settings vs messing with the timers. Using a different frequency divider will mess with your delay() functions, and any other library that uses timer2.
I just ignore him, in my experience he's more of a poster then a answer-er. Take what he says with a grain of salt.
Don't worry about peak charge so much.
When the motor starts to do any work the battery will load down.
If a motor stall occurs then the deal is nothing but coil resistance (wire) - that'll load down your battery good.
14.8V is the load voltage, unloaded its 16.8V.
My battery is a lithium-polymer 5Ah 35C continious rating, at 5A its not going to get loaded down, not even close. This thing was previously used to power 4 30A brush-less motors on a quad with power to spare. It wouldn't likely start loading down till it reached at least 175A at which point the cells are in high risk mode of being damaged.
14.8-12 = 2.8 --> 2.8x5A =14W, a heatsinked regulator should be able to handle that. Over time its only going to decrease.
Clearly Grumpy mike doesn't understand the concept of default settings vs messing with the timers. Using a different frequency divider will mess with your delay() functions, and any other library that uses timer2.
Clearly you do not know what timer is used to define delays.
I just ignore him, in my experience he's more of a poster then a answer-er.
Odd that when you consider that you are more of an asker of questions than a listener of answers..
harddrive123:
Well the arudino PWM frequencies max out at 62.5KHz, which is 16nS. Perhaps a little faster would be better but it is what it is.
[ 16us, not 16ns!!!! ]
I wasn't talking about frequency, I was talking about switching speed.
You want your devices to switch in < 1% of the PWM period, whatever it
is, for reasonable switching losses (which means < 2% of the cycle is
switching)
At 10kHz PWM you want < 1us switching time, for instance. For very high
power applications switching losses usually dominate because during switching
the devices dissipate a substantial fraction of the load power, and you switch the
devices hard (typically an amp or two into the MOSFET gates is needed to
achieve this).
For your low power bridge this won't be necessary but you will need to calculate or
measure the switching time (gate driver source resistance x effective gate capacitance)
For instance you sometimes see MOSFET H-bridge circuits on the internet with
10k gate resistors - typically that would mean a switching time of perhaps 10 to 300us
depending on the device, completely inadequate for PWM.
With a 220 ohm resistor from an Arduino pin you might get 0.2us to 6us, so you
will need to check with the actual gate effectice capacitance of your MOSFETs.
Gate effective capacitance for this calculation = total gate charge / gate drive voltage.
So a logic-level MOSFET with a 7nC gate charge = 7n/5 = 1.4nF. With 220 ohms
that gives a time constant of 1.4n x 220 = 0.3us (pretty fast).
I sometimes use huge MOSFETs with 100nF gate capacitance or so, and these are
driven from MOSFET driver chips with perhaps 3 ohms output resistance, giving
a time constant of 0.3us again...
PWM frequencies are tied together in pairs of pins. If one in a
pair is changed, the other is also changed to match:
Pins 5 and 6 are paired on timer0
Pins 9 and 10 are paired on timer1
Pins 3 and 11 are paired on timer2
Note that this function will have side effects on anything else
that uses timers:
Changes on pins 3, 5, 6, or 11 may cause the delay() and
millis() functions to stop working. Other timing-related
functions may also be affected.
And this is why you take what he says with a grain of salt, unless he thinks the learning blogs are wrong?
I've had timer conflicts in the past (servo + softserial), this isn't something I just looked up.
Odd that when you consider that you are more of an asker of questions than a listener of answers..
I don't consider vague, off topic, miss-leading, un check-able answers to be answers at all.
16us, not 16ns!!!!
typo
You mean I need to calculate the RC time constant of the gate capacitance and the resistor be that a series or pull/down config, and keep that time value within ~1% of the PWM half cycle.
And this is why you take what he says with a grain of salt, unless he thinks the learning blogs are wrong?
I've had timer conflicts in the past (servo + softserial), this isn't something I just looked up.
I don't get your point. There is nothing in conflict with what I said here.
You said that changing timer 2 would change the delay function. This is wrong, are you going to admit that?
You said the maximum frequency of the PWM output was 62.5KHz. This is wrong, are you going to admit that?
Changes on pins 3, 5, 6, or 11 may cause the delay() and
millis() functions to stop working. Other timing-related
How many times to I have to post the same stuff before you read it? I'm not saying anything, they are.
You said the maximum frequency of the PWM output was 62.5KHz. This is wrong, are you going to admit that?
I made it very clear that I was talking about the DEFAULT SETTINGS. One would be very foolish indeed to disable the system clock functions (delay(), millis() )in a motor control application just so that they could make the motor just a little bit more efficient.
Just so you don't look like a fool, when I say disable I mean un-usable, most like it will still output values but what it thinks is 1mS won't be anywhere close to 1 mS.
Later I'll post my logic wiring for everyone else interested. Undoubtedly not a coincidence; driving the p-channel at 12V while driving the n-channel at 5V makes them near perfectly match up in spec. (Rds(on), gate capacitance...)
Lets try with just one point so as not to confuse you.
Changes on pins 3, 5, 6, or 11 may cause the delay() and
millis() functions to stop working.
Now this is not wholly correct. The millis timer and delay are controlled by Timer 0. No changes to Timer 1 or Timer 2 are going to affect Timer 0 and hence they will not change delay. It says "Changes on pins". What do you think they mean by that? Change from zero to one? Changes in the duty cycle? Changes to the timers behind it?
Now here is a piece of news for you. Those playground article are written by anyone, they are not official. Even the official stuff has errors in it. That is what the forum is all about.
I made it very clear that I was talking about the DEFAULT SETTINGS.
No you didn't you said:-
harddrive123:
Well the arudino PWM frequencies max out at 62.5KHz, which is 16nS. Perhaps a little faster would be better but it is what it is.
Right now my next biggest issue is power delivery from the battery.
The batter is 14.8V charged and 12.8V discharged, and the motor is 12V @5A.
I know the motor isn't going to blow up if you put 3 more volts on it but the proper way is to regulate. I'm going to have to heat sink the smitten out of a LM1084 (12V 5A) just to barely keep it in spec should a motor stall happen.
P.S This is going to be a open air board, at least in theory right now. Heat build up in ambient is a none issue.
That is the whole of your post. Nowhere in that little lot did you mention default settings. What do you mean by that anyway. You can't change anything let alone any PWM frequency with the default settings. If they are default then why are you talking about 62.5KHz.
Later I'll post my logic wiring for everyone else interested. Undoubtedly not a coincidence; driving the p-channel at 12V while driving the n-channel at 5V makes them near perfectly match up in spec.
That is the most desperate post for attention I've seen in recent memory. Pushing the term, taken out of context to the limits and raising several questions like "where you born without common sense?"
I make references to actual articles, supported by Arduino under there learning section. He calls them incorrect with no references and expects us to whole heatedly assume he can't be wrong.
Like I said just ignore him, I'd have better luck having rational conversation with a headless chicken.
harddrive123:
I make references to actual articles, supported by Arduino under there learning section. He calls them incorrect with no references and expects us to whole heatedly assume he can't be wrong.
Grumpy was the first guy who called me out for something, on one of my very first posts on this forum back in 2009 or so. It irked me then, but I got over it, and I learned an important lesson (always define your acronyms before you use them - that way people understand what you are talking about).
Needless to say, I trust Mike's judgement - he has proven his worth and knowledge are immense over the years. Yes, sometimes he goes off on a tear - we all have bad and/or "off" days. But that's his charm; I always hope that someday he and I could go for a pint at a local pub - he seems like someone worth getting to know better. But I digress...
As far as the Arduino site's learning tutorials? Above all, I have learned to take most of them with a "grain of salt" over anything Mike says. Indeed, between the known errors in both the documentation of the Arduino, the references, and the learning examples - none of which ever seemingly get fixed (then again, I don't constantly check them - but I am certain there are documentation bugs still out there which have been there since the beginning). It's kind of like the extra 0.5 inch header offset, which is also a bug in the design due to an admitted 11th hour "too-tired-to-be-working-on-this-but-gotta-get-it-out" mistake made by the founder. Always been there, not going to change now - even if it would help the project overall.
Here is a snippet of wiring.c, taken from IDE version 1.5.7 beta.
#if defined(__AVR_ATtiny24__) || defined(__AVR_ATtiny44__) || defined(__AVR_ATtiny84__)
ISR(TIM0_OVF_vect)
#else
ISR(TIMER0_OVF_vect)
#endif
{
// copy these to local variables so they can be stored in registers
// (volatile variables must be read from memory on every access)
unsigned long m = timer0_millis;
unsigned char f = timer0_fract;
m += MILLIS_INC;
f += FRACT_INC;
if (f >= FRACT_MAX) {
f -= FRACT_MAX;
m += 1;
}
timer0_fract = f;
timer0_millis = m;
timer0_overflow_count++;
}
Take a look in there, and you will see that millis() uses Timer0.
He didn't correct me, I made a generalized statement that is correct to every arduino coming out of the box and he turned it into some silly argument about how I was wrong because I didn't spend half a page talking about how it could be changed?
Edit: After re-considering the practicality of the PWM of the arduino, I'm realizing I'm over designing and over specing in some area's, I'll re-post a design later.
