ASI BAC 8000 cut off after big jumps with high wheelspeed

[MXE]

Hi all,

I do have a issuse on the motocrosstrack with a ASI Bac 8000 Controller wich is build in to a dritbike.

On real big jumps it somtimes cut off on the landing.

When the rider revs the rearwheel in the air, and while landing the rearwheel gets a "hit" because of the rpm drop then the controller cuts off. on the display it says "abnomal current". After switch off the bike and turns back on it runs again.

When hitting the landing very smooth with perfect wheel rpm, it works fine.

Do anybody has the same problem so far? Or any advise how to solve this?

Its a pretty dangerous situation on the mx track.

Best regards form switzerland, Breth

 

[amberwolf]

I don't know a definite solution, but the problem is the sudden current spike.

You'd probably need to find out how high that spike is, and set the system to allow it in whatever current limits it has, if that wouldn't endanger the controller's hardware (overcurrent spikes may have a risk of blowing FETs).

Otherwise the solution is likely simply to not rev the wheel in the air, if it does not overcurrent when the wheel is not rev'd in the air.

If the controller has a function to not allow very fast ramp-up of RPM, you could set that up to prevent the revving in the air from happening.

 

[MXE]

Hi, thank you for your answer.


So it doesnt depend on how fast it revs up in the air alone. its also when you land with early throttle whil landing. this is a common drivingstyle while jumping from every motcross guy. It depends from every different rider, thats clear. But we want to sell our MX kit to different people, so the soulution is not to dont rev in the air.

Yeah of cours ei need to find out how high this overcurrent is.

It dosent cut of whil just reving up in the air, its only under hard load.

 

[amberwolf]

So it doesnt depend on how fast it revs up in the air alone.

That's very likely, given the error condition you report. A simple RPM-change problem shouldn't be reported by the controller as a current error.

its also when you land with early throttle whil landing. this is a common drivingstyle while jumping from every motcross guy. It depends from every different rider, thats clear. But we want to sell our MX kit to different people, so the soulution is not to dont rev in the air.

It's possible that you'd need to do something that prevents revving it up unloaded like that, so that it won't get an overcurrent error, regardless of what the rider attempts to force it to do. It depends on what the controller's limits are and what specifically is causing the error.

If the overcurrent is because it is actually going beyond the controller's limits, then to operate the way the riders will expect you might need a bigger controller able to handle the current required.

If the ability to rev in the air and have the motor and controller and battery be guaranteed to handle the resulting conditions is a requirement, you may have some work ahead to resolve it.

I don't know enough about that specific controller to tell you which settings to start with, unfortunately, just that in general a current error should be caused only by a current problem. If the error is a phase current error, then it's something caused by motor operation, and it is probably a sudden change in current as the RPM suddenly drops (could be either a drop or rise in current; hopefully the specific error the controller gives tells you which one). If it's a battery current error, and the system can feedback current to the battery, it could be the sudden change in RPM is causing a voltage spike at the motor, thus a phase current spike back to the controller, and thus a battery current spike back to the battery (which would be seen by the battery as a voltage spike as well).

It dosent cut of whil just reving up in the air, its only under hard load.

Under any hard load, or only *after* revving it unloaded in the air?


If you're not already doing it this way, then for fastest troubleshooting and resolution, I would recommend doing a good hard ride under all the conditions you expect it to be used in (at least the ones you intend to guarantee users that it will work correctly in), and noting down all error conditions you see, and the specific circumstances they happen in while riding. Then wherever possible, replicate the errors under more controlled conditions (dyno, etc) so you can do controlled experiments with settings changes more quickly (rather than having to take your programming equipment to the riding conditions that cause the errors and experiment there, or worse having to go ride, find problem, go home, change settings, go back to track, ride, get error, go home, change settings....etc. ). Once the error conditions are resolved in the lab, try another hard test ride session under realworld conditions.

Unless there simply are conditions you can't replicate in the lab with some creative equipment and fixture management then this should be a fairly quick test/repair/test scenario.

 

[thoroughbred]

MX riders use the rear wheel as a gyroscope to either lift or drop the front end while airborne. I have read about this exact problem with the ASI BAC controllers, it is a known issue. I'm not sure if anyone figured out how to get around it.

 

[MXE]

yeah i also heard its a commond problem. The ASi would be then usless for fast motocrossriding, i hope it can be fixed somehow.

 

[MXE]

MX riders use the rear wheel as a gyroscope to either lift or drop the front end while airborne. I have read about this exact problem with the ASI BAC controllers, it is a known issue. I'm not sure if anyone figured out how to get around it.

But its not when you rev up in the air (when using as gyro) its only when landing. Or i had it two times when hitting whoops on full load and wheel rpm spinns up while wheel in the air and hits next whoop....

 

[amberwolf]

If it's an unsolvable controller response to the situation, and that controller is the one you have to use, and you are using a motor outside the wheel, you could add a clutch between the motor and wheel that is automatically activated (or rather, deactivated) when this situation would occur.

A sensor would detect the wheel RPM and compare it to the motor RPM, and when the wheel RPM is above some critical point that would never happen on the ground, the clutch would disengage so that the wheel can't feedback into the motor by a jolting RPM change.

At the same time the clutch disengages, it would also limit the motor RPM back to what is expected on the ground at landing, so that when the clutch reengages there won't be such a huge difference in RPM between wheel and clutch and motor such that the system has a problem of any kind.

An acceleration sensor would detect the landing and reengage the clutch at that instant if it wasnt' already reengaged from RPM drop before that, as that is the time momentum transfer to the ground would slow the wheel enough to prevent sudden RPM change at the motor/controller.

I'm sure this system would require significant work to achieve and tune, but if the problem is indeed the RPM change causing an excessive change in phase current in the controller/motor beyond it's limits, it should be able to prevent that without interfering with the ability to use the wheel as a gyroscope (too much).


If it's a hubmotor in the wheel then that solution isn't possible unless it's a geared hubmotor, in which case the clutch would go between the motor and the casing (as the freewheeling clutch in most geared hubs does now).