Really strange KT controller issue, help please!

[Daan]

Hi!

I have the following issue:

Sometimes the motor assistance completely cuts-out and does only reingage when I stop pedalling for a second or two and/or release the throttle and then start again. The display stays on, it's only the motor that cuts out. It seems to can happen in any assist level, and only occurs within the 1-2 seconds after you start pedalling or engage the throttle. The strange thing is that it only does this like 1 out of 100 times. 99% of the time it works perfect, and then sometimes randomly it doesn't. When it happens and I just continue pedalling or use the throttle it won't ever work. You really have to stop pedalling to break the cycle or something. So it is also not the same a the brake cut-off for example.

My set-up:

Controller: KT48SVPRM-JBK001 22A (built-into Hailong battery deck)
Display: KT LCD3 V3.0 3CM
Motor: Bafang 500W geared hub motor

Display settings:

P1 100
P2 6
P3 1
P4 0
P5 15

C1 7
C2 0
C3 0
C4 0
C5 10
C6 5
C7 1
C8 0
C9 0
C10
C11 0
C12 2
C13 0
C14 3
C15 6

What I have tested:

- Changed the PAS sensor to one of KT (KT-V12L), did not make a difference, same issue.
- I had the feeling it might be a BMS cut-out, therefore I tested with a battery that doesn't have a BMS, although same issue, so also not BMS/battery related.

I am completely clueless, since it is so random. I have a lot of experience with KT controllers, but have never had these issue before.

These controllers and displays are ordered directly from the KT factory, I ordered 10 sets, all have these problem. I suspect some sort of weird firmware issue, someone has any thoughts?

 

[amberwolf]

Since this is the same problem as here

KT display overheating issues?? Help!

Hi community, I have build over 60+ e-bikes with a 48V, 22A KT controller, almost all of them with a KT LCD3 (I sell them). I now am experiencing very weird issues, which I have never had before. Three main issues: 1. Complete cut-out of power when accelerating full power with throttle from...

endless-sphere.com

that you are troubleshooting, I recommend letting me merge this thread with that one, and then you can edit the first post to change the title to whatever you like (such as the one from this thread). Or I can change it. Otherwise you are starting over with everyone not knowing what you've already done and what conditions you've eliminated, etc., except for those things posted in this thread.

The reply below was typed up before I saw your other thread's last post from you and realized it is this same thing, so you can see how it is going to get people asking you about things you've already answered....

What are the specific conditions the problem happens in? Is it under load? Is the weather cold? Hot? Rainy? Etc.

What specific actions are taken at the time it happens? Is there anything common between them?

Is it always during throttle use? Or only during PAS? Or random?





If it was a BMS cutout, you'd lose all power to the system (a BMS can only turn on, or turn off the entire output).

It's unlikely it could be a battery issue (dropping too low under load) if it happens in all assist levels.

It's unlikely that all ten setups would have the same problem, but:

It could be a motor hall signal issue, either an actual problem with a sensor, or more likely an electrical noise issue. The usual issue is that there is current-flow in the phase wires that induces voltages into the hall wires running parallel to them in the same cable.

Does the problem happen more often under high loads? (regardless of assist level) If so, it could be the phase-current-induced noise.

Sometimes the problem is a connection between controller and motor, often the hall ground wire.

The noise can be there all the time, but only on rare occasions be enough to interfere with enough of the hall signals to cause the controller to send the wrong pattern of phase currents, which result in the motor doing the wrong thing which the controller responds to by shutting off motor power until the error condition is reset.


A phase connection problem could cause a similar controller shutdown.



If your controllers are compatible, you could try flashing one set with the OSFW opensource firmware to see if it changes the behavior, eliminating firmware as a cause.

 

[Daan]

Since this is the same problem as here

KT display overheating issues?? Help!

Hi community, I have build over 60+ e-bikes with a 48V, 22A KT controller, almost all of them with a KT LCD3 (I sell them). I now am experiencing very weird issues, which I have never had before. Three main issues: 1. Complete cut-out of power when accelerating full power with throttle from...

endless-sphere.com

that you are troubleshooting, I recommend letting me merge this thread with that one, and then you can edit the first post to change the title to whatever you like (such as the one from this thread). Or I can change it. Otherwise you are starting over with everyone not knowing what you've already done and what conditions you've eliminated, etc., except for those things posted in this thread.

The reply below was typed up before I saw your other thread's last post from you and realized it is this same thing, so you can see how it is going to get people asking you about things you've already answered....

