wideband or EIO latency in logging
wideband or EIO latency in logging This post is a copy of one made on HPT's forum, so some of it is specific to there, but:
I searched and searched and remarkably can't seem to find this mentioned anywhere...
This isn't a big deal with a dyno, but I have some customers with fairly serious setups that want only street and track tuning. Basically, I hook up my LM1 and log, and at WOT, what is recorded error-wise is about 2 cells off in VE because of latency from one place or another that makes it's way into the logs.
It's easy to see in the logs when going into PE and out, you can clearly see that the actual AFR from the wideband is behind the rest of the logging. The car I'm working on now needs to be done on the street (OLSD) in first and second gear, but the latency is so high that I am having a fit with it at WOT. It sure would be nice to be able to positively or negatively offset EIO data time-wise in the logs. Could this be a potential feature?
What is the best way to deal with this, or is my LM1 the slow culprit?
Thanks for any insight.
I searched and searched and remarkably can't seem to find this mentioned anywhere...
This isn't a big deal with a dyno, but I have some customers with fairly serious setups that want only street and track tuning. Basically, I hook up my LM1 and log, and at WOT, what is recorded error-wise is about 2 cells off in VE because of latency from one place or another that makes it's way into the logs.
It's easy to see in the logs when going into PE and out, you can clearly see that the actual AFR from the wideband is behind the rest of the logging. The car I'm working on now needs to be done on the street (OLSD) in first and second gear, but the latency is so high that I am having a fit with it at WOT. It sure would be nice to be able to positively or negatively offset EIO data time-wise in the logs. Could this be a potential feature?
What is the best way to deal with this, or is my LM1 the slow culprit?
Thanks for any insight.
Voltage offset seems to be a big issue and I'll bet more people would realize this if they used two widebands as often as I do. I calibrate mine every time I use it by matching up what the LM1 says with what HPtuners is reading. I'm not sure why it changes from day to day as the EIO is well grounded at the same spot as the LM1 and all the connections except for the socket at the EIO are soldered.
I don't mean the voltage offset; with attention to detail, as you noted, it's a non-issue.
Go look at your logs and the switch in commanded AFR from cruise to PE. The wideband tracks slower in the logs. It's a few frames behind the rest of the data. On a dyno, where it can be done slowly in third gear it's easy enough to get around and get worked out, but if all you could do was to the top of second gear, this latency will kill you when getting the SD part worked out.
Go look at your logs and the switch in commanded AFR from cruise to PE. The wideband tracks slower in the logs. It's a few frames behind the rest of the data. On a dyno, where it can be done slowly in third gear it's easy enough to get around and get worked out, but if all you could do was to the top of second gear, this latency will kill you when getting the SD part worked out.
On my LM-1 there is adjustable filtering which adds
lag as it smooths the data. I don't know what the
intrinsic unfiltered latency is, but it's worse as you
up the smoothing. The natural data rate is 12Hz
(roughly a frame) and filtering blows that way out.
Maybe you could ballpark it by an abrupt pedal-
mash and look at EQ and WB_AFR to see where the
various activity-points hit (maybe go back to Excel
and then you could "slide" the data vectors back
into alignment based on what you see).
Don't know how much latency there is, just in the
pipe gas flow and sensor response either. Probably
see that in the EQ:unfiltered AFR lag, rolled up.
lag as it smooths the data. I don't know what the
intrinsic unfiltered latency is, but it's worse as you
up the smoothing. The natural data rate is 12Hz
(roughly a frame) and filtering blows that way out.
Maybe you could ballpark it by an abrupt pedal-
mash and look at EQ and WB_AFR to see where the
various activity-points hit (maybe go back to Excel
and then you could "slide" the data vectors back
into alignment based on what you see).
Don't know how much latency there is, just in the
pipe gas flow and sensor response either. Probably
see that in the EQ:unfiltered AFR lag, rolled up.
I thought about a spread sheet, but the latency seems to put me 1.2-2 cells behind on this car. I ended up with it 'raw' as you suggest at first, but moved it back and just did the work one cell at a time until it was right.
It's not usually much of an issue, this particular car came up fast though and has a pretty loose stall. I was trying to avoid top gears pulls on the street.
It's not usually much of an issue, this particular car came up fast though and has a pretty loose stall. I was trying to avoid top gears pulls on the street.
I've wondered about this issue myself. Due to backpressure-skewed readings, I had to place the wideband on my STS GTO behind the turbo. This gives me a ridiculous lag in the readings. I can normally tell from injector PW and other data enough info to hand correct, but it IS tedious. I'm not sure how to do a blanket time offset to facilitate multi cell corrections. A lot of aftermarket computers have a built in adjustable setting in the logging software to make up for the distance the sensor is placed from the motor.
I don't think you can even do a flat offset; the sensor has its
own latency, but gas velocity varies roughly with intake airflow
(at least in straight pipe, dunno about how the turbo might act
as an accumulator). So lag would go with 1/flow.
I calculate that 100CFM exhaust gas flow in 3" pipe has a lag
of 0.08 sec at 3 feet. Which may or may not be right, it's just
a whack at it in Excel. More flow, less lag. So if this is any kind
of close, the gas flow itself is not the primary factor for a high
output, close-in sensor setup. Dunno how much gas flow you'd
see out one side of the motor, but it says to me maybe one
frame worth of lag or less.
own latency, but gas velocity varies roughly with intake airflow
(at least in straight pipe, dunno about how the turbo might act
as an accumulator). So lag would go with 1/flow.
I calculate that 100CFM exhaust gas flow in 3" pipe has a lag
of 0.08 sec at 3 feet. Which may or may not be right, it's just
a whack at it in Excel. More flow, less lag. So if this is any kind
of close, the gas flow itself is not the primary factor for a high
output, close-in sensor setup. Dunno how much gas flow you'd
see out one side of the motor, but it says to me maybe one
frame worth of lag or less.
