Ninebot One died and came back to life

[glorat]

On the way to my lunch destination today, I had a very minor loss of control. I clipped the road side barrier so ended up turning into and momentarily getting my foot stuck into the barrier with the forward lean causing the bot to try to keep moving forward into the immovable barrier. I was quick to extricate myself and the Ninebot seemed to have wisely switched itself off. Unfortunately, it didn't come on again.

I had my trolley handle with me so had to scoot it the remaining kilometer to lunch. Pressing the power button would make something beep - but there was no other effect on the LEDs nor the motor. I had a dead bot for the next two hours, worried I had a fried motherboard.

When I finally returned home, I plugged it into the charger for a few minutes. Then, just to check, I pressed the power button and it all came to life, with its near full battery as if nothing bad had happened. I gave it a quick test drive and it seemed totally fine.

Any ideas what happened?

This is the Ninebot One C 2016 model running firmware 1.30

[SlowMo]

43 minutes ago, glorat said:

On the way to my lunch destination today, I had a very minor loss of control. I clipped the road side barrier so ended up turning into and momentarily getting my foot stuck into the barrier with the forward lean causing the bot to try to keep moving forward into the immovable barrier. I was quick to extricate myself and the Ninebot seemed to have wisely switched itself off. Unfortunately, it didn't come on again.

I had my trolley handle with me so had to scoot it the remaining kilometer to lunch. Pressing the power button would make something beep - but there was no other effect on the LEDs nor the motor. I had a dead bot for the next two hours, worried I had a fried motherboard.

When I finally returned home, I plugged it into the charger for a few minutes. Then, just to check, I pressed the power button and it all came to life, with its near full battery as if nothing bad had happened. I gave it a quick test drive and it seemed totally fine.

Any ideas what happened?

This is the Ninebot One C 2016 model running firmware 1.30

Please check for a burning smell even though your Ninebot is still alive. 

[SuperSport]

I believe I read somewhere that there is a safety cutoff that is enabled under high stress like that and that it is reset by plugging back into a charger. 

[glorat]

2 hours ago, SlowMo said:

Please check for a burning smell even though your Ninebot is still alive. 

There was no burning smell today.

BUT, I had a slightly similar incident yesterday when parking my Ninebot after use, I placed it on forward lean against a wall and left a big treadmark on the floor. There was a distinct burning smell but the Ninebot seemed unharmed at that time so I put it down the smell of burning rubber rather than burning electronics... although I don't know the smell difference between the two.

Is it worth me opening up the casing for a visual on the mobo? Although not sure what I would be looking for.

2 hours ago, SuperSport said:

I believe I read somewhere that there is a safety cutoff that is enabled under high stress like that and that it is reset by plugging back into a charger. 

Would love to get confirmation of people experiencing this in practice.

[SlowMo]

56 minutes ago, glorat said:

There was no burning smell today.

BUT, I had a slightly similar incident yesterday when parking my Ninebot after use, I placed it on forward lean against a wall and left a big treadmark on the floor. There was a distinct burning smell but the Ninebot seemed unharmed at that time so I put it down the smell of burning rubber rather than burning electronics... although I don't know the smell difference between the two.

Is it worth me opening up the casing for a visual on the mobo? Although not sure what I would be looking for.

Would love to get confirmation of people experiencing this in practice.

The Ninebot when lifted in an uneven manner will not stop running even if you put it back on the floor or against a wall. It once made a nasty mark on our cheap carpeting when accidentally lifted by my daughter. Our experts on the Ninebot would be able to reply to you on whether you need to check the motherboard or not. I hope it's not damaged. Service is not easy to get.

[DangerousDick]

Most likely it 'cut-out' due to an over-current situation.  The temperature might well have increased to the point where it wouldn't return to action straight away - once cooled it will quite happily work perfectly again.

You could take the covers off and take a look at the board but even if there was damage you'd be very lucky to find any visual clues.  Most of the surface mount components just stop rather than deteriorate visibly.

