Power Spikes - Modifying Ninebot Controller

Hi All,

Along with about 80% of the other riders, I've had the unfortunate experience of frying the controller on my Ninebot ES2/ES4. After researching online I came to the conclusion that these boards are flawed in their design and many consumers are having to replace their control boards after as little as 3 weeks of normal use. OEM control boards (not clones) go for about $75-$100.

What seems to be triggering the board failure is use of the electric recuperative brake. If you read the reviews and forums you'll find that people are simply told not to use it or risk frying their board.

The board has weak solder traces on the back which share a common path to the MOSFETs. So luckily the traces blow long before the MOSFETs can be damaged - this means anyone with basic soldering skills can fix their own board. I personally have beefed up my solder traces but that ended up damaging the MOSFETs during the next incident. Some out there are just buying new boards each time.

I have a good understanding of electronics and i'm also a developer, what I'd really like to do is figure out a way to modify this board so that it can cope with the surges created by using the recuperative electric brake. After researching a bit online some suggest adding capacitors to the board to absorb the load but my research shows that caps are good for mitigating high frequency short duration spikes. In the case of the recuperative e brake the voltage / amperage generated would be considered long duration.

My goal is to be able to solder some protective components to the board or possibly attach another circuit to key places on the controller to deal with the excess energy. Ideally the energy would route to something like a headlight or dissipate as heat.

I would like some advice on what components would work best for this application so I'm hoping someone here with an electronics or engineering background can point me in the right direction:
- Add capacitors?
- Add a load dump circuit which would take excess energy and route it to another place (like a light or a battery or something)
- Add a gas discharge tube - these are relatively slow devices but once activated, they can shunt a lot of energy away
- Add a Transient Voltage Suppression (TVS) diode
- Add a metal oxide varistor - A MOV protects electronic components by suppressing the voltage when it exceeds a certain threshold and safely discharging the excessive energy.

Burnt traces after using the e-brake:


Diagram showing the common weak points:


The traces marked in red are the ones which get overloaded and burn up, the Motor wires and MOSFETs are connected to the same traces, I believe the motor is throwing too much energy back into the circuit and frying it. What kind of components can I put in place to shield the circuit from the surge of energy? The normal voltage on this controller is 36 volts.

The community would greatly appreciates any help you can offer to resolve this long standing problem.

Kiki

Hey there, I also have a ES4 and have been playing with the custom firmware generator.
I am very interested in a solution, I'd be happy to place a bounty, nevertheless, this is the right forum.
And I bet many here could boost the damn controller for low orbit travels.

After reading some info on the french forums I've gone ahead and purchased some upgraded MOSFETs and a MOSFET driver.

Current MOSFETs:

Current MOSFET Driver:


Upgrades purchased:

I'm hoping these components (along with beefing up the traces with solder and bridging the weak connections with copper wire) will help but I still believe we need to add something to this circuit to protect it from excess energy. Finding a solution for this would sure help alot of people.

A fuse perhaps?

A fuse on the wires running to the motor? Interesting idea - I guess we’d have to figure out what the current draw and voltage is under normal operating conditions and then install the correct type of fuse.

Ideally though there would be something to add to the board to handle this scenario repeatedly and without manual intervention (like changing a blown fuse)

I'm no expert in circuit design but from what I gather ESCs blowing up under braking is a fairly common issue and as far as I can tell it's usually due to latch up, the gate voltages get high enough to turn themselves on. A "double pulse test" seems to be a good method of evaluating how well an ESC performs and spotting these kind of issues, not sure how to go about doing one though :/

It would be important to know if the FETs blew first or if just the trace blew off the board. If the FETs are OK, then you just need to solder some heavy copper wire over the traces.

It would be very hard to dissipate the amount of energy needed by adding external dissipating elements. Normally you want all that energy to go back into the battery. In the event the pack is fully charged and you start going down a hill, there should be something that reduces or inhibits the braking function to prevent over voltage (it may actually have this already).

The maximum braking current should be limited by something in software. I don't know if there is a way to reprogram it for something lower.

If the FETs are blown you could try upgrading them. IRLB4030 is a pretty good part to start with though. A possible upgrade would be MDP10N027 or TK72E12N1.

Thank you both for your reply, i agree there should be something in the software to limit the over voltage scenario when the brake is applied at high speed but there doesn’t appear to be. I was going down a hill and hit the brake and it didn’t try to let up on the brake even a little before it blew.

It blew the traces out first, then I did exactly what you suggested and soldered copper wire over the traces - a few rides later the same thing happened but this time the MOSFET(s) went. The new mosfets will arrive in a few days so I’ll try those out and repor back.