What are the specific conditions the problem happens in? Is it under load? Is the weather cold? Hot? Rainy? Etc.

What specific actions are taken at the time it happens? Is there anything common between them?

Is it always during throttle use? Or only during PAS? Or random?





If it was a BMS cutout, you'd lose all power to the system (a BMS can only turn on, or turn off the entire output).

It's unlikely it could be a battery issue (dropping too low under load) if it happens in all assist levels.

It's unlikely that all ten setups would have the same problem, but:

It could be a motor hall signal issue, either an actual problem with a sensor, or more likely an electrical noise issue. The usual issue is that there is current-flow in the phase wires that induces voltages into the hall wires running parallel to them in the same cable.

Does the problem happen more often under high loads? (regardless of assist level) If so, it could be the phase-current-induced noise.

Sometimes the problem is a connection between controller and motor, often the hall ground wire.

The noise can be there all the time, but only on rare occasions be enough to interfere with enough of the hall signals to cause the controller to send the wrong pattern of phase currents, which result in the motor doing the wrong thing which the controller responds to by shutting off motor power until the error condition is reset.


A phase connection problem could cause a similar controller shutdown.



If your controllers are compatible, you could try flashing one set with the OSFW opensource firmware to see if it changes the behavior, eliminating firmware as a cause.

Thanks a lot for your detailed response! Really appreciate it!

It doesn't seem to happen under specific circumstances, but it does seem to happen more often on higher powers. Both in PAS and throttle. It also happens on all 10 bikes, just not just a single bike.

If it is a phase current or haul sensor issue, is it fixable?

I will definitely look into the osfw firmware, no experience with that though, so have to see if I can do that.

 

[amberwolf]

*If* it's a phase-current-induced motor hall signal issue (which it might not be; it's not all that common in relatively low power systems), you can try to fix it in a few ways, but they all require some form of modification of the motor/controller cabling or the motor or controller. It'd be better to verify that you have noise on the halls under load before doing it, using an oscilloscope to see the actual hall signals while the motor is running under a load on a "test bench" setup...but most people dont' have a oscilloscope and rarely would have any use for one even in testing for things like this.

The "easiest" fix is to cut into the cable sheath near the controller and add some small ceramic capacitors, usually something like 0.1uF, from each signal line to the main hall ground wire, which will tend to dampen out noise spikes. Sometimes this is too much capacitance and will degrade the hall signals too much for the controller to read them, especially at high motor speeds, and you may have to go for 0.01uF or smaller.

Because the modifications needed for the next steps are pretty intense, I'd do as much narrowing down of the specific situations that cause the glitch as possible to see if it might be solveable some other way. But sometimes it takes less time to just do the mods and try them than to isolate a 1-in-100 glitch. :/

The next step is fairly drastic, which is to separate the hall wires from the phase wires for the entire run from the cable exit of the motor to the cable entrance of the controller, by as much distance as you can physically manage with the available wire--but if you have the typical Higo or Julet waterproof connectors that have phase and hall in the same connector, this means destroying those connectors/cables by cutting off the connectors and wiring direct (or installing different connectors), and removing the cable sheath containing all the wires. That means exposing the connections to weather, and the wires to more-easily-created damage from pinches or scrapes on them in the event of any impact that could touch those wires at any point along their routing, unless you then re-wrap the hall and phase wires as separate bundles with something to protect them.

The next step if that doesn't fix a current-induced hall signal issue is to actually shield the hall wires with metal mesh or foil that is grounded *only* at the controller end. Some cabling already includes this in it...in which case I wouldn't bother with the other fixes because it's probably not this kind of issue (unless you can see the noise in an oscilloscope and it's clearly from the phases).

After that you get into stuff like building circuits to buffer the signal from the halls to the controller, and upping the pullup voltage on the halls to 12v or 15v instead of the 5v they are now, so they have a much better signal-to-noise ratio (since their "on" grounded state will be much better separated from their "off" floating-voltage state), etc. Yuck.

 

[Daan]

*If* it's a phase-current-induced motor hall signal issue (which it might not be; it's not all that common in relatively low power systems), you can try to fix it in a few ways, but they all require some form of modification of the motor/controller cabling or the motor or controller. It'd be better to verify that you have noise on the halls under load before doing it, using an oscilloscope to see the actual hall signals while the motor is running under a load on a "test bench" setup...but most people dont' have a oscilloscope and rarely would have any use for one even in testing for things like this.

