Top speed of 84v Monster V2

[Nick McCutcheon]

1 hour ago, Chriull said:

But your reported values would indicate clearly an overlean.

Correct me if I'm wrong, but I thought an overlean is when you exceed the wheel's capabilities while it is still trying to balance you? In my case (and possibly in this case), the wheel simply removed power as it decided you have gone too fast for your battery level so you must obviously be doing a lift test (often untrue), which would be a cutout. I still think these types of cutouts are avoidable in firmware/can at least be converted into overleans in the case of high speed overpowerings, but I suppose I'll have to develop my own wheel to verify this 

Looking at the chart it seems the current drops sharply before the speed, which would indicate that the wheel stopped delivering power just before the crash/deceleration happened. I would think this indicates a cutout rather than an overlean?

Regardless, a working beeper would have at the very least let this rider know he was approaching the speed limit. @Slartibartfast are you sure it was a broken beeper issue and not just plugged into the wrong port? I've had that happen before and just switched the port it was plugged into to the correct one, and it worked again. Maybe you could test this by trying out the beeper from your MSX in this wheel to see if the beeper is broken? And just to make sure I understand, is this the same board that was installed in the wheel from the factory or a replacement board? I've never seen a fresh board with a defective beeper port before. If you are able to send a picture of your board I can help identify where the port is if that's needed, but I can imagine you've found the connector diagram for your board online. 

[Chriull]

1 hour ago, Slartibartfast said:

I'm not exactly sure what you mean by a "motor/phase current vs speed" diagram,

As written above like the second diagram shown in 

On the y axis the current and on the x axis the speed.

1 hour ago, Slartibartfast said:

but does this plot help:

 

This is "just" current and speed over time.

1 hour ago, Slartibartfast said:

I also tried rendering the data as an X-Y Scatter Plot but that doesn't seem to show anything intelligible.

This should be exactly such a diagram. If one has the points follow a line (current(torque) over speed limit) down on the right most side it was an overlean. Like the example in my link above.

[Chriull]

18 minutes ago, Nick McCutcheon said:

Correct me if I'm wrong, but I thought an overlean is when you exceed the wheel's capabilities while it is still trying to balance you? In my case (and possibly in this case), the wheel simply removed power as it decided you have gone too fast for your battery level so you must obviously be doing a lift test (often untrue), which would be a cutout

No. The firmware only cuts off the wheel once lift cut off speed is reached fir some time.

With an overlean one just reaches the system limit and the euc can't provide needed (counter)torque and one falls foward. Many details to be foud in 

 

21 minutes ago, Nick McCutcheon said:

Looking at the chart it seems the current drops sharply before the speed, which would indicate that the wheel stopped delivering power just before the crash/deceleration happened. I would think this indicates a cutout rather than an overlean?

One has to make the current over speed graph to draw conclusions out of the data. In my overlean example there also current decreases first. The wheel is still a bit accelerating, but not enough - as available torque==current decreases.

[supercurio]

1 hour ago, Slartibartfast said:

Thanks @Slartibartfast for sharing the data, yes it's a great diagram. Battery current estimate could also add insight in this context. 
Agree with @Chriull, the wheel data confirms 100% confirms a textbook overlean.

