Quote:
Originally Posted by
kur4o
Since you`re going to rewrite most of the program, it`ll be great if you make it easy reconfigurable for other aldl streams. At least the mode 4 part.
i can add specific features, but this is not and will never be a general purpose ALDL toolkit. it's purpose-specific for lt1 tuners, so unless i can find a reason for the feature; i don't really want to spend time on it.
Quote:
The custom send interface need some work too. I found that the delay timeout works only when it receive successfully the response frame. If the response frame is not received the delay is not applied.
i kinda figured since at least 1 second has passed if there's no response (due to a fairly long timeout), an additional delay wouldn't be necessary, but i can change it if you like
Quote:
One more thing I have on mind is 5, 6 or more data log items that pick selected byte from the response and show the result on screen with graph functionality and customs data conversion.
i'll think about that, but i think that's back to making it a general purpose aldl toolkit, which it isn't.. i'd rather those bytes are clearly defined, patched in, given a proper identity, and added as real data instead of making them arbitrary so people can make use of them
Quote:
I think that the most important part of the program is mode 4 functionality and auto tuning capability with some complex algorithm that produce tuned ve tables spark and fuel. Loading custom tables with eside aldl compatability.
i know im saying no a lot here, but auto-tuning ve and spark tables isn't happening.
i'm a firm believer that algorithmic tuning doesn't work, since there is almost always bad data that has to be human filtered, and simply applying trims or wideband readings directly to a table usually results in a really gimpy looking table that doesn't run properly.
interpolating areas of the table that don't have data is also really hard. im not a mathematician... i don't feel i'd do a very good job with that.
it's very difficult for a program like this to determine bad data records like false knock, poor o2 behavior, etc.. and i feel people would rely on eehack to do their entire tune for them, and be angry when their lazy o2 causes it to make their car run worse and worse.
spark tables are something that's damn near impossible to tune automatically, especially in most driving ranges where i don't even know how it'd be possible to determine optimal timing advance just from data, and in WOT ranges where the knock sensor may or may not work properly, computers simply dont have enough common sense to not blow your car up.
Quote:
The different data rates could be because of the extremely low load on the processor. One thing I noticed all other software I tried use 100 % cpu even on quad core xeon. The eehack use 15-20 % on ancient pentium m during flash.
I am very happy with the low processor load anyway, but that may be the problem with some buggy machines.
i never thought about processor sleep states..but this is millisecond range stuff, surely sleep states on any processor should recover within a millisecond? i'll have to test that