Help in making my BLDC controller

The Vb pin should show a more-or-less constant voltage referenced to the Vs pin. It's a floating supply, so the ground-referenced voltage will vary. There will probably be a little bit of ripple to it for the charge-discharge cycle, but it shouldn't be too large. Also, 0.1 uF is too small for the bootstrap cap. You should probably use a minimum of 1 uF, 2.2 uF or so would be even better. A ceramic cap would also be much better here than an electrolytic. Electrolytics have too much leakage current. It should be fairly easy to find ceramic caps in the 1-4.7 uF range which would be ideal.

Based on what you've said, it seems likely that something is preventing the bootstrap supply from working correctly. The driver chips have an undervoltage lockout, so if the bootstrap voltage is too low the gate drive signals will not be sent. The cap being too small might cause that, but probably not. It seems likely that something else is wrong in the circuit. I can't really speculate beyond that.
 
Hey guys.
I powered everything with batteries instead of switching power supply to exclude another source of problems.
Today I was testing again and low side was working flawlessy as usual but no way to get something solid from higher side, so I decided to get the bootstrap first working on a breadboard to really figure out something.

This is what I did:

schemadh.jpg

Edit: on my pc image is not showing, if its the same 4 you here`s the direct link: http://imageshack.us/photo/my-images/696/schemadh.jpg


Then i "fed" its Vcc with 12v and also I gave 12v to the Vs, expecting the bootstrap to work and actually see a potential difference of a few volts between VS and Vb pin (probe 1).
There was none, even pulling the Hin pin high or low nothing happened. Still, the low side was working as supposed, so there must be something wrong with the bootstrap but i cant really figure it out

Help please :cry:
 
Like rhitee was saying, make sure your capacitor is big enough.

For a similar type of controller, I calculated my caps to need to be 2uF (according to International Rectifier formulas) or 4uF (according to Semikron). Can't find the appnotes right now, but they are on their web. I still have my calcs though, and the language at my uni is English (EE-student), so I do much of the electrically related stuff in English, including this. PM me if you need the calcs, but I can't tell you what each entry means, this was sometime last year. :lol:

You can also skip these calculations all together and go for a >2uF cap, electrolyte or not don't matter that much if oversizing. And they virtually can't be too big, I have used 22uF at some point.

Your connection looks fine. Make sure you energize Vs after Vcc is applied, or better yet, try and switch Vs between 0 and Vcc, frequency not important. Important is that your bootstrap cap is >> than the gate capacitance, and that HO is not connected to anything but an undamaged FET or a correspondingly sized cap while testing.

Personally, besides scoping, I find connecting a really small motor is a good way to debug the drive. It should have high enough resistance not to damage anything if shorted even for several seconds, and spin very easily to signal your are on the right path. Mine is a thumb-size hall-sensored Techtop that I got from a local electronics company. If HIN is active at PWM frequency, your schematic should work.
 
The bootstrap won't do anything if you apply constant voltage to the Vs pin.

In the controller, the Vs pin will be switching between zero and Vbatt as the high and low FETs switch on and off. To test it on the bench you need to duplicate that by feeding Vs with a square wave. The amplitude doesn't really matter.

To do a really, really basic functional test you can tie Vs to ground. You should see a little less than Vcc at the bootstrap pin (Vcc minus a diode drop). You could then apply a signal to HIN and see if HOUT switches.
 
Thank you. I won't get bored of repeating that, your help is insanely valuable to me and I hope I'll manage to share to someone else the knowledge you are passing to me. :D

Performed the rhitee05's test and the thing is propely working, the output is switching and if fed with a squarevawe it actually "bootstraps". I was going wrong because I thought the IC cointained a switching thing in order to generate the squarevawe for bootstrapping but clearly I was wrong. It happnens :lol:

Incememed, I am glad that another Engineering student follows this 3d(the other one is me, just done with first year of engineering of automation), may you please mail your calculations to belgxx@hotmail.it?

Seems it's time for me to do the big jump and connect a motor... I'll go for that following your security advices and be back with news :wink:
 
Hey guys! I connected it to a motor, but it doesen`t work.

