Evoscan v0.8 feedback
Jul 6, 2006, 10:10 PM
#1
Evolved Member
Thread Starter
iTrader: (17)
Join Date: Apr 2004
Location: 41° 59' N, 87° 54' W
Posts: 6,224
Likes: 0
Received 0 Likes
on
0 Posts
Evoscan v0.8 feedback
I tried logging some data with the just released v0.8 Evoscan software. Fired up the car and after a couple of minutes of idling ... SHAZAM ... my idle jumps to 3000 RPM. I have tried running v0.8 with and without the second connector of the tactrix cable hooked up. The idle jumps with and without the second connector hooked up.
I'm thinking it is somehow affecting the ICSV setting, but I cannot confirm, since I also got several garbage log files (reading RPM of 7968.75 at idle and what look like max values across the board - see attached file).
LC-1 support also does not work. It tries to access com1, but gets no data.
l8r)
I'm thinking it is somehow affecting the ICSV setting, but I cannot confirm, since I also got several garbage log files (reading RPM of 7968.75 at idle and what look like max values across the board - see attached file).
LC-1 support also does not work. It tries to access com1, but gets no data.
l8r)
Jul 6, 2006, 10:14 PM
#2
Originally Posted by Ludikraut
I tried logging some data with the just released v0.8 Evoscan software. Fired up the car and after a couple of minutes of idling ... SHAZAM ... my idle jumps to 3000 RPM. I have tried running v0.8 with and without the second connector of the tactrix cable hooked up. The idle jumps with and without the second connector hooked up.
I'm thinking it is somehow affecting the ICSV setting, but I cannot confirm, since I also got several garbage log files (reading RPM of 7968.75 at idle and what look like max values across the board - see attached file).
LC-1 support also does not work. It tries to access com1, but gets no data.
l8r)
I'm thinking it is somehow affecting the ICSV setting, but I cannot confirm, since I also got several garbage log files (reading RPM of 7968.75 at idle and what look like max values across the board - see attached file).
LC-1 support also does not work. It tries to access com1, but gets no data.
l8r)
If you affected that setting, hopefully you made a backup map so you can load it on there.
Jul 7, 2006, 12:03 AM
#3
Evolved Member
iTrader: (20)
Join Date: Apr 2005
Location: Chantilly,VA
Posts: 920
Likes: 0
Received 0 Likes
on
0 Posts
It worked pretty good for me. I don't know about the wide band since I don't have one. sampling rate was really fast and being able to read knock sum is the best about Evoscan. It reads the timing correctly now.
Jul 7, 2006, 03:14 AM
#4
Evolving Member
iTrader: (3)
Join Date: Jan 2004
Location: SoCal
Posts: 443
Likes: 0
Received 0 Likes
on
0 Posts
You beat me to it, I was going to post about this very same issue. Last night I encountered the 3,000 rpm idle after the evoscan logging was activated. Oddly enough evoscan did not cause any idle issues tonight and worked fine other than randomly stopping a time or two. The only variable for me was attempting to use the LC-1 logging the night before.
Jul 7, 2006, 04:02 AM
#5
We need adjustable audible alarms.
I'd like to be able to tell it "if you see XXX knock voltage, ring a bell" so that I can stop my current pull and see what's going on.
I'd like to be able to tell it "if you see XXX knock voltage, ring a bell" so that I can stop my current pull and see what's going on.
Jul 7, 2006, 05:34 AM
#6
Evolved Member
iTrader: (17)
Join Date: Nov 2005
Location: NNJ
Posts: 2,544
Likes: 0
Received 0 Likes
on
0 Posts
Originally Posted by Ludikraut
I tried logging some data with the just released v0.8 Evoscan software. Fired up the car and after a couple of minutes of idling ... SHAZAM ... my idle jumps to 3000 RPM. I have tried running v0.8 with and without the second connector of the tactrix cable hooked up. The idle jumps with and without the second connector hooked up.
I'm thinking it is somehow affecting the ICSV setting, but I cannot confirm, since I also got several garbage log files (reading RPM of 7968.75 at idle and what look like max values across the board - see attached file).
LC-1 support also does not work. It tries to access com1, but gets no data.
l8r)
I'm thinking it is somehow affecting the ICSV setting, but I cannot confirm, since I also got several garbage log files (reading RPM of 7968.75 at idle and what look like max values across the board - see attached file).
LC-1 support also does not work. It tries to access com1, but gets no data.
l8r)
Originally Posted by Cannonballer
You beat me to it, I was going to post about this very same issue. Last night I encountered the 3,000 rpm idle after the evoscan logging was activated. Oddly enough evoscan did not cause any idle issues tonight and worked fine other than randomly stopping a time or two. The only variable for me was attempting to use the LC-1 logging the night before.
Sounds like this issue is only happening when you try to use the LC-1
Jul 7, 2006, 06:07 AM
#7
Evolved Member
iTrader: (5)
Join Date: Nov 2003
Location: Birmingham, Al
Posts: 849
Likes: 0
Received 0 Likes
on
0 Posts
I had a very weird experience when I tried to access my LC-1 through evoscan as well. The car actually died on me and when everything came back up, I could only sample at about 6 hz down from ~90 on avg without speed booster on.
Trending Topics
Jul 7, 2006, 08:40 AM
#8
Yeah it has something to do with initializing the port.. It was something that Colby and I had a passing conversation about with serial communications on the PC.. I do not experience it on my car, but I don't have any additional wideband attached thats compatible with the software..
My two pressing issues are that the time and seconds should be combined into 1 field for a timestamp, otherwise using third party log analyzers is virtually impossible.. The other obvious issue I get is that the MAF reading never goes above 1603.95 or something llike that when my car is clearly reading 2000hz or higher Unless airflow is not actually MAF reading..
My two pressing issues are that the time and seconds should be combined into 1 field for a timestamp, otherwise using third party log analyzers is virtually impossible.. The other obvious issue I get is that the MAF reading never goes above 1603.95 or something llike that when my car is clearly reading 2000hz or higher Unless airflow is not actually MAF reading..
Jul 7, 2006, 08:45 AM
#10
Evolved Member
iTrader: (1)
Join Date: Aug 2004
Location: eastern pa
Posts: 935
Likes: 0
Received 0 Likes
on
0 Posts
i had the same problems yesterday but today i dont have the error...... no lc-1 no problem.....
when this happened i got a DT** error in the log window it was 4 letters but i can remember the last 2
when this happened i got a DT** error in the log window it was 4 letters but i can remember the last 2
Jul 7, 2006, 08:50 AM
#11
Evolved Member
Thread Starter
iTrader: (17)
Join Date: Apr 2004
Location: 41° 59' N, 87° 54' W
Posts: 6,224
Likes: 0
Received 0 Likes
on
0 Posts
Originally Posted by MalibuJack
Yeah it has something to do with initializing the port.. It was something that Colby and I had a passing conversation about with serial communications on the PC.. I do not experience it on my car, but I don't have any additional wideband attached thats compatible with the software..
My two pressing issues are that the time and seconds should be combined into 1 field for a timestamp, otherwise using third party log analyzers is virtually impossible.. The other obvious issue I get is that the MAF reading never goes above 1603.95 or something llike that when my car is clearly reading 2000hz or higher Unless airflow is not actually MAF reading..
My two pressing issues are that the time and seconds should be combined into 1 field for a timestamp, otherwise using third party log analyzers is virtually impossible.. The other obvious issue I get is that the MAF reading never goes above 1603.95 or something llike that when my car is clearly reading 2000hz or higher Unless airflow is not actually MAF reading..
l8r)
Jul 7, 2006, 08:57 AM
#12
Originally Posted by Ludikraut
So any idea what Evoscan is sending to the ECU to trigger the high idle? Sounds like the MUT-II/MUT-III protocol allows for two way communication of some kind.
l8r)
l8r)
Jul 7, 2006, 08:58 AM
#13
Originally Posted by DynoFlash
I have had no problems - ita great product at a even better price ! Rock on
Jul 7, 2006, 10:42 AM
#14
Evolved Member
Thread Starter
iTrader: (17)
Join Date: Apr 2004
Location: 41° 59' N, 87° 54' W
Posts: 6,224
Likes: 0
Received 0 Likes
on
0 Posts
Originally Posted by MalibuJack
Its probably not a protocol thing, WIndows intializes the port when you open it or change baud rates.. If you trigger a particular handshake line on the port, you trigger the ECU to go into a bootstrap mode (Engine stalls) Raising idle I'm not sure what that is, that could be some data being sent to the ECU.. What is odd is it may be trying to initialize the com port for your Wideband, why would it do that to the Openport cable.. Ya know? Switching Baud rates I understand though, since it may be necessary to slow it down to synchronize with the Wideband's data stream.. But its probably just a minor glitch..
). The part of it being able to affect the ECU via the tactrix cable is what has me bugged. It did it with only the OBD-II portion of the cable connected. So as far as I know the ECU should have been in read-only mode, unless the MUT protocol has a different feature set from the OBD-II protocol.
l8r)