Hi Nye,
I packed a ton of information into that post in potentially haphazard fashion, and I'm worried that it may have been unclear.
There are two voltages that emerge from a traditional wideband controller, making for two topics:
Topic 1: The serial, digital signal that is passed from the wideband at 5v logic levels. 5v logic corresponds to the RS232 protocol.
Since few computers have actual serial ports anymore, this serial signal is commonly interpreted by using an RS232-to-usb UART adapter cable. 0-5v logic levels, such as are produced by widebands, apparently require a cable that expects those RS232/5v logic levels. I discovered this by first buying and wiring in a seemingly appropriate but ultimately unsuitable cable that expected 3.3v (3v3 in electronics notation) logic levels, which correspond not to the RS232 protocol but instead the TTL logic level. Amazon is rife with 3v3 "serial-to-USB" cables, which look perfect to wire in, but ultimately will not correctly interpret the 5v logic level.
Topic 2: The typical analog voltages put out by wideband controllers on a different wire than the serial logic. It is this analog voltage that ME7 can be tweaked to log via the ADC's used for the rear, post-cat oxygen sensors (pins 69 and 11, for bank 1 and bank 2 respectively). In many cases, widebands emit 0-5v, and the typical scale factors (often around .01) and offsets (usually around -10) applied to uushk_w and uushk_w2 handle this voltage in a way that produces AFR values from 10:1-20:1.
My goal was to calibrate the analog voltages found in topic 2 using the serial voltages found in topic 1 as a benchmark / reference standard. I took this path to deliberately avoid using values and voltages that the wideband controller documentation would cause one to expect, instead favoring experimental data from the serial (topic 1) voltages. Perhaps it's better to say that I wasn't trying to completely avoid using or discard the math suggested by the documentation, but I rather didn't want to rely solely on what was to be "expected".
My discoveries from this exercise:
- As mentioned before, serial-to-USB cables must be at the RS232/5v level - TTL/3v3 cables are unsuitable and will send you on a goose chase.
- The scale factor that my AEM 30-4110 controller required to create near-alignment with the serial signal was different than any value I had seen in this thread. Who knows why that was, but it highlights the value of performing this personalized benchmarking. To confirm, I applied a .0093 scale factor and a -10 offset to the uushk_w variable found at 0x381116. This is not very different from other scale/offset calcs found elsewhere in this thread, but it was different enough. This unique and personalized value was required to calibrate the interpreted analog output to the raw serial values.
- In reviewing the documentation for my WB controller:
https://www.aemelectronics.com/files/instructions/30-4110%20Digital%20Wideband%20UEGO%20Gauge.pdf, there are a few calibration settings (listed on page 11) that create analog voltage outputs comparable to the voltages produced by narrowband. This *may* allow logging on ushk or another variable that expects or interprets low voltage and doesn't require finding where uushk_w lives for a particular ECU. I don't know what value there is for this but it was intriguing for about 20 seconds.
- The analog signal seems to be far more resolute and faster to respond than the serial data. My suspicion is that the serial signal that comes out of the back of the WB controller (which is also the gauge, in the case of the AEM system) appears subject to the same smoothing that the gauge experiences. If I had to guess further, AEM has probably realized that users are expecting a slower, less-jumpy gauge behavior, and so they've applied signal processing to the actual UEGO WB sensor data to smooth out the numbers seen on the gauge. In contrast, the analog outputs from at least this WB controller seem more aligned with the actual WB sensor data, making them superior for logging purposes.
Hopefully this at least clarifies some of the stuff I had posted previously.
