You're gonna hate me for this... Couple gripes and usability things.
- When opening the log window it would be nice to be able to log without having to save to a file first (temp file mayb). Just open the window and hit record. When finished asked to save or provide the option.
- When saving a log file the .csv extension should be automatically added. As it is it just saves the file without an extension.
- Not sure what the limitation is but more resolution would be nice. Things happen fast so the more the better. Maybe make it adjustable for those people with fast enough computers?
---------------------
These fall under wish list items. Basically things that would make the logging more functional. If you have a chance to check out Logworks from InnovateMotorsports.com (free download and I can provide a log) it would be an ideal program to get some ideas from.
Here's some that I think are pretty important.
- Add some visual indication of where on the graph you're currently located. Maybe a vertical bar in the middle of the graph?
- Add some sort of time counter
- Give some indication of the scale being used for the inputs
- A way to select a specific point and show the actual values would be awesome (I know excel works but its a pain)
----------------------
Logging suggestions
Moderator: Matt
logging has changed now
when consult connected - it will be in 'record mode' otherwise in 'playback mode' the browse button will save a file in record mode or open a file in playback mode
the last opened file will be available when opening log player subsequent times
i may provide a timestamped default log file in future for saving but not a priority at this stage. i will automatically add .CSV to the filename... to do
resolution is 4 times second (250ms updates). what resolution would you like. i can only push the interface so far before things slow down too much and become unusable (tradeoff). the other limitation is that standard consult is 9600 bps and i am turning streaming on/off to multiplex it with upload commands. this will be running a slower resolution also. i could make perhaps 8 times second configurable option. see how it runs i guess. let me know....
you are always located on RHS of the graph. there is 80 display points in the graph about, RHS is the last one retrieved from log file. this also gets displayed in consult display window.
i have now added time counter, current values inside log viewers and scaling
someone else has requested click and get value. i should be able to do this once i work out my mouse click/point/enter/exit window problems
when consult connected - it will be in 'record mode' otherwise in 'playback mode' the browse button will save a file in record mode or open a file in playback mode
the last opened file will be available when opening log player subsequent times
i may provide a timestamped default log file in future for saving but not a priority at this stage. i will automatically add .CSV to the filename... to do
resolution is 4 times second (250ms updates). what resolution would you like. i can only push the interface so far before things slow down too much and become unusable (tradeoff). the other limitation is that standard consult is 9600 bps and i am turning streaming on/off to multiplex it with upload commands. this will be running a slower resolution also. i could make perhaps 8 times second configurable option. see how it runs i guess. let me know....
you are always located on RHS of the graph. there is 80 display points in the graph about, RHS is the last one retrieved from log file. this also gets displayed in consult display window.
i have now added time counter, current values inside log viewers and scaling
someone else has requested click and get value. i should be able to do this once i work out my mouse click/point/enter/exit window problems
The more logging resolution you can provide the better I think. Looking back at my Logworks logs from a track day shows a large dip in afm voltage lat lasts about 1/3 of a second during a shift. Logworks does 12 samples a second I believe. Little details like that can aid a lot in finding odd little problems. For example I need to find out why my car misses at a particular rpm under high boost. 8 samples a sec would be great but obviously 12 or 16 would be even better if its feasable.
If its not too hard maybe provide two modes. When using the romulator or NVram you could limit the resolution to whatever the ecu/pc/serial can handle. In full logging mode you could use the extra resources not used by the Romulator or NVram to provide better resolution. This would be useful for things like track runs where you obviously wont be changing anything. When making changes the log resolution isnt going to be so important because you're likely on a dyno or sitting still and changes will be happening much slower.
About the logging window. If it's not too hard..it would be nice to provide a target area on the log window indicating where the live display is currently located. If this could be offset a bit form the RHS of the log it would allow the user to see what kind of data is coming up. This would be useful for stopping on high or low points as the log plays. Otherwise you have no way to know when you need to stop to find your max tp, afm voltage, rpm, ... Of course if you do a mouse pointer selection feature that would probably provide a similar function and the target indicator wouldnt be so important.
If its not too hard maybe provide two modes. When using the romulator or NVram you could limit the resolution to whatever the ecu/pc/serial can handle. In full logging mode you could use the extra resources not used by the Romulator or NVram to provide better resolution. This would be useful for things like track runs where you obviously wont be changing anything. When making changes the log resolution isnt going to be so important because you're likely on a dyno or sitting still and changes will be happening much slower.
About the logging window. If it's not too hard..it would be nice to provide a target area on the log window indicating where the live display is currently located. If this could be offset a bit form the RHS of the log it would allow the user to see what kind of data is coming up. This would be useful for stopping on high or low points as the log plays. Otherwise you have no way to know when you need to stop to find your max tp, afm voltage, rpm, ... Of course if you do a mouse pointer selection feature that would probably provide a similar function and the target indicator wouldnt be so important.
Version .701a looks great. Havent logged anything yet but the display of the values is great.
Wish list item- For the lazy people like myself would it be possible to subtract the begin time of the log from the current time so we have a separate "log time".
I'm also tempted to say the log time is in GMT rather than local time. I need to verify this.
Wish list item- For the lazy people like myself would it be possible to subtract the begin time of the log from the current time so we have a separate "log time".
I'm also tempted to say the log time is in GMT rather than local time. I need to verify this.