RomRaider

Just a few questions about the wideband O2 sensor w/ guage that was given to me.. Please excuse me if this thread is posted in the wrong forum and point me to the proper one.

Info on the wideband..
It is an APSX D2. It looks to be based off of an AEM UEGO. Has a digital 9600 8N1 baud output, analog output, and simulated narrowband output.. The sensor only uses 5 wires instead of 6 and the output harness has 5 instead of 4 (the simulated nb is the extra wire)..

I'm not familiar with permanent mount AFR guages because I used ms on the miata I used to have and the signal was piped into the ms..

Is it possible that this wideband could be logged with romraider since it appears to be based off of a supported platform? If so which output would I need to use and what would I need to do to get the signal to the OP2 to see if it can be?

I'm just trying to see if this platform can be used for logging purposes since it was given to me.

You can try using the AEM 9600 plugin to read the serial stream in RR Logger.
If that doesn't work then we need the protocol spec for it.

Ok I'll give it a shot. I'll download the AEM install guide and use that to reference..

You should be following the APSX D2 install guide.

There isn't an install guide... well the "guide" they use is extreamly vague... that's why I was noticed the AEM UEGO was similar, which led me to realize that the D2 is probably based off of the UEGO.. the only thing I need the AEM guide for is to see what pins to use on the 232 connector for logging..

Hi guys,

I was actually thinking of posting here about a similar thing. I'm currently working with an APSX D1 (inline-controller style, not the in-gauge style) and trying to figure out how I can work with the serial out.

From what I've found out, it seems to be different in protocol than a lot of the other units around. Most of them seem to be ASCII text with delimiters of various sorts (at least some AEM and Innovate things I've read were), but it seems the D1 (and probably the D2, I'd imagine) has the info in raw byte value.

I spent some time viewing the bytes in different ways in a terminal (uint8, float, raw hex, etc) and was a little confused so I asked APSX, and what they told me is that I need to read the value of the bytes, and that, say a byte of 147 (hex 93) = 14.7 AFR. I also saw some other things on the terminal that seemed a little funky during the configuration setup of the box, but it may have been an artifact of the way the terminal displayed things.
Knowing that, I ran the sensor calibration, after which it says it should read "19.0" (which is the default max-limit for AFR, so for the still-free-air sensor, that makes sense) and then did see a nice steady stream of 190 (int value) coming into the serial port.


Is there a way we can log that with any existing plugins, or at least dump the raw values to a log somehow to be interpreted later on the PC side?



FWIW, I'm also looking into whether I can get an Openport 2.0 to log the non-ASCII data over its serial-capable pins (everyone I've found online is doing an AEM or Innovate style setup). I'd love to get both OP2.0 and RR able to log the data, but I'd settle for at one or the other at this point!

Use HyperTerminal or PuTTY and log (or save) all received data from the serial port. Then post that log(s) indicating the conditions under which it was made. i.e.: free air, steady cruise, etc.

You could also try the AEM plugin in RR Logger with the system level log set to TRACE, then send the rr_system.log in there's any valid info in it.
http://www.romraider.com/RomRaider/HowToDebug

I've been messing with different terminal programs tonight, but there's not much to it.

Steady state, it's litterally just 0xBE (190) coming out repeatedly once it gets into its data mode. This is with the sensor in free air (I have this running off a lab power supply right now) which makes sense per the example they gave me since it should be pegged at the default AFR max value of 19.0 (can be set).

There's also a burst of other data that comes out at start up, followed by a small time (several seconds) and then the stream of what will be output data. I'm not sure that data means anything and nobody probably cares about that for logging purposes. They also sell a small LED display that would use this serial data, so there may be special characters or formatting for the display; as far as logging goes, the site only says "9600 8n1 serial" and I had to ask to find out a bit more about the format.

Here's a sample of the startup info (after power is turned on) I just got in case it helps anyone. This is raw byte data, displayed as unsigned integers by RealTerm:


The 190 will repeat periodically as it sends output data. I believe the format is really as simple as that.




I did also run RomRaider and try to instantiate an AEM UEGO log and record the following in the rr_system.log:



Not being familiar with RR log format, that looks to me like the kind of message you get when a port is opened by another application, but I cycled things time and again to make sure it wasn't opened by anything else. Maybe a timeout issue upon not seeing expected data?
From some other things I've read it looks like the AEM format is an ASCII-formatted output delimited as "1.770\tReady\tNo-errors\r".