The "easiest" fix is to cut into the cable sheath near the controller and add some small ceramic capacitors, usually something like 0.1uF, from each signal line to the main hall ground wire, which will tend to dampen out noise spikes. Sometimes this is too much capacitance and will degrade the hall signals too much for the controller to read them, especially at high motor speeds, and you may have to go for 0.01uF or smaller.

Because the modifications needed for the next steps are pretty intense, I'd do as much narrowing down of the specific situations that cause the glitch as possible to see if it might be solveable some other way. But sometimes it takes less time to just do the mods and try them than to isolate a 1-in-100 glitch. :/

The next step is fairly drastic, which is to separate the hall wires from the phase wires for the entire run from the cable exit of the motor to the cable entrance of the controller, by as much distance as you can physically manage with the available wire--but if you have the typical Higo or Julet waterproof connectors that have phase and hall in the same connector, this means destroying those connectors/cables by cutting off the connectors and wiring direct (or installing different connectors), and removing the cable sheath containing all the wires. That means exposing the connections to weather, and the wires to more-easily-created damage from pinches or scrapes on them in the event of any impact that could touch those wires at any point along their routing, unless you then re-wrap the hall and phase wires as separate bundles with something to protect them.

The next step if that doesn't fix a current-induced hall signal issue is to actually shield the hall wires with metal mesh or foil that is grounded *only* at the controller end. Some cabling already includes this in it...in which case I wouldn't bother with the other fixes because it's probably not this kind of issue (unless you can see the noise in an oscilloscope and it's clearly from the phases).

After that you get into stuff like building circuits to buffer the signal from the halls to the controller, and upping the pullup voltage on the halls to 12v or 15v instead of the 5v they are now, so they have a much better signal-to-noise ratio (since their "on" grounded state will be much better separated from their "off" floating-voltage state), etc. Yuck.

Thanks again for your very detailed response. Let's hope it's not that, because modifying all my bikes definitely is not an options.

I will continue searching. Currently the KT factory has one of my bikes, they will test as well now. Hope they can find something.

 

[E-HP]

It also happens on all 10 bikes, just not just a single bike.

Maybe they sent you a defective batch of displays. The issue with the buttons and erratic menu behavior seems to point in that direction. Can you swap out the display from one of the other working bikes with one of the defective ones and see if you can replicate the problem?

 

[AHicks]

Still betting the controller is overheating due to no air flow to help dissipate heat.

 

[E-HP]

Still betting the controller is overheating due to no air flow to help dissipate heat.

I guess if there was a design change, but the other 50 bikes don't have the issue and I'm assuming the battery cradle is mounted on the frame in open air.

 

[amberwolf]

I wouldn't make that assumption. There's lots of people that stick their controllers and wiring in bags because it's ugly...and most of them don't have problems, but the other thread says it's really hot there and that would not help let the controller dissipate heat.

