System keeps shutting down

qwerkus

10 kW
Joined
Jul 22, 2017
Messages
785
So now that the motor is finally spinning in the right direction, the bike is nearly finished, and I took it out for a test ride. Unfortunately, it keeps shutting down. There are 2 types of different shutdowns: either the controller just cuts power but stays on, or everything shuts down. In the second scenario powering it on again shows half a second of display and they turns off again. After half a min or so it can be switched on normally... until the shutdown happens again. Seems to happen past 800w - not sure how correct display reading is though. Interestingly, when I pedal for a while with the system turned off, I cannot switch it on immediately. (same behaviour: display switches on briefly and than goes off again) Could it be some over voltage protection issues ?

System is:
- rh212 dd hub motor
- kt s12s controller + kt lcd3 display
- 14s battery (charge level is 50% during test) with 60A jbd bms.

Besides some wiring issues, I think either its the jbd bms wrongly configured, or the kt controller also wrongly configured - or both. I've beeing playing around with c parameters of the controller without success so far, and I'd hate to take the battery apart to check the bms, but will probably have to do it - unless someone comes up with an alternative explanation :D

Thanks for your help!
 
I'd double check the connections and BMS configuration if you're able to. Charge it, make sure it's balanced, and try again.
 
HK12K said:
I'd double check the connections and BMS configuration if you're able to. Charge it, make sure it's balanced, and try again.

Can do, but would this explain the weird startup behavior when the motor is already spinning ?
 
qwerkus said:
HK12K said:
I'd double check the connections and BMS configuration if you're able to. Charge it, make sure it's balanced, and try again.

Can do, but would this explain the weird startup behavior when the motor is already spinning ?

I honestly don't know what's going on with that, but best to refer to your other thread to make 100% certain you have your hall and phases wired correctly as well. Who knows what pedaling around with a mismatch might be capable of doing? (Seriously, who knows? Anyone?)
 
I think you may have only gotten one-half of the problem.

You described BOTH possible common shutdown scenarios, A, total power loss, indicating battery shutdown, and B, loss of motor power but controller and display still on, indicating a controller shutdown.

Scenario A usually involves a time delay to restore function. The pedal period described may be a red herring.

Scenario B is usually remedied by simply cycling controller and/or display off and then on again. You did not mention restore methods used other than the delay while pedaling. IMO there was a delay due to battery shutdown, and during that time, you just happened to be pedaling. Quite possibly because turning it off and on again did not work, and when that did, you never pedaled because there was no delay required. Good thing you didn't just happen to dance the hokey-pokey for a few minutes before it worked, the first time.

From your other thread there may be some funkiness in your controller setup, although the battery issue could easily have been triggering controller LVC, only, some of the time and others going all the way to BMS LVC, or both.
 
AngryBob said:
I think you may have only gotten one-half of the problem.

You described BOTH possible common shutdown scenarios, A, total power loss, indicating battery shutdown, and B, loss of motor power but controller and display still on, indicating a controller shutdown.

Scenario A usually involves a time delay to restore function. The pedal period described may be a red herring.

Scenario B is usually remedied by simply cycling controller and/or display off and then on again. You did not mention restore methods used other than the delay while pedaling. IMO there was a delay due to battery shutdown, and during that time, you just happened to be pedaling. Quite possibly because turning it off and on again did not work, and when that did, you never pedaled because there was no delay required. Good thing you didn't just happen to dance the hokey-pokey for a few minutes before it worked, the first time.

From your other thread there may be some funkiness in your controller setup, although the battery issue could easily have been triggering controller LVC, only, some of the time and others going all the way to BMS LVC, or both.

You nailed it: Shutdown A has been tracked to the bms and is on its way to get fixed. Shutdown B is trickier - frankly I have no clue what's going on. The controller is standart KTs(sine wave) 12Fet, and while overcurrent shutdown past 2000w or so seems obvious, the controller keeps cutting power around 600w. I'm running in PAS mode (no throttle) and if I enter assist level 5, the motor just flies up to 45km/h, while the controller pumps 1900w without flinching. But than when I reduce assistance, there is always a threshold where the controller cuts power. As you pointed it, rebooting temporary fixes the issue - at least until the next power cutoff. Any experts of kt controllers in here who know what's going on ? Always running on max power ain't an option. I tried various P an C parameter tweaks - no success so far.
 
Do you always start with high assist, or it works on low until you go high, then reduce from there?

What happens if you start with a lower level assist, and just leave it there?