If you had the app on the machine at the time it would have given you notification, or hopefully at least clues?

With Ninebot - I'd at least hope? - there should be over-current, over-voltage, under-voltage, and over-temperature conditions which would cause the board to fail.  Hopefully these failures would be temporary and go away as soon as the condition improved, but it's largely due to the software / component layout available during manufacturer, and tolerance come to that, so it's really anybodys guess.

Hopefully your 'protection' side of the motherboard kicked in and saved vital components and you're now good to go

[Chriull]

Should have been the over-current cutoff from the BMS. This gets "reset" by plugging the charger to the wheel. The other way to reset your ninebot is by dis- and reconnecting the battery pack. Then you do not need to carry/transport it home - with some tools you can open the bot and reconnect the battery just on the street.

[glorat]

Over-current seems the likely issue... would people mind giving me a bit of basic education on what causes this in a design and how circuits protect themselves? I'm a curious engineer.

In this case, I'm guessing what has happened is that with the wheel jammed leaning forward against the wall and my foot, the motor is trying to go at max power output to try to right itself but the wheel gets jammed quickly. I mean it leaves a treadmark on my shoe but the friction means it quickly comes to a full stop despite max power output. Then it shuts itself off.

However, it doesn't make sense to me that a system would be designed in such a way that even in this situation the max power output exceeds the maximum current. I mean voltage is fixed, power output of the motor is capped, so how can current exceed the presumably designed current cap?

And couldn't a BMS correct itself given both the situation rectifying itself plus a bit of time (it stayed dead for 2hours until I got home)? It seems unfortunate if I need equipment to do the reset assuming that there is a non-negligble chance of this happening in general.

@Chriull - Many thanks for this info. If you're right then I feel a lot better and will carry my allen key around with me. May I ask where you got this information from on the reset?

[esaj]

3 minutes ago, glorat said:

Over-current seems the likely issue... would people mind giving me a bit of basic education on what causes this in a design and how circuits protect themselves? I'm a curious engineer.

I'd be interested in seeing a schematic or explanation of how the undervoltage / overcurrent / short circuit protections are handled. Earlier I thought that these were handled separately by having the protection mosfets in series, but based on yesterdays' discussion in the BMS-shunting topic, it seems the transistors mosfets of the BMS are in parallel, and driven by a single gate-signal used by all of them, I wonder how the separate measurements are done and combined to single gate-drive that's dropped to 0V if any of them trigger... all the outputs of the measurements "ANDed" to form the gate signal or some more clever way to handle them all?  My understanding of electronics is still pretty lacking, I tried looking at various protection circuit schematics yesterday, but most of them were made using various more-than-basic ICs and the only one made from discrete components I understood just by looking at the schematic was this: http://3.bp.blogspot.com/_FdGFE8NBDgc/TBtiz9yqfhI/AAAAAAAADRw/siV7n4xfVRs/s1600/low-voltage-cutout-for-12v-sla-batteries.jpg  , so if anyone bothers the explain them, please keep it simple   

3 minutes ago, glorat said:

In this case, I'm guessing what has happened is that with the wheel jammed leaning forward against the wall and my foot, the motor is trying to go at max power output to try to right itself but the wheel gets jammed quickly. I mean it leaves a treadmark on my shoe but the friction means it quickly comes to a full stop despite max power output. Then it shuts itself off.

The current will likely go very high pretty fast if the motor cannot turn, there's very little internal resistance in the mosfets and coils, although inductive behavior of the coils should resist the change in current (slow it down, but not totally prevent it)... kinda like a short circuit, I think? From the forum, I know at least one Ninebot that blew at least some of its half-bridge mosfets after being stuck in a wall leaning forwards. I think the problem might be because the motor will need more than "usual" current to start turning from standstill vs. acceleration when it's already turning... the mainboard might use a higher PWM-duty cycle (higher voltage -> higher current) to get the motor moving when it detects the motor isn't turning yet?

