Speed-to-voltage scatter plots for few popular EUCs

[Seba]

From time to time there are various discussions on our forum, concerning the dependence of the maximum speed of a given unicycle on the battery charge. I have decided to make a few graphs that show this relationship based on the actual data from our EUCs. Unfortunately you won't find any Gotway wheels here. This is due to the fact that these wheels do not send any data to the application allowing for their unambiguous identification. @Chriull and @Aneta, I think this is something for you 

 

[Chriull]

@Seba -Nice data! No need for excel sheets and guessing anymore!

There are 2 KS18XL?! Two different mainboar/firmware versions?

The KS16X has a bunch of entries downto 58V! That would be 2.9V cell voltage! And a "hole" around 62V?! Some "aretfact" or firmware reporting error?

The other wheels have just some "dips at speed" downto lower voltages - riders desperately trying to get home and getting low voltage tiltbacks?

Edited December 4, 2019 by Chriull

[Seba]

22 minutes ago, Chriull said:

There are 2 KS18XL?! Two different mainboar/firmware versions?

No, there is KS-18L and KS-18XL. Unfortunately there is no way to determine board version, but I don't think this would cause any significant difference.

23 minutes ago, Chriull said:

The KS16X has a bunch of entries downto 58V! That would be 2.9V cell voltage! And a "hole" around 62V?! Some "aretfact" or firmware reporting error?

I was surprised too. I suspect it's a problem with early versions of firmware. In the case of King Song, the communication protocol includes the transmission of the exact voltage value, so there is no possibility of erroneous calculation or scaling.

25 minutes ago, Chriull said:

The other wheels have just some "dips at speed" downto lower voltages - riders desperately trying to get home and getting low voltage tiltbacks?

It's very possible. But what surprised me the most was that KS-16X starts throttling just after passing 78 V. In this regard I rather expected it to be no worse than KS-18XL, which starts to throttle below 68 V.

[Blueblade]

Nice charts!  One suggestion that might be interesting if the plotting program supports it: make the dots partially transparent.  This way instead of all dark blue blobs, you will be able to much more clearly see clustering/groups within, shown as darker areas.

For example:

https://blogs.sas.com/content/iml/2011/03/04/how-to-use-transparency-to-overcome-overplotting.html

[Seba]

5 minutes ago, Blueblade said:

Nice charts!  One suggestion that might be interesting if the plotting program supports it: make the dots partially transparent.  This way instead of all dark blue blobs, you will be able to much more clearly see clustering/groups within, shown as darker areas.

For example:

https://blogs.sas.com/content/iml/2011/03/04/how-to-use-transparency-to-overcome-overplotting.html

Yes, I know it could be done much better  I just wanted to make a quick & dirty plots that will show speed limits at certain speeds.

[Blueblade]

Just now, Seba said:

Yes, I know it could be done much better  

Don't be too humble, now... these are the best plots of this kind of data anybody has posted to date :-)

[Aneta]

Good effort, @Seba! I love visualizations of big data, you get to see what's not "visible to naked eye". I'd love to see scatter plots of current and power vs. speed as well.

[Seba]

Just now, Aneta said:

I'd love to see scatter plots of current and power vs. speed as well.

In order for such charts to have any value, I will need to complete the data with weather conditions and the weight of the rider. Fortunately, it should be doable :-) Historical weather conditions can be found on the Internet (there are several weather services with API), and everyone will be able to add their weight in the account settings.

[Mike Sacristan]

11 minutes ago, Seba said:

In order for such charts to have any value, I will need to complete the data with weather conditions and the weight of the rider. Fortunately, it should be doable :-) Historical weather conditions can be found on the Internet (there are several weather services with API), and everyone will be able to add their weight in the account settings.

Very nice work!
Corresponds very well with what I am getting on my 16X and this was regardless of FW 1.05 or 1.07.

[Aneta]

11 hours ago, Seba said:

In order for such charts to have any value, I will need to complete the data with weather conditions and the weight of the rider. Fortunately, it should be doable :-) Historical weather conditions can be found on the Internet (there are several weather services with API), and everyone will be able to add their weight in the account settings.