Arduino is propely reading all 3 the halls, (which are spaced 17.14 degrees) controls the outputs propely according to the code but it doesn`t make the motor spinning. Even if i manually move them around the can i can not get anything more than little "bumps" :cry:

What should I do?

My only doubt is that 10k ohm pull down resistors on both high side and low side msofets may be too big (especially for the bootstrapped side) but still I don`t focused so much on that since a lot of current is being pushed thru the windings. Could those resistors be the problem or at least part of it? I am thinking about replacing with 100k

Also I am going to lower switching freq down to less that 10 khz, just to make things better anyway I hardly see that being so big of a problem to make the motor not even spinning

tnks for your help :wink:
 
rhitee gave good advice. There is a follow on "trick" I usually do in the initialization code, before we go into the main loop, I typically turn all three lower FET's on to specifically charge the bootstrap sections. Think of it as bringing the engine up to speed before you first engage the transmission. I like everything to be determinate. It helps preclude unexpected outcomes.
 
The trick suggested by bigmoose is a good idea. The bootstrap charges when the phase is low, so holding them low briefly on startup ensures that they will be charged. The circuit will still work if you don't do this - it just might take a few PWM cycles to charge up.

You should probably make sure you have the right connection of the Hall sensors. If the FETs are switching and outputs are (supposedly) correct, the hall configuration seems like the most likely candidate. Try switching which sensor is connected to which input and see if you can find a configuration that spins the motor.
 
Great! I`ll go for a new test run with the trick on the lower mosfets and trying to change the hall sequence and placement, proper pwm freq and 100k pulldowns.

I also posted a question about hall placements in the proper topic, so we "keep the knowledge organised" ,I`d love you to help here : http://endless-sphere.com/forums/viewtopic.php?f=30&t=15686&p=447089#p447089 :D