3 minutes ago, glorat said:

However, it doesn't make sense to me that a system would be designed in such a way that even in this situation the max power output exceeds the maximum current. I mean voltage is fixed, power output of the motor is capped, so how can current exceed the presumably designed current cap?

Voltage isn't exactly fixed, as the battery output voltage will drop when more discharged and when large currents are drawn due to internal resistance of the cells themselves (voltage sag). The maximum current is limited by the BMS (by cutting off power when the limit's exceeded, there's some delay before this happens depending on the BMS) and likely the mainboard samples the current and also does some sort of limiting, I don't think anything else than those and the circuit resistance limits the current/prevents the motor from being driven above it's rated/maximum powers (well, except parts blowing up ). Meaning the motor itself doesn't limit the power input / output in any way, the rated / maximum powers are just what it can withstand continuously / for a limited amount of time.

3 minutes ago, glorat said:

And couldn't a BMS correct itself given both the situation rectifying itself plus a bit of time (it stayed dead for 2hours until I got home)? It seems unfortunate if I need equipment to do the reset assuming that there is a non-negligble chance of this happening in general.

@Chriull - Many thanks for this info. If you're right then I feel a lot better and will carry my allen key around with me. May I ask where you got this information from on the reset?

At least the BMS spec-sheets I've seen say that disconnecting the load will reset the over current/short circuit protections, but if the mainboard is always connected and has some sort of "sleep"-state (kinda like ATX-power supplies), I guess that could keep the protection triggered (some sort of Schmitt trigger?)? But I'm just guessing, I really need to learn a lot more about electronics to be able to understand it all

[Chriull]

25 minutes ago, glorat said:

Over-current seems the likely issue... would people mind giving me a bit of basic education on what causes this in a design and how circuits protect themselves? I'm a curious engineer.

A schematic of the mostly used BMS you find in http://forum.electricunicycle.org/topic/459-electric-unicycles-bms-problem-and-solution/

25 minutes ago, glorat said:

...

However, it doesn't make sense to me that a system would be designed in such a way that even in this situation the max power output exceeds the maximum current. I mean voltage is fixed, power output of the motor is capped, so how can current exceed the presumably designed current cap?

Power Consumption/Output of a motor is only capped by the coils starting to melt . (And to a degree of the permanent magnets loosing their magnetization by excess heat.)

25 minutes ago, glorat said:

And couldn't a BMS correct itself given both the situation rectifying itself plus a bit of time (it stayed dead for 2hours until I got home)? It seems unfortunate if I need equipment to do the reset assuming that there is a non-negligble chance of this happening in general.

@Chriull - Many thanks for this info. If you're right then I feel a lot better and will carry my allen key around with me. May I ask where you got this information from on the reset?

The reset is from experience/trial and different descriptions around here.

The short circuit protection has to stay live, as long as it is connected to the load, which caused the overcurrent or it would make not to much sense. So the BMS latches and stays "protected" until the load is disconnected. The second way to reset the BMS is with the charger - the desiger assumed, that the short circuit should be eliminated by the time you charge the pack again.

(IMHO the ninebot needs no shunting - the current limit for BMS cut off should be high enough)

[Chriull]

41 minutes ago, esaj said:

I'd be interested in seeing a schematic or explanation of how the undervoltage / overcurrent / short circuit protections are handled. Earlier I thought that these were handled separately by having the protection mosfets in series, but based on yesterdays' discussion in the BMS-shunting topic, it seems the transistors mosfets of the BMS are in parallel, and driven by a single gate-signal used by all of them, I wonder how the separate measurements are done and combined to single gate-drive that's dropped to 0V if any of them trigger... all the outputs of the measurements "ANDed" to form the gate signal or some more clever way to handle them all?  

You need to put them in parallel to reduce the resistance and divide the current and so the power consumption/heat dissipation of each mosfet. So you have less losses while the high currents (normal situation) are flowing.