I think it would still be useful, because what we look at these scatter plots is the envelope of all possible states, i.e. extremes. So the upper boundary of the blob of current or power vs speed will show the maximum current or power of the given segwheel. (well, not exactly maximum, because maximum = overlean, but the upper limit of how close the riders of this wheel dare to approach "the cutting edge") On average, light or heavy riders will approach the limits of the wheel to the same extent (for example, where a heavy rider will be accelerating or going up steep slopes more cautiously, intuitively taking into account heavier load, the lighter rider will accelerate more aggressively and go up steeper slopes - but the max current will be about the same). So, the envelope will be a distinctive fingerprint of the given segwheel. Should be interesting!

PS. Too bad we don't have the phase current (only for Gotways?), or better yet, both battery and phase currents. (and motor voltage?) Then we could get something resembling the Motor Simulator (ebikes.ca) graphs. Oh well.

Edited December 5, 2019 by Aneta

[Ben Kim]

This is basically what I've been saying, Kingsong wheels ride slower than their app-reported speeds by a good ~10%.  I'd love to see Gotway data, but based on my own anecdotal testing, the app-reported speed and GPS are within 1 mph of each other, usually less.

[MexicanBatman]

I can still do 30km/h on my MSX @ 66.5v

 

but she tilts back almost 45deg, it’s a real good calf stretch!

 

sub 60v is madness on the 16x

 

if my MSX would go that low I’d get another 40km out of it
 

photo is a screen shot from the video where I’m riding it 30km/h

Edited December 5, 2019 by Trevor Phillips

[Seba]

11 minutes ago, Ben Kim said:

Kingsong wheels ride slower than their app-reported speeds by a good ~10%.

~9% in case of KS-16X and ~18% in case of KS-18L/XL.

12 minutes ago, Ben Kim said:

I'd love to see Gotway data, but based on my own anecdotal testing, the app-reported speed and GPS are within 1 mph of each other, usually less.

You're right, Gotways report exact speed.

[Chriull]

12 hours ago, Aneta said:

Good effort, @Seba! I love visualizations of big data, you get to see what's not "visible to naked eye". I'd love to see scatter plots of current and power vs. speed as well.

Me too - but i do not really see by now how to too this in detail. For current, power could work wo problem? At least for wheels reporting battery current one gets the battety power easily. Motor output power needs some calculations...

12 hours ago, Seba said:

In order for such charts to have any value, I will need to complete the data with weather conditions and the weight of the rider. Fortunately, it should be doable :-) Historical weather conditions can be found on the Internet (there are several weather services with API), and everyone will be able to add their weight in the account settings.

Why? That's a nice addition, too - imo especially for range considerations.

Current over speed diagrams just show where within the "limit" one is driving. No matter of weight, incline,... All this burden factors "just" determine the reported current value.

1 hour ago, Aneta said:

I think it would still be useful, because what we look at these scatter plots is the envelope of all possible states, i.e. extremes. So the upper boundary of the blob of current or power vs speed will show the maximum current or power of the given segwheel.

"Unfortionately" the upper boundary (max current == torque over speed limit) shifts proportionally with battery voltage (the no load battery voltage - without the burden induced voltage sag). So in a big data scatter graph the limit lines are a range/area, too. One will just see the outermost limit for full batteries. Faceplants happend with low/empty batteries are just somewhere inside of the blob.

I tried, to overcome this, to "normalize" every point by dividing current and speed by their according no load battery voltage and multiply again with a fixed voltage (for example 84V).

So one "projects" all possible limit lines to one line again, but all other points "below" are "indeterministicly skewed".

So it is not possible anymore to draw for example lines to show tiltback speed - they are by this transformed to an area...

1 hour ago, Aneta said:

... On average, light or heavy riders will approach the limits of the wheel to the same extent (for example, where a heavy rider will be accelerating or going up steep slopes more cautiously, intuitively taking into account heavier load, the lighter rider will accelerate more aggressively and go up steeper slopes - but the max current will be about the same). So, the envelope will be a distinctive fingerprint of the given segwheel. Should be interesting!

+1. The limit (currentwise) will be exactly the same for a light or heavy rider. There is no influence of weight. Just the resulting accelerations/burdens will differ - but they are not known/in the diagram anyways.

1 hour ago, Aneta said:

PS. Too bad we don't have the phase current (only for Gotways?), or better yet, both battery and phase currents. (and motor voltage?) Then we could get something resembling the Motor Simulator (ebikes.ca) graphs. Oh well.

Yes - having both would be great. But at the limit battery current and phase current are identical! It's just the further one is from the limit, the more the currents will differ. So the high phase currents at low speeds (inclines!) will be "lost" if one plots battery current.

24 minutes ago, Seba said:

