VCM Scanner 3.0 Serial Wideband Feedback

[Turbomangto]

http://aemelectronics.com/files/inst...GO%20Gauge.pdf


I will try to connect to it with my laptop and see what info i can find.



Bits Per Second = 9600
Data Bits = 8
Parity = None
Stop Bits = 1
Flow Control = Hardware

[Keith@HPTuners]

I need the actual format of the serial stream.

[Turbomangto]

This must not be common information as i searched every link i could find with no references to it. Is there a way i can discover it by connecting to it or do we need to contact AEM?

[dr.mike]

AFR in straight ASCII text:

xx.x<cr><lf>

[Turbomangto]

Interesting, this is for which unit?

[dr.mike]

4100 4110 2310 and 30-0300 / 30-0310

But, as I noted in another post, you are much better off connecting the 30-0300 directly via OBDII.

IIRC the serial data rate is only 10Hz.

[Turbomangto]

4100 4110 2310 and 30-0300 / 30-0310

But, as I noted in another post, you are much better off connecting the 30-0300 directly via OBDII.

IIRC the serial data rate is only 10Hz.

Isn't 10Hz a pretty good refresh rate? What do the others support?

So you believe the analog output is the way to go?

[dr.mike]

Isn't 10Hz a pretty good refresh rate? What do the others support?

So you believe the analog output is the way to go?

10Hz is OK for steady state ( constant or slow changing RPM/Load ). But, it can be too slow for transition tuning. You learn a lot about what's really going on with 100Hz data. Plus the WB data is always in the right rpm/map cell when accelerating/decelerating.

With full-speed WB you can see things like imbalances between cylinders, lean spikes on throttle tip-in, etc. You can pick up a lot of misfires, too.

I actually found a bad header gasket on one cylinder because I was getting a series of tiny lean pulses that would track at a rate of RPM/2. After I changed out the gasket, it was smooth data

oscillation.jpg

Light blue trace is lambda. White trace is RPM. Lambda oscillation was about 22Hz @ ~2650RPM. Injector imbalance would look similar. You cant see that with 10Hz data.

I would not recommend using analog outputs in an automotive environment. Unless it were 4-20ma current loop. Which, nobody seems to support.

[schpenxel]

I've always wondered if there could be some kind of response time "offset" added to wideband readings to account for the slight delay of WB's. I may be wrong but I was under the impression they usually take 75-100 msec to react.

[gmtech16450yz]

I've got a PLX 4.9 sensor Keith, I'll try to get it hooked up to serial as soon as I can. I promise I'll let you know even if it works fine!

I'll have to read through whatever info is out there on how to do it though. I'm assuming I can daisy chain it so I can read it off of my PLX gauge in addition to the HPT scanner or can you only read one at a time? Obviously having the gauge AND HPT scanning the wideband is the only real way to verify your offset settings, but I guess with serial I could do without the dash gauge. Thanks!

[dr.mike]

"offset" is not really the right word. It is a lag. i.e. it takes the controllers a certain amount of time to 'adjust' to a new value.
It's not that you get the right data, but, later. You get the wrong data, later.

The output of a wideband, when responding to a change in lambda, kinda looks like this:
t63-plotsb.jpg

Each controller type has a "t63" time. which is the time it takes for it to get to at least 63% of the new value. In the picture, you can see how a controller of a given t63 time responds to a change from Lambda 1.00 to lambda 1.5. The t63 time is how long it takes for the wideband to report at least Lambda 1.32. i.e. it is still 37% off, at that point. The longer it sits, the closer to the actual value it gets.

This is also why it is more important for a wideband to be "fast" than absolutely accurate. You get much more error from the lagging response time than from any steady-state error.

e.g. a wideband that has a t63 time of 20ms but an error of 10% will give better output than a wideband with a t63 time of 100ms and 1% error. Unless you are at a constant lambda for an extended period. Looking at the graph, after 100ms, when the actual value is lambda 1.50, the 100ms t63 wideband reports lambda 1.32. The 20ms t63 wideband reports better than 1.49. Even with an extra 10% error added on that's 1.35-1.65. Closer to correct than the slower unit, even if we assume the slower unit has 0% error.

This picture shows why you can't just add some value to compensate. This is an 80ms lean spike of lambda 1.5
t63-plots2b.jpg
Any wideband with a slower t63 time than about 50ms, pretty much loses the whole event. It's not just shifted to later. It's smooshed


75ms-100ms is pretty average for a t63 time on a wideband. So you want the fastest t63 time, with the least noise. Because, filtering out noise has the same effect as having a slower t63 time.

[dr.mike]

I've got a PLX 4.9 sensor Keith, I'll try to get it hooked up to serial as soon as I can. I promise I'll let you know even if it works fine!