If you put the mosfets in series, each has the same current with the full internal resistance and each mosfet burns the whole power and you have multiplied the loss.

Imho you have in the BMS only the overcurrent and overvoltage protection. And these are handled by two different mosfet groups (one in the charge path and one in the discharge path)

Undervoltage protection could be implemented with the overdischarge Mosfets - so its only a simple OR of the alarm signals (with AND both signals would have to trigger at the same time to activate the protection ). Or the undervoltage protection is handled from the mainboard - should both be possible.

Quote

The current will likely go very high pretty fast if the motor cannot turn, there's very little internal resistance in the mosfets and coils, although inductive behavior of the coils should resist the change in current (slow it down, but not totally prevent it)... kinda like a short circuit, I think? From the forum, I know at least one Ninebot that blew at least some of its half-bridge mosfets after being stuck in a wall leaning forwards. I think the problem might be because the motor will need more than "usual" current to start turning from standstill vs. acceleration when it's already turning... the mainboard might use a higher PWM-duty cycle (higher voltage -> higher current) to get the motor moving when it detects the motor isn't turning yet?

Yes - i would see it the same way. While turning the motor should be quite some inductive load limiting the max current, while at standstill you have more or less a short circuit.

But with the PWM pulses it should be possible to make the design fail-safe(r). With some short low duty cycle PWM pulses and the wheel information(rpm) the EUC could detect a "stuck" wheel and prevent the mosfet bridge from blowing up/the BMS overcurrent protection to trigger. While at the same time normal acceleration is not restricted.

But somehow, if you look at the firmware update experiments of the ninebot people, i am happy that they to no make their firmware too sophisticated and at the end you can mostly at least drive nicely with the ninebot

 

[SuperSport]

2 hours ago, Chriull said:

Should have been the over-current cutoff from the BMS. This gets "reset" by plugging the charger to the wheel. The other way to reset your ninebot is by dis- and reconnecting the battery pack. Then you do not need to carry/transport it home - with some tools you can open the bot and reconnect the battery just on the street.

Thank you, that's what I was referring to.  I probably read it in the Additional Battery threads.  I'm considering that mod at some point.

[fearedbliss]

@gloratThats exactly what happened to me when I updates my bot from 1.2.2 to 1.2.7. I was jumping down some stairs and I ended up getting bot go since I jumped off the bot in one of my landings and it just hit the ground and shut down.. It didn't turn back on until I plugged it back in. I had to walk like half a mile back home.. It wasn't an enjoyable experience. Now if I am riding my Ninebot, I always carry a screwdriver with me so that I could try and reconnect the battery if this issue ever happens again. I thought it was related to 1.2.7 but I guess not.

You could read the original post here

http://forum.electricunicycle.org/topic/1673-127-ninebot-one-e-appeared-dead-after-i-was-going-down-multiple-stairs-and-it-fell/

[esaj]

32 minutes ago, Chriull said:

You need to put them in parallel to reduce the resistance and divide the current and so the power consumption/heat dissipation of each mosfet. So you have less losses while the high currents (normal situation) are flowing.

If you put the mosfets in series, each has the same current with the full internal resistance and each mosfet burns the whole power and you have multiplied the loss.

Yeah, that makes sense.

Quote

Imho you have in the BMS only the overcurrent and overvoltage protection. And these are handled by two different mosfet groups (one in the charge path and one in the discharge path)

Undervoltage protection could be implemented with the overdischarge Mosfets - so its only a simple OR of the alarm signals (with AND both signals would have to trigger at the same time to activate the protection ). Or the undervoltage protection is handled from the mainboard - should both be possible.

I was thinking of it more along the lines of n-channel mosfets and that low-voltage cutout -schematic I linked; if all the protections would keep their output high when they are NOT triggered, ANDing all the protection outputs you'd get a "high"-state to the mosfet gates (mosfets conducting). If any of the outputs would go "low", the ANDing of outputs would cause the entire signal would drop to low, preventing the mosfets from conducting... But of course there are multiple ways of doing it.

Quote

Yes - i would see it the same way. While turning the motor should be quite some inductive load limiting the max current, while at standstill you have more or less a short circuit.

Another thing that probably could be affecting the current, on top of inductive phenomenons, is that when the motor's not turning, the back-EMF is essentially 0V. Now, if you put in 30V for example (50% duty-cycle at 60V), the potential difference (voltage drop) over the motor will be the full 30V (minus whatever drops before the motor in the half-bridge high-mosfet etc). If the motor is already running and the back-EMF is 29V, that same 30V from the bridge would only cause 1V voltage drop, and thus much lower current? I could be wrong though, multiple voltage sources in single circuit confuse me

Quote

But with the PWM pulses it should be possible to make the design fail-safe(r). With some short low duty cycle PWM pulses and the wheel information(rpm) the EUC could detect a "stuck" wheel and prevent the mosfet bridge from blowing up/the BMS overcurrent protection to trigger. While at the same time normal acceleration is not restricted.

I think the problem could be that the motor position is unknown, at least when the unit is first started and the motor hasn't turned yet? So the first step is probably to use a bit higher current to drive the motor into a "known position" (induced from the hall sensors?), before the commutation cycle can be started "correctly"... I'm not 100% sure on this either, but plan on testing this once I get my goddamn parts. The postal strike over some days here has made the already long delivery times even longer, and I've currently got around 60 packets (yeah, I've ordered more again ) on the way to get started. I probably forgot something, but here's what's coming over now:  http://ezbe.underkround.fi/shoppinglist.txt  Should be enough to get me started on building all kinds of projects   So far, I've only received a single Uno (well, at least it was the one with the USB-cable), a motor shield and some RF-transceivers (pretty useless without two boards ). But at least some packets should get here early next week, hopefully "enough" so I can build at least something... Over time, I'll probably also need a bench power supply and maybe a better oscilloscope (that 16€ DIY-kit probably isn't exactly high quality ). For start, I'll just go with wall-mounted adapters, 9V rechargeable batteries and maybe using the extra 16S-packs through the DC-DC step-down.

 

 

[glorat]

Thanks all for the replies! This has been very educational and you have implicitly corrected my faulty assumptions behind my last questions and given answers that make sense.

So in lay terms, it with a stuck wheel, the unit is trying to generate max power to correct its position but ultimately fails and cuts out before shorting itself from pushing max power through a non-turning motor. The power cut remains until either the charger is plugged in or the battery disconnected.

My final thoughts are... couldn't a unicycle reasonably detect such a stuck wheel situation? That seems to be what you're discussing. Are there any diagnostics to see if damage got done... or is it just a case of seeing if it still rides okay later?

[Bryan.wells]

I own 2 generic 14" wheels with 350watt motors, BOTH of them occasionally hit a "stress limit" from my 180lbs riding up to steep of a hill or if i ever lean past the point the motor can't dish out.

I will confirm that EVERY time this has happened i just pop it on the charger for literally 5 sec and it resets it right away and off I go. I can confirm this is probably what you have as a feature, I'm guessing the circuit board has capacitors that just get over discharged at that instant and need to be charged back up a little.

[esaj]

6 hours ago, Bryan.wells said:

I own 2 generic 14" wheels with 350watt motors, BOTH of them occasionally hit a "stress limit" from my 180lbs riding up to steep of a hill or if i ever lean past the point the motor can't dish out.

I will confirm that EVERY time this has happened i just pop it on the charger for literally 5 sec and it resets it right away and off I go. I can confirm this is probably what you have as a feature, I'm guessing the circuit board has capacitors that just get over discharged at that instant and need to be charged back up a little.

Sounds like the BMS undervoltage / overcurrent protection triggering.