Graph for Wheellog data

[Chriull]

@ir_fuel and all the other wheellog users - i use gnuplot http://www.gnuplot.info/ to plot my graphs. The imho nicest feature is, that one can zoom and scroll around...

I currently use version 5.0 of gnuplot ( http://sourceforge.net/project/showfiles.php?group_id=2055 )  ( the previous stable version) - don't know if my script works with the actual version 5.2 and what's new...

The script file:

Usage:

[path-to-gnuplot-executable]\gnuplot.exe -c [path-to-script-file]\wheellog.dem [path-to-wheellog-data-file]\[data-file-name].csv

If one has the gnuplot executable in the PATH Enviroment variable and is in the directory of the scriptfile and wheellog data file a simple

gnuplot -c wheellog.dem [data-filename].csv

is enough.

Also a batchfile with the content

[path-to-gnuplot-executable]\gnuplot.exe -c [path-to-script-file]\wheellog.dem %1

is nice for windows users. One can then in the windows explorer drag a wheel log data file on the batchfile and this starts gnuplot with this data file.

Some points regarding customization of the script file:

Wheellog data is saved in a csv file with different columns. As far as i know this columns change either one activated GPS logging or not. Also for different wheel brands and types could be different columns.

This columns have to be entered in the corresponding lines in wheellog.dem

This is either the p1axis1 or p1axis2 variable (p1axis1 shows this column on the left axis, p1axis2 on the right axis.)

The corresponding title can be set with p1a[1|2]title. (Attention - space is a seperator and can by this not used within a title!)

The next variables are p1a[1|2]factor, if some fixed factor division is needed/wanted.

Color can be choosen with df_colors[1|2]. The last variables df_with[1|2] set the line width.

This sample script works for KS16[B|C|S] with GPS logging activated. For other wheels and depending on GPS logging the column numbers in p1axis[1|2] have to be adopted according to the used csv file format.

[ir_fuel]

Thanks for the info!

[Chriull]

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

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:

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:

 

[Chriull]

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):

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...)

 

[Chriull]

A java file to extract the gps coordinates from (multiple) wheellog data file into one gpx file with different tracks:

 

 

[Chriull]

After one year an update :

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 

- 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:

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":

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

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":

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:

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:

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 . 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:

and 

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... 

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

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:

 

... 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

 

[Rehab1]

1 hour ago, Chriull said:

What's new:

You sir have conducted some very impressive research on the Wheellog.  

[meepmeepmayer]

Very nice Though I must admit I don't care enough to use this