SOLVED! Infineon Cutting out Question

gwhy,
I just want to say thanks for doing all these tests :D You seem to be consitently a step ahead of me, which means I get to sit back and wait for your results :mrgreen:

-Matt
 
matt_in_mtl said:
gwhy,
I just want to say thanks for doing all these tests :D You seem to be consitently a step ahead of me, which means I get to sit back and wait for your results :mrgreen:

-Matt

Its no problem,
It seems to be a problem for a quite a few people, I want to peruse this because I like the size/price of these controllers and what sort of performance they can output with some additional mods and heatsinking. I just hope it can be sorted as I have 2 of the newer 6fet that I cant use yet :cry:
 
gwhy,

Yes I am also seeing this problem with an unmodified 206 controller at 50v when running my Astro.
It only happens in the delta mode where the motor draws significantly more current than when it is in wye.
The cutting out problem can not be cured by adjusting the timing, but I can make it worse!

I have no problems with an EB218 (18 FET) controller on the same setup.

I have tried programming various combinations of phase and battery current limits, seems to make no difference.

Burtie
 
Burtie said:
gwhy,

Yes I am also seeing this problem with an unmodified 206 controller at 50v when running my Astro.
It only happens in the delta mode where the motor draws significantly more current than when it is in wye.
The cutting out problem can not be cured by adjusting the timing, but I can make it worse!

I have no problems with an EB218 (18 FET) controller on the same setup.

I have tried programming various combinations of phase and battery current limits, seems to make no difference.

Burtie

Thanks Burtie,
Seems like its by design then like Lyen said, Now the question is how do we get around it.. :?: , as far as I can see the fet drive circuits are the same on the 12 fet as the 6fet the only real differences are the voltage dropper circuit and the shunt arrangment, just hope that there isnt a major firmware difference . I will do some bench tests to compare the 6fet with the 12fet. I think I need to sleep on it..... :?

edit: I wonder if like Jeremy said " the EB206 controllers regulate phase current by inference " then this will indicate that this is done through the firmware would it not :?: so I wonder if it would be possible to reprogram the 206 using 218 settings :? .. and adjust/fudge shunt accordingly, I really need to get some sleep :mrgreen:
 
Keep the discovery coming guys, I have a new 6 fet & this is all good info,

BIG thanks for your efforts.
 
Jeremy Harris said:
gwhy,

The test for this would be to deliberately programme a low phase current ratio and then see whether or not the problem is worse (apologies if you've already tried this). If changing the phase current doesn't make a difference then it's likely to be something else, like a momentary voltage drop under high peak current demand conditions causing the controller to glitch, as has already been mentioned. It might be worth lowering the LVC to as low a voltage as possible, in case voltage drops are the problem (again, apologies if you've already tried this).

Jeremy

I thought I would try testing the effect of changing the phase current and rated current settings, I didn't expect to see much, but ran into some interesting results. All tests were done using 12S lipo and 20V LVC (to prevent accidentally tripping the LVC), and with motor on the bench unloaded.
1st test:
Rated Current: 30A
Phase Current: 80A
Results: roll throttle on slowly worked up to 30 - 50% throttle, then it would die. Snap the throttle quickly and the motor would barely blip.

2nd test: (go for really wide ratio)
Rated current: 15A
Phase Current: 130A
Results: no change from test 1, same results

3rd test:
Rated current: 30A
Phase Current: 30A
results: much better I could snap the throttle on and it would rev-up. Only cut out sometimes when snapping the throttle to 100% from full stop (very high phase currents).

4th test: Maybe it works when rated and phase are set to the same value, try increasing the current
Rated current: 57A
Phase Current: 60A
results: same as test1/2 could not rev up the motor, had to use very gentle throttle to keep the motor from dying.

5th test: Maybe it is just important that the phase current is 30A
Rated current: 57A
Phase current: 30A
results same as test 3, so it would seem that it is the phase current which is causing the limit.