Detail the EXACT sequence of events, from when you first start riding to when it shuts down, and just as important, those times when it does NOT shut down, how are they different?

You are going to take this as a joke but it is an example I frequently use to explain the level of detail needed, and LEAVE NOTHING OUT, because something is different in the two usage patterns, but - if at any time you actually dance the hokey-pokey in the sequence of events, I need to know about it.

I am thinking something goes wrong when assist level is reduced. DETAILS - how long, rough estimate, between the time you reduce assist level and it shuts down? If immediate, there is the answer. If so, I would guess it is not the assist level specified, but the act of reduction which somehow either triggers a shutdown, or IMO more likely, directly engages it due to either a malfunction or settings issue. Recommend reset all controller changes to factory defaults, if available. Back to the Known Good.
 
AngryBob said:
Do you always start with high assist, or it works on low until you go high, then reduce from there?

What happens if you start with a lower level assist, and just leave it there?

Detail the EXACT sequence of events, from when you first start riding to when it shuts down, and just as important, those times when it does NOT shut down, how are they different?

You are going to take this as a joke but it is an example I frequently use to explain the level of detail needed, and LEAVE NOTHING OUT, because something is different in the two usage patterns, but - if at any time you actually dance the hokey-pokey in the sequence of events, I need to know about it.

I am thinking something goes wrong when assist level is reduced. DETAILS - how long, rough estimate, between the time you reduce assist level and it shuts down? If immediate, there is the answer. If so, I would guess it is not the assist level specified, but the act of reduction which somehow either triggers a shutdown, or IMO more likely, directly engages it due to either a malfunction or settings issue. Recommend reset all controller changes to factory defaults, if available. Back to the Known Good.

I managed to narrow the problem down to the pas. Either the sensor is bugged, or the controller processes it the wrong way. The result is that somehow the controller randomly looses PAS signal and hence cuts of power. The pas sensor is a 12L so I configured c1 parameter of the kt controller to 07 - yet its not working. Any idea what I could change. Pretty sure the sensor is not defective, since it worked fine with another controller.
 
I have asked several questions designed to nail this down. You have failed to answer several of them.

SO, I shall repeat and reword just one of the most relevant, in order to proceed in a logical, efficient fashion, as I strongly dislike random procedures as they usually just waste time, and cause me to rapidly lose interest, as no useful data is gathered.

Now, you seem to have described that the system is functional, and does so for somewhat extended periods of time - UNTIL YOU CHANGE THE ASSIST LEVEL. You may note that I consider the all caps statement above to be extremely critical to arriving at the correct solution. ISOLATE and IDENTIFY. Say it with me.

Verify, think, check notes, - Does it ONLY fail after the level is changed, does it NEVER fail if no change is made, and does it fail at the same level it fails at, AFTER the change, IF you start out at that same level and DO NOT change it?

If you want me to describe methods to determine functionality in the above testing scenario, that will require several answers to previously asked questions. Plus a few more.

ALSO, you asked about making changes - STOP DOING THAT. The very first question asked in standard diagnostics and troubleshooting is "Did you mess with it?". That is because, if you did, it is now a completely different system than the one all the previous questions and answers referred to, and now that entire process has to be repeated because it is no longer relevant to the system you have now. It is also because, in the vast majority of cases, it turns out that it worked, right before you messed with it, and it stopped working, right after you messed with it.
 
AngryBob said:
I have asked several questions designed to nail this down. You have failed to answer several of them.

SO, I shall repeat and reword just one of the most relevant, in order to proceed in a logical, efficient fashion, as I strongly dislike random procedures as they usually just waste time, and cause me to rapidly lose interest, as no useful data is gathered.

I tried to follow your advice, and establish a clean bug protocol.
A. Bms failures / shutdown --> solved! No more lvc reported in the bms config.
B. Controller shutdowns: still a problem!
Protocol:
1. C10 - controller reset to factory defaults
2. P1 -> set to 52 # 26 pole pairs for accurate speed reading
3. P2 -> set to 0 #(same as above)
4. C1 -> set to 7 # 12 magnets left side (reverse) pas
5. C12 -> set to 0 # LVC set to 40 - 2V = 38V
6. C13 -> set to 3 # lvl 3 regen braking
No further changes.
7. Reboot, taking the bike for a tour. Full battery at 57.6V. Assist lvl 0 on startup.
8. Pas assist lvl 1: no shutdown observed
9. Pas assist lvl 2: one power cutoff during a climb. speed: 20km/h, power: 600w
10. Pas assist lvl 3: 4 power cutoff. 3x during a climb and 1x on flat. speed: variable: 22-27km/h; power: variable 700-800w
First lvc shutdown. Voltage was 53V
11. Restart system. Pas assist lvl 3: next power cutoff
12. Pas assist lvl 4: 2nd lvc shutdown. Same Voltage. 3 Power cutoff during a climb. Same speed; power: 900-1000w
13. Pas assist lvl 5: no shutdown until max power is reach @2000W, than ovc. Speed: 48km/h. min. Voltage: 52V
Back home. The whole tour was around 5min.

