Valuable information about narrowband oxygen sensors...

[10_SS]

Hate to say it but I don't agree with a couple of your points here.

First off, what you're talking about as far as data updates being faster in the Channels vs. Chart, that's actually a problem WITH 2.24. V3.0 updates chart data at a speed of 10ms. How much interpolating do you think is happening in less than 10ms? lol. Not much. I can guaranty you are missing WAY more data using 2.24 than you are using 3.0. Did you read my comments on the 8 data points vs. the 64 in the new software? You're seeing 8 points of data in 2.24 while we're seeing 64 in 3.0. And even that's in a 650ms clip.

As far as the CAN bus, I'm no computer Engineer but I'm pretty darn sure the CAN bus is digital. "Offsets" are only an issue when you're dealing with analog. Digital is digital, it's hard to mess up 1's and 0's.

And as far as which sensor is more repeatable or reliable, again I'm no Engineer but I'm gonna say you will get more repeatable results from a digital narrowband than an aftermarket wideband hooked up through an analog 0-5v conversion.


I think one of the problems we have when we're talking about narrowbands is guys think, or want them to be a linear sensor like a wideband. They're not. That's not how they work. You're never going to be able to match a full range of wideband readings with a full range of narrowband readings. I think that's what RAO was trying to convey or was the problem he saw with his spreadsheet??? Data points or "hits" will be all over the board with the narrowbands, that's exactly what the ECM needs to see to figure out what the mixtures are. Especially in normal driving, low voltages will have more hits simply because of things like DFCO.

2.24 updates everything at the same time. 3.0 doesn't since some data logs fast, some logs slow. So if you scroll through the chart, you'll see that data change, whereas the channels data doesn't (with the slow).

Digital is Digital. Analog to Digital. You need alignment. "100% Purge Digital Signal" from XM Radio means what? Telephone quality audio. I would rather have some static in my TV show or Radio broadcast than have what I get sometimes with digital... complete loss of signal with artifacts and no audio, but video.

[schpenxel]

Pretty sure 2.24 just takes data from the closest point in time that it has for each input and puts all that into a "frame" and calls it all at the exact same time. I highly doubt it's actually from the same point in time, if that's what you're saying.

[dr.mike]

I've read that the temperature of NB O2 sensors makes their output vary at lean/rich ends of the spectrum, so that could explain the drift you mentioned.

Yes, the slope changes at the extremes on NB sensors vary with exhaust gas temperature and pressure. So, what is 800mv on one run could be 900mv on another, etc. This is a function of the Nernst equations; which is the principle that the NB sensors work on.

You kinda have to interpret the NB voltages, like reading plugs, or a colortune ( if you are that old ) etc. You learn more from the changes than the actual voltages. But, still, anything under 800mv is probably DANGEROUSLY close to Lambda 1.0 ( AFR 14.7 ), under load.

[gmtech16450yz]

As far as the "data points" goes between 2.24 and 3.0, all you have to do is look at the file sizes. Scanning the exact same PID's for the exact same time period the file size in the new software will be about 4 times as big as 2.24 files were.

[10_SS]

As far as the "data points" goes between 2.24 and 3.0, all you have to do is look at the file sizes. Scanning the exact same PID's for the exact same time period the file size in the new software will be about 4 times as big as 2.24 files were.

Do you realize interpolation takes two data points that are far apart, and adds 'fake' data points between them? "In the mathematical field of numerical analysis, interpolation is a method of constructing new data points within the range of a discrete set of known data points."

That's what the chart does. I wish there was a setting you could apply after the log that would reduce all of this fake data to actual data... there's really not a need for ultra high res RPM data when most of the other channels lag behind. The problem is sensors like RPM log so fast... that may be one of the few channels that actually have real data in them.

[jtrosky]

So if I'm understanding you correctly, if there are some sensors that provide data "snapshots" quicker than others, all of the other slower sensors will have to add 'fake' data in order to fill in the frames where they dont provide real data (the "Fake" data would just be generated from the last and next real data snapshot)? If so, I agree that it would be nice to at least have an option to not interpolate data for the slower sensors... I'd rather the scanner not create "fake" values just to fill in frames where they don't provide data.

