Serial wideband with APSX wideband controller?

[joecar]

Save the output to a file and keep it handy.

[Blacky]

OK, I got a capture of the serial output from the APSX today with my car running (see picture below). Looks like a bunch of garbled ASCII. Any thoughts?
The last row and a half of the "upside down F's" is engine off, key on.

And the V2 does have blinking lights when it is hooked up, but none of the protocols seem to recognize the output. I do get Error 128 when selecting a couple of them however.

Brent


Attachment 20559

If you have FlashScan hooked up and the orange RS232 LED* is flashing (i.e. it is receiving serial data) then you can "Save a COM Trace" and then look at the com trace using a hex editor such as "Hex Workshop".
To save a COM Trace use the FlashScan menu option: F1 Scan Tool->F3 Scan Options->F4 Save COM Data

* The RS232 LED is the orange LED second from the left.

Regards
Paul

[brentg454]

Thank you Paul and Joe, I appreciate you guys taking the time to answer all my goofy questions. My V2 is definitely receiving the serial data; where I'm currently getting hung up is in how to interpret what it is giving me (and hopefully getting it to jive with Scan Tool so I can log it). After some more research, I am told that the serial output from the APSX is in raw bytes, which correlates to the AFR * 10. So for example, an output byte with an int value of 147 is equivalent to 14.7 AFR. Looking at the data from the screenshot I posted, this makes sense, as most of the displayed ASCII character int values from my steady-state idle are in the 142-152 range (14.2-15.2 AFR), and the output pegged out the limit of the WB controller at an ASCII int value of 190 with the engine off, key on (free air or 19.0 AFR). Hopefully I understand / explained that right, does that make sense?

That being the case, can we somehow take the raw byte data that I'm getting from the serial port and just divide it by 10 to display and / or log AFR? Is it as easy as defining this in my Calc.pids file? It would be sweet if we can make this work with the V2 WB output display, but if that won't work I can live without it as long as I can still pass-through log it, which is 99% of what I do anyways. Thanks again for your help, and let me know if you need me to post a COM trace or any other info.

Brent

[Tre-Cool]

If it's that simple, the Guys might be able to update the v2 firmware/cal to work it out for you.

[Blacky]

Thank you Paul and Joe, I appreciate you guys taking the time to answer all my goofy questions. My V2 is definitely receiving the serial data; where I'm currently getting hung up is in how to interpret what it is giving me (and hopefully getting it to jive with Scan Tool so I can log it). After some more research, I am told that the serial output from the APSX is in raw bytes, which correlates to the AFR * 10. So for example, an output byte with an int value of 147 is equivalent to 14.7 AFR. Looking at the data from the screenshot I posted, this makes sense, as most of the displayed ASCII character int values from my steady-state idle are in the 142-152 range (14.2-15.2 AFR), and the output pegged out the limit of the WB controller at an ASCII int value of 190 with the engine off, key on (free air or 19.0 AFR). Hopefully I understand / explained that right, does that make sense?

That being the case, can we somehow take the raw byte data that I'm getting from the serial port and just divide it by 10 to display and / or log AFR? Is it as easy as defining this in my Calc.pids file? It would be sweet if we can make this work with the V2 WB output display, but if that won't work I can live without it as long as I can still pass-through log it, which is 99% of what I do anyways. Thanks again for your help, and let me know if you need me to post a COM trace or any other info.

Brent

I'd really need to see the saved COM trace to see exactly which bytes are being transmitted. Unless/until we add specific support for that wide band then you wan't be able to log it using the serial interface.

Regards
Paul

[joecar]

Thank you Paul and Joe, I appreciate you guys taking the time to answer all my goofy questions. My V2 is definitely receiving the serial data; where I'm currently getting hung up is in how to interpret what it is giving me (and hopefully getting it to jive with Scan Tool so I can log it). After some more research, I am told that the serial output from the APSX is in raw bytes, which correlates to the AFR * 10. So for example, an output byte with an int value of 147 is equivalent to 14.7 AFR. Looking at the data from the screenshot I posted, this makes sense, as most of the displayed ASCII character int values from my steady-state idle are in the 142-152 range (14.2-15.2 AFR), and the output pegged out the limit of the WB controller at an ASCII int value of 190 with the engine off, key on (free air or 19.0 AFR). Hopefully I understand / explained that right, does that make sense?

That being the case, can we somehow take the raw byte data that I'm getting from the serial port and just divide it by 10 to display and / or log AFR? Is it as easy as defining this in my Calc.pids file? It would be sweet if we can make this work with the V2 WB output display, but if that won't work I can live without it as long as I can still pass-through log it, which is 99% of what I do anyways. Thanks again for your help, and let me know if you need me to post a COM trace or any other info.

Brent

Hi Brent,

see Paul's post above where he said this:

If you have FlashScan hooked up and the orange RS232 LED* is flashing (i.e. it is receiving serial data) then you can "Save a COM Trace"...

To save a COM Trace use the FlashScan menu option: F1 Scan Tool->F3 Scan Options->F4 Save COM Data

* The RS232 LED is the orange LED second from the left....

Paul wants to see the COM trace (it might have other protocol characters in addition to the raw values).

[brentg454]

Alright, finally got a COM trace (attached). Sorry it took so long, been out of pocket lately!
Brent

[Blacky]

Alright, finally got a COM trace (attached). Sorry it took so long, been out of pocket lately!
Brent

Thanks, it appears that the serial data is indeed just single-byte, AFR values*10.
I'll add support for it in a future update.

Regards
Paul

[brentg454]

Thanks, it appears that the serial data is indeed just single-byte, AFR values*10.
I'll add support for it in a future update.

Regards
Paul

That's great! Thank you so much for the support. Looking forward to the update.

Brent