Hope this is helpful. Thanks for helping, dshultz. As I've been doing research on the different wideband serial protocols I've come across a number of threads here where you've been able to help different people with logging issues and I just wanted to say as a some-time lurker/first-time poster that people like me are out there reading and really do appreciate the time that people like you are putting into this.


gullet89,
If you look at http://wide-band.com/techinfo and go to the D1 page (it's not in the D2 users guide for some reason; I think the PDF guides aren't updated as well as they should be) there's a diagram that shows a hookup to a DB9 (serial) connector - I've hooked it up like that with the green wire to pin 2 (RXD) and the black ground attached to both my power ground and pin 5. It's a standard D-SUB serial connection, although I imagine the protocol of the D2 will be exactly the same as the D1 and you'll need to find the same solution I'm looking for to get the serial data logged from it.






Some electrical-level tech info that may help someone else looking at this (might have saved me some time):

One thing to keep in mind is that the levels aren't true RS-232 levels (which I believe will be common among most of these type of devices) but is the same thing output as 0-5V TTL levels. This is only of note in that it differs from a standard UART connection on a microcontroller in that it's basically inverted:

UART right off a microcontroller will look like this:

whereas what I saw on the scope is inverted from that to look like a pseudo-RS-232:

with levels of 0V and 5V for a 1 and 0, respecively (not -3 to -15 and +3 to +15).

That was important for me because I initially tried to use it with a Sparkfun FT232 breakout module that was expecting a UART signal and it needed to be inverted to work correctly and I only knew it because I happen to have an oscilloscope handy. I've since picked up a USB-to-Serial (DB-9) converter that seems to interpret the levels correctly even though it's not true RS-232. Again, I wouldn't be surprised if most of these kind of devices do that, although I haven't actually looked at anything else like this on a scope.

-Matt

Thanks for the info.

This means exactly what it says. The driver believes the COM port is open by some other application.

As you noted the AEM plugin is expecting a line of text so this won't work for this WBO2 controller. A new plugin is needed and seems simple enough to create. Basically read a byte of data, divide by 10 and report that as Gas AFR. Why didn't they spit out lambda instead?

I'll see if I can get something build over the next week or two.

If the serial stream is really TTL levels then you'd be better off using a TTL to USB converter.

I have the APSX D1 and could never get the serial to read, even with APSX’s program. I am not sure if mine was messed up or not. So, I ended up taking an analog pin on an Arduino to read the voltage from the analog out of the APSX. Then the Arduino outputs identical to an AEM UEGO @ 9600.

Hope that helps.

I also added an OLED to display AFR, since the one it came with looked like crap.

Apologies for resurrecting an ancient thread. I'm having a little trouble getting an APSX D2 Wideband to log anything meaningful in RR Logger. I've been using it standalone for a while and it seems to work fine, but for meaningful tuning I wanted to log AFR data along with other engine parameters, so I set about connecting it to RR Logger.

I bought a TTL to USB converter board that uses the FTDI FT232RL IC in accordance with the suggestions above.
I can connect to the COM port it creates by choosing the APSX plugin.
This causes the "RXD" LED on the converter board to show a steady stream of data from the gauge.
When I select the APSX as an external sensor, I get mostly 0 and the odd flicker of some other value. Graphing this data shows a square wave that is mostly 0 with short intervals in the 2-3 range.

At this point I'm unsure what do to next. Any suggestions?

Thanks,
Nigel

Post your rr_system.log.
http://www.romraider.com/index.php/RomRaider/HowToDebug

Thanks for the speedy reply!

Edit: Log file removed, not the source of the problem.

Edit:
I reassigned the TTL to USB converter to COM 1 and managed to get some sort of communication between RR Logger and the device, but there is still a problem with the data.

Check the updated log here:
https://drive.google.com/file/d/1_A1VXP ... sp=sharing

And an image of the graphed data here:
https://drive.google.com/file/d/1CX2ukN ... sp=sharing

Thanks again for the help.
-Nigel

Problem solved!

As one of the previous posters mentioned, the RS232 5V TTL logic signal is inverted from the ASPX wideband gauge. The FDTI FT232RL-based converter I used *can* handle the inverted signal, but you have to download the FDTI configuration utility from the web, connect to the RS232 TTL to USB converter, and configure the RXD channel on the converted to "invert". As soon as I did that, everything worked great.

There was a little bit of sequence-of-operations I had to do, but no big deal. I had to start the logger software with only the ECU connected, get it talking, then plug in the USB converter and get the AFR going. Otherwise RR Logger tries to open the external sensor port first and doesn't seem to release it properly even when selecting a different port for the ECU to connect to.