Be careful. IIRC the PLX serial data lines run at 3.3v. Connecting it to a +/-12v RS-232 serial port may cause problems/damage. Also, again, IIRC, the PLX serial data is inverted, compared to normal RS-232 signaling.

[gmtech16450yz]

"offset" is not really the right word. It is a lag. i.e. it takes the controllers a certain amount of time to 'adjust' to a new value.
It's not that you get the right data, but, later. You get the wrong data, later.

The output of a wideband, when responding to a change in lambda, kinda looks like this:
t63-plotsb.jpg

Each controller type has a "t63" time. which is the time it takes for it to get to at least 63% of the new value. In the picture, you can see how a controller of a given t63 time responds to a change from Lambda 1.00 to lambda 1.5. The t63 time is how long it takes for the wideband to report at least Lambda 1.32. i.e. it is still 37% off, at that point. The longer it sits, the closer to the actual value it gets.

This is also why it is more important for a wideband to be "fast" than absolutely accurate. You get much more error from the lagging response time than from any steady-state error.

e.g. a wideband that has a t63 time of 20ms but an error of 10% will give better output than a wideband with a t63 time of 100ms and 1% error. Unless you are at a constant lambda for an extended period. Looking at the graph, after 100ms, when the actual value is lambda 1.50, the 100ms t63 wideband reports lambda 1.32. The 20ms t63 wideband reports better than 1.49. Even with an extra 10% error added on that's 1.35-1.65. Closer to correct than the slower unit, even if we assume the slower unit has 0% error.

This picture shows why you can't just add some value to compensate. This is an 80ms lean spike of lambda 1.5
t63-plots2b.jpg
Any wideband with a slower t63 time than about 50ms, pretty much loses the whole event. It's not just shifted to later. It's smooshed


75ms-100ms is pretty average for a t63 time on a wideband. So you want the fastest t63 time, with the least noise. Because, filtering out noise has the same effect as having a slower t63 time.

Absolutely! That's why, at least on the PLX 4.2 vs. PLX 4.9 Bosch sensors, there was a huge difference in "accuracy" just from the speed difference. The 4.2 sensor missed a ton of info I was looking for or it gave it too late to be useful. I totally agree, If I could only have one, I'd much rather have a fast wideband than an accurate one. By looking at other data from places like the narrowbands you can get an idea of where your mixtures are in relation to what the wideband is reading. But if the data simply isn't there, it doesn't matter how accurate it is. Thanks for posting those details.

[gmtech16450yz]

Be careful. IIRC the PLX serial data lines run at 3.3v. Connecting it to a +/-12v RS-232 serial port may cause problems/damage. Also, again, IIRC, the PLX serial data is inverted, compared to normal RS-232 signaling.

Yikes! Thanks! Maybe I'll wait for somebody else to be the guinea pig? I actually have the car with the PLX apart right now because I'm switching my onboard/in dash PC from an Intel NUC to a Microsoft Surface Pro 4 tablet. It sure is awesome having onboard scanning and tuning! Even better once I get 3.0 up and running on this new 12.5" touch screen!

[dr.mike]

Yep. I just verified it. PLX SM-AFR is 3.3v positive logic. So, a inverting levelshifter is needed to connect it to a standard RS-232 serial port.

Their data format is described in the file PLXAPP018.PDF if you can find a copy.

It updates 10 times per second. Their analog output is faster than that. But, it is very noisy ( to the point that they supply an external capacitor to be placed across their output ), and, subject to large ground offsets. So, for them, the serial data is preferable.

[Keith@HPTuners]

Does anyone know if PLX sells an adapter or converter?

If not, then we might as well remove the planned PLX serial support from the software.

[Keith@HPTuners]

If you want to use a PLX device, you HAVE to use one of their proprietary adapters from here: http://www.plxdevices.com/Kiwi-2-Wir...7346002412.htm

If anyone is interested, we will continue development to support these.

[ElecTech]

Does anyone know if PLX sells an adapter or converter?

If not, then we might as well remove the planned PLX serial support from the software.

Yes they do. Its a one piece serial-to-USB converter cable. It is used currently with the PCM Scan application in a similar fashion to what you are doing. It is a little pricey, but there are do-it-yourself options outlined in some forums to make your own, if one wishes.

http://www.plxdevices.com/Kiwi-2-Wir...7346002412.htm




EDIT: Treed again!

[ElecTech]

If you want to use a PLX device, you HAVE to use one of their proprietary adapters from here: http://www.plxdevices.com/Kiwi-2-Wir...7346002412.htm

If anyone is interested, we will continue development to support these.

I'm interested.

[Keith@HPTuners]

K, get the cable, and try the built in PLX. Maybe we got the implementation right, blind.