The power cutoffs are annoying but somewhat manageable. All I have to do is a quick retro-pedaling and than pedal forward again to restart the motor. The LVC (low voltage cutoff) are more of a problem, since whole system switches off and I don't understand why they are happening. The battery is fully charged, and even at full power, voltage drop doesn't nearly reach 38v. Maybe it's buggy because I'm running 14s ? Is there a way to disable LVC on kt controllers ? The bms is calibrated to protect the cells from undervoltage anyway, so I don't need the controller doing it.
 
Outstanding!

Some more questions. Do you have a temperature sensor, and is the voltage reading direct from the display? Over temp can turn you off, and voltage drop under load is very momentary.

Next, is this controller and display specced for 14S?

I have read of some controllers doing some strange math and/or readouts with the numbers when they are outside of designed norms.

Is there anything on the display during the cutouts where power remains on, and just the pedal thing? That procedure is not normal. Look for any small icon or change.

You STILL have two different types of cutout, meaning you actually had THREE before solving the BMS problem.

Almost all, but not ALL, cutouts were during a climb. Many in a 5-minute period.

Either the battery has a major weakness, the controller is operating way outside its designed parameters, or it is defective. The PAS sensor being bad is a remote possibility, but the PAS circuitry in the controller is highly suspect.

Do you have a throttle, if so, disconnect PAS, disable PAS in controller if at all possible, and do a similar run to this one with throttle only.

If you have real-time voltage display, and the controller powered down as described, with voltages in the 50+ range, then I would go hard on replacing the controller. If you have a throttle, test as described first and if not, get a throttle with the new controller. Throttle will bypass PAS sensor, PAS settings, and controller PAS circuit. Three possible problem areas eliminated by one inexpensive component. Makes me all warm and fuzzy.

Do you have regen enabled? If so, turn it off for testing.

Am still thinking on this one, absolutely fascinating. Report any additional findings. Throttle test and regen off in particular.
 
Some additional thoughts.

I recall from your previous thread that there were some issues getting the phase and halls set correctly. Wrong phase order can cause extremely high amp draw in some conditions, high amp draw can cause dramatic voltage drop, which could trigger LVC.

Also, you have a high powered motor which is not commonly used with pedal sensors. Odd behavior might be related here. Could be an "out of bounds" sort of issue.
 
qwerkus said:
The LVC (low voltage cutoff) are more of a problem, since whole system switches off and I don't understand why they are happening.
if the whole system switches off, if the display and any lights / etc actually turn off, then the battery has an issue that is triggering it's bms to shut off the output. and/or there is a connection issue between the battery and the controller causing it to disconnect.

you'll have to find and fix that to prevent the problem.


if it only happens under loads above a certain point, then either the bms is shutting off from overcurrent, or it's shutting off to protect a cell taht's dropping below lvc (defect, poor connections, etc).


you'll have to determine the specific situations that the complete power off / shutdown occurs in to know which of the above (if it's not both) is happening, and then you can investigate inside the battery pack for what is causing it to happen.


if it's a connection problem, then it will happen "randomly", whenever the right vibration or mechanical movement causes the disconnect to occur. but in this case, it would also come back on very quickly, not stay off. (if it stayed off, then it would only come back on when you mechanically move the connection problem area again to make it make a good connection, and this would be a very obvious problem and you'd already know it was there and hopefully have investigated it and fixed it. ;) ).
 
AngryBob said:
I recall from your previous thread that there were some issues getting the phase and halls set correctly. Wrong phase order can cause extremely high amp draw in some conditions, high amp draw can cause dramatic voltage drop, which could trigger LVC.

That’s what I thought on reading the description of system behavior.

When I have to match a brushless motor and controller by working out Hall and phase assignments, I have found that there are two combinations forward and two in reverse that will make the motor turn. One in each direction is correct, and the other will cause the motor to run too fast, noisily, without enough torque, while drawing too much current. I suspect that one of these false combinations is what the bike is working with now.