But given the subsequent info that's been posted, and the fact that the displays go blank sometimes, it doesn't sound like it is overheating of the controller itself causing it. (that could be happening too, but it would not cause the display to go blank--that only happens if it's own power is cut off, either at the battery's output, or inside the display at it's own regulator).

However, the OP still has not systematically tested to eliminate heat via various cooling methods they could use on various system parts, so it's possible overheating of some system part could be causing it.

 

[E-HP]

I wouldn't make that assumption. There's lots of people that stick their controllers and wiring in bags because it's ugly...and most of them don't have problems, but the other thread says it's really hot there and that would not help let the controller dissipate heat.

Seems like it would need to be a custom bag to get it and the battery inside, and still be mounted on the downtube, but I guess it's possible.

 

[amberwolf]

Seems like it would need to be a custom bag to get it and the battery inside, and still be mounted on the downtube, but I guess it's possible.

As unlikely as it is, it could be. Since we haven't seen any pics from the OP of anything, we don't know how they actually built their bikes.

But I still woudn't bet on it being the problem, just because of the symptoms provided regarding the display, in the original thread.

 

[AHicks]

Nothing saying that the controller temp couldn't be one of maybe several issues stacking up on him.

 

[Daan]

As unlikely as it is, it could be. Since we haven't seen any pics from the OP of anything, we don't know how they actually built their bikes.

But I still woudn't bet on it being the problem, just because of the symptoms provided regarding the display, in the original thread.

I use a controller build into the deck, like the picture above, not in a bag. So the set-up is simple.

I have done a LOT of testing, systematically going over all components. I have ruled out:

- Battery, I removed BMS, still the issue.
- PAS sensor, replaced by other type, still the issue.
- Display, swapped out many displays, same issue.

When I swapped the controller to a unit that were used on the previous 10 bikes, which did not have any issue, all problems disappeared. The issue is therefore 100% controller related.

I also have two bikes now that are reporting error code 6, investigating them now. But basically all the 10 controllers have issues with motor cut-out, complete cut-out (display of), or error code 6.

The difference in firmware seems to be the issue, which I reported to the factory now, I hope they can find it.

If any other ideas, let me know.

Thanks for all feedback so far!

 

[geofft]

The difference in firmware seems to be the issue, which I reported to the factory now, I hope they can find it.

With the Kunteng open source fw there was an issue with the main branch in that when the torquesensor code was selected it produced random processor overloads and resets, with symptoms virtually identical to those you describe. Eventually the developer created a new branch with the tqsr code re-written to remove processor intensive instructions, this seems to have completely solved the issue.

It would now seem that you are moving towards this as a possible cause - it looks like the processor is near its limit in these controllers, maybe Kunteng have recently modified the code in some way to push the cpu over the limit? - pure speculation on my part of course.

You would think that any problem like this would not get past the Kunteng testing phase but it could possibly have slipped through. The fact that all your controllers are showing this issue certainly points to a fw problem of some kind.

 

[Daan]

With the Kunteng open source fw there was an issue with the main branch in that when the torquesensor code was selected it produced random processor overloads and resets, with symptoms virtually identical to those you describe. Eventually the developer created a new branch with the tqsr code re-written to remove processor intensive instructions, this seems to have completely solved the issue.

It would now seem that you are moving towards this as a possible cause - it looks like the processor is near its limit in these controllers, maybe Kunteng have recently modified the code in some way to push the cpu over the limit? - pure speculation on my part of course.

You would think that any problem like this would not get past the Kunteng testing phase but it could possibly have slipped through. The fact that all your controllers are showing this issue certainly points to a fw problem of some kind.

Interesting analysis, it could be.

The KT factory is now testing with one of the bikes, but on their testbike the issue doesn't show up. Could be random, could be because they test in the wrong way. Anyway, it's annoying that I have 10 bikes here with the issue, and they can't get it to show up there.

But pretty sure it is the firmware indeed.

The old controllers definitely had some sort of different programm, the power curve is different and the motor only throttles back at 45km/h, instead of 40km/h which it did previously. Both with identical display settings and no speed limit.

So this newer firmware definitely has something to do with it. I hope that they track which firmware they used on which models, then they could easily look at the differences.

 

[Daan]

Alright, the saga continues...

Currently, on 2/10 controllers I get error code 6. Motor cuts out immediately, then shows this error code.

I measured that with the motor UNPLUGGED the yellow and blue phase wires ware shorted ONLY with the display/controller on. So if the power is off, this short is not present.

The other 8/10 don't have this issue yet, but they might face the same faith soon....

Could this indicate a production failure? Or still firmware likely to be the issue?

 

[Daan]

OK, update.

I found that KT used a different MOSFET number on a older controller. I swapped the old mosfets to the controllers that have issues, all was solved. So I am now 99% sure that this different mosfet is causing all the problems.

The new mosfet give more power, sustain higher power, but cut-out and even fail within 2 weeks now. I have had two completely short out, giving error code 6.

Seems plausable?

 

[geofft]

Seems plausable?

.....certainly seems plausible if it's working for you. Those mosfet type numbers look fairly similar, it would be interesting to know if there's any difference in the specs.

All my experience with the KT controllers has been with the 6fet type, the early versions I used had the K150E09NE mosfet, not sure if they were genuine Toshiba or Chinese copies but they proved to be very robust. even with frequent bursts at 20+ amps.

 

[Daan]

.....certainly seems plausible if it's working for you. Those mosfet type numbers look fairly similar, it would be interesting to know if there's any difference in the specs.

All my experience with the KT controllers has been with the 6fet type, the early versions I used had the K150E09NE mosfet, not sure if they were genuine Toshiba or Chinese copies but they proved to be very robust. even with frequent bursts at 20+ amps.

Yeah, the power output is noticeably different with these other mosfets though. Indeed part numbers are sort of similar, so you would not expect big performance changes. But it still seems that is the case....

 

[Daan]

Never mind, it did not fix it.

Instead of opening a new thread, I posted this to Reddit, the same applies here:

Hi Reddit,

Since I am completely clueless, I would like to state my current problem here.

I sell e-bikes for a living and now have issues with 10 of my bikes, which are all related to new KT controllers I got. Before these 10 new bikes, I sold 10 other bikes, which were identical, but there I bought KT controllers (with the same specs) from a third party (re-seller) instead of from KT directly. I will call the 10 bikes without problems BIKE A, and the bikes with problems BIKE B.

BIKE A has the following controller:

On the enclosure:
- KT48SVPRM-CYJF01L 22A
- 22120052
On the PCB:
- KTE-9S5-J2

BIKE B has the following controller:

On the enclosure:
- KT48SVPRM-JBK001 22A
- 23031092
On the PCB:
- KTE-9S5-J6

A picture of the controllers can be found here

Apart from the controller, both bikes are identical, same bafang motor, same battery, same display settings, same everything.

With BIKE B I have the following issues:

- 10/10 bikes have random motor cut-outs. You will start pedaling, or engage the throttle, the motor will turn on for like 0.5 seconds, and afterward will cut off, no power to the motor anymore. The only way to get it started again, is to lift off the throttle, or stop pedaling, and then start pedaling again or engaging the throttle. This only happens like 5% of the time, 95% of the time it doesn’t do this and it works perfectly fine.

- About 3/10 bikes have the same issue as above, but instead of only the motor turning off, the entire system turns off, including the display. You then have to turn on the display again to continue.

- About 4/10 bikes have some sort of display ghost behavior. When you full throttle in the highest assist level, the display changes menus on the KT LCD3 as if you would single press the power button. It only does this when accelerating full throttle, it then ghost presses like 3 times.

- 2/10 bikes have error code 6, I measured a short on the blue phase. Which seems to correlate to a short on of the MOSFETS. So those controllers died already, with only riding a very limited amount. Before they died, they all had the above problems as well.

With BIKE A none of these issues are present, those work totally fine.

What I have tried:

- Used a battery without BMS, same issue.
- Installed a different PAS sensor, same issue.
- Switched 3 MOSFETs there were different in EBIKE A to EBIKE B, same issue.
- Used a lot of different display settings, the same issue.

At this point, I am just clueless. Any help would be much appreciated. If someone can pinpoint the problem, and I can confirm that, I will give you 100 USD. Yes, I am that desperate to get it fixed, or at least knowing what it is caused by. I have a degree in Electrical Engineering, so don't get afraid to get technical. Thanks in advance!

 

[amberwolf]

If it is only happening with that specific set of controllers (and doesn't matter what display you use, one from BIKE A or BIKE B), then it is specific to something in that version of controller. The hardware is probably not different between them, at least not in a way that would do what you see, unless they all have some part that is out of spec and causing an issue.

Things that come to mind are:

-- the MCU itself, for instance if it is a different batch or version, it might have different CPU errata causing different behavior even with identical firmware.

--LVPS; some part of the regulator(s) is unable to supply enough current so the voltage is already right at the edge of the MCU or gate driver tolerance, and drops under specific conditions enough to cause a glitch, shutdown, or reboot, etc. Since heat often affects PSU parts in ways that reduce their ability to supply current, or regulate voltage, this is a thing you could check even on the bench, without riding for random conditions to apply. (but be careful in applying test heat, as if they're already on the edge you could make them fail (though at least you'd know which part was bad :lol: )). Sometimes extreme cold will cause a similar failure to heat for a part that is on the edge.


-- If an external part (motor hall, throtlte hall, PAS hall) draws too much current from the 5v, it could cause this LVPS dropout too.


--Much less likely because it would almost certainly be different failures on each unit in a batch: PCB thru-holes; if the vias or the barrels on a doublesided or multilayer board don't fully attach to the thruhole traces, and the parts attached there aren't fully soldered on both sides, you can have poor or intermittent connection problems, usually on the top (component) side of the PCB, right at the part leg. SMD parts could have solder fractures or even insufficient/incomplete soldering, where the solder on some legs isn't even present, so the only contact happens from pressure applied by the legs of the part that *are* soldered in place holding the part to the board.



Non-hardware issues:

--If the firmware is not identical to those that don't have the problem, it's possible that the FW is the issue, and you'd have to check with KT to see if you can get the non-problem version to flash and test that.

Or try the OSFW on one unit, and see if it still happens.

 

[amberwolf]

About 3/10 bikes have the same issue as above, but instead of only the motor turning off, the entire system turns off, including the display. You then have to turn on the display again to continue.

If power actually shuts off, this isn't (just) a controller issue (unless it is causing such an overcurrent situation that the BMS of the pack turns off, but the fuse doesn't blow).