6th test:
Rated current: 7A
Phase current: 30A
betting results than test 1/2, I could reach full throttle if I rolled the throttle on. If I hit the throttle straight to 100% I could still get the motor to die. I wonder if this is tripping the rated current limit which is causing the controller to fault requiring me to reset the throttle to 0?

7th test:
rated current: 15A
phase current: 30A
same results as test 6. The only way I can make the controller fail is by snapping the throttle from stopped to 100% as fast as I can.

So far it looks like controller doesn't like anything above 30A phase, so lets test this:

8th test:
rated current: 40A
phase current: 40A
as predicted, worked better than 60 phase current, but not as well as 30A. I could make the controller fail easily by not being gentle with the throttle, but I could reach full throttle easily by rolling the throttle on.

So, it seems to me either the is an internal hard phase current limit of ~30A, and if you surpass that it causes a fault, or there is an electronic issue that occurs when there are higher phase currents which may be causing noise causing the controller to fault or reset.

Has anybody been able to get this generation of 6-fet controller to blink fault codes?

My next test will be to solder in another shunt in parallel to see if I can bypass the hypothetical 30A firmware limit.

-Matt
 
OK, well that was fast...
I just went ahead with my shunt mod.. and the results aren't good.

I started by measuring the voltage drop across the stock shunt at a constant measured current. I repeated this for a few currents from 1A to 3.7A (I couldn't go higher without figuring some way to load the motor on the bench). I measured between 5mV and 16.2mV across the shunt which comes out to approx 4.5mohm. I think I saw the value on the forum before, but don't remember if this is what it was. I then soldered in some about a 1-inch long piece of solid copper wire in parallel. I did another test, and arrived at 0.6mV at 2A which gives me 0.3 mohm! It is possible that this is too low, but the controller worked OK. Unfortunately it did not work as well as it had before my mod. I can reach full throttle if I am gentle. Once revved up it is generally OK, however if I crack the throttle open the motor will blip and die. This suggests to me that we may not be looking at a firmware issue :( I am finding my results a little bit strange considering that it seemed like others have been able to get much higher power from these 6-fet controllers.

-Matt
 
matt_in_mtl said:
OK, well that was fast...
I just went ahead with my shunt mod.. and the results aren't good.

I started by measuring the voltage drop across the stock shunt at a constant measured current. I repeated this for a few currents from 1A to 3.7A (I couldn't go higher without figuring some way to load the motor on the bench). I measured between 5mV and 16.2mV across the shunt which comes out to approx 4.5mohm. I think I saw the value on the forum before, but don't remember if this is what it was. I then soldered in some about a 1-inch long piece of solid copper wire in parallel. I did another test, and arrived at 0.6mV at 2A which gives me 0.3 mohm! It is possible that this is too low, but the controller worked OK. Unfortunately it did not work as well as it had before my mod. I can reach full throttle if I am gentle. Once revved up it is generally OK, however if I crack the throttle open the motor will blip and die. This suggests to me that we may not be looking at a firmware issue :( I am finding my results a little bit strange considering that it seemed like others have been able to get much higher power from these 6-fet controllers.

-Matt

Well that doesn't sound very promissing, Matt (but at least it does confirm that it is high phase currents causing the problem). After soldering up the shunt, did you reduce the programmed current limits in the controller by the same factor as the shunt was changed - so about 10X lower?

Have the controller's caps been upgraded to handle the extra current ripple?

BTW: Does this problem show up only when using big outrunners, or has someone had this happen with regular hubs too? If it is only an issue with large, low resistance/inductance motors, then I'm not too surprised. These things are much more brutal than hub motors on the controller, and will cause very large current spikes. The best bet is to fit as many good capacitors as you can in there, including some extra high frequency ones too right close to each phase's + and - bus connections (as close to the FETs legs as possible for these). I use multi-layer ceramic chip capacitors for this. Keeping the battery-side inductance low is also important, so keep battery wires short and twisted together. You might even put a large electrolytic right across the battery input if there's not enough room inside - it will kive a hand to the ones inside *if* installed very close to the input.

Pat
 
ZapPat said:
After soldering up the shunt, did you reduce the programmed current limits in the controller by the same factor as the shunt was changed - so about 10X lower?

Have the controller's caps been upgraded to handle the extra current ripple?

Pat

My thought was to try to see if I could 'trick' the controller into allowing higher current. If I had lowered the current by 10X then I would have been the same ~30A true phase current as pre-mod.

I have not yet added caps, but I think that ghwy has and it did not cure the problem.

I think we are reaching the end of the guess-and-check phase, time to break out the 'scope :?

-Matt
 
matt_in_mtl said:
My thought was to try to see if I could 'trick' the controller into allowing higher current. If I had lowered the current by 10X then I would have been the same ~30A true phase current as pre-mod.
OK, maybe don't cut it down by 13X as your shunt did changed, but at least reduce the previous limits by at least 4X or 5X or else your shunt mod won't help you from hiting the same overcurrent cutoff as before. You want the controller's programmed limits to be hit *before* the brutal overcurrent cutoff current is hit, so if you leave the limits programmed the same as before the shunt mod it wouldn't help. If this does not work, then yes it'll be the scope. I checked out the current reading input to the MCU on the controller, and it looks identical to the 212 I have here... :?

I just tried out my 206 driving a rear 9C, and yes it cuts out at low RPM at about 40A battery current. I checked my saved programming file for this bike and it indicates that I had it programmed at 40A batt / 70A phase... I can't believe I didn't solder up that shunt!? I'll have to open it up to refresh my memory, and I'll beef the shunt up if needed.
 
I dont know how good this diagram is, But there seems to be some difference between the R45 value ( with a meter )on the 12fet board and the 6fet board , its all in the right ball park ( I need to sort out better light and get something to magnify everything up as my eyes are getting very old and are not what they used to be :roll: before I try anything with power going thought it :shock: ).
View attachment 6fet.pdf
 
gwhy! said:
I dont know how good this diagram is, But there seems to be some difference between the R45 value ( with a meter )on the 12fet board and the 6fet board , its all in the right ball park ( I need to sort out better light and get something to magnify everything up as my eyes are getting very old and are not what they used to be :roll: before I try anything with power going thought it :shock: ).
R45 on both my 212 and 206 is the same, as well as all the other parts around that current-sense conditioning area of the controllers.

Does anyone know what function the transistor QF1 (close to the 5V regulator) do? It looks to be hooked up to the resistors and caps used for the current sense circuitry... although even this looks the same on both boards.
 
I think we might be getting somewhere with this observation. I'd not bothered to look at the current limit circuits (plural!) before, but can now see some areas to look at closer.

Firstly, there is a current measurement capability there, as the voltage across the shunt is being fed to an analogue to digital converter in the controller, that will give the controller the average current being drawn from the supply.

Of more interest is the transistor, QF1. This is a switch, that will take pin 27 of the 116 low if the voltage across the shunt exceeds about 0.6 - 0.7V. This limit can't be programmed, as it's wholly dependent on the shunt value. I'm guessing that this is a backstop "emergency" current limit, that kicks in to kill the controller in the event of a current overload. It seems likely that this "might" be the cause of the cutting out problem, but the way to prove it would be to put a 'scope on pin 27 and see what happens.

*edited to add:*

I can see a fix, if what I think is happening can be proven. The capacitor and resistor, C20/R43, control the rise time of the voltage to QF1 base. This means that increasing either will slow down the rate of rise of voltage, which would then smooth out rapid high current peaks. This may well get rid of the cutting out problem.

Jeremy
 
ZapPat said:
OK, maybe don't cut it down by 13X as your shunt did changed, but at least reduce the previous limits by at least 4X or 5X or else your shunt mod won't help you from hiting the same overcurrent cutoff as before. You want the controller's programmed limits to be hit *before* the brutal overcurrent cutoff current is hit, so if you leave the limits programmed the same as before the shunt mod it wouldn't help.

I'm sorry ZapPat, I think I still may be missing something. Assuming the 'brutal overcurrent cutoff ' is in the firmware, and assuming the only way the firmware has to measure the current is through the shunt... by changing my shunt from 4.5mohm to ~0.4mohm, I have increased all firmware based current limits by at least 10X. The controller worked well with phase/rated currents set to 30A, which suggests the 'brutal overcurrent cutoff' must be higher than 30A. If the cutoff is firmware based, then my 10X reduction in shunt resistance would raise the cutoff to over 300A. I don't see any way that my motor could be pulling over 300A at 50V sitting unloaded on the bench?

-Matt

*Edit: 2 new responses while I was writting this*
Jeremy Harris said:
Of more interest is the transistor, QF1. This is a switch, that will take pin 27 of the 116 low if the voltage across the shunt exceeds about 0.6 - 0.7V. This limit can't be programmed, as it's wholly dependent on the shunt value. I'm guessing that this is a backstop "emergency" current limit, that kicks in to kill the controller in the event of a current overload. It seems likely that this "might" be the cause of the cutting out problem, but the way to prove it would be to put a 'scope on pin 27 and see what happens.

Jeremy

So, wouldn't this mean that the cutting out would quit also if we decreased the voltage across the shunt by lowering the resistance?
 
Matt,

Looking at the circuit I'm near-certain that the brutal cut off is the QF1 switch, not anything in the programming.

The fix may be something as simple as increasing the value of C20 by enough to slug down the big spikes, or adding a resistor across it to divide down the voltage.

Here's an experiment to test this idea. Fit a 1k resistor in parallel with C20. This should double the "emergency current limit" point. Should be easy enough to test.

Jeremy
 
matt_in_mtl said:
If the cutoff is firmware based, then my 10X reduction in shunt resistance would raise the cutoff to over 300A. I don't see any way that my motor could be pulling over 300A at 50V sitting unloaded on the bench?
An RC motor can have about 30 or 40 mohms of phase resistance, is this right? If so then at 50V your motor current could build up rapidly to 50V/0.04ohms = 1250A! So if don't reduce the software (ADC-based) current-regulation limit after changing the shunt, it will just let the current get *really* high before hitting the hard cutout.

matt_in_mtl said:
So, wouldn't this mean that the cutting out would quit also if we decreased the voltage across the shunt by lowering the resistance?
Not if your software is letting it go 10X+ higher than before...


BTW, I just opened up my 206, and the stock caps got hot, and one has started puffing! They are 100V caps, but I have not even used it over 50V. The shunt is not even soldered up! :shock: I'll have to replace the caps and solder up the shunt, then scale down the current limits in the software to see if the cutouts are solved.
 
Jeremy Harris said:
I think we might be getting somewhere with this observation. I'd not bothered to look at the current limit circuits (plural!) before, but can now see some areas to look at closer.

Firstly, there is a current measurement capability there, as the voltage across the shunt is being fed to an analogue to digital converter in the controller, that will give the controller the average current being drawn from the supply.

Of more interest is the transistor, QF1. This is a switch, that will take pin 27 of the 116 low if the voltage across the shunt exceeds about 0.6 - 0.7V. This limit can't be programmed, as it's wholly dependent on the shunt value. I'm guessing that this is a backstop "emergency" current limit, that kicks in to kill the controller in the event of a current overload. It seems likely that this "might" be the cause of the cutting out problem, but the way to prove it would be to put a 'scope on pin 27 and see what happens.

*edited to add:*

I can see a fix, if what I think is happening can be proven. The capacitor and resistor, C20/R43, control the rise time of the voltage to QF1 base. This means that increasing either will slow down the rate of rise of voltage, which would then smooth out rapid high current peaks. This may well get rid of the cutting out problem.

Jeremy
Very cool, Jeremy! I had looked at that transistor many times wondering what it was there for, and your conclusion would make sense. I'll solder up the shunt, reduce programmed limits and post back to confirm. Would it be possible to just remove this transistor BTW?
 
ZapPat said:
gwhy! said:
I dont know how good this diagram is, But there seems to be some difference between the R45 value ( with a meter )on the 12fet board and the 6fet board , its all in the right ball park ( I need to sort out better light and get something to magnify everything up as my eyes are getting very old and are not what they used to be :roll: before I try anything with power going thought it :shock: ).
R45 on both my 212 and 206 is the same, as well as all the other parts around that current-sense conditioning area of the controllers.

Does anyone know what function the transistor QF1 (close to the 5V regulator) do? It looks to be hooked up to the resistors and caps used for the current sense circuitry... although even this looks the same on both boards.

Hi Jeremy,
They may well be the same value but there seems to be a difference in how quick the cap c21 charges up between the 6fet and 12 fet with the meter. I know there are a lot of things can effect this, and the only real way to see what this part of the circuit is doing is with a scope.
 
If you remove QF1, then the "emergency current limit" capability would be disabled altogether. This may or may not be a good thing.

Adding a resistor across C20 would be more effective than changing the shunt, I think, as it's quite possible that the high current spikes may be generating spikes from the circuit inductance. The shunt may not be acting resistively under these conditions, hence some of the apparent anomalies being seen.

Adding a bigger capacitor across C20 might do the job just as well as a resistor, whilst leaving the emergency current limit intact.

Jeremy
 
gwhy! said:
Hi Jeremy,
They may well be the same value but there seems to be a difference in how quick the cap c21 charges up between the 6fet and 12 fet with the meter. I know there are a lot of things can effect this, and the only real way to see what this part of the circuit is doing is with a scope.

I'm reasonably sure that the problem isn't with the R45/C21 part of the circuit at all. I think you need to look at the R43/C20 circuit, as that is almost certainly governing the un-programmable current limit.

Jeremy
 
Hi Jeremy,
The R43/C20 was my first gut reaction to look at until I started metering the circuit, But what you say certainly makes sense. We will have to give it ago :p and see what happens.
 
I'd be really interested to see what you find out. In my application for these controllers I have no way of loading the motor at low rpm, so the problem doesn't arise (I'm driving a boat prop, whose load is proportional to the cube of rpm).


Jeremy
 
Jeremy Harris said:
Matt,

Looking at the circuit I'm near-certain that the brutal cut off is the QF1 switch, not anything in the programming.

The fix may be something as simple as increasing the value of C20 by enough to slug down the big spikes, or adding a resistor across it to divide down the voltage.

Here's an experiment to test this idea. Fit a 1k resistor in parallel with C20. This should double the "emergency current limit" point. Should be easy enough to test.

Jeremy

As I think about this more, I think this makes alot of sence. I suspect that if we scope it we will find the RC time constant of C20 and R43 will be quite low. I suspect that the ADC current input is polled by firmware, mabye at around 100hz? This allows average current regulation, but is much too slow to limit pwm frequency current spikes. The output of QF1 possibly triggers an interrupt in the controller causing instant shutdown. A lower C20 value will give faster response to over current-scenarios better protecting the controller. 0.6V drop accross the 4.5mohm shunt would require 133A. if C20 is 1uF, that would give an RC time of 1mS, and 10uF would be 10mS, so I suspect that if the current exceeds 133A for even 1/100 of a second, it would be enough to trigger the over-current shutoff. This actually seems like a fairly smart feature of the controller. I am excited to test this out when I get home. Unless of course you beat me to it gwhy!! :x

-Matt
 
Well Have a guess what.... 1k across C20 makes the controller WORK, I fitted the 1k to my new virgin controller so its stock settings and stock shunt. I havent tested it under a big load yet ( but that will come ) , without the mod the motor would peak at 10A on the watt meter but cut out and with the mod watt meter still peaked at 10A but no sign of the motor cutting out no matter how you used the throttle. So proof of concept yes! ( maybe ) but more testing to do. :mrgreen:
 
Nice one!

I'm glad that this idea seems to have some merit. The next step is to have a think about ways to fully understand this and the impact it has on performance and FET longevity.

It should be possible to fit a small trim pot across C20, so that the peak current cut-off can be fine tuned. Whether this is worth it or not is debatable, though.

Jeremy
 
Back
Top