Reply to thread

Message

The data outputted is similar to an OBD2 car, but the protocols to communicate with it aren't. I doubt you would ever be able to hook up an OBD2 scanner directly, but a custom program can surely be made that mimics all of those functions. There are data logging capabilities built into the stock software but I'm not sure how they work. There are many factors - baud rate, data framing, parity, input and output commands, etc that would have to be reverse engineered.

Right now I am using a custom program that outputs one data value directly from RAM. You punch in the RAM address you want to view into the program, upload it with the Ostrich and the serial port starts transmitting the current value instantly. This value is the current raw hex of whatever sensor you want to see - TPS, CTS, RPM, IAT, etc. Each of these RAM addresses has to be painstakingly hunted down within the code, documented, searched and labeled ONE AT A TIME! The benefit is that once they are labeled the code starts making a LOT of sense . The second hardest part after you find each one is to figure out how to calculate that raw hex value into a real world number on the fly.

I currently have the following RAM addresses documented for the NSX:
Raw MAP
Calc MAP
F&R o2's
Speed
RPM 8 &16bit
Current Fuel Cut RPM
TPS (multiple)
Battery Volts
CTS
IAT
PA (baro)
EGR Lift
EGR sol. active
ITA (ignition timing adj.)

Status Bits/Switches:
Clutch
Power Steering
Nuetral
Brake
Starter
A/C Request
Fuel pump sol.
A/C Clutch
EVAP Sol.
VIS Sol.
FPR Sol.
o2 Heaters

-Matt

<blockquote data-quote="sr5guy" data-source="post: 1381679" data-attributes="member: 16606">The data outputted is similar to an OBD2 car, but the protocols to communicate with it aren&#039;t. I doubt you would ever be able to hook up an OBD2 scanner directly, but a custom program can surely be made that mimics all of those functions. There are data logging capabilities built into the stock software but I&#039;m not sure how they work. There are many factors - baud rate, data framing, parity, input and output commands, etc that would have to be reverse engineered. Right now I am using a custom program that outputs one data value directly from RAM. You punch in the RAM address you want to view into the program, upload it with the Ostrich and the serial port starts transmitting the current value instantly. This value is the current raw hex of whatever sensor you want to see - TPS, CTS, RPM, IAT, etc. Each of these RAM addresses has to be painstakingly hunted down within the code, documented, searched and labeled ONE AT A TIME! The benefit is that once they are labeled the code starts making a LOT of sense <img src="https://cdn.jsdelivr.net/joypixels/assets/8.0/png/unicode/64/1f642.png" class="smilie smilie--emoji" loading="lazy" width="64" height="64" alt=":)" title="Smile&nbsp; &nbsp; :)"&nbsp; data-smilie="1"data-shortname=":)" />. The second hardest part after you find each one is to figure out how to calculate that raw hex value into a real world number on the fly. I currently have the following RAM addresses documented for the NSX: Raw MAPCalc MAPF&amp;R o2&#039;s Speed RPM 8 &amp;16bit Current Fuel Cut RPM TPS (multiple) Battery Volts CTSIAT PA (baro)EGR LiftEGR sol. activeITA (ignition timing adj.)Status Bits/Switches: ClutchPower Steering Nuetral BrakeStarterA/C RequestFuel pump sol.A/C ClutchEVAP Sol.VIS Sol.FPR Sol.o2 Heaters-Matt</blockquote>

[QUOTE="sr5guy, post: 1381679, member: 16606"] The data outputted is similar to an OBD2 car, but the protocols to communicate with it aren't. I doubt you would ever be able to hook up an OBD2 scanner directly, but a custom program can surely be made that mimics all of those functions. There are data logging capabilities built into the stock software but I'm not sure how they work. There are many factors - baud rate, data framing, parity, input and output commands, etc that would have to be reverse engineered. Right now I am using a custom program that outputs one data value directly from RAM. You punch in the RAM address you want to view into the program, upload it with the Ostrich and the serial port starts transmitting the current value instantly. This value is the current raw hex of whatever sensor you want to see - TPS, CTS, RPM, IAT, etc. Each of these RAM addresses has to be painstakingly hunted down within the code, documented, searched and labeled ONE AT A TIME! The benefit is that once they are labeled the code starts making a LOT of sense :). The second hardest part after you find each one is to figure out how to calculate that raw hex value into a real world number on the fly. I currently have the following RAM addresses documented for the NSX: Raw MAP Calc MAP F&R o2's Speed RPM 8 &16bit Current Fuel Cut RPM TPS (multiple) Battery Volts CTS IAT PA (baro) EGR Lift EGR sol. active ITA (ignition timing adj.) Status Bits/Switches: Clutch Power Steering Nuetral Brake Starter A/C Request Fuel pump sol. A/C Clutch EVAP Sol. VIS Sol. FPR Sol. o2 Heaters -Matt [/QUOTE]

Verification