I`ll be back soon!
 
I`m getting pretty desperate, this thing doesnt wanna work :(

low side phase 1 mosfet put up his holy smoke, no idea why that happened. I removed them from the board and nothing happens, no pwm buzzing, nothing at all, only high side "having a life" was number one.

I will now draw a schematic up to the smallest wire and post it here, this is my last attempt before giving up. :cry:
 
That's a good idea, this forum will spot any anomalies in your schematic in a blink.

Another remedy might be to first make sure everything else in your application is working as expected, and then focus on the bootstrapped high side. One way to do that is to build a simpler transistor stage by temporarily replacing your N-channel high side FETs with P-channel type. They don't need any extra components to operate, just the gate on/off (although inverted; gate high means off, gate low is on). Once the motor is spinning happily in this configuration, the complexity of the bootstrap configuration can be added.
 
I approve your idea.
On Monday I`ll send an order of a few components (needed to fix my lawnmower) to RScomponents and I`ll add P channel mosfets so I can take you advice.

Attached is the schematic, let me know if it is correct and also if it looks "ok" for a schematic :wink:

the mosfet driver schematics (to see the pin layout and maybe other things I don`t even know about) is attached too

here is the code too, it follows the pattern found here http://dc-brushless-open-source-controller.googlecode.com/files/FollowedScheme.jpg

Code:
[pre]//commutatoR, Pwmming LOW SIDE

#define S1 0// 3 hall sensors, on the first 3 pins of Uncle Ardu
#define S2 1
#define S3 2

#define H1 7// 3 digital outputs
#define H2 8
#define H3 12

#define L1 9 // 3 pwm outputs WAS 3 5 6, CHANGED TO BE ABLE TO SET PWM FREQ
#define L2 10
#define L3 11

#define GAS 0 //gas (AKA THROTTLE) potentiometer pin
#define CURRSENS 1 // current sensor pin



void setup(){

              TCCR1B = TCCR1B & 0b11111000 | 0x02; // change freq for pins 9 & 10
              TCCR2B = TCCR2B & 0b11111000 | 0x02; //change freq to 11 & 3, to 3.9 khz as above
              
              pinMode(H1, OUTPUT); // the 3 highside digital output 
              pinMode(H2, OUTPUT);
              pinMode(H3, OUTPUT);
              
              pinMode(S1, INPUT); // the 3 hall sensor, imputs
              pinMode(S2, INPUT);
              pinMode(S3, INPUT);
             } // If I`m not going wrong only digital pins should be configured in here
             
 
 
             
int valS1 = 0; //variables where hall states are saved, so we read them only once
int valS2 = 0; 
int valS3 = 0;   

int gasread; //the raw analog read from the throttle
int stadiocorrente;// the value that, basing on the halls readings, indicates the currint step of the commutation (goes from 1 to 6, with 0 being incoherent readings)
int ultimostadio;//"LAST STEP", used to see if the rotor entered in a new step since last commutation occured. Extremely useful, allows to re-write phase status only when really needed
int gasprint = 0; //gas value after some statistical math to smooth its value and after current limiting "decisions", ready to be printed on the pwm outputs
unsigned long timenow; //millis now since arudino booted
unsigned long timelastwrote;//millis since arduino booted measured when last pwm writing function was performed 



void loop(){valS1=(digitalRead(S1)); // Now we get data from the 3 halls
            valS2=(digitalRead(S2));
            valS3=(digitalRead(S3));
             
                                      //Now we find wich step are we in 
                                      
            if(valS1>0){             //IF S1 IS HIGH
                         if(valS2>0){// OK NOW AS A SUBROUTINE OF "YES S1 IS HIGH" WE EVALUATE S2, AND, IN THE SAME WAY, S3 AS A SUBROUTINE OF BOTH S2 HIGH AND S2 LOW      
                                       
                                     if(valS3>0)   {stadiocorrente=2;
                                                    } 
                    
                                      else{stadiocorrente=3;};                                
                                     } 
                                       
                                       
                          else

                              { if(valS3>0) {stadiocorrente=0;///SE S1 E` ALTO, MA S2 E` BASSO.... VALUTIAMO S3
                                             }   
                                            
                                else {stadiocorrente=4;};             
                              };
                        }            

            
            
            
            
           
           
           
           
           
            else                   //WELL, S1 IS LOW...
                {if(valS2>0){   if(valS3>0){stadiocorrente=1;} // // OK NOW AS A SUBROUTINE OF "S1 IS LOW" WE EVALUATE S2, AND, IN THE SAME WAY, S3 AS A SUBROUTINE OF BOTH S2 HIGH AND S2 LOW
                                  else {stadiocorrente=0;};
                            
                            }
                             
                             
                
                 else 
                   
                    {if(valS3>0){stadiocorrente=6;}
                       
                     else{stadiocorrente=5;};
                      };
                             
                             
                             
                };
            /////////// BY NOW WE KNOW WICH STEP ARE WE IN! COOL!///////////
         
                                  
                                    
                                    
                                    
                                    
                                    
timenow=millis(); // we get "what time is it uncle Ardu"?
                                    
      if ((stadiocorrente!=ultimostadio)or((timenow-timelastwrote)>100)){    //IF THE COMMUTATION STEP NOW DETECTED DIFFERS FROM THE ONE DETECTED ON THE LAST LOOP OR WRITING HAS NOT BEEN PERFORMED IN THE LAST .08 SECONDS WE CHANGE THE OUTPUTS, OTHERWISE WE SKIP ALL THIS BLOCK
          
           switch (stadiocorrente) {     // BASING ON THE CURRRENT STEP WE SET OUTPUTS
                                         
                          
                           case 1:analogWrite(L1,0); analogWrite(L2,gasprint); analogWrite(L3,0); digitalWrite(H1,LOW); digitalWrite(H2,LOW); digitalWrite(H3,HIGH); 
      
                           break; 
                          
                         //  case 2: analogWrite(L1,0); analogWrite(L2,gasprint); analogWrite(L3,0); digitalWrite(H1,HIGH); digitalWrite(H2,LOW); digitalWrite(H3,LOW);
      
                           //break;
                           
                           //case 3:analogWrite(L1,0); analogWrite(L2,0); analogWrite(L3,gasprint); digitalWrite(H1,HIGH); digitalWrite(H2,LOW); digitalWrite(H3,LOW);
                           
                           //break;
                           
                          // case 4:analogWrite(L1,0); analogWrite(L2,0); analogWrite(L3,gasprint); digitalWrite(H1,LOW); digitalWrite(H2,HIGH); digitalWrite(H3,LOW);
                           
                          // break;
                           
                          /// case 5:analogWrite(L1,gasprint); analogWrite(L2,0); analogWrite(L3,0); digitalWrite(H1,LOW); digitalWrite(H2,HIGH); digitalWrite(H3,LOW);
                           
                          // break;
                           
                          // case 6:analogWrite(L1,gasprint); analogWrite(L2,0); analogWrite(L3,0); digitalWrite(H1,LOW); digitalWrite(H2,LOW); digitalWrite(H3,HIGH);
                          
                          // break;
                       
                          default:analogWrite(L1,0); analogWrite(L2,0); analogWrite(L3,0); digitalWrite(H1,LOW); digitalWrite(H2,LOW); digitalWrite(H3,LOW);  // WE KEEP IT FOR ERROR MODE, WERE THE CASE IS 0 OR SOMETHING (REALLY) WEIRD
                             
                           break;      }
      
                                 timelastwrote=timenow;   }//ok last outputs writing was... now! 


 /////////PART OF THE CODE THAT READS GAS SENSOR AND CURRENT SENSOR BEGINS HERE/////// 

            //WE READ THE GAS SENSOR AND THE CURRENT SENSOR EVERY .05 SECONDS OR SO (BASING ON THE ARDU FUNCTIONS THAT GIVES MILLLISECONDS FROM BOOT),
            //WE AVERAGE LAST 4 READINGS FOR THE GAS (NOT FOR THE CURRENT) AND WE DECIDE WHAT THE GASPRINT VALUE IS GONNA BE.
            //THIS PART IS REALLY EASY BUT (AS REGARDS THE THROTTLE) DIFFERS A BIT DEPENDING ON WHAT POT ARE YOU USING. 
            
                                 
                                  
gasread=(analogRead(GAS));//we read teh value from the gas pot
gasprint=100;
                        
            ////END OF THE AWESOME PART OF THE CODE MENTIONED ABOVE////      
                        
                          ultimostadio=stadiocorrente; //LAST STEP=CURRENT STEP... WE SAVE THE STEP COMING TO THE LAST READINGS SO IN NEXT LOOP WE CAN SEE IF SOMETHING CHANGED. With this we are done with a cycle
            

  
            }//end of loop, e viva la figa!! :-)[/pre]
 
Let me tell you how I did the "bring up" of my controller's power stage (it's a DC brushed H-Bridge).

First I assembled (solder the components to the PCB) the microcontroller's (uC) power supply and tested it, then the uC and respective auxiliary circuit and tested it. At this point, I was sure that this control part was working good.

Then I assembled the drivers, assembling and testing one by one. To test the drivers, I used a 10nF capacitor to "simulate" a MOSFET gate, and looked at the "gate" with the oscilloscope while having a square wave at the driver's input. A final test checked the dead time switching between the top and bottom MOSFETs. At this point, I was sure that the drivers would turn ON/OFF the MOSFETs, and with the correct logic.

Then I assembled the MOSFETs. In my case, I left them in electric isolation because I can do that in my design; in your design, I would assemble the low ones first, checking they work, and moving on to the upper ones. I tested each MOSFET with a light bulb. At this point I was sure that all the MOSFETs were turning ON/OFF correctly.

In the final step I "closed" the electric isolation to complete the bridge, attached a small 10W motor, tested with a very small duty cycle and it all worked. I scoped the positive power line, the shunt, the motor output lines to see if there were any unfriendly spikes or "bad behaviors". There were none relevant, so I pluged-in the final motor and retested with a small duty cycle. Then I slowly increased duty cycle while keeping the shaft stopped and scoping the power lines, until required current was flowing. No spikes or bad behavior so it got my OK.

The method is to assemble the circuit part by part, testing as you assemble and moving on only when happy with test results. This is a very simple and fruitful way of bringing up a design. At every step you are building over something that is already tested and working, so you can concentrate only on the small part being tested at each step. Building an entire project and then turning the power on is the road for disaster and frustration.
 
Building an entire project and then turning the power on is the road for disaster and frustration.

I agree and I did somewhat same thing as you, I tested each block individually to see if there were big faults :D

Hall block is working good, the 6 steps follow each other as expected

The arduino seems to be ok (To be 100% sure I`l add a serial print to the code to have it actaully telling me the steps one by one)

The lower side mosfets are ok, they succesfully pwm a light bulb.

The high side mosfets are my biggest concern right now, they where not working with the "bulb test" but I thought it was due to the bootstrap taht doesn`t work without a "floating base" voltage, wich a light bulb cannot provide.

If no major mistakes are spot in the schematics/code I`ll perform the P channel mosfet test to see if the problem is in the high side drivers :wink:
Also: if I connect the controller to the motor, set all the 6 gates to off and make the motor spinng manually should I see the Vb pin rise over the phase V?
 
Congratulations!

very excited for you to get it working

did you use the p-channel fets? or did you get the bootstrapping to work?

Niels
 
Hey! I moved hall sensors a bit (I didnt realize it was so sensitive to their placing, it needs to be precise to the tenth of a millimiter!) and I moved the high side output on another arduino pin since the one I was using seemed to be somehow not working, maybe bad connection on the screw shield, idk. I also put bigger caps on the bootstraps, maybe not needed but the things worked so it was fine for me.
It spins kinda chunky (very) but I think it is a matter of tuning parameters.
Let`s see how it goes! Finally I got rewarded by this complicate adventure, perseverance works.
 
Very good, congrats. One small step at a time...
 
hey guys! Like someone said a few pages ago my thermal design is just useless. I got tricked into doing that looking at mosftest "piled up" in up to 4 layers in chinese escs.... well, probably those mosfets havea different internal thermal design...

Anyway, I am turning the little black almost useless heatsinks into parts of a super powerful liquid cooling sistem. Obviously each heatsink is good for one mosfet only so it will become a 6 fets controller.... not a tragedy since next step will involve going high voltage with a "stock mosfet arrray" from digikey... But, given my mosfets ratings, what could be the actual controllers final specs??

It says 120A package limited, 200 A silicon limited, 850 A 1ms max ,75 volts max voltage.... taking in account things such as current peaks during pwm cycles and so on, what`s the max battery voltage i can use? And what "rms current" can I expect to use?
Many tnks!
 
Ludo91 said:
It says 120A package limited, 200 A silicon limited, 850 A 1ms max ,75 volts max voltage.... taking in account things such as current peaks during pwm cycles and so on, what`s the max battery voltage i can use? And what "rms current" can I expect to use?

Assuming that your "super powerful liquid cooling" eliminates any thermal limit, the package limit will apply. That's a pretty big assumption and you may have thermal issues before you reach that point. For voltage, I would allow at least 10% headroom, possibly more.
 
This is pretty good news, working at 100A and 48v is still a very decent boost :lol:
RIght now I`m working on the current sensor, so I can keep the thing almost under control as regards current.

Very pratical question: I need to unsolder the mosfets in order to turn it in a 6 fets controller (my "dumb love" for high current low voltage was from the r/c field, where things like 14v 100 A are pretty common for some reasons I still do not understand), how to do that?
I am afraid of killing them with the heat, should I take away the "soldering tin" (is this the right name?) or just melt the tin on all the 3 leads at the same time with a wide soldering iron it and take away the fets asap?
Also, should I hold the fets with something like a wet cloth in order to keep them at a decent temperature?

tnks so much ;)
 
If you can "afford" it, cut the pins close to the PCB and then unsolder the pin remains.

If going with the unsolder-only method, it can help to cut the pins as much as possible on the copper side before unsoldering.
 
Back
Top