If this is the case, it could be that the battery is cutting off when the BMS reaches its amp limit. Or it could be the controller is faulting out and cutting off for self-protection.
 
He has at least two, different, power loss issues, and initially had three.

BMS LVC events were apparently recorded, BMS replaced, no longer happening or at least indicated.

Motor power loss with functioning display restored with retrograde pedaling. ??? This one just reeks of funkiness.

Total system power loss, mostly but not always during climbs. This IMO is likely related to the phase wires issue.

Two, or possibly three, different shutdown issues, possibly separate, possibly related.

Some mysteries are Agatha Christie style, some more John le Carre.
 
How would I know if there is a phase / hall mismatch ? I tried several combination, and found one that seems to be working quietly (at least in comparison to previous ones). Didn't try all combinations though. I asked the motor manufacturer, and they say it was tested with kt controller in out-of-the-box phase / hall configuration and that's the one I'm using now.

From what I can see based on controller shunt readings, power consumption is on the higher side, but that was expected due to the switch to DD. No real spikes noticeable but maybe I'd need better equipment to detect it.

1. Now I did some further tests, and in pure throttle mode, LVC shutdowns also happen but as expected no more power cutoffs (where the system stays on, but cuts power). Narrowing it down to the PAS, I tried different pedaling cadence and notice the cutoff only happen at low cadence (like 70 rpm). Past 90rpm the system almost never cuts power. So my conclusion is that those cutoffs are the result of a bad assist algorithm, or at least one that is not adapted to my behaviour ! I see 2 possible workaround for this:

a- switch from "torque simulation mode" to "speed control" (P3) and than try different C14 configurations.

b- ditch the controller firmware completely and try the open source firmware. As I had bad experiences with that one, I've become cautious flashing $50 controllers...

2. The main issue is still the LVC shutdowns. Very annoying, especially when in the mids of a climb. Still I have a couple of options left:

a- try a different controller. I have another 12FET KTs controller on a different bike. Could try to use it as debugging tool, though this would mean soldering another motor cable and changing all the settings = time consuming + another bike not working.

b- One idea would be to upgrade the entry capacitors of the problematic controller. The dual shunt sits just next to the caps, meaning that the resistance shunt-caps will always be lower than the resistance shunt-battery. Perhaps in some situation the current draw is so high that the mean value between Vcaps and Vbattery drops below 38V. It would have to happen faster than the display can notice, as I've never seen a voltage reading so low. If this is true, the obvious fix would be to add more capacitors in parallel to the existing ones.
 
Good progress.

One of the systems of incorrect phase/halls order MIGHT be relatively correct functionality, but very high amp draw. When testing, use EXTREMELY MINIMAL throttle movements while measuring amp draw, and as mentioned power down controller, I would disconnect battery, before changing connections. This high power draw, MAY, or MAY NOT, be the source of your problem.

I would leave the PAS alone for now, no changes. I know it is tempting to try to get that component working just right, but right now it is not part of the problem, so it is removed from the solution. ISOLATE and IDENTIFY. Tweak it later.

You mention throttle mode, do you mean a controller setting or a physical throttle, if so, disable PAS in controller and after this remove the sensor connection. Get it out of the picture totally.

On the firmware - no cost, little time, reversible, BUT - there is some risk. 1 - backup existing firmware, 2 - backup AGAIN to a removable medium, like a USB stick, 3 - repeat #2. Check all three files ON THE SAME MEDIUM for identical size. When updating - Make certain cable connection is solid and secure and protect it from any source of interruption including mouse farts. ANY interruption to firmware update usually results in totally unusable hardware. As much as is possible, make certain firmware version matches controller model. Spend some time and effort on this.

This may have some positive effect on the primary problem, especially considering the possibility of flaky firmware maybe being the cause of the PAS issue. Could just be bad hardware, or the problem might be something completely different.

Describe you battery in some detail. A Vruzend kit, by any chance?

The ideal instrument to have now would be an inline wattmeter with separate power source which will record Vmax and Amax and maintain after power off.

Failing that, measure a known distance, do some repeated test runs, starting with minimal throttle and maximum pedaling, then gradually increase throttle and decrease pedaling, repeat several times, can you maintain max speed on level ground, accelerate to that speed in different timed intervals, etc. Can you maintain a high power level if you build to it slowly, or does what should be a relatively moderate acceleration cut you off consistently?

Also you mentioned BMS not showing LVC events, how was this recorded, what info does it record, and are there any entries on recent events? Not familiar with BMS having log files.
 
Back
Top