~9% in case of KS-16X and ~18% in case of KS-18L/XL.

Ks16s was quite exact speedwise? Just distance was about 20% off? Or did this change too with newer firmwares?

Could rhis come from the deviation from the different wheel diameters - so that they are calculated from real 16 and 18 inch but both wheels used tires differ from that?

Pfff... But +18% for the KS18 would mean they should have been 21 inch wheels;)

-18% could mean they calculate as for an 16 inch but the tire diameter is 19. That could be realistic?

 

[Aneta]

2 hours ago, Chriull said:

"Unfortionately" the upper boundary (max current == torque over speed limit) shifts proportionally with battery voltage (the no load battery voltage - without the burden induced voltage sag). So in a big data scatter graph the limit lines are a range/area, too. One will just see the outermost limit for full batteries.

Thank you for pointing this out, I overlooked this consideration. But outermost limit for full batteries will still be interesting to look at. (graphs at ebikes.ca are also for the same level of battery)

2 hours ago, Chriull said:

But at the limit battery current and phase current are identical!

Why is it so? I don't see this in Motor Simulator, at 100% duty cycle battery current and motor current are quite different.

[Chriull]

30 minutes ago, Aneta said:

But outermost limit for full batteries will still be interesting to look at. (graphs at ebikes.ca are also for the same level of battery)

Yes of course.

If I look at such a diagram for my ride i want to see how near or far i was to the limit - to learn about how much my "safety margin" was. This is not possible with just seeing the limit for the full battery - this needs some "transformation" to get battery voltage "fixed".

But maybe there are also other interesting aspects to be seen i am not aware of?

2 hours ago, Chriull said:

But at the limit battery current and phase current are identical!

18 minutes ago, Aneta said:

Why is it so? I don't see this in Motor Simulator, at 100% duty cycle battery current and motor current are quite different.

Isn't that called throttle % in the motor simulator? With 100% duty cycle no PWMing happens - the full batter power goes to the motor. So in my simple equivalent circuit diagram there is just the battery, their internal resistance the coil resistance and the motor. So the battery output voltage is the same as the motor terminal voltage and maximum motor current can be produced for this speed. In this case battery current is motor current.

Another "special" case in the simulator is the first part of the diagram as there is current limiting active - so there is never a duty cycle of 100% reached for the limit. For the rest of the diagram the motor current is already quite similar with the motor current for throttle=100%. Could be that the controllers have some maximum duty cycle and never reach real 100%?

Ps.: Just tried a custom controller with enormous current limits - there also at low speeds motor current is almost battery current!

 

[Aneta]

4 minutes ago, Chriull said:

Isn't that called throttle % in the motor simulator? With 100% duty cycle no PWMing happens - the full batter power goes to the motor. So in my simple equivalent circuit diagram there is just the battery, their internal resistance the coil resistance and the motor. So the battery output voltage is the same as the motor terminal voltage and maximum motor current can be produced for this speed. In this case battery current is motor current.

Yes, throttle = D. Yes, at D=100% the full battery voltage is applied to motor, but the current in the motor is determined by I_motor = (U_batt - U_EMF)/R_windings, while I_batt = U_batt/R_batt (?). In general, these are not equal. Am I mistaken here?

7 minutes ago, Chriull said:

Ps.: Just tried a custom controller with enormous current limits - there also at low speeds motor current is almost battery current!

Do you have an example? (just copy/paste URL, the simulator dynamically updates url when you change parameters)

[Aneta]

E.g. here battery current is 50A, motor current 75A:

https://www.ebikes.ca/tools/simulator.html?batt=cust_84_0.2_20&cont=cust_50_200_0.05_V&wheel=16i&frame=cust_1_0.01&hp=0&blue=Lbs&motor=M3540&cont_b=cust_100_200_0.03_V&batt_b=cust_84_0.2_20&wheel_b=22i&frame_b=cust_1_0.01&hp_b=0&grade_b=30&eff_b=97&gear_b=2&mass=80&mass_b=110&autothrot=false&autothrot_b=false&throt_b=100&grade=40&throt=100

[Aneta]

15 minutes ago, Aneta said:

while I_batt = U_batt/R_batt (?)

I think I made a mistake here? Should be

I_batt = (U_batt - U_EMF)/R_batt

[Aneta]

33 minutes ago, Chriull said:

Another "special" case in the simulator is the first part of the diagram as there is current limiting active - so there is never a duty cycle of 100% reached for the limit. For the rest of the diagram the motor current is already quite similar with the motor current for throttle=100%. Could be that the controllers have some maximum duty cycle and never reach real 100%?

Ps.: Just tried a custom controller with enormous current limits - there also at low speeds motor current is almost battery current!

You're absolutely right, I understand now. Because of controller current limits, even when throttle = 100%, D can be less than 100%, which results in different battery and motor currents: Imotor = Ibatt/D.

[Chriull]

49 minutes ago, Aneta said:

Yes, throttle = D.

I'd understand throttle as input to the controller, the PWM duty cycle as output. Should, but does not have to be the same as one sees with the current limiting. And the not 100% duty cycle achieved for 100% throttle. But yes - more or less.

Quote

Yes, at D=100% the full battery voltage is applied to motor, but the current in the motor is determined by I_motor = (U_batt - U_EMF)/R_windings, while I_batt = U_batt/R_batt (?). In general, these are not equal. Am I mistaken here?

For Imotor it's right.

For battery it's a bit more "complicated" - it is not the whole battery voltage dropping at Rbatt! Your formula for Ibatt is for short circuiting the battery.

For the battery one has to consider the internal Battery Voltage (before Rbatt, the no load battery voltage) Ubatt_0. Then with some battery current Ibatt flowing the terminal voltage of the Battery Ubatt = Ubatt_0 - Ibatt * Rbatt

Same with the motor - it has an internal Voltage Uemf and a terminal voltage of Umotor=Uemf + Imotor * Rwindings

Now the controller with his duty cycle D "connects" both terminal voltages: Ubatt * D = Umotor. Without losses in the controller Pin = Pout and so Ibatt*Ubatt = Imotor*Umotor or Ibatt = D * Imotor. So again for D=1 Ibatt = Imotor.

 

33 minutes ago, Aneta said:

I think I made a mistake here? Should be

I_batt = (U_batt - U_EMF)/R_batt

Almost

For D=1 (as with no controller inbetween) Ibatt = (Ubatt_0 - Uemf) / (Rbatt + Rwinding) = I_motor or Ibatt=(Ubatt-Uemf)/Rwindings=Imotor

PS.: That's all in detail worked out in 

 

with LTSpice Simulations, circuit diagrams and formulas... (and some trial and errors...:) )

Edited December 5, 2019 by Chriull

[Chriull]

@Seba @Aneta - here a battery current over speed scatter graph from KS16S wheellog logs:

Points above tiltback speed (35 km/h) are drawn in red. ("Guessed") limit lines are drawn for low and full battery voltage (3.3V*16=52.8V and 4.2V*16=67.2V).

Here the try to "normalize" the graph. All the speed and current values were multiplied with 67.2V/(U_batt_reported+I_batt_reported * R_i_batt):

As one sees the red dots do not "start straight at" at 35 km/h anymore but are scattered by the "normalization". And some points are beyond the limit line. Seems to be my "guesses" for R_i_batt and/or jitter/not timely exact reported values...

The same with calculated motor currents (a first try - imo they are to low - have to adopt calculations/factors...):

And motor current normalized:

 

PS.: pythons matplotlib gets already noticable slow with >3 Mio datapoints  @Seba - I hope you have something more "intelligent" not putting every datapoint to the scatter plot... I'd assume you have much more datapoints than this... Seems something like a "clustering of points within one area" would more appropriate here...

[Seba]

Ok, here are speed-to-current and speed-to-power scatter plots for King Song KS-16X, KS-18L and KS-18XL.

[Seba]

46 minutes ago, Chriull said:

PS.: pythons matplotlib gets already noticable slow with >3 Mio datapoints  @Seba - I hope you have something more "intelligent" not putting every datapoint to the scatter plot... I'd assume you have much more datapoints than this... Seems something like a "clustering of points within one area" would more appropriate here...

I apply data filtering, binning and clustering on database server side. This way I get only ~60k of data points per wheel.

[Chriull]

40 minutes ago, Seba said:

Ok, here are speed-to-current and speed-to-power scatter plots for King Song KS-16X, KS-18L and KS-18XL.

Thanks!

The datapoints above tiltback speed are missing in these graphs? There were (not too many) in your speed over voltage diagramm!

Or they few points are just invisible by the 

35 minutes ago, Seba said:

data filtering, binning and clustering

?

This would be the "interesting" parts of riders reaching the limit (beside some lift cut off speed test)