[gmtech16450yz]

Do you realize interpolation takes two data points that are far apart, and adds 'fake' data points between them? "In the mathematical field of numerical analysis, interpolation is a method of constructing new data points within the range of a discrete set of known data points."

That's what the chart does. I wish there was a setting you could apply after the log that would reduce all of this fake data to actual data... there's really not a need for ultra high res RPM data when most of the other channels lag behind. The problem is sensors like RPM log so fast... that may be one of the few channels that actually have real data in them.

Lol. I said I suck at math. That doesn't mean I have no idea what things like "interpolation" are. I've been working with digital music since iTunes was actually SoundJam and digital imaging since Painter was THE program and Photoshop was a baby.

I think you should talk to Keith about this "fake" data problem in 3.0.

[James87]

Would the "mv=AFR" chart that 10_SS posted be a decent reference?

[10_SS]

So if I'm understanding you correctly, if there are some sensors that provide data "snapshots" quicker than others, all of the other slower sensors will have to add 'fake' data in order to fill in the frames where they dont provide real data (the "Fake" data would just be generated from the last and next real data snapshot)? If so, I agree that it would be nice to at least have an option to not interpolate data for the slower sensors... I'd rather the scanner not create "fake" values just to fill in frames where they don't provide data.

just scroll through the chart with the keyboard left/right arrow button... and compare the Chart data value to the Channel data value. You'll find some chart data that increases or changes (appears to update), while the Channel data does not move at all. In some cases, allot actually, the values never line up, thanks to interpolation. 2.24 never did this, but it also was slower log rate. But, all channels would update the same on 2.24, to they didn't have to interpolate... RPM is one that seems to be VERY fast, but I wonder if I slow down some of the very fast channels, if interpolation will be less. I did not notice this for awhile, but now that I know it exists, I know that I cannot trust the Chart data for pinpoint results, you have to look at the channel data for that.

Pic attached. Notice some values do not match in the chart window. This is interpolation, filling the gap between real data points with fake data.

Channel vs Chart.PNG

[10_SS]

Would the "mv=AFR" chart that 10_SS posted be a decent reference?

you might want to make your own as your values could be different... but the correlation will not always be the same... so that;s why it's not a great Idea to tune based on that. It's a general rule to make sure your above 900mv or 925mv at WOT just so you know your not crazy lean, but that's about all you get from it... there's a ton of power left there if you tune with a WB.

[Keith@HPTuners]

3.0 draws the chart lines just the same as 2.24 did.

The difference is 3.0 shows the # values where your cursor/line is, where as 2.24 showed the previous data point.

If you have a huge gap between data points, either version is just as inaccurate.

[gmtech16450yz]

Thanks Keith!

And as far as MY experience, there are 4 to 6 times as many data points shown in the Chart Display of 3.0 than there was in 2.24. Same car, same PID's. And in 3.0 those data points are 10ms apart. I wouldn't call that a "huge gap". lol.

[Keith@HPTuners]

Yea, 3.0 logs a heck of a lot more data.

So, think of this as an example.

Let's say you're logging Engine Coolant Temp at 10 second intervals. That means, you are getting an accurate reading, every 10 seconds.
Let's assume the first reading is 160 F, and the second reading is 210 F.

Would you want to see the chart draw a horizontal line at 160 F and then just jump up instantly at 210 F? Would you want to see the chart show the # 160 F, 9 seconds after the first data point, and 1 second before the next?

Interpolating makes sense in more cases than it doesn't, which is why it's the default. For those that only want to see stepped data points, we will eventually add that option.

[10_SS]

2.24 channel data always matches the chart plot data.
2.24.PNG


3.0 rarely matches, and it's not that it's one point behind, sometimes the two values never match in a complete section like a transition. It's very confusing.
3.0.PNG

For example the difference between Accel Pedal Position between the Channels and the Chart is off by 32% unless I'm steady state with the channel. So I would think maybe I should use the Chart data since it is interpolated, and maybe I should not use the Channel data since it's just the last value that was read... 2.24 you did not have to decide which to use, so very easy.

