Jump to content

Graph for Wheellog data


Chriull
 Share

Recommended Posts

For KS16S riders who logged with older wheellog versions (negative currents where recoreded to have 70.00 A) get nasty graphs like:

5VZQjMe.png

They can easily be repaired with excel, openoffice calc or similar. One just has to replace in the column "current" 70.00 by 0.00 or some slight negative value (this is where regenerative braking occurs) and gets the "nicer" graph:

s5pyrtg.png

Where of course the negative currents are not valid (where it was replaced by the older wheellog versions by the value 70.00).

With gnuplot this graphs can be exported as an pdf file and linked with for example imgur.com to this forum easily.

An example of the zoom function (draw an rectangle by two clicks with the right mouse button in gnuplot) used on the previous graph:

zu4GzUV.png

 

  • Like 1
Link to comment
Share on other sites

A just tried a second script, which generates a Current (~torque) over Speed graph (for now for KS16B/C - the only wheels of which i have "reliable" data):

Description, Comments, Usage is in the file download section (above link) under "About this file".

Sample graph (same datafile as for the above graphs):

OKvyr8e.png

At each point of this graph the battery voltage has a distinct value - the limit lines (blue & violet) are just for the minimum and maximum voltages - so there is no correlation of such a point to one of the limit lines. The limit corresponding to one data point lies somewhere inbetween these two limit lines...

The limit is by now not really exactly calculated - i used the battery output voltage instead of the "ideal" internal Battery Voltage "before the internal resistance" to simplify the script. Should not be too much of a deviation (particulary considering the "accuracy" of the used motor/wheel constants...)... Will maybe be changed in some future version.

Ps.: i just realized that this script just works for speed in km/h - if someone logged speed in mp/h the limit lines will be wrong (the kv value in the script file would need an adoption)

PPs.: for the Msuper V3s+ i imho worked somewhere in http://forum.electricunicycle.org/topic/7549-current-demand-versus-battery-voltage/ together with @zlymex the following values out: kv=1,2 V/km/h and R_internal=0,383. (Very Very roughly estimated numbers! ... maybe...)

 

Edited by Chriull
repaired invalid image link
  • Upvote 1
Link to comment
Share on other sites

  • 2 weeks later...
  • 1 year later...

After one year an update :D:

What's new:

- Works now with gnuplot 5.2.5 (latest stable version)