It’s really disappointing that these things are basically throwaways because the boards have such a bad design flaw. Part of me wonders if it was intentional to capture more revenue on the parts side of things but who knows.

It seems the only protection built into the software is to limit the top speed so the end user doesn’t generate enough energy to blow the board out - that also tells me they don’t have a way to fix this at the software level or they would have.

The community was hoping you’d say we could add some caps or some other components to soak up that excess energy but it is what it is - maybe the only real solution is to install an aftermarket controller and stuff that into the deck somehow. I bought this as a last mile vehicle to commute to work, but given it’s so unreliable I’m not sure I trust it not to fail. If you think of anything else let me know - I’m up for experimenting since I have so many blown boards hanging around.

Thanks
Kiki

From what I gather it's largely rpm related, e-skateboard folks seem to get it a lot when going faster than the ESCs peak speed, ie. coasting downhill and often unexpected, like someone hit the brakes hard. Could be I'm on the wrong track entirely with that though, might be getting mixed up with VESC's electrical rpm limitations.

You could disconnect the brake lever switches so the regen never activates, but that would sort of suck.

Can somebody post a pic of the board top side? There must be a shunt to measure the current. The current signal will feed to the MCU, usually through an amplifier first. It may be possible to spoof the current signal during regen to get a lower current limit. It may also be possible the controller has NO control of the current during regen which would make it hard to fix.

A new controller would be one solution but there aren't many choices that will fit in the space.

I also fried something on my board when going downhill with a fully charged battery . Does somebody know why my battery input terminal is shorted? I already blew two battery connectors. Is it enough to change the MOSFETs and which one would you recommend?

Thanks for your help in advance

Hi guys,

I had customer bring me 2 of these scooters (and approx. 7-8 blown controllers down to this same issue. Didn't seem to make difference if was aftermarket type or genuine parts all suffering the same issue. one has a 48v upgrade and the other one will be getting same battery upgrade while all this being swapped around.
So my theory on how best to solve it would be to just get a bit higher quality controller that will fit in space behind battery and goodbye ninebot problem components.

The owner of the scooters seems to want to keep it to a genuine ninebot setup by upgrading Fets, Caps ect.

Lucky he has 2 scooters so soon will be an answer hopefully as to what is going to be best resolution to issue.
1 scooter will be converted to largest decent controller I can fit in it while other will get most components on board upgraded in hopes to stop it from occurring

This will happen over next couple weeks once get parts so will keep you updated

Hey, I might be one of the people on this forum capable of "boosting this for low earth orbit travel"... But there are so many shit circuit boards out there I'm only focusing on my own ones

Could you post some pics of the other side of the board so i know exactly what we're dealing with?

The reason why controllers fail under regen is multiple:

1) there's a phenomenal amount of instantaneous power that can be generated by the riders mass.
2) the current in a control failure is only limited by the circuit resistance... The motor and pcb... Battery need not be involved
3) in the event of control failure, the 3 phase h bridge system acts as a very erratic buck boost converter, converting the motor voltage into random spikes of voltage and current.
4) MOSFETs die pretty much instantly when their rated voltage is exceeded by more than ~10% and they go into avalanche. The power dissipated in them is then equal to their breakdown voltage x the current your motor can generate, which can be many kW for a few milli seconds.

5) gate drivers tend to die as a side effect of MOSFET death, the MOSFET gate gets punched through and the driver is exposed to the switch node (motor phase) voltage and current.

What causes this control failure?

Badly written software can lose track of the rotor position or lock up.

BMS kicking in and stopping the battery absorbing the regenerates power - it'll build up rapidly into over voltage.

Without robust protection (whether in software or hardware) losing track of rotor position causes the above phenomena.

The over voltage condition can be reached within a few pwm cycles, perhaps 50 micro seconds.

The cure for this is likely not easy in hardware. Swapping out for bigger FETs or gate drivers is unlikely to work unless either it's all just designed right on the edge or you go absolutely nuts with specs. I'd err on the side of higher voltage over higher current, since it's more likely your failure is a result of control loss and avalanche than over heating.

Swapping out bigger capacitors will make the difference between 2 and 5pwm cycles before failure. Again, it'll help if things are right on the edge or the software only checks for faults every 5 cycles but it's unlikely to help much.

Potentially there are things on the board that might enable a fast turn off if you added comparators on the bus voltage and/or current sensors. This would be quite involved modification.

Depending on the board and mcu, there might be open source or off the shelf firmware that could be dropped onto it with more robust control.

Double pulse testing is useful for funding the fundamental limits of a controller, but most likely this is software cock up and the double pulse test will find nothing conclusive... And take extensive mods/reprogramming to do...