And for some reason, somehow, the Chart data like Accel Pedal %... the Chart data is always ahead of the channel data (reading higher) on a ramp regardless if I use the low speed or high speed PID for Accel Pedal Position.

The more I think about it, the more it looks like RPM is updated insanely fast 90hz... but that's the only channel that fast! So... I might slow that down a bit, maybe fix all of the other channel updating problems im having? But, polling for that channel says 5hz... and it's about 100hz... so I dunno...

With 2.24 everything updates at 13.4hz with my setup.

With 3.0 things like MAP and MAF update at 20hz (20 times per second)... so really there's no point in having 90hz updates for only RPM for me anyway... hopefully there's a way to cut RPM back to near 20hz, or maybe 30hz, and everything else will appear more accurate?

Update: Nope. I removed all of the "Fast" channels and went back to SAE PID's for things like RPM so everything except maybe the Analog Input is updating at 20hz... but i still get a 90hz Chart update with interpolation. Oh well to that idea.

[schpenxel]

Did you set the polling interval to 100hz on everything?

I still don't get why this is a big deal to be honest.

[Keith@HPTuners]

It's likely because you're plotting a sensor on your chart, which is averaging all those inputs.

And also, like I said before, the chart is interpolating between data points. The channels display is showing you the nearest data point.

You can do the math yourself. Zoom in, find the data points, calculate the time in between, and you'll see what the chart is showing you is accurate.

[10_SS]

no everything says it's at 5hz but log at 20hz, RPM said 5hz and logs at 90hz. Apparently that doesn't work for some reason. Theres a few people that dont like it, not just me. Its confusing. I guess if the update settings worked and if that did reduce the 90hz vs 20hz difference between RPM and all of the other channels it wouldnt be confusing or a big deal as long as the excess steps (90 per second) in the charts also were reduced. It's just so much non-data, I dont see the point.

Or, if there were little dots on the chart lines where the actual data points were, that would fix this confusion. Only needed when zoomed in,

[Keith@HPTuners]

I've explained it before, but, many manufacturers support what we call "fast packet" scanning mode. They support sending us blocks of data, at X hz.

What you do when you select the interval in the channels is help the scanner determine how to populate the fast packet methods, and what overlaps into a manual polling interval.

You're not commanding data at X hz, you're helping the scanner know what you want prioritized, and, if possible, to achieve your desired results.

ALso, why would you want to reduce a 90hz RPM parameter (that is a broadcast parameter, and is free data) to something lower? There's no point. We're not trying to save disk space here, and even so, 3.0 has better file compression than 2.24 logs did.

There's no non-data. It's just interpolated. It's a very simple concept. The # you see displayed on the chart is the current value of where your cursor intersects the line drawn.

[10_SS]

I've used many logging software with various hardware, one I use is Tunerstudio (Megasquirt), I think that logs at something like 200hz, all channels all the time... it's almost too much data I would be fine cutting that back to probably 50hz and be just fine, datalogs with 3.0 are simply too large, 3-4x larger than 2.24, most of the time I cant upload most of mine anymore... if we could cut them down that would also be nice... like cut a snippet out, or something like that.

yea the update hz thing is confusing since none of the polling or broadcast channels seem to be affected by the update interval, at least RPM or MAP and a few others I looked at. So then your saying the chart has the most accurate data? Since the channels data sometimes (most of the time) never lines up with the chart data... that's the part that really doesnt make sense when your scolling through. If the points all line up every 5 frames or 10 frames then there's no confusion... just gives you the feeling of well what one should I be paying attention too... and 2 months later you forget what we talked about and back to wondering why there's a difference and what one is most accurate.

[Keith@HPTuners]

You can cut logs in 3.0.

File->Export Log File
select HP Tuners (.hpl)
select Visible Range

Every channel in 3.0 is treated as its own stream of data points, and are drawn independently of each other on the chart. It's pretty basic man. It draws lines that connect all the data points, for each series.

Once again, the actual # value displayed on the chart is the value of the series, where the cursor intersects it, meaning, it's an interpolated value if it doesn't fall precisely on a data point.