- Needs and uses the columnheader of the wheellog logs (beside date and time column... ;( ) - no need to fiddle around anymore with new wheellog versions :D

- i-v and normal logs in one script

- limit calculations included

- direct file output for batch processing

So, a normal call with [path to gnuplot]\gnuplot.exe -c "[path to scriptfile]\whellog 1.0.2.dem" whellog-data-file.csv (gnuplot.bat data.csv for short) shows the following "normal" graph:

yqCkjMy.png

This png file was directly created with "gnuplot.bat data.csv out"

The second possible graph is made with "gnuplot.bat data.csv i-v":

bTuMgPj.png

For this the limits can be shown with "gnuplot.bat data.csv i-v lim":

Zl3xJNT.png

Here are two blue lines showing the limit for the highest and lowest battery voltage within the log file. The different points (and lines) are differently colored depending on "burden". 100% signifies hitting the limit (line). Up to 50% it's light green, and above changes the color for each 10% (green, dark-green, orange, dark-orange, dark-red).

For points, were with the acutal acceleration and current-change would hit the limit within 0.3 seconds black vectors are shown.

As one sees it is not possible to correlate the different points to a limit, as this limit line "moves" with changing battery voltage - so i made also a "normalized" version of this chart:

"gnuplot.bat data.csv i-v norm":

osEpVJ7.png

So here the limit lines "for all voltages" come together in one line and the different points can be "compared". But by this the values on both axes become "relative" and show not the real actual speed and current values anymore.

These calucluated limits/values can also be shown in the normal diagram: gnuplot.bat data.csv lim:

GgaqLWc.png

Here the calculated "internal" battery voltage is shown (U Battery 0) (This value is used to "normalize" the i-v diagram - there every speed/current point is mutliplied with the factor (maximum U battery 0 of the log file)/(acutal U battery 0).

Also the "Percentage" which was used above to color the points is shown (on the bottom of the graph) here with the same color coding. Above this in dark blue time to overlean is shown - signifying how much seconds one has left until one hits the limit if driving on with the same acceleration. (-5 on the left axis is 1.5 seconds, 0 is 0 seconds).

Here a zoom into some details of the above graph:

m9hkJ1Y.png

So the ones who made it till here without just thinking wtf - i don't need this bs, may question themself how they could get the limits for their wheels. So here first as "disclaimer", the values are highly imprecise, beside the imprecise reported values from the wheel there is a high timely jitter in the logs. For KS for example the values are reported 5 times a second and i'd assume these should be quite "syncronous" in 0.2 second intervalls. (Un)fortunately that is true for most of the values - but some come within 0.1 seconds, some take longer... So there "happen"  inhuman accelerations of around 30 m/s²... (btw: just put on todo that accelerations are shown by now in km/h/s without showing this strange unit in the legend...;) )

Easiest solution is to own a KS16S or KS16B/C - there i have the approxiamate values already in the script :D. If one has another wheel - most importantly the wheel has to report the motor current and this value has to be logged by wheellog. Some wheels (inmotion (1), ?newer KS? report the battery current - which is nice for showing power consumption but irrelevant for this graphs here). If so and motor current is not reported/logged one had bad luck (one could change the formulas and calculate the motor current from the battery current, but this would make this much more imprecise as it already is. Could easily render this useless by then...)

If this first step is solved one needs the valus _R_i_battery, _R_coil, _kv to set them in the script. _R_i_battery is the internal resistance of the battery. One gets a first approximation by looking this value up in the data sheet of the used cell and then multiplies it with the amount of cells in serie and divides it by numbers of cells in parallel of ones pack configuration. So for the LG MJ1 37mOhm per cell are specified, with (KS16) a pack configuration of 16S4p this leads to 0,037*16/4=0.148 - but this is just a "theoretical" number. From the overlean data of the KS16B i came to a value of 0.23 Ohm.

For the coil resistance (_R_coil) values of around 0.3 to 0.4 Ohms could be around sane. (These two resistance values determine the steepness of the limit line).

And as the from the wheel reported values of the current are just some values somehow corresponding to the "real" current (peak values, true rms, some mean value or just any arbitrary factor) these factor has to be applied to the two resistances values two. These could be the explanation why 0.23 Ohm for the internal battery resistance "fits" the graph (see https://forum.electricunicycle.org/topic/7855-anatomy-of-an-overlean/) instead of the calculated 0.148 Ohm from the datasheet. (Beside the difficulty to get an real internal resistance of li ion cells for "real" operations...). Also the coil resistance is a "difficult" value - copper has a not to be neglected temperature coefficient. The calculation are based on a "static" model of the motor - in for "real world" operations the inductance of the coils should play an important role too which could explain many peaks/deviations seen...

For the last value _kv (motor constant in V/km/h). This is determined by dividing the voltage generated by the motor by the actual speed. Can be measured by doing the lift cut off test - at maximum speed (cut-off speed) the generated voltage is (almost) the battery voltage. So by logging some lift cut-offs like here:

il3Hcbx.png

and s8qBnlJ.png

By changing the values one can fit these limit lines according to the lift cut off logs. For the steepness of the limit lines the sum of coil and battery resistance is important. To determine the distribution on can use the diagram of U_battery_0. In a perfect simulation this should be a straight line, just going down with battery charge. So one changes this internal battery resistance (and R_coil accordingly to keep the sum and by this the steepness) to "minimize" the ripples of U_battery_0... :ph34r:

Very helpful for this if one has logs of overleans :D or just hitting a curb:

7FIDgHw.png

With such logs one gets real limit points at higher current values as just with lift cut off tests...

So by this one can see for example, that driving with a battery charge a bit below 50% in cold temperatures near the speed limit of my KS16S (35 km/h) can leave as good as no safety margin:

TNhklck.png

wEHO0py.png

 

... although this insight is no real surprise - the wheel already started some random beeping and the pedals felt "weak/spongy" while riding... just maybe how near this ride was to the limit...

 

(1) https://forum.electricunicycle.org/topic/6678-v8-battery-upgrade/?do=findComment&comment=188032

 

Edited by Chriull
  • Like 2
  • Upvote 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...