I'll also add that under regen the battery voltage increases where under drive it drops. This reduces margins all round.

The control scheme may be stable under drive but much less stable or unstable under regen

The BMS may be saving from control failure under drive but causing gross failure by cutting out under regen.

The firmware may only detect positive over current not negative.

Your idea in the first comment for building a load dump might help... A comparator with hysteresis, a large MOSFET, a large resistor for disipating power... I built one of these in the past as a power supply protection device. It was very effective at saving MOSFETs when my prototype firmware ate itself.

Interesting forum, as this issue seems to be very common.

I'm not an electronic expert at all so I would really apreciate if someone finds a solution after trying all the things you are suggesting. Meanwhile, I will give my oppinion just in case it may help.

As the main problem seem to be overload of energy trying to recharge the baterry when using the electric brake, specially when the battery is fully charged, my first recomendation is to limit the charge of the battery (this has already been suggested before in this forum). This can easily be done in the Segway-Ninebot App. In the top left corner you can access a menu with a "Configuration" option; There you can limit the charge of the battery. Mine has been setup to 90%.

But another great solution, that requires some time and skills, is to install a rear disc brake. There are some videos in youtube on how to do this. I have already installed one. What I did was to install a Xiomi 365 brake kit, which actually has a cable conected to the electonic brake. When you press slightly the brake, the electonic brake takes effect and starts braking the motor, and whe you press harder, the disc brake starts acting, giving you a better and faster "stop". In this case, as the electronic brake is still in use, the risk about frying the board will still be there, so the solution will be to disconnect the wire that goes into the electronic brake.
Actually, I have not tried this yet as in my scooter the wire is still connected, so I'm not sure if dissabling this wire will prompt on an error but if this does not happen, then you will no longuer be using the electronic brake and will not have the risk on frying the board.

Of course, you will no be recharging the battery while riding anymore, but if the distance to be ridden is not too long, then it will be worth it.

Anyway, installing a disc-brake is not an easy solution so lets hope all your ideas/attempts came up with a better solution.

Keep up the good work you are sharing with all of us.

By the way, is there a way MOFETS can be tested in order to check if they are short-circuited, without dissasembling them from the board?

Disconnect the motor wires and measure resistance between the wires (all combinations). A shorted FET will give you a short between a pair of motor wires. Good FETs will measure like a diode, near shorted in one direction and open in the other direction.

Well I've convinced the owner of scooter that it's too much trouble playing with these toy ninebot controllers so we headed down a different path now. The hole design of battery controller needs to fit into original under feet compartment and have managed to go from 36v battery 10x4 config to 16x6 cells for 67v pack in basicly same room the original took up . Has left just enough room by removing
on board charger and have gone with a VESC type controller normally used on skateboards due to the size. Only just getting that all happening over last few days so once finish mucking around with the software side of things be able to tell you how that's all gone.ill get a few pics so can see too. You guys are awesome with your insights into this stuff so much appreciate Ur input

For any 1 interested almost up and running with the new version of the Ninebot Max that I guess could more realistically call a 16bot now due to its new power setup.
I wouldnt be supprised if this 1 of the more extreme ones out there as its had a few modifications but from outside cant really tell is any different to a standard one.
Its got a 16s 6p battery made from Tesla cells out of a model S pack


Running a VESC type controller- Flipsky FSESC 7550 75V ESC Base on VESC6 With Aluminum Case







Just finished getting it all together and ready for its first test on road .
These controllers are really good from what seen so far but not the easiest setup compared to typical controllers as everything needs to be programmed into it. I do literally mean everything , it can link to bms all the control inputs need to be setup and motor parameters just about anything you can think of is all adjustable to the extreme.
It far from the cheapest controller around but to all be located in original space needed something with a lot of power but very small

Very nice build. Only comment would be that the blue film might not be enough to stop breaking through to the metal on the battery. I'd err towards some rigid plastic in select places.

This thing should be easy more powerful than the original.

Few questions...
The original controller. Can you flash different firmware e.g. One of the ebics firmwares to it? What MCU is it? Looks like there are lots of board variants.

What are the wheel motors? That FSESC controller might be capable of melting them.

mxlemming said:

Very nice build. Only comment would be that the blue film might not be enough to stop breaking through to the metal on the battery. I'd err towards some rigid plastic in select places.

This thing should be easy more powerful than the original.

Few questions...
The original controller. Can you flash different firmware e.g. One of the ebics firmwares to it? What MCU is it? Looks like there are lots of board variants.

What are the wheel motors? That FSESC controller might be capable of melting them.

Click to expand...

MCU is STM32, you can flash a custom firmware that you configure on this page : https://max.cfw.sh/