Either the BMS is shutting down for whatever reason, or the display is not able to stay on, and if it's not on, no power goes to the LVPS in the controller so the controller stops working.

In KT systems (and almost all others using displays), B+ is routed to the controller's FETs, and to the display, anytime the battery is turned on and connected.

The display has a tiny LVPS of it's own that is always on, and keeps the MCU alive to watch the power button. When the power button is pressed, the MCU wakes and turns on the transistor (or FET) that passes B+ to the controller LVPS, which turns on and supplies 12v/5v to the ocntroller and wakes it's MCU, and it begins operating and communicating iwth the display, responding to your inputs, etc.

 

[amberwolf]

- 10/10 bikes have random motor cut-outs. You will start pedaling, or engage the throttle, the motor will turn on for like 0.5 seconds, and afterward will cut off, no power to the motor anymore. The only way to get it started again, is to lift off the throttle, or stop pedaling, and then start pedaling again or engaging the throttle. This only happens like 5% of the time, 95% of the time it doesn’t do this and it works perfectly fine.

- About 3/10 bikes have the same issue as above, but instead of only the motor turning off, the entire system turns off, including the display. You then have to turn on the display again to continue.

- About 4/10 bikes have some sort of display ghost behavior. When you full throttle in the highest assist level, the display changes menus on the KT LCD3 as if you would single press the power button. It only does this when accelerating full throttle, it then ghost presses like 3 times.

