Logging with the (Beta) Standalone Tactrix Cable Logger (No More Computer!)
Sep 19, 2010, 10:57 AM
#92
Evolved Member
iTrader: (3)
Join Date: May 2009
Location: Autocrossing Somewhere
Posts: 501
Likes: 0
Received 0 Likes
on
0 Posts
It has nothing to do with how many items I am logging. I am only logging TPS, boost, fuel load, boost, and rearO2AFR, on both Evoscan and OpenPort logs. I get 92 data points for both OpenPort and Evoscan in my logs, logging the same items on a 3rd gear pull. Time delta is approximately 8 seconds for the log on both. At each point in both logs I am at the same approxiate RPM for each time stamp. For some reason VDR doesn't like the format of the time and pukes. I can overlay my seconds column from Evoscan log over the time column in OpenPort log and it looks perfect (keeping in mind when they are superimposed on each other in Excel they damn near match perfectly with respect to time, value, and position.
With those 5 data points selected I get within .5 seconds alignment on data points between my standalone and Evoscan logs. I was apprehensive about it due to so many saying it got exponentially slower when using the standalone.
Update: Very odd, all of the logs are showing up fine this morning. Same logs direct from my OpenPort. I messed with them for over an hour yesterday and they all looked terrible and today they look like they should. Oh well, I guess it was a bug with VDR.
Update to Update: It stopped working again after reopening so there must be something wonky with VDR.
With those 5 data points selected I get within .5 seconds alignment on data points between my standalone and Evoscan logs. I was apprehensive about it due to so many saying it got exponentially slower when using the standalone.
Update: Very odd, all of the logs are showing up fine this morning. Same logs direct from my OpenPort. I messed with them for over an hour yesterday and they all looked terrible and today they look like they should. Oh well, I guess it was a bug with VDR.
Update to Update: It stopped working again after reopening so there must be something wonky with VDR.
Last edited by SiliconTek; Sep 19, 2010 at 11:02 AM.
Sep 19, 2010, 11:13 AM
#93
Evolved Member
iTrader: (3)
Join Date: May 2009
Location: Autocrossing Somewhere
Posts: 501
Likes: 0
Received 0 Likes
on
0 Posts
I took a snap shot of both 3rd gear logs and also loaded both in VDR so everyone can see I am getting roughly the same data points for both logs. I really hope I am just overlooking something obvious. I will post this over on the VDR thread as well, maybe it is just a VDR thing. Something is going wrong with the calculations. If you look at the boost curve the points damn near line up perfectly.
Oct 22, 2010, 10:01 PM
#94
Evolved Member
Oct 25, 2010, 09:21 AM
#98
. I guess that would be "connected to the ECU rear O2" and not "connected to the op2.0".Logging via rearO2 always generates enough noise to throw my AFR reading off by a few tenths compared to serial stream. That is why we are interested in getting ASCII logging via standalone or pass-through to work.
Oct 25, 2010, 02:12 PM
#99
Evolved Member
iTrader: (3)
Join Date: May 2009
Location: Autocrossing Somewhere
Posts: 501
Likes: 0
Received 0 Likes
on
0 Posts
Then I'm pretty sure we had that down a while ago . I guess that would be "connected to the ECU rear O2" and not "connected to the op2.0".
Logging via rearO2 always generates enough noise to throw my AFR reading off by a few tenths compared to serial stream. That is why we are interested in getting ASCII logging via standalone or pass-through to work.
. I guess that would be "connected to the ECU rear O2" and not "connected to the op2.0".Logging via rearO2 always generates enough noise to throw my AFR reading off by a few tenths compared to serial stream. That is why we are interested in getting ASCII logging via standalone or pass-through to work.
Oct 25, 2010, 02:45 PM
#100
If you calibrate the rear properly you will get damn near EXACTLY the same performance out of the rear O2 logging within a given range. I found that calibration via Evoscan using the ADC and serial stream favors one end or the other with respect to the ADC, i.e., either you get it accurate in the 11-12 range or you get it accurate in the 14-15 range. My ADC reading versus serial is perfect between 10.5-12.5, being off no more than 0.1, which is the range I am interested it. If it is 14 or 14.5 I really don't care they are both bad at WOT.
But anyway... OP2.0 can do ascii datastream now (as mentioned above), we just need to get it working!
Last edited by fostytou; Oct 25, 2010 at 03:19 PM.
Oct 28, 2010, 04:15 PM
#102
Evolved Member
I'm going to try something in a day or two. Looking over how they love via openport s.a . Using 0x0*mut address* .... I saw to log afr via 2.0 s.a u loged mut 100 or 101 I can't remeber off hand
soo maybe that will work I hope it does! If anyone tries this before I do please post your finding
soo maybe that will work I hope it does! If anyone tries this before I do please post your finding
Oct 29, 2010, 08:15 AM
#103
I'm going to try something in a day or two. Looking over how they love via openport s.a . Using 0x0*mut address* .... I saw to log afr via 2.0 s.a u loged mut 100 or 101 I can't remeber off hand
soo maybe that will work I hope it does! If anyone tries this before I do please post your finding
soo maybe that will work I hope it does! If anyone tries this before I do please post your finding
Oct 29, 2010, 10:14 AM
#104
------
This is the data from the "other forum" that he is talking about (from the example files but credit to xPRimNT for the post):
Code:
;----------------inno---------------- type=inno ; log from an innovate MTS bus via the 3/32" jack ; multiple LC-1 and other MTS devices (e.g. TC-4) are supported ; ; each MTS parameter has a special parameter ID: ; ; paramid parameter ; 0x0101 LC-1 #1 AFR ; 0x0102 LC-1 #1 lambda ; 0x0201 LC-1 #2 AFR ; 0x0202 LC-1 #2 lambda ; 0x0301 LC-1 #3 AFR ; 0x0302 LC-1 #4 lambda ; (etc) ; ; 0x0001 aux #1 data (e.g. TC-4 #1 channel 1) ; 0x0002 aux #2 data (e.g. TC-4 #1 channel 2) ; 0x0003 aux #3 data (e.g. TC-4 #1 channel 3) ; 0x0004 aux #4 data (e.g. TC-4 #1 channel 4) ; 0x0005 aux #5 data (e.g. TC-4 #2 channel 1) ; (etc) ; the LC-1 parameters are already scaled correctly and require no scalingrpn setting ; however, the LC-1 is known to lose its stored AFR multiplier, so we recommend calculating ; AFR from lambda like this ;paramname = mylc1.afr ;paramid = 0x0102 ; get lambda from first LC-1 ;scalingrpn = x,14.7,* ; scale to an AFR
Oct 29, 2010, 10:30 AM
#105
Evolved Member
I'm thinking all the request I've seen ecu based are 2digits or 5 like the evo x (I think its 5 can't remeber off hand) maybe the 100 set are "read from cable" worth a shot though. I appologize for pming that and not posting it publicly first . Thnx for putting it up . Pain in the *** from a phonne I can barely use lol