Some stuff is just plain obvious, things that normal users never really touch - like wideband PID settings, only the calibration is necessary in practice. I know that configuration handling has been greatly improved, some old 1.0.x are not supported in a good way but it warns about all mis-matches when you upgrade !
My thougts about 1.0 an 1.1 branch - i think more and more functions, settings, constants are more and more self explaining oposite to 1.0.x where some constants was deep mystery - hard or even not possible to understand. But of course hitting F1 is much more nicely than digging in wiki to find nothing
How VT handles files might have been strange in the early stages, you now set a working directory. For each new box that connects with VT a new unique folder named by you is where all config and log files will be dumped, for anyone that wonders how? The serial number of the box is used along with a name of your choice.
Is it changed during last two relises? I have folders with box serial number and given name on C: directly all empty. And same in My Documents\VEMS_Files\ Both are not my desired places where to store data. When I connect new board VT asks just for project name, but not location....
Seeing the important data in one screen is important, me and Emil worked on a decent default gauge layout with 3D and 2D table views of the main stuff, the moving target and actual lambda gauge with a graph below is a real neat feature that makes datalogging less of a necessity in many situations. There is always a need to custom-make things that are very specific, like for idle or boost control tuning, and that is a big step away from how MegaTune works (or really didn't work at all).
Can you also take care to not destroy previous settings when installing new version of VT. It happened time to time with older versions.
One more issue is screen resolution of my current laptop 1400x1050. I see 5 and 1/2 gauge in each row
But it is not problem if my file is not overwrited during upgrade.
Other than that.. I personally always map spark in 2D, but each to his own I guess. I must see the number, not a 3D vector line that can be spun around.
This point is important: there are many succesive tuning strategies around. Some tuner feels comfortable just with numerical tables, some can't imagine life without 3D edditor (me), some use mouse w/o problems, some hate it and so on.. up to small but important details (later example). So sharing experiences and suggestions between users is urgent during creating of good s/w tool (it is why VEMS is successive - many experiences/knowledge in one resulting product). And this is the point where VT limped on both legs. Up to yesterday!
Datalogging.
MegaLogViewer support is important as long as there isn't an internal function that is better.
agree with that. But as I wrote, it is tool coded by deep talent (Phil Tobin). And it will be hard to overtake. It is very handy today. Are someone notice, how nice is average statsistics tool in bottom of graphs accesible by dragging mouse along datalog part?!
I recently tuned MBE unit
http://www.sbdev.co.uk/Display.htm. Its datalog tool seems quite advanced. But some things killed me - perceptibility, migrating over datalog, numerical data in side window apart from graphs... I filled myself like with no fingers. Case when badly designed features kills simplicity of simple using.
We brought this up already last week that it was not working, I have to check up on the progress. Either way the big thing which VT brings is the SIPR protocol and higher serial port speeds which will allow for higher datalogging frequency, at 19200 you're already at 20+ Hz. This could be improved a lot but there is a lot about how datalogging is handled that would require change to make this frequency even higher if anyone actually needs it. Some systems only datalog things like coolant temp a few times each second, while lambda is nice to have at a faster update frequency. By the way, you can always see the frequency in the status bar.
I have 24 samples per second in latest 1.1.53 datalog with MT, but lambda value changes just every ~4 samples. I think because of some filtration inside board. Most important datalog rate is for knock logging.
As far as manual/"mechanical" or automatic tuning I'm personally afraid to use EGO correction for anything but tuning the low load and cruising part of the VE table. You have to be pretty close to the final tune to be able to trust it and even then a mis-fire can wreak havoc given too much free control for the EGO correction algorithm. I usually run open loop and work out everything in real-time and when the load is higher it's all datalogging, and I'm pretty sure my methods will change once the Real Time data system is tested and functional as that will make VE tuning into a really quick procedure if you have a dyno load cell.
When wrote
mechanical I tried to describe fact that VEMS have exact VE table for given engine. If it is tuned by hand or tuned by software - no difference in results. It has no any creative/artistic part where tuner care is needed.
Belive me, no any problems to use lambda correction over all loads/speeds during tuning. Yes it require some care for smoothness in strat map and driving. But it works wonderfully on VEMS. I use EgoC support even at 2.5bar boost! BTW MLV do not need EgoC switched on.
It is one significiant difference between real time automated tuning and on datlog analysis based. Second one have one important advantage. Very important! It do not change any cell during run. If manual or VE learning alike tool works in real time it cripple table around tuning point. It makes everything around this point unstable, especialy if entry table is far from output table. But when using datalog based kind - there is no such problem, because routine do not create problem for itself - table stays as is. And if nothing bother egocorection (accel/deccel) output is very clean.
In first look real time method seems faster. But it is oposite in fact. No matter - dyno or especialy road tuning is used. I respect my sentences about different strategies wroten higher: it would be nice to keep both routes by choice
You guys bring up many valid points, most are easily solvable and that was what I found to be the case during my visit - a short list of changes was given to the programmers everyday and progress was instant. I'm not sure on the order within the the priority list but the main problems that the programmers are working on right now are :
- datalogging
- real time statistics
- internal log viewing
- and simply removing developer crud and things normal users don't want.
From my point of view one of main points should be MLV comparability. It would tear out main reason why to use MT. And as result much higher user comunity.
Gints