FWIW, if there is something wrong with the display power supply (LVPS) so that noise induced on the B+ line (like from excess loading from the FETs, during full throttle, etc.) causes it to output insufficient or noisy / glitchy supplies to the display MCU/etc., it could cause all of those things, assuming that the MCU in the display is able to tell the controller MCU to stop responding to user command inputs (safety shutdown, etc) until the input is removed and repeated, for case 10/10.

Case 3/10 would be that the LVPS glitch crashes the MCU or lasts long enough brownout that the MCU assumes sleep mode, or is an extreme version of case 4/10 below, where the glitch lasts long enough to trigger longpress shutdown.

Case 4/10 would be the glitch is affecting the debounce logic (if any in hardware) or the MCU inputs so that it detects a false input, probably on all input lines at the same time but the power button is probably the highest priority input (interrupt, etc), so it's the one that "sees" the glitch.

 

[Daan]

FWIW, if there is something wrong with the display power supply (LVPS) so that noise induced on the B+ line (like from excess loading from the FETs, during full throttle, etc.) causes it to output insufficient or noisy / glitchy supplies to the display MCU/etc., it could cause all of those things, assuming that the MCU in the display is able to tell the controller MCU to stop responding to user command inputs (safety shutdown, etc) until the input is removed and repeated, for case 10/10.

Case 3/10 would be that the LVPS glitch crashes the MCU or lasts long enough brownout that the MCU assumes sleep mode, or is an extreme version of case 4/10 below, where the glitch lasts long enough to trigger longpress shutdown.

Case 4/10 would be the glitch is affecting the debounce logic (if any in hardware) or the MCU inputs so that it detects a false input, probably on all input lines at the same time but the power button is probably the highest priority input (interrupt, etc), so it's the one that "sees" the glitch.

Thanks for all your replies!

The LVPS is definitely something I will look into more tomorrow. On Bike A I measure 4.8V on the throttle, for bike B I mesure 4.4V. I will do a test under load tomorrow, possibly it drops too much. That indeed could cause issues.

I also will check with the OSFW later indeed. I have been hesitant to do that, since I don't have that many controllers to test with. And once you flash that, you can't go back. But will definitely try this later.

The two controller sets seem to have the same architecture, but quite some components have different model names, but often very similar numbers though. So in theory, every component that is different could be causing issue.

But like you said, it very well could also be firmware related.

Will report back tomorrow.

 

[amberwolf]

So in theory, every component that is different could be causing issue.

Probably not every one...but ones in specific areas affecting specific things common to the problems, especially those as the groups that have the most symptoms in common.

The display is the most common to all the reported symptoms, but if you have used BIKE A displays on BIKE B and still had all of the problems anyway, then it's probably not the display--however, if it isn't, then I don't know what could cause the 2/10 problem (since you've already eliminated the BMS by using a battery that doesn't have one).

(unless the firmware in the KT has error detection that includes a "fatal error" that is so bad that it doesn't just stop and give an error code, but instead actually tells the display to turn the system off because it doesn't know how to deal with it and it's so bad it could destroy things if left powered on, such as a stuck-on gate drive that could create a shoot-thru event, blowing up FETs).