• Speed increases up to the level where back-EMF voltage of the motor is getting too close to the battery voltage
• Controller can't push enough current anymore into the coils to maintain the torque necessary to fight the wind+rolling resistance
• The lack of torque makes the wheel tip forward
• The wheel balancing algorithm "shuts off" beyond a maximum forward tilt angle for longer than a brief instant (and the wheel doesn't have to torque to recover anyway)

Most likely @Slartibartfast you must find a way to restore the beeper function, even if it requires a bit of wiring, soldering and glue.
My app EUC Alarm will help if you have a new board which supports the bluetooth beeper status but I'd still recommend to have the hardware beeper wired, for sure.

@Nick McCutcheon your description also matches the overlean definition.
Yeah it would be a great feature to let the user select a preferred safety margin for alerts, between 80% and any lower percentage if they'd like, like 60% if they only care about safety. This will be part of the spec for the upcoming safety data wireless protocol standard.

But what's wrong with voltage-dependent speed alarm you might ask?
It's fairly simple actually:

Here's what's not taken into account

• Wind
• Gradient
• Bumps
• Road surface

Imagine if like @Nick McCutcheon you confirmed many time your wheel does 46 mph at 50% battery just fine.
Okay but that time you have a 20mph headwind, 2% uphill gradient, there's bumps on the road here and there, and the road surface is a mix of gravel&sand.
What do you think would happen?

[Freestyler]

Here is another overlean / overspeed taken from my monster sport for your viewing pleasure.

[Nick McCutcheon]

8 hours ago, supercurio said:

Thanks @Slartibartfast for sharing the data, yes it's a great diagram. Battery current estimate could also add insight in this context. 
Agree with @Chriull, the wheel data confirms 100% confirms a textbook overlean.

• Speed increases up to the level where back-EMF voltage of the motor is getting too close to the battery voltage
• Controller can't push enough current anymore into the coils to maintain the torque necessary to fight the wind+rolling resistance
• The lack of torque makes the wheel tip forward
• The wheel balancing algorithm "shuts off" beyond a maximum forward tilt angle for longer than a brief instant (and the wheel doesn't have to torque to recover anyway)

Most likely @Slartibartfast you must find a way to restore the beeper function, even if it requires a bit of wiring, soldering and glue.
My app EUC Alarm will help if you have a new board which supports the bluetooth beeper status but I'd still recommend to have the hardware beeper wired, for sure.

@Nick McCutcheon your description also matches the overlean definition.
Yeah it would be a great feature to let the user select a preferred safety margin for alerts, between 80% and any lower percentage if they'd like, like 60% if they only care about safety. This will be part of the spec for the upcoming safety data wireless protocol standard.

But what's wrong with voltage-dependent speed alarm you might ask?
It's fairly simple actually:

Here's what's not taken into account

• Wind
• Gradient
• Bumps
• Road surface

Imagine if like @Nick McCutcheon you confirmed many time your wheel does 46 mph at 50% battery just fine.
Okay but that time you have a 20mph headwind, 2% uphill gradient, there's bumps on the road here and there, and the road surface is a mix of gravel&sand.
What do you think would happen?

@Chriull I'm trying to rework how I think about this by reading the anatomy thread, and I think I'm getting it, but I still have a few questions. I'm not trying to refute what you are saying as obviously you have a lot of experience analyzing overleans, I am just trying to better understand your findings.

• So the reason current decreases as you are overleaning is because there's less "room" for current to be drawn because the back emf gets too close to the battery voltage? If not, why does this happen?
• It seems like the "time to overlean" figure is basically a function of current, acceleration and speed given relatively constant (decreasing as the battery voltage decreases) I_max and v_max_no_load, which together give a constant motor Kv rating. So as you accelerate/continue to draw high current, the time to overlean decreases as your speed increases, and reaches 0 when your speed given your current current (haha) is too high? 
  • What determines this "maximum speed" that can be reached before overleaning?
• In these types of cases the torque limit is reached so quickly that it would feel like a cutout? In my case it still felt like there was plenty of power left on flat ground, but I suppose this is not an indicator of how close you are to overlean?
• Isn't the beeper voltage-dependent as confirmed by GW and thus would not be a good indicator of proximity to danger? In supercurio's hypothetical case, those added-on obstacles would just demand more current causing a voltage drop and thus "triggering a beep"/alarm earlier? Admittedly only being able to set 3 distinct steps for the speed alarm in EUC World is a bit limiting, ideally there would be an option to "connect" these points together to form a line/graph which determines when the alarm sounds. 
• Is there ever a case where a legitimate cutout at high speed (without the board failing) can occur as opposed to an overlean, or have we all been wrongly calling these cases cutouts when they are really overleans?

Also, @Seba do you know how the safety margin is approximated/"calculated" for GW/Veteran? I tried searching the forums for an explanation as to how this value is determined but I didn't have much luck, however it's possible I missed it. 

Sorry if I am missing something obvious, I really am trying my best to understand the anatomy thread, I just want to make sure I'm not misinterpreting your calculations. 

[Slartibartfast]

15 hours ago, Chriull said:

On the y axis the current and on the x axis the speed.

Here is the scatter plot:
 

That really just looks like a random splattering to me but perhaps it means something to you. It seems the current values are all over the map in relation to the speed, until I come off and you can see that straight line from 52 -> 33 -> 23 ->  9 ... 0 which I dare say happened after I fell.

Is there another way you'd like the data visualised?

Note the above diagram is showing just a small amount of data before and during the crash. with the full ride up to the crash it's even more chaotic:

 

And with lines connecting the dots:

You can see the line through the middle showing the sudden drop to zero but apart from that there isn't much correlation. It pretty much looks like every "phase_current" value is more or less achieved at every speed (other than when traveling very slow).

Edited January 23, 2022 by Slartibartfast

[Slartibartfast]

10 hours ago, supercurio said:

Battery current estimate could also add insight in this context. 

Battery started at 90% and I estimate the crash would have happened at about 85% however with the current draw the battery is showing to be down to about 50% at the time of the crash:

 

This is a graph of the entire ride with the crash happening a little before halfway.

[supercurio]

@Slartibartfast note that *battery percentage* is typically a processed and smoothed value which is based on voltage, but might use other data points to give a state of charge estimate in % by removing the voltage sag.

So for anything margin or alarm related it should be ignored: raw voltage value is the reference.

Edited January 23, 2022 by supercurio
Oops! Fixed stupid error: meant battery %

[Slartibartfast]

40 minutes ago, supercurio said:

@Slartibartfast note that voltage is typically a processed and smoothed value which is based on voltage, but might use other data points to give a state of charge estimate in % by removing the voltage sag.

I assume you mean the battery value is processed...

Here is the critical section with speed plotted along with raw voltage values:

Edited January 22, 2022 by Slartibartfast

[supercurio]

1 hour ago, Slartibartfast said:

I assume you mean the battery value is processed...

Oops yes absolutely! my bad for not proofreading.

Yes unless it's a "dumb" percentage calculation directly based on voltage it will be likely at least smoothed over time.

 

So at the end we see well what happened with voltage as main cause for the overlean: voltage sag by a few seconds draining significant current from the packs, which reduced pushed the voltage down too low compared to the motor back-EMF, meaning not enough current into the motor, not enough torque and ground.

Do you think you'll be able to fix the beeper? I hope you will 👍

[Slartibartfast]

26 minutes ago, supercurio said:

Do you think you'll be able to fix the beeper? I hope you will 👍

I'd much prefer to have tilt back come in than a beeper. I typically listen to podcasts while I wheel and I simply can't hear a beeper at speed.

I'll have a go at getting it operational again but honestly, I don't think it would have helped in this instance even if it was working.

 

Now that I know this wheel is prone to cutting out at 55 I'll be sure to keep away from that speed. My typical cruising speed on this wheel is probably about 40 and I'll just be much more conscious of being closer to the limit that I previously thought. I grant you "staying below 50" isn't a foolproof solution but just being aware of how close it is to the limit will stop me "pushing it" unnecessarily.

Edited January 23, 2022 by Slartibartfast

[Slartibartfast]

My original purpose in starting this thread though was to ask what kind of speed the 84v Monster was meant to be capable of.

Personally I thought a 55 km/h (35 mph) cut-out was lower than I was expecting. Does anyone know if this is actually normal for flat ground, smooth riding and a relatively full battery, even for an admittedly heavy rider?

Edited January 23, 2022 by Slartibartfast

[supercurio]

3 hours ago, Nick McCutcheon said:

• So the reason current decreases as you are overleaning is because there's less "room" for current to be drawn because the back emf gets too close to the battery voltage? If not, why does this happen?

Yep exactly that 👍 for mechanical torque to be generated there need to be a certain amount of current going through these coils. The controller steps down the battery voltage into the voltage for the motor following the rotation speed back EMF + whatever is needed to get the current expected to get the torque needed.

Then at higher speeds the voltage of the battery, then not stepped down anymore might not be enough to get the current & torque. And even if the rider has constant speed, it can't necessarily be maintained due to voltage trending downwards.

3 hours ago, Nick McCutcheon said:

Isn't the beeper voltage-dependent as confirmed by GW and thus would not be a good indicator of proximity to danger? In supercurio's hypothetical case, those added-on obstacles would just demand more current causing a voltage drop and thus "triggering a beep"/alarm earlier? Admittedly only being able to set 3 distinct steps for the speed alarm in EUC World is a bit limiting, ideally there would be an option to "connect" these points together to form a line/graph which determines when the alarm sounds. 

I think this is where a good alarm calculation is at the very minimum based on the controller's inverter load, which takes speed+voltage+power everything into account by nature. Ideally it would take a voltage dependent battery current as well in order to not drain the cells themselves too much, which could accelerate the voltage sag so much the user might not be able to slow down fast enough to avoid an overlean.

35 minutes ago, Slartibartfast said:

I'd much prefer to have tilt back come in than a beeper. I typically listen to podcasts while I wheel and I simply can't hear a beeper at speed.

I'll have a go at getting it operational again but honestly, I don't think it would have helped in this instance even if it was working.

Then using another wheel would be advisable I'm afraid, since Gotway wheels don't have a tiltback alternative to beeps. Only a fixed speed tiltback which doesn't adapt to battery voltage nor load. Or a new enough board which will give you the beeper status over Bluetooth (and you'd hear the beeps for sure over music or podcast since they're muted when it beeps)

 

To answer your last question, well sort of: there's no anser to the question: "what kind of speed the 84v Monster was meant to be capable of."

Because it depends on your height, what you're wearing, your posture (all 3: aero drag), the weather and temperature, the wind at any point in time, tire pressure, tire wear, battery state of charge, cells degradation, incline, if its s speed reached gradually or after a strong acceleration.

I hope you see what I mean 😄: max safe speed depends on so many variables that it doesn't exist for any wheel, unless your riding conditions are as repeatable and predicable they'd be in a lab.

Otherwise you have to get the motor controller status itself in your alarm feedback, or have a really solid model based on voltage, phase current and speed - that's what Seba tried to implement with the safety margin estimate. It's not usable for alarms at all for Sherman, maybe it's a bit better for Gotway wheels it was designed against.

Edited January 23, 2022 by supercurio

[meepmeepmayer]

I would consider these Gotways (like the Monster 84V or msuper V3) 50kph wheels. They weren't that fast, and are not comparable to modern 100V crazy fast wheels. So a cut-out at 55kph seems normal to me, at least for a bigger rider (50kg riders can do a lot of things).

[Slartibartfast]

Yeah, I get there are a lot of variables that affect the maximum speed but simply saying there's no way to know isn't helpful.

The best answer we've had so far has been @alcatraz's "20 below free spin" rule of thumb, which, although imprecise definitely indicates I was pushing the limit at 55, which I had no idea that I was.

@Chriull's recollection of the V1 Monster having the third alarm at 45-55 km/h also seems to imply I was also pushing it.

Edit:

50 minutes ago, meepmeepmayer said:

I would consider these Gotways (like the Monster 84V or msuper V3) 50kph wheels. They weren't that fast, and are not comparable to modern 100V crazy fast wheels. So a cut-out at 55kph seems normal to me, at least for a bigger rider (50kg riders can do a lot of things).

Arr, thanks @meepmeepmayer, that puts it beyond doubt!
 

I guess I just bought this wheel when it was the biggest and fastest wheel on the market. I actually bought it for the range rather than the speed and never expected to exceed it's speed capability. Over the years wheels have gotten faster and faster and I guess I never stopped to think my wheel was in fact an old 84v beast and that I had actually progressed unwittingly up to it's limit. Time for a Sherman me thinks: 

Edited January 23, 2022 by Slartibartfast

[mrelwood]

 

3 hours ago, supercurio said:

Yes unless it's a "dumb" percentage calculation directly based on voltage it will be likely at least smoothed over time.

Isn’t the percentage value always a product of the app though, as I don’t think any wheel itself reports actual percentage in the data it sends. Only voltage, IIRC. So for any data dump and post crash analysis, unless the graphing app smoothes the percentage for the graph as well, a percentage value is a true representation of the actual battery state at any given time. Or just a “dumb” conversion as you called it.

2 hours ago, Slartibartfast said:

Time for a Sherman me thinks: 

If you’d be fine crawling under 50km/h for a little longer, there are seemingly amazing large wheels coming out this year, the KS S20 and the Inmotion “V13”. Both with a 2nd gen suspension, and both largely exceeding the rideable top speed of your current 84V Monster. (Note that the top speed of KS and IM already include a hefty safety margin, so you don’t need to add one yourself like you do with GW/BG/Veteran.)

[supercurio]

8 hours ago, Slartibartfast said:

Yeah, I get there are a lot of variables that affect the maximum speed but simply saying there's no way to know isn't helpful.

I understand your point of view.

I still think that the answer to "what's the maximum safe wheel for my wheel" is: there's no such thing, without a functioning alarm system connected to the controller.

That might be a bit too literal in some cases, but given the total amount of people crashing due to the belief that X speed is safe on Y wheel and either not hearing or ignoring the beep, I believe it's the better answer - and all these crashes could be avoided.

On the flip side, when you anchor beliefs like max safe speed is freespin -X km/h, you might end up with things like "cutout tunnel" in NYC (primary cause: change of incline)

Edited January 23, 2022 by supercurio

[Chriull]

18 hours ago, Nick McCutcheon said:

@Chriull

• So the reason current decreases as you are overleaning is because there's less "room" for current to be drawn because the back emf gets too close to the battery voltage? If not, why does this happen?

True. Maybe easy to understand in combination with the simplified equivalent schematcs in the "basics" topic prior to the anatomy of an overlean topic: 

 

18 hours ago, Nick McCutcheon said:

• It seems like the "time to overlean" figure is basically a function of current, acceleration and speed given relatively constant (decreasing as the battery voltage decreases) I_max and v_max_no_load, which together give a constant motor Kv rating. So as you accelerate/continue to draw high current, the time to overlean decreases as your speed increases, and reaches 0 when your speed given your current current (haha) is too high? 
  • What determines this "maximum speed" that can be reached before overleaning?

Time to overlean is derived from the motor current over speed diagram. There the max current (==torque) over speed limit line can be drawn (line from (Imax,0km/h) to (0A,max no load speed)).

If one looks at the csv log data and takes two consecutive points one can extrapolate how long it will take until one hits this limit line - i.e. overleans the wheel.

18 hours ago, Nick McCutcheon said:

• In these types of cases the torque limit is reached so quickly that it would feel like a cutout? In my case it still felt like there was plenty of power left on flat ground, but I suppose this is not an indicator of how close you are to overlean?

How to feel how much power is left?

18 hours ago, Nick McCutcheon said:

• Isn't the beeper voltage-dependent as confirmed by GW and thus would not be a good indicator of proximity to danger?

Voltage is one parameter as it shifts the limit line to the left or right.

18 hours ago, Nick McCutcheon said:

• In supercurio's hypothetical case, those added-on obstacles would just demand more current causing a voltage drop and thus "triggering a beep"/alarm earlier? Admittedly only being able to set 3 distinct steps for the speed alarm in EUC World is a bit limiting, ideally there would be an option to "connect" these points together to form a line/graph which determines when the alarm sounds. 

The "real" alarm should be based on pwm duty cycle as reported by inmotion and ks wheels. Ks wheels have a fixed alarm once 88% are exceeded, so 12% "safety margin" left.

Perfect would be a tiltback based on a configurable pwm duty cycle value. Or even better dynamicly like with a settanle "time to overlean" based on pwm duty cycle change.

18 hours ago, Nick McCutcheon said:

• Is there ever a case where a legitimate cutout at high speed (without the board failing) can occur as opposed to an overlean, or have we all been wrongly calling these cases cutouts when they are really overleans?

I'm not sure i understand this question. But without a hardware or firmware fault there are only overleans and no cutouts possible. There is nothing that could or would "cut out".

18 hours ago, Nick McCutcheon said:

Sorry if I am missing something obvious, I really am trying my best to understand the anatomy thread, I just want to make sure I'm not misinterpreting your calculations. 

Seems you got the most important pounts quite well!

Edited January 23, 2022 by Chriull

[Chriull]

17 hours ago, Slartibartfast said:

Is there another way you'd like the data visualised?

Your first scatter plot (data points just around the overlean) connected with lines would be great.

The points around (80A,55km/h) seem to be were you touched shortly the limit. But the "normal overleans" i've analyzed show the points to follow down this limit line (decreasing motor current, increasing speed) until the rider is off the wheel faceplanting. Then the wheel "breaks" with maybe some "jumps" before. As likely the current spike after the overlean in @Freeforester's example above.

So it seems as you intuitively reacted to the overlean and stopped accelerating the wheel somehow? But hard to say by the scatter plot without connecting lines as the timely order cannot be seen.

[Slartibartfast]

Okay, here are some more plots.

This is a line connecting the last 20 points up to and including the crash:

 

Here are the last 150:

 

And the last 500:

It appears data is collected at a rate of about 5 samples per second, so that last plot is showing a little under a minute of riding time.

I'm not seeing anything significant in these plots myself. In the 150 point plot (30 seconds) you can see there were two "slow down" events where the current drops and goes negative, one from about 38 -> 28 km/h and another from more like 40 -> 35 km/h, and the 500 point plot shows several slowdowns, the most significant being from about 52 -> 28 km/h but I'm not seeing anything out of the ordinary here.

 

Edited January 24, 2022 by Slartibartfast

[Slartibartfast]

Note: The same can be seen, probably more intuitively when the two curves are plotted along a time axis:
(my apologies for the lack of labels, but the blue line is "speed" and orange is "current_phase")

 

 

 

As I say though, I'm not seeing anything out of the ordinary here myself –well nothing other than that extreme trop in speed at the end: 

Edited January 24, 2022 by Slartibartfast

[alcatraz]

If rider weight, tire pressure, tire type, ambient temperature, road surface smoothness, wind conditions, influences the torque requirement for any given speed...

...what good is it then to know the max speed if you can never use it?

A young boy, riding in a vaccuum going down a newly paved hill on slick tires with research rubber pumped up rock hard, you can theoretically reach it. 

To account for day to day changes you should adopt healthy margins. 

Edited January 24, 2022 by alcatraz

[Chriull]

4 hours ago, Slartibartfast said:

I'm not seeing anything significant in these plots myself.

Yes. Not too much to be seen, everything went "very fast" in your case...

Serms to be a "short touch" at the limit and the more or less immediate fall. Everything happened between point 12 and 18 in the first of your "normal" curves - so within a second.

This 5 points a second is unfortionately a little bit coarse.

 

[Slartibartfast]

1 hour ago, Chriull said:

Everything happened between point 12 and 18

I would say everything happened between points 16 and 17, when the speed was at 52 km/h and the "phase_current" plummets from 65 to -10 for no apparent reason.

Who knows if the wheel basically just shut off, making me fall, or if I fell which lead to the wheel shutting off: ¯\_(ツ)_/¯

What ever it is that happened sure looks like it happened in that 1/5th of a second though.

Edited January 24, 2022 by Slartibartfast