I've been working writing my own scan tool to interface via the OBDII port for the RX-8. I bought an ISO interface card that allows me to communicate via my laptops comm port. After some initial testing, I figure that current scan tools will not work. Thing is the RX-8 communicates via the CAN protocol. So now I'm trying to get my hands on every CAN document I can find. If anyone has any documentation or info on this protocol please PM me. I'm just trying to gauge how much time and effort this project will require as I’ll be working on it on my spare time. Initially I just want to read data from the car (temps, rpm, etc..). After that is as close to bug free as possible, I'll try to add the ability to write to the PCM (Adjust fuel maps, timing, etc..). Two guys from the forum have already expressed their interest in helping out with the coding (Sorry I haven't PM'ed you guys back) so hopefully we'll get something going soon. I've already completed the comm port routines in .NET Managed C++ so for now I'll try to get the GUI going until I get more info on the CAN protocol.

Here some pages on CAN and the RX=8:
http://www.etools.org/files/public/CAN_this_year_3-6-03.htm
http://www.etools.org/files/public/generic-protocols-02-17-03.htm

There are some books on Amazon.com. I found this one linked from some site (I've been searching around, too):
Controller Area Network (http://www.amazon.com/exec/obidos/tg/detail/-/3000073760/qid=1063590917/sr=1-1/ref=sr_1_1/104-3652902-7965504?v=glance&s=books)
There are a couple of others - search for the full acronym.

Take a look at this site. They seem to have a lot of tools (hardware interfaces and software) for vechile ECU development and diagnostics but I bet they aren't cheap. You might want to get a quote tho, no use reinventing the wheel.

http://www.vector-cantech.com/products/index.html??diagnostics.html

Neither of these tools can see the car's ecu or connect properly:

Vag-com (http://www.ross-tech.com) - Full Registered version

Alex Peper's obd-2.com tool (http://www.obd-2.com)

What can I do to help with this VERY intriguing project? Would you like me to sticky this thread?

Please do!

Now, does the engine have to be running.... I just turned the key on, but didn't start like almost every other car out there.... worth a try later tonight again.

Of note: The emissions states "OBDII Certified", but the connector port is missing a pin where the 12v+ connector should be.

second link from the top, this is probably why most tools won't connect:

60%-CAN 40%-ISO 9141

Grrrr.

Found this list of OBDII Scan Tools.
http://www.obdiicsu.com/ScanTools/ScanTools.asp

From the above list
http://www.drewtech.com/Products/Catalog/CarDAQ2534/cardaq2534.html

This tool can reprogam also.


Might get one of the Autoxray scanners for my home use. Quite a lot of bang for the buck.

Alternatively,

Crack the ECU open and look at: CPU and ROM (if any). If you can get me the part #'s off the top of those chips I can find out how to re-flash them directly. All you need then is for someone to get a dump from the 247HP JDM roms.

-pete

So where exactly is the ecu? Sorry, haven't had the car for long, especially over a weekend where I can start looking for things .

ecu is under the hood to the left and by the headlight it has a plastic cover over it like everything else

Here's what the ECU looks like. Chip #s follow.

http://www.rx8club.com/attachment.php?attachmentid=4625&stc=1

I think this other board is related to the suspension, since the housing said "Showa". But, I could be wrong.

.

The chip numbers on the actual chips are extremely fine & small. You can only read them if the light hits them just right. These numbers are only from the main board. Be aware that "5s" could actually be "Ss" - its that hard to read em. Also, these are only the larger chips & I could have missed some numbers even on these chips.

Anyways, I put my best guess as to the chip's function in parens. Hopefully some hardware-based EE can help us figure it all out.

D151815-8550 / SC 515611MFC185

64F7055F40

D151821-1280 (RAM?)

SPF00001 / SK3206 (Surface-mount Power Transistor Array?)

SE585

3E19 SE555 (timer?)

MC 331 (CPU?)

All you need then is for someone to get a dump from the 247HP JDM roms.


It would be nice if you could compare dumps from both, ie with software interpreting the data and spewing it out in some readable form. This way we could, for instance, see if the only 'emissions change' is the retardation of timing due to lower octane fuel in the US as opposed to Japan, something that I think most owners wouldn't want changed here in the states as far as having their ECU reflashed.

I wish I was a bit nerdier and could get into the discussion more - just a tad bit of assembly and serial communication experience.

I've got access to a cardaq & interface software, if anyone has a wiring schematic for how to hook up the cardaq to the ODBII bus interface (or a place to get a premade harness) That would help me, I could then get some dumps of the Flash contents..

OverLOAD

I found a few CAN Adapters ranging from $2000 to $220. The $220 adapter is USB compatible. That scared me a little since I've never written anything that interface's via a USB port. So I was looking up all sorts of junk on how to enumerate and access USB ports. Then I downloaded the documentation and drivers for the USB Adapter and found it comes with an API. They have every interface a developer could need (vb, c++, delphi, C#, etc...). So I went ahead and ordered it. As soon as it comes in I'll test it out and post the results.

This is the site that sells the USB CAN Adapter:
http://www.gridenabled.com/canboandto.html

BTW: It doesn't come with an OBD-II cable. You have to get that separately.

Nice, even a linux driver!!!!

Embed linux on a pda, create the software with the api guide, and go go go!

Sounds like something I'd rather buy than take the time to make

Originally posted by astrlsrfr

64F7055F40

hahaha nice work :D

That there is the CPU that runs the show. This is a Hitachi SuperH processor by Renesas(hah!), and an impressive one at that:

High-performance single-chip RISC with SH-2E core
52 MIPS/40 MHz/3.3 V
High-speed multiplication/accumulation operations
Built-in 32-bit multiplier
Built-in single-precision floating-point operation unit
Built-in large capacity flash memory with a single power supply and large capacity RAM
Write and erase operations available with the single power supply 512 kB Flash ROM/32 kB RAM

Powerful peripheral functions
Timer: ATU-II (a maximum of 65 input and output process) Compare-match timer 2 ch
A/D: 10 bit x 32 ch
Serial: 5 ch DMAC: 4 ch
HCAN: 2 ch (1 ch is shared with a serial interface)
Package QFP-256

You can see the CAN interface for you OBD guys. But it's the flash I'm interested in. I'm going to have a read about this today but straight away you can see the JTAG pins on the block diagram:
http://www.renesas.com/eng/products/mpumcu/32bit/sh/sh7055/sh7055_block.html
(thats the TCK,TMS,TDI,TDO pins on the LHS) All you need to do is trace those pins to the headers they use for production programming and read it in :)

-pete

Originally posted by blizz81


It would be nice if you could compare dumps from both, ie with software interpreting the data and spewing it out in some readable form.

What you're asking is no small feat. Gone are the days when you can just trace out a netlist, get the ASM dump and figure out how it does everything. Big (huge for the embedded world) processors like the SuperH often run operating systems (a superH can run Linux for example), so decoding the ASM to find the fuel/ignition maps is an exponentially harder job than it was in the days of the old 8/16 bit mazda ECU's.

Second to this, Japan rates it's fuel using RON whereas the US uses PON, so saying one fuel is better than the other is flawed because they can't be compared. I wouldnt mind betting that US high octane (93?) is probably near identical to Japan's 100RON

-pete

Be carefull about purchasing a low dollar CAN interface. The intent of the new interface is to allow real time data logging without use of an oscilloscope thereby reducing the requierment for maintenance aids at dealerships. In short a low speed CAN interface won't work. The best I have been able to ascertain at this point is a data transfer rate in excess of 500 kbs to communicate with the chip. The great part of this is that we've basically got a car that's fully instrumented from the factory!

Originally posted by Sparky
Be carefull about purchasing a low dollar CAN interface. The intent of the new interface is to allow real time data logging without use of an oscilloscope thereby reducing the requierment for maintenance aids at dealerships. In short a low speed CAN interface won't work. The best I have been able to ascertain at this point is a data transfer rate in excess of 500 kbs to communicate with the chip. The great part of this is that we've basically got a car that's fully instrumented from the factory!

The CAN interface I ordered is supposed to go upto 1MBaud. So it should be capable of High / Med speed CAN. If it doesn't work then my little project is over since I can't afford to buy a $2k CAN interface. Mazda bought 12hp for $500 from me. I'm just trying to buy them back for under $500.

Hopefully it works out!!!

Otherwise I might have to take the plunge, but I'll see what others can figure out first.

I'm very mad that my two other obdii tools didn't work!!!

There was another real-time CAN device listed in my OBDII/CAN revisited thread in here by someone else. Also I found out from carchip.com that they have no idea when their reader will be CAN-compatible but that they were working on it. Crap, I don't know why I trashed that email, I was going to paste it but trash has been emptied since then.


Second to this, Japan rates it's fuel using RON whereas the US uses PON, so saying one fuel is better than the other is flawed because they can't be compared. I wouldnt mind betting that US high octane (93?) is probably near identical to Japan's 100RON


That's a good thing to keep in mind. But you can understand my concern. I wouldn't want a bunch of people without pondering it over to flash their ECUs with JDM dumps say, in the winter time, and then later find out when the temperature is over 75 degrees, the engine knocks easily and their KS kicks in retarding the timing down to the original degrees in the US ECU, or lower. etc.

Friend pointed this out to me, since I work with CAN some, and he owns an RX-8. I think he wants free work from me or something!

Anyway, here are what the chips are:

MC 331 (CPU?)
____________
Motorola Part, but Incomplete Number
Could be a MC68331CFC16B1-ND, which is a microprocessor, but unlikely since there is the hitachi chip on there.
Best guess is that it is a MC33199, commonly used in interfacing with diagnostic equipment doc sheet even has a schematic of it in a car electronic control unit http://rocky.digikey.com/WebLib/Motorola/Web%20Data/MC33199.pdf
**********************************************

(3E19) SE555
__________
This is probably a Texas Instruments part. Can be used as a Timer, or a Clock output. Will have to convince friend to let me see his board, unless someone can post a clearer picture of the board for me.
************************************************

SE585
_____
Also appears to be a TI part, but seaching for it didn't bring anything up. Searching for 585 gave me parts, but nothing that looked obvious
**************************************************

SK3206
______

Nothing on this part on digikey, or google. Will try other places later
*************************************************

D151821-1280
____________
Can't find anything useful on this number either. Will try other places later
************************************************** **

64F7055F40
__________
See Above
************************************************** **

D151815-8550
____________
Can't Find anything on this either. Will try other places later
************************************************** **

For the ones I couldn't find anything on, the numbers might not be the actual part number.

Cynan,

Best ways to search for chips via part # would be to use chipdir:
http://www.xs4all.nl/~ganswijk/chipdir/
And if that fails use something like this:
http://www.broker1.tv/index1.html?chipdir_t0

Regardless, you dont really need to know the other chips. Maybe knowing the CAN transciever might be useful for some but the rest will be FET packs etc for output switching and stuff for input scaling.

-pete

HIgh speed CAN chipsets are running around $120 in quantity on the projects I'm working. Hence my previous skeptisism that someone can produce a device that retails less than 300 dollars that can produce the speed. I've been doing some research myself and the gist that I'm getting is that most of the low dollar diagnostic folks are in over their head on this one. The real time PC dataloggers via PC card seam to be the most viable but they're around $600 for the hardware plus whatever the resaler wants to charge for his S/W front end.

I've heard a few developers as my place of work say that they doubt some of these cheap boards too, however that said, for the price they seem to be worth exploring.. As long as they support the right CAN bus spec..

I also found a super cheap CAN bus site, which will sell a harness interface to convert the OBDII connector to RS-232 with a CAN interface board protocol analyzer:

under $100 for the module, and the cable:

http://www.multiplex-engineering.com/products.htm

forgive my transgressions, but this is in no way an endorsement on my part, just another picture of what's out there.

I'm going to be seeing if I can pick up the interface cable, and running some info with either the CARDAQ boxes, or the Saint boxes, which are both $1500+ analyzer modules.. plus there's tons of extra analyzer software... all of which I have free access to.

OverLOAD

I, for one, welcome our new ECU scanning OVERLOADs. :D

You have our gratitude and best wishes for success. Keep us posted.

I can add a little more info on the chips:

there are three (3) D151821-1280 chips. Rmember that 5s could be Ss, so it may be D1S1821-1280?

the Moto part MC331 has an additional # - 86DH

There are three (3) SK3206 & they have an addition #, too: SPF0001.

Originally posted by rpm_pwr
Alternatively,

Crack the ECU open and look at: CPU and ROM (if any). If you can get me the part #'s off the top of those chips I can find out how to re-flash them directly. All you need then is for someone to get a dump from the 247HP JDM roms.

-pete

Hate to burst everyone's bubble, the Japan spec RX8 HP is the same as the US version.

M Monkey: How is 247 JDM = 238 US?

From every source on this forum, and many off of it, Mazda is still saying 247 in japan for the JDM RX-8 and the dyno's proove it. do you think we'd all be trying to go through this much effort if there wasn't some power to be gained? (oh, and the US 238 HP number is still an overstatement).

No offence, but please do a little bit of research before you make unfounded comments.


official numbers from http://www.rx-8.mazda.co.jp/spec07.html state: 184 KW for the 6MT. (~247 hp, 250 ps). They state 154 KW for the 5MT and the automatic (~207 hp, 209 ps)).

Official numbers from www.mazdausa.com, and the letter that everyone who purchased an RX-8 before August 27 indicate that the North American model has revised power in the 6MT from the 247 to 238 hp.

OverLOAD

Hello monkey!!


Would also like to state that 238 is not equal to 247. Hate to burst your bubble ;)

http://www.swankmonkey.com/images/monkey.jpg

For whatever this is worth . . . today I visited my local Vehicle Inspection 'diagnostic' Station (Nashville, TN) in preparation for purchase of my next years auto tags for my '8'. The glitch I experienced today was the inspection station was not CAN-compatible. The under-dash connection was made (to 'read' from the cars' computer), but the 'information' couldn't be read by their computer. The CAN system, I was told, is "too new", and the necessary 'air quality' diagnostic was completed using a 'sniff-probe' stuck into one of the exhaust pipes. (BTW, "RX-8" was not one of the vehicle options listed under "Mazda". I'm now listed as driving a 2004 Mazda "Other".)

The inspection guy (very courteous) said "all cars will be going to CAN in the future, but Mazda was cutting edge by using CAN on the Mazda 6 and the RX-8 now."

As I began to slowly drive out of the inspection bay (with windows open), inspection guy, critically appraising my '8', said "I sure do love your car." I said "thanks" and thought to myself . . me too. I love this car!

Ok, here's the deal. The RX-8 does not support PWM or VPW ODB..

It does support ISO ODB... however not the older standard ISO9141.. Here's the output from the j1699.c ODB complaince test procedure document when connected to to the RX-8 with a CarDAQ box:

51924ms Checking for OBD on J1850PWM protocol
59065ms REQ MSG: J1850PWM 61 6A F1 01 00
59075ms TX MSG: 95184usec J1850PWM 61 6A F1 01 00
60356ms Checking for OBD on J1850VPW protocol
69019ms REQ MSG: J1850VPW 68 6A F1 01 00
69029ms TX MSG: 105011usec J1850VPW 68 6A F1 01 00
69560ms Checking for OBD on ISO9141 protocol
80676ms Checking for OBD on ISO14230 Fast Init protocol
87856ms REQ MSG: ISO14230 C2 33 F1 01 00
87876ms TX MSG: 123609usec ISO14230 C2 33 F1 01 00
88697ms Checking for OBD on ISO14230 protocol
99743ms Checking for OBD on ISO15765 protocol
105932ms REQ MSG: ISO15765 00 00 07 DF 01 00
105942ms TX MSG: 141451usec ISO15765 00 00 07 DF 01 00
105962ms RX MSG: 141452usec ISO15765 00 00 07 E8 41 00 BE 1F E8 13
106142ms 1 OBD ECU(s) found
106142ms OBD on ISO15765 protocol detected


So, basically, in order to communicate with the RX-8, you must use the newer ISO spec.. meaning just about all the older, cheap tools just plain won't work.. if you've got $ to spare, buy a cardaq or a JPOD...

I've heard about a new tool coming out soon fo USB that'll support the newer tool, whih is much cheaper.. Check the spec first..

OverLOAD

I think this link might be what you talking about : http://www.mecel.se/products/cantools/usbtocan/default.htm
and this web site also may help some : http://www.mecel.se/services/loc3t/default.htm

I don't own an Rx-8 and porbally wont for a few years, but I wanna see this thang get hacked and see people be able to talk to there cars.

Originally posted by Mazda Family
I think this link might be what you talking about : http://www.mecel.se/products/cantools/usbtocan/default.htm
and this web site also may help some : http://www.mecel.se/services/loc3t/default.htm

I don't own an Rx-8 and porbally wont for a few years, but I wanna see this thang get hacked and see people be able to talk to there cars.

:)

Here's one response from a vendor. Even another one is baffled about the missing +12 line.


Hello Lee,

It is very odd that your diagnostic connector is missing pin 16. Any car that has OBD-II has to have +12V according to the J1962 document. The pins in the DLC go as shown on this diagram: http://www.scantool.net/faq/which_protocol.htm

Try asking our German distrubutor, www.obd-2.de. He is selling a scan tool called AutoMex, and it supports all known OBD-II protocols.

Best regards,

Vitaliy Maksimov
General Partner, ScanTool.net
vitaliy@scantool.net


----- Original Message -----
From: "It's Lee" <lee@lasvegastech.com>
To: <info@scantool.net>
Sent: Sunday, September 21, 2003 4:58 PM
Subject: Hybrid OBDii's?


> This info request was submitted
> by lee@lasvegastech.com (It's Lee)
> on Sunday, September 21, 2003 at 19:58:59
> ----------------------------------------------------------------------
>
> Ok,
>
> Im' trying to connect a 2004 Mazda RX8. Fully registered vag-com
(bi-com) won't connect nor will alex peper's tool.
>
> I did some research and 60%-CAN 40%-ISO 9141 is what the car is.
> Can
you help me with a tool that will actually communicate with this car?
>
> Also on the pinout:
http://www.ross-tech.com/vag-com/images/DLC_Pinout.gif
>
> There are only pins at 2,3,4,5,9 & 11. Maybe I read that backwards,
> but
that's how it shows on the connector on the car. So instantly, we are missing a +12v.
>
> If you have any ideas, let me know. If you have something that will
work, then I'll buy something right away.
>
> Thanks,
> Lee
>
>
> ----------------------------------------------------------------------
> IP address: 65.40.151.137
> User Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b)
Gecko/20030611 Mozilla Firebird/0.6
>

Hello, I live in Albuquerque, NM and have access to a OTC Genisys and several other scan tools. The Genisys chip is supposed to be able to handle all of the CAN protocols but the cable and software is to be released at the end of the year, in a few months when it comes out I'll be more than happy to "demo" it on a RX8 and get some numbers for you guys.

PM me if any one is interested.

As soon as someone is able to read the ecu and the sensors successfully, let us all know.

On another note, I just got this wideband O2 setup:

http://www.innovatemotorsports.com/

I've already read a few of the sensors, as I submitted a partial log previously, let me include the whole thing:

j1699.c source file output, using CarDAQ:

0ms Mon Sep 22 13:07:02 2003
0ms **** LOG FILENAME 2004-Mazda-RX8-1.log ****
0ms **** SAE J1699-3 Revision 10.2.2 (Buid Date: Aug 7 2003) ****

0ms **** NOTE: Timestamp on left is from the PC ****
0ms **** NOTE: Timestamp with messages is from the J2534 interface ****

0ms Windows NT/2K (08930005)
8432ms Enter your name and/or contact information (optional) (Press Enter): XXXxxx
16333ms How many OBD-II ECUs are on this vehicle (1 to 8)? (Press Enter): 1
20038ms Does the vehicle use compression ignition (i.e. diesel)? (Enter Yes or No): n
21601ms Is this a hybrid vehicle? (Enter Yes or No): n
24565ms Is this an engineering test (i.e. ignore protocol errors)? (Enter Yes or No): y
24565ms Device = CarDAQ
24565ms ProtocolsSupported = CAN,ISO9141,KWP2000,CAN,ISO15765,J1850VPW,J1850PWM
24565ms Device = JPod
24565ms ProtocolsSupported = CAN,ISO9141,KWP2000,CAN,ISO15765,J1850VPW,J1850PWM ,SCI,ISO14230
24565ms Select tool from following list:

24565ms 1 CarDAQ (CARDAQ32.DLL)
24565ms 2 JPod (JPOD32.DLL)
24565ms Enter device number (1-2): 28280ms 1
28280ms Loading CARDAQ32.DLL library
31515ms Would you like to run the optional tests first? (Enter Yes or No): n
31515ms **** Test 1.1 (No DTC set) ****
36192ms Turn key OFF for at least thirty (30) seconds (Press Enter):
36192ms Turn key ON with engine OFF.
36192ms Do not crank engine.
51924ms Was the MIL ON for at least fifteen (15) seconds? (Enter Yes or No): y
51924ms **** Test 1.1 PASSED ****
51924ms **** Test 1.2 ****
51924ms Checking for OBD on J1850PWM protocol
59065ms REQ MSG: J1850PWM 61 6A F1 01 00
59075ms TX MSG: 95184usec J1850PWM 61 6A F1 01 00
60356ms Checking for OBD on J1850VPW protocol
69019ms REQ MSG: J1850VPW 68 6A F1 01 00
69029ms TX MSG: 105011usec J1850VPW 68 6A F1 01 00
69560ms Checking for OBD on ISO9141 protocol
80676ms Checking for OBD on ISO14230 Fast Init protocol
87856ms REQ MSG: ISO14230 C2 33 F1 01 00
87876ms TX MSG: 123609usec ISO14230 C2 33 F1 01 00
88697ms Checking for OBD on ISO14230 protocol
99743ms Checking for OBD on ISO15765 protocol
105932ms REQ MSG: ISO15765 00 00 07 DF 01 00
105942ms TX MSG: 141451usec ISO15765 00 00 07 DF 01 00
105962ms RX MSG: 141452usec ISO15765 00 00 07 E8 41 00 BE 1F E8 13
106142ms 1 OBD ECU(s) found
106142ms OBD on ISO15765 protocol detected
106673ms Checking for OBD on ISO15765 29 Bit protocol
109006ms REQ MSG: ISO15765 18 DB 33 F1 01 00
109016ms TX MSG: 144492usec ISO15765 18 DB 33 F1 01 00
112091ms Firmware Version: 04.52
112091ms DLL Version: 05.01
112091ms API Version: 02.02
112111ms Battery = 11.910V
112111ms **** Test 1.2 PASSED ****
112121ms **** Test 1.3 ****
112201ms REQ MSG: ISO15765 00 00 07 DF 04
112211ms TX MSG: 147640usec ISO15765 00 00 07 DF 04
112251ms RX MSG: 147681usec ISO15765 00 00 07 E8 7F 04 78
115135ms RX MSG: 150519usec ISO15765 00 00 07 E8 44
122326ms **** Test 1.3 PASSED ****
122336ms **** Test 1.4 ****
122426ms REQ MSG: ISO15765 00 00 07 DF 01 01
122436ms TX MSG: 157734usec ISO15765 00 00 07 DF 01 01
122446ms RX MSG: 157735usec ISO15765 00 00 07 E8 41 01 00 07 6D 6D
122626ms **** Test 1.4 PASSED ****
122636ms **** Test 1.5 ****
122716ms REQ MSG: ISO15765 00 00 07 DF 06 00
122736ms TX MSG: 158029usec ISO15765 00 00 07 DF 06 00
122746ms RX MSG: 158030usec ISO15765 00 00 07 E8 46 00 C0 00 00 01
123007ms REQ MSG: ISO15765 00 00 07 DF 06 20
123027ms TX MSG: 158313usec ISO15765 00 00 07 DF 06 20
123037ms RX MSG: 158314usec ISO15765 00 00 07 E8 46 20 80 00 00 79
123297ms REQ MSG: ISO15765 00 00 07 DF 06 40
123317ms TX MSG: 158601usec ISO15765 00 00 07 DF 06 40
123327ms RX MSG: 158602usec ISO15765 00 00 07 E8 46 40 00 00 00 01
123567ms REQ MSG: ISO15765 00 00 07 DF 06 60
123577ms TX MSG: 158864usec ISO15765 00 00 07 DF 06 60
123587ms RX MSG: 158865usec ISO15765 00 00 07 E8 46 60 00 00 80 01
123818ms REQ MSG: ISO15765 00 00 07 DF 06 80
123828ms TX MSG: 159110usec ISO15765 00 00 07 DF 06 80
123848ms RX MSG: 159110usec ISO15765 00 00 07 E8 46 80 00 00 00 01
124108ms REQ MSG: ISO15765 00 00 07 DF 06 A0
124118ms TX MSG: 159398usec ISO15765 00 00 07 DF 06 A0
124138ms RX MSG: 159400usec ISO15765 00 00 07 E8 46 A0 00 00 00 01
124419ms REQ MSG: ISO15765 00 00 07 DF 06 C0
124429ms TX MSG: 159702usec ISO15765 00 00 07 DF 06 C0
124449ms RX MSG: 159703usec ISO15765 00 00 07 E8 46 C0 00 00 00 01
124709ms REQ MSG: ISO15765 00 00 07 DF 06 E0
124719ms TX MSG: 159991usec ISO15765 00 00 07 DF 06 E0
124739ms RX MSG: 159991usec ISO15765 00 00 07 E8 46 E0 80 00 00 00
125019ms REQ MSG: ISO15765 00 00 07 DF 06 03
125029ms TX MSG: 160295usec ISO15765 00 00 07 DF 06 03
125290ms REQ MSG: ISO15765 00 00 07 DF 06 01
125310ms TX MSG: 160569usec ISO15765 00 00 07 DF 06 01
125320ms RX MSG: 160570usec ISO15765 FirstFrame Indication
125360ms RX MSG: 160572usec ISO15765 00 00 07 E8 46 01 80 20 00 00 00 00 00 00 01 81 20 00 00 00 00 00 00
125630ms REQ MSG: ISO15765 00 00 07 DF 06 02
125640ms TX MSG: 160897usec ISO15765 00 00 07 DF 06 02
125650ms RX MSG: 160898usec ISO15765 FirstFrame Indication
125771ms RX MSG: 160903usec ISO15765 00 00 07 E8 46 02 01 0A 00 00 00 00 00 00 02 03 0A 00 00 00 00 00 00 02 04 0A 00 00 00 00 00 00 02 05 10 00 00 00 00 00 00
126031ms REQ MSG: ISO15765 00 00 07 DF 06 21
126041ms TX MSG: 161296usec ISO15765 00 00 07 DF 06 21
126061ms RX MSG: 161298usec ISO15765 FirstFrame Indication
126071ms RX MSG: 161299usec ISO15765 00 00 07 E8 46 21 80 20 00 00 00 00 00 00
126331ms REQ MSG: ISO15765 00 00 07 DF 06 3A
126351ms TX MSG: 161596usec ISO15765 00 00 07 DF 06 3A
126361ms RX MSG: 161597usec ISO15765 FirstFrame Indication
126381ms RX MSG: 161598usec ISO15765 00 00 07 E8 46 3A 80 0D 00 00 00 00 00 00
126642ms REQ MSG: ISO15765 00 00 07 DF 06 3B
126652ms TX MSG: 161900usec ISO15765 00 00 07 DF 06 3B
126672ms RX MSG: 161901usec ISO15765 FirstFrame Indication
126682ms RX MSG: 161903usec ISO15765 00 00 07 E8 46 3B 80 0D 00 00 00 00 00 00
126952ms REQ MSG: ISO15765 00 00 07 DF 06 3C
126962ms TX MSG: 162204usec ISO15765 00 00 07 DF 06 3C
126982ms RX MSG: 162205usec ISO15765 FirstFrame Indication
126992ms RX MSG: 162206usec ISO15765 00 00 07 E8 46 3C 80 05 00 00 00 00 00 00
127253ms REQ MSG: ISO15765 00 00 07 DF 06 3D
127263ms TX MSG: 162502usec ISO15765 00 00 07 DF 06 3D
127283ms RX MSG: 162502usec ISO15765 FirstFrame Indication
127293ms RX MSG: 162504usec ISO15765 00 00 07 E8 46 3D 80 0D 00 00 00 00 00 00
127563ms REQ MSG: ISO15765 00 00 07 DF 06 71
127573ms TX MSG: 162805usec ISO15765 00 00 07 DF 06 71
127583ms RX MSG: 162807usec ISO15765 FirstFrame Indication
127603ms RX MSG: 162808usec ISO15765 00 00 07 E8 46 71 80 10 00 00 00 00 00 00
127874ms REQ MSG: ISO15765 00 00 07 DF 06 E1
127894ms TX MSG: 163117usec ISO15765 00 00 07 DF 06 E1
127904ms RX MSG: 163118usec ISO15765 FirstFrame Indication
127954ms RX MSG: 163120usec ISO15765 00 00 07 E8 46 E1 80 20 00 00 00 00 00 00 E1 81 16 00 00 00 00 00 00
128234ms REQ MSG: ISO15765 00 00 07 DF 06 00 20 40 60 80 A0
128254ms TX MSG: 163475usec ISO15765 00 00 07 DF 06 00 20 40 60 80 A0
128274ms RX MSG: 163476usec ISO15765 FirstFrame Indication
128344ms RX MSG: 163480usec ISO15765 00 00 07 E8 46 00 C0 00 00 01 20 80 00 00 79 40 00 00 00 01 60 00 00 80 01 80 00 00 00 01 A0 00 00 00 01
128524ms **** Test 1.5 PASSED ****
128524ms **** Test 1.6 ****
128595ms REQ MSG: ISO15765 00 00 07 DF 01 00
128605ms TX MSG: 163828usec ISO15765 00 00 07 DF 01 00
128615ms RX MSG: 163829usec ISO15765 00 00 07 E8 41 00 BE 1F E8 13
128885ms REQ MSG: ISO15765 00 00 07 DF 01 20
128895ms TX MSG: 164111usec ISO15765 00 00 07 DF 01 20
128905ms RX MSG: 164112usec ISO15765 00 00 07 E8 41 20 80 07 B0 11
129165ms REQ MSG: ISO15765 00 00 07 DF 01 40
129185ms TX MSG: 164395usec ISO15765 00 00 07 DF 01 40
129195ms RX MSG: 164396usec ISO15765 00 00 07 E8 41 40 7A D0 00 00
129456ms REQ MSG: ISO15765 00 00 07 DF 01 01
129466ms TX MSG: 164679usec ISO15765 00 00 07 DF 01 01
129486ms RX MSG: 164679usec ISO15765 00 00 07 E8 41 01 00 07 6D 6D
129746ms REQ MSG: ISO15765 00 00 07 DF 01 03
129766ms TX MSG: 164967usec ISO15765 00 00 07 DF 01 03
129776ms RX MSG: 164967usec ISO15765 00 00 07 E8 41 03 04 00
130037ms REQ MSG: ISO15765 00 00 07 DF 01 04
130057ms TX MSG: 165254usec ISO15765 00 00 07 DF 01 04
130077ms RX MSG: 165256usec ISO15765 00 00 07 E8 41 04 DC
130267ms LOAD_PCT = 86%
130267ms WARNING: LOAD_PCT > 0%
130347ms REQ MSG: ISO15765 00 00 07 DF 01 05
130357ms TX MSG: 165555usec ISO15765 00 00 07 DF 01 05
130367ms RX MSG: 165556usec ISO15765 00 00 07 E8 41 05 52
130537ms ECT = 42 C
130607ms REQ MSG: ISO15765 00 00 07 DF 01 06
130617ms TX MSG: 165817usec ISO15765 00 00 07 DF 01 06
130628ms RX MSG: 165818usec ISO15765 00 00 07 E8 41 06 80
130898ms REQ MSG: ISO15765 00 00 07 DF 01 07
130918ms TX MSG: 166104usec ISO15765 00 00 07 DF 01 07
130928ms RX MSG: 166104usec ISO15765 00 00 07 E8 41 07 80
131188ms REQ MSG: ISO15765 00 00 07 DF 01 0C
131198ms TX MSG: 166387usec ISO15765 00 00 07 DF 01 0C
131218ms RX MSG: 166388usec ISO15765 00 00 07 E8 41 0C 00 00
131399ms RPM = 0 rpm
131479ms REQ MSG: ISO15765 00 00 07 DF 01 0D
131499ms TX MSG: 166677usec ISO15765 00 00 07 DF 01 0D
131509ms RX MSG: 166678usec ISO15765 00 00 07 E8 41 0D 00
131689ms VSS = 0 km/h
131769ms REQ MSG: ISO15765 00 00 07 DF 01 0E
131789ms TX MSG: 166966usec ISO15765 00 00 07 DF 01 0E
131799ms RX MSG: 166967usec ISO15765 00 00 07 E8 41 0E 80
132090ms REQ MSG: ISO15765 00 00 07 DF 01 0F
132110ms TX MSG: 167279usec ISO15765 00 00 07 DF 01 0F
132120ms RX MSG: 167280usec ISO15765 00 00 07 E8 41 0F 41
132310ms IAT = 25 C
132370ms REQ MSG: ISO15765 00 00 07 DF 01 10
132380ms TX MSG: 167558usec ISO15765 00 00 07 DF 01 10
132390ms RX MSG: 167559usec ISO15765 00 00 07 E8 41 10 00 00
132570ms MAF = 0.000000 gm/s
132640ms REQ MSG: ISO15765 00 00 07 DF 01 11
132650ms TX MSG: 167820usec ISO15765 00 00 07 DF 01 11
132660ms RX MSG: 167821usec ISO15765 00 00 07 E8 41 11 2B
132831ms TP = 16%
132921ms REQ MSG: ISO15765 00 00 07 DF 01 12
132931ms TX MSG: 168096usec ISO15765 00 00 07 DF 01 12
132941ms RX MSG: 168097usec ISO15765 00 00 07 E8 41 12 04
133201ms REQ MSG: ISO15765 00 00 07 DF 01 13
133221ms TX MSG: 168380usec ISO15765 00 00 07 DF 01 13
133231ms RX MSG: 168380usec ISO15765 00 00 07 E8 41 13 02
133492ms REQ MSG: ISO15765 00 00 07 DF 01 15
133512ms TX MSG: 168667usec ISO15765 00 00 07 DF 01 15
133522ms RX MSG: 168668usec ISO15765 00 00 07 E8 41 15 A1 FF
133782ms REQ MSG: ISO15765 00 00 07 DF 01 1C
133802ms TX MSG: 168954usec ISO15765 00 00 07 DF 01 1C
133812ms RX MSG: 168955usec ISO15765 00 00 07 E8 41 1C 01
133992ms OBD_TYPE = OBD II
134072ms REQ MSG: ISO15765 00 00 07 DF 01 1F
134082ms TX MSG: 169233usec ISO15765 00 00 07 DF 01 1F
134092ms RX MSG: 169234usec ISO15765 00 00 07 E8 41 1F 00 00
134253ms RUNTM = 0 sec
134323ms REQ MSG: ISO15765 00 00 07 DF 01 21
134333ms TX MSG: 169480usec ISO15765 00 00 07 DF 01 21
134343ms RX MSG: 169480usec ISO15765 00 00 07 E8 41 21 00 00
134513ms MIL_DIST = 0 km
134593ms REQ MSG: ISO15765 00 00 07 DF 01 2E
134613ms TX MSG: 169751usec ISO15765 00 00 07 DF 01 2E
134623ms RX MSG: 169752usec ISO15765 00 00 07 E8 41 2E 00
134884ms REQ MSG: ISO15765 00 00 07 DF 01 2F
134904ms TX MSG: 170039usec ISO15765 00 00 07 DF 01 2F
134914ms RX MSG: 170040usec ISO15765 00 00 07 E8 41 2F 98
135174ms REQ MSG: ISO15765 00 00 07 DF 01 30
135194ms TX MSG: 170328usec ISO15765 00 00 07 DF 01 30
135204ms RX MSG: 170330usec ISO15765 00 00 07 E8 41 30 00
135384ms WARM_UPS = 0
135474ms REQ MSG: ISO15765 00 00 07 DF 01 31
135484ms TX MSG: 170617usec ISO15765 00 00 07 DF 01 31
135495ms RX MSG: 170618usec ISO15765 00 00 07 E8 41 31 00 00
135675ms CLR_DIST = 0 km
135765ms REQ MSG: ISO15765 00 00 07 DF 01 33
135775ms TX MSG: 170906usec ISO15765 00 00 07 DF 01 33
135795ms RX MSG: 170907usec ISO15765 00 00 07 E8 41 33 61
135975ms BARO = 97 kPa
136055ms REQ MSG: ISO15765 00 00 07 DF 01 34
136075ms TX MSG: 171195usec ISO15765 00 00 07 DF 01 34
136085ms RX MSG: 171196usec ISO15765 00 00 07 E8 41 34 80 00 80 02
136346ms REQ MSG: ISO15765 00 00 07 DF 01 3C
136366ms TX MSG: 171484usec ISO15765 00 00 07 DF 01 3C
136376ms RX MSG: 171484usec ISO15765 00 00 07 E8 41 3C 0B 70
136636ms REQ MSG: ISO15765 00 00 07 DF 01 42
136656ms TX MSG: 171772usec ISO15765 00 00 07 DF 01 42
136666ms RX MSG: 171773usec ISO15765 00 00 07 E8 41 42 2F 3A
136937ms REQ MSG: ISO15765 00 00 07 DF 01 43
136947ms TX MSG: 172059usec ISO15765 00 00 07 DF 01 43
136957ms RX MSG: 172060usec ISO15765 00 00 07 E8 41 43 00 86
137137ms LOAD_ABS = 52%
137137ms LOAD_ABS > 0
137227ms REQ MSG: ISO15765 00 00 07 DF 01 44
137237ms TX MSG: 172350usec ISO15765 00 00 07 DF 01 44
137257ms RX MSG: 172352usec ISO15765 00 00 07 E8 41 44 00 00
137517ms REQ MSG: ISO15765 00 00 07 DF 01 45
137537ms TX MSG: 172638usec ISO15765 00 00 07 DF 01 45
137547ms RX MSG: 172639usec ISO15765 00 00 07 E8 41 45 13
137728ms TP_R = 7%
137818ms REQ MSG: ISO15765 00 00 07 DF 01 47
137838ms TX MSG: 172932usec ISO15765 00 00 07 DF 01 47
137848ms RX MSG: 172933usec ISO15765 00 00 07 E8 41 47 55
138038ms TP_B = 33%
138038ms TP_B exceeded normal range
138138ms REQ MSG: ISO15765 00 00 07 DF 01 49
138148ms TX MSG: 173247usec ISO15765 00 00 07 DF 01 49
138168ms RX MSG: 173248usec ISO15765 00 00 07 E8 41 49 51
138349ms APP_D = 31%
138439ms REQ MSG: ISO15765 00 00 07 DF 01 4A
138449ms TX MSG: 173545usec ISO15765 00 00 07 DF 01 4A
138469ms RX MSG: 173545usec ISO15765 00 00 07 E8 41 4A 34
138639ms APP_E = 20%
138729ms REQ MSG: ISO15765 00 00 07 DF 01 4C
138739ms TX MSG: 173834usec ISO15765 00 00 07 DF 01 4C
138759ms RX MSG: 173835usec ISO15765 00 00 07 E8 41 4C 14
139020ms REQ MSG: ISO15765 00 00 07 DF 01 00 20 40 60 80 A0
139040ms TX MSG: 174121usec ISO15765 00 00 07 DF 01 00 20 40 60 80 A0
139050ms RX MSG: 174122usec ISO15765 FirstFrame Indication
139090ms RX MSG: 174124usec ISO15765 00 00 07 E8 41 00 BE 1F E8 13 20 80 07 B0 11 40 7A D0 00 00
139370ms REQ MSG: ISO15765 00 00 07 DF 01 01 03 04 05 06 07
139380ms TX MSG: 174463usec ISO15765 00 00 07 DF 01 01 03 04 05 06 07
139390ms RX MSG: 174464usec ISO15765 FirstFrame Indication
139430ms RX MSG: 174465usec ISO15765 00 00 07 E8 41 01 00 07 6D 6D 03 04 00 04 DC 05 52 06 80 07 80
139620ms **** Test 1.7 ****
139701ms REQ MSG: ISO15765 00 00 07 DF 08 00
139721ms TX MSG: 174795usec ISO15765 00 00 07 DF 08 00
139731ms RX MSG: 174796usec ISO15765 00 00 07 E8 48 00 80 00 00 00
139991ms REQ MSG: ISO15765 00 00 07 DF 08 01
140011ms TX MSG: 175084usec ISO15765 00 00 07 DF 08 01
140021ms RX MSG: 175085usec ISO15765 00 00 07 E8 48 01
140281ms REQ MSG: ISO15765 00 00 07 DF 08 00 20 40 60 80 A0
140301ms TX MSG: 175369usec ISO15765 00 00 07 DF 08 00 20 40 60 80 A0
140311ms RX MSG: 175370usec ISO15765 00 00 07 E8 48 00 80 00 00 00
140492ms **** Test 1.8 ****
140502ms Start engine and let idle for one (1) minute.
164496ms USER TIP: Set A/C to defrost on hybrid vehicles to keep engine running (Press Enter): Start engine and let idle for one (1) minute.




As you can clearly see, I get RPM's, Speed, Engine coolant Temp (ECT), Mass Airflow readings, etc etc... This is a pretty well supported applicaiton, but I don't OWN any hardware, I can only borrow it, so any solution I could make with it would be temporary at best...


OverLOAD

Originally posted by Sparky
HIgh speed CAN chipsets are running around $120 in quantity on the projects I'm working. Hence my previous skeptisism that someone can produce a device that retails less than 300 dollars that can produce the speed. I've been doing some research myself and the gist that I'm getting is that most of the low dollar diagnostic folks are in over their head on this one. The real time PC dataloggers via PC card seam to be the most viable but they're around $600 for the hardware plus whatever the resaler wants to charge for his S/W front end.

A microchip CAN capable PIC is under $10.
A phillips CAN transceiver is under $2.

Both can support up to 1Mbps. Automotive CAN only runs at 500kbps.

Jeff

how is this going?!?!

I've traded emails with a couple of current OBD-2 scan solution providers (apart from the intrepid efforts of our resident RX-8 researchers here in the forum). Affordable commercial solutions should become available about 6 months from now (Spring 04), if not a little sooner.

I plan on getting a solution for either a PDA or a laptop -- probably about 8-10 months from now.

I agree with that.. I'm aware of a couple of developers who are working on new, small CAN tranciver modules.. One of particular interest to me, in development is supposedly going to be less than $500 (~$300?) and will be a compact device that comes complete with cables, and an API to make function calls.

In between full time work, school, and tons of other stuff, I'm trying to work on a DirectX 3D program which will be extensible and modifiable, and will work with a variety of units..

I'm quite a ways away, but the initial concept is done, and the process to implement it is complete. It's just a matter of bringing the concept completely into the code..

I probably won't really be able to get too far until spring time.. But that suits me fine, since my RX-8 is going in mothballs over the winter.

OverLOAD

Keep us posted! By developing interpretive software for the CAN on the RX-8, will you end up with a product that works universally for all cars that support CAN, or are you only keying in on things specific to the RX-8 (ie, leaving out codes and responses only found on piston engines?)

for the most part, it doesn't look like it has the capability of being completely comprehensive without the help of a Mazda insider to find out what the specific requests are to get the majority of the information, but it looks like if could very well all be there..

It should work with not only CAN protocol, but any other type of OBD-II bus protocol... potentially, depending on the message structure and how extensible I can make the application in the time I have.. I can always go back and add more later..

OverLOAD

I saw your discussion on CAN and the RX-8. We have finished our CAN electrical interface and are working towards completing the protocol layer for our software now. (www.autoenginuity.com). CAN is a lot more difficult than KPW2000 or ISO9141-2. You can get the specs. for the protocol from SAE only. They are the keepers of the knowledge as far as this goes. Also, keep in mind that CAN is used for several things so don't confuse any CAN article with the CAN-bus you require.

Our CAN support will be finished in Dec.

Vivid,

Thanks for your reply. I've got some good contacts already, and the "Team" is working on a custom hardware interface for CAN, with a few IO's for extra processing capability, and a Serial port connection. We'll probably be making the basic softwaer to display a neat on-screen gauge cluster soon. The concept software is just about done, and the software interface is next.

I do have some access to SAE documents, as another contact is a member.

Thanks for the info, the AutoEnginuity site looks pretty neat.

OverLOAD

Hi guys,

For what it is worth, what do you reckon about this one?

http://www.intrepidcs.com/vcan/

I have it on my shopping list.

Cheers,
Hymee.

Looks good, but I'm not sure.

The RX-8 (and 2004 Mazda6) have been verified by me, to use ISO15765, no ISO11898, as the people in that link say their device supports..

My colleage and I have a preliminary hardware design using a microcontroller based CAN transciver. We've built a couple of transciever modules, and are working on the code.

I've got an ealy beta of the software running. It works, but we've had some hardware problems with other units. We'll probably end up making a hardware revision and going with a different bus, maybe even some sort of wireless lan transciever would be very nice.

See a picture of the app. It doesn't tell you much, but I don't want to give away too much until the project's complete.

Looks kewl. I assume your application would use an interface cable and then be processed through a laptop, correct?

Ssssschweet!!!!!!

OverLOAD,
Looks like your project is coming along nicely. You mentioned that you were thinking of doing a wireless LAN connection and I think it would be pretty cool to have it work with a PocketPC (WiFi is built-in on a few models and can be added to most of the others). So in essence you would have a small and portable diagnostic tool that is a little easier to manage than a laptop.

Well,

That's a possibility for the future. The application is being designed to be as portable as possible right now, so the limitation isn't going to be the OS, etc.

The first Rev of the hardware we're working on will be a serial port to OBD-ii Can transciever. It's going to be capable of about 250 data updates per second, so about 10 gauges at 25 frames per second. This should be do-able on a PIII-700 class cpu.

For a PocketPC, that's a bit more development, since I have no hardware or development environment for that purpose, but maybe IPAQ support could be possible in the future.

More likely, in the future, is a USB type connector, and maybe even an 802.11b transciever. This would enable remote monitoring of your car via wireless, and even a whole bunch more neat possibilities, but as for what's actually going to happen, I can't really say for sure. But I do know that the app works, and it can give you literally TONS of gauges, an as configurable as you can think, but I'm still not ready to commit to a product for sale.

I'm probably going to be ordering the Mazda factory LCD assembly and getting a ~$300 mini-board PC to run in the car to get ym onscreen MazdaSpeed style gauges... More as it progresses,

OverLOAD

Well, the software is near complete, and the interface board is getting there...

For now, the plans are the display on a Windows OS, through a wire to the OBD-II connector.

I'm working on polishing up the app, and adding some more features. We're getting close to running our first in-car beta.

Originally posted by VividRacing.com
I saw your discussion on CAN and the RX-8. We have finished our CAN electrical interface and are working towards completing the protocol layer for our software now. (www.autoenginuity.com). CAN is a lot more difficult than KPW2000 or ISO9141-2. You can get the specs. for the protocol from SAE only. They are the keepers of the knowledge as far as this goes. Also, keep in mind that CAN is used for several things so don't confuse any CAN article with the CAN-bus you require.

Our CAN support will be finished in Dec.

Huff,

I noticed the Auto Enginuity software is prominently displayed on your new website (http://www.vividracing.com/index.php?src=news&prid=139&category=Press%20Releases) and was wondering if it now supports our RX-8s?

Originally posted by OverLOAD
Well, the software is near complete, and the interface board is getting there...

For now, the plans are the display on a Windows OS, through a wire to the OBD-II connector.

I'm working on polishing up the app, and adding some more features. We're getting close to running our first in-car beta.

sounds great.


I'd also vote for getting a Pocket PC version... my Dell PDA would be much easier to mount somewhere on the dash to use for guages and temporary amusement then my laptop.... however the advantage of a laptop is obvious for datalogging and more complicated things.

A wireless hook up would be awesome.

We'll see how things go.. Right now the software side is just a one man show. In the future, depending on many factors, who knows what might happen,

OverLOAD

nice nice!
since the 6 and the 8's ECU are similar, would the governor code be the same aswell?

If you guys are looking for a CAN compatible scanner, AutoXray's 4000, 5000, and 6000 series scanners support it.

Here's one for $359
http://www.ai-supply.com/search/ShowItem.asp?ItemCode=HEM+5000

The 4000 has been used on the Mazda6, but its just a scanner, you can't change parameters. It works pretty well, but there are small bugs. For instance, the program won't yet show the 2nd O2 sensor on bank2.

Maybe if you guys and us start pounding AutoXray with requests, we can get something done!

Here are a few threads regarding this:
http://mazda6club.com/forums/read.php?TID=12682
http://mazda6club.com/forums/read.php?TID=12084

BTW, we're having the same problem as you guys on the dyno. Car seems to be going into a safe mode and dumping boatloads of fuel at higher RPMs.

I was actually thinking the other day that the 6 owners would probably appreciate this tool...

Originally posted by pr0ber
I was actually thinking the other day that the 6 owners would probably appreciate this tool...

we would, mostly me. i'm ready to go past the 120 barrier, take advantage of $$$ gas (lol) and dust few more peeps. if sumone could drop sum lines off at the www.mazda6club.com boards to state this lovely tool. they get tired of me there cause i'm always bitchin about shit.

Overload - on the scanning software, do you guys have any plans to develop a device that tracks CAN data and stores it for later use, rather than the real-time connection via a portable PC and serial connection? Such as a device like the Carchip that plugs into OBDII ports, stores something like 70 hours worth of information, and later can be interfaced w/a desktop PC and the complete data analyzed?

blizz81,

The way that the ODBII diagnostic messages work, requires a message to be sent in order to recieve a status update, of say, the Mass AirFlow sensor reading.

The mesaging structure is pretty complicated, and the number and frequency of message data that can be stored is immense. With at least 50 trackable parameters, it's not feasable to track them all with a high update-rate.

So, instead of building a very complex piece of hardware, our plan is to build a very simple, low cost CAN interface transciever to connect to the computer, and make the computer software capable of mesasge selection, update frequency, logging capabilities, and playback (logging and playback aren't done yet). However the device and software work well, and you can select as many gauges as you want to show simultaneously.

The capability of using an integrated PC gives many additional options, such as race-cam gauge overlay, and being able to go back and replay data with the actual car data being shown, such as yaw rates, engine load, etc.

There's too much potential in the integrated PC for me to want to start with a smaller 'black box' data logger. As basic $150 barebones PC will be able to do the same thing and still less cost than we would have to charge to add the functionality to the device.

OverLOAD

I must be going mad - when I search www.iso.org for ISO15765 or just 15765 I get nothing!

Anyone been lucky?

Cheers,
Hymee.

You have to be a member of the IEEE or the SAE group I think, in order to get access to their specifications.

But, if you want some more details, I can probably help point you in the right direction... PM me.

OverLOAD

I was prepared to purchase parts of 15765 if they were relevant to what I needed, but the site didn't seem to know about them.

I ended up purchasing my own version of the SAE J1979 spec. It appears to be the standard the specifies all the messages for reading OBDII information.

Cheers,
Hymee.

WOW, I just read the thread and had to shed some tears as I'm seeing those familiar hexdumps :):)

I've been working on a CAN protocol stack implementation for two years and got to work with tons of dumps like that.

Sure the HW is cheap for up to 1Mb transmission speed, but the protcol stack and application layer is the key to dechipher anythig useful. Not to mention proper message sequences and timing.

Good luck!

test only, please ignore.

I saw the CarChip http://www.carchip.com/drive/products/carchip_products.asp heralded on the TechTV site and it seems to have some really nice features for what appears to be a reasonable price. However, in reading this thread, it appears that they may not be ready for the RX-8. Can you tell me if the features that the CarChip site list are "for real"? How does your solution differ or share similarities? I apologize for not understanding most of what's being posted on this thread, just looking for some friendly advice on what an ordinary "consumer" might purchase with regard to ODB-II interfaces. In addition to the features listed on the above link, I'd really like to know my coolant temp and oil pressure readouts, even if only after-the-fact, in a PC download. TIA

Basically, It's just another OBD-II scan tool. The big difference is that it's going to be cheap because it only has the minimal functionality that we require. The use of a computer means the software can have the brains, and the hardware can be made cheap.

I bet that CarChip, or any other vendor out there would love it if someone designed a proprietary solution using their interface. They'd have guaranteed sales, except for the problem of the additional cost. even $100 (??) for software plus $300 to $500 for a hardware interface (check around, the good ones cost big time), makes for a tough sell...

OverLOAD

any updates??

need any testers??? ;)

any updates?

I just started looking at this stuff this weekend and the first thing I did was look to see if there are already projects out there trying to do this. There is a OBDII implementation in java up on sourceforge.net that I just downloaded the code about 30 minutes ago. So I don't know much about the code yet, but I think it only supports the older ISO standard. However, it seems they were just using the cable from multiplex-engineering to read data from the car. It doesn't seems like the project has been active for a while, so I haven't been able to talk to the origonal developers yet to find out what kinds of data rates they were getting.

Here is a link to their project:
http://sourceforge.net/projects/jobdii/
http://jobdii.sourceforge.net/

As I've said, i'm really new to the whole OBDII stuff, but I would really like to get involved. I'm just not sure where to start yet. I wanted to look at all this code first to see if there are ways to enhance it. If anyone would have the time to point me to info about the kinds of things that you can get from the OBD interface that would be great. Also, I don't really understand why the cable that multipllex is selling wouldn't work for the data rates we need to do the real time stuff.

If anyone thinks that the project above may be useable, let me know. I'm very intrested in helping with it.

Thanks!

Basically, CAN is a very simple communication protocol. ISO15765 makes a lot of sence, and there's enough information around to figure out how to send the data to get what you want. It's actually very easy to get the information that's available in the OBD spec codes..

Now the real gravy in the RX-8 ECU, is the Mazda specific vendor data. If you knew the codes to retrive data like the TPMS sensor module values, being able to set them too, and about 10x as much capability as the OSB spec.. You can do a lot with just the J1699 test codes, but to really have an impressive setup, and get control of the system, rather than just watch it, you need the Mazda specific codes. some shops out there may actually have that info, but it probably isn't free.

OverLOAD

Multiplex sells a CAN interface. It works for me on my RX-8 :) and also on my good wifes Mazda 6.

The J1699 sourceforge project I looked at also required the interface to conform to J2354 specs, which is basically a software device driver layer. Multiplex interfaces do not come with any driver software, you need to write your own.

Cheers,
Hymee.

Originally posted by Hymee
Multiplex sells a CAN interface. It works for me on my RX-8 :) and also on my good wifes Mazda 6.

The J1699 sourceforge project I looked at also required the interface to conform to J2354 specs, which is basically a software device driver layer. Multiplex interfaces do not come with any driver software, you need to write your own.

Cheers,
Hymee.

The j1699.c source code still does show you what the raw data your need to tx/rx is. IT may require a J2534 compatabile device, but that's just for the interface communication standards, the raw OBD data is just encapsulated behind a simple header.

I've used very nice and expensive interfaces with success on the RX-8, including the Saint, and the CarDaq, but very pricy, but effective. If you want to use a simpler device, the same data still needs to be sent.

What data have you managed to be able to get?


OverLOAD

Have you seen this?

www.autoenginuity.com

What do you think about it? I'm thinking about getting the Palm version...

Originally posted by neit_jnf
Have you seen this?

www.autoenginuity.com

What do you think about it? I'm thinking about getting the Palm version...

It's been mentioned by others before. Last I heard from them was they they were looking into adding support for the RX-8, I don't know if they've done so yet. Call them and find out.

OverLOAD

bump

how's the progress??

Originally posted by OverLOAD
It's been mentioned by others before. Last I heard from them was they they were looking into adding support for the RX-8, I don't know if they've done so yet. Call them and find out.

OverLOAD


I checked with them and their product has a CAN expansion pack now to make the scan tool look at the majority of the 79 OBDII supported sensors, but nothing beyond that. In comparision the Ford expansion pack gives you close to 200 sensors and the GM pack gives 600 sensors.

Were you planning on only reading the OBDII sensors or going beyond that?

Originally posted by pr0ber
I checked with them and their product has a CAN expansion pack now to make the scan tool look at the majority of the 79 OBDII supported sensors, but nothing beyond that. In comparision the Ford expansion pack gives you close to 200 sensors and the GM pack gives 600 sensors.

Were you planning on only reading the OBDII sensors or going beyond that?

The base sensors are pretty comprehensive, but still, there's no oil pressure. You get Oil Temp & Coolant Temp, MAF, etc etc, but you're still missing a bunch.

I personally not interested in trying to find out what the custom Mazda codes are. It's possible that they're the same as Fords, but until someone else tries, I'm pretty much settled on using the OBDII codes, besides, once you've done the legwork to make the base codes work, it's a cakewalk to get the vendor specific codes to work, once you know what they are....

If someone were able to confirm/deny the Form/Mazda codes being the same, that would be a big step in the right direction. This project is still pretty much on hold for me at the moment, as I've got too much else happening at the moment.

Regards,

OverLOAD

I just got told by Auterra (http://www.auterraweb.com) that their Palm scan tool doesn't support the RX8 either. And they've got a picture of the 8 ON THEIR BOX!

Jeez! They have agreed to give me back my money, but no mention of this limitation on their web site. I tried to find the thread where they were mentioned to post to, but I couldn't get any search results using Auterra.

I've asked the guy to let me know when they come out with a version that works...

Originally posted by OverLOAD
The j1699.c source code still does show you what the raw data your need to tx/rx is. IT may require a J2534 compatabile device, but that's just for the interface communication standards, the raw OBD data is just encapsulated behind a simple header.

I've used very nice and expensive interfaces with success on the RX-8, including the Saint, and the CarDaq, but very pricy, but effective. If you want to use a simpler device, the same data still needs to be sent.

What data have you managed to be able to get?


OverLOAD

Sorry,

I haven't responded to this very valuable thread for such a long time.

I can get all the RX-8 supported PIDS. To my disgust, I found J1979 doesn't even mention a knock sensor. That is a real must IMHO for serious tuning.

I am trying to find out the "manufacturer specific" PIDs that are "reserved" by J1979. Like what has been mentioned above for GM and Ford. I'm sure it would be in there somewhere. Can anyone help finding out what the RX-8 specific PIDS are?

Here is my contribution. These are the stock J1979 ones that the RX-8 supports. This was found out by sending the message to "request all supported PIDS":


3754ms TX: ---> A6 08 08 02 01 00 00 00 00 00 00 00 00 00 13
3914ms RX: <--- 40 88 06 41 00 BE 1F E8 13 00 00 00 00 A7

41 = Service 01
00 = PIDs 01-20
BE = 10111110 = 01 xx 03 04 05 06 07 xx
1F = 00011111 = xx xx xx 0C 0D 0E 0F 10
E8 = 11101000 = 11 12 13 xx 15 xx xx xx
13 = 00010011 = xx xx xx 1C xx xx 1F 20

01 = Monitor Status since DTC's cleared
03 = Fuel System status (open/closed loop etc.)
04 = Calculated LOAD value
05 = Coolant Temp
06 = STFT Banks 1 & 3
07 = LTFT Banks 1 & 3
0C = RPM
0D = Vehicle Speed
0E = #1 Cyl advance
0F = Intake Air Temp
10 = MAF - Air flow rate
11 = TPS - absolute
12 = Commanded 2ndry air status
13 = O2 sensor location
15 = Bank 1 Sensor 2 O2, Volts and STFT
1C = OBDII requirements met
1F = Time since engine start (s)
20 = Check for PIDs 21-40

3145ms TX: ---> A6 08 08 02 01 20 00 00 00 00 00 00 00 00 33
3648ms RX: <--- 40 88 06 41 20 80 07 B0 11 00 00 00 00 37

20 = PIDs 21-40

80 = 10000000 = 21 xx xx xx xx xx xx xx
07 = 00000111 = xx xx xx xx xx 2E 2F 30
B0 = 10110000 = 31 xx 33 34 xx xx xx xx
11 = 00010001 = xx xx xx 3C xx xx xx 40

21 = Distance travelled while MIL activated
2E = Commanded Evaporative Purge
2F = Fuel Level Input
30 = Number of warm-ups since diagnostic codes cleared
31 = Distance since diagnostic codes cleared
33 = Barometric pressure
34 = Bank 1 - Sensor 1 Wide-range O2 Lambda / current.
3C = Catalyst Temperature
40 = Check for PIDs 41 - 60


3656ms TX: ---> A6 08 08 02 01 40 00 00 00 00 00 00 00 00 53
4156ms RX: <--- 40 88 06 41 40 7A D0 00 00 00 00 00 00 59

40 = PIDs 41 - 60

7A = 01111010 = xx 42 43 44 45 xx 47 xx
D0 = 11010000 = 49 4A xx 4C xx xx xx xx
00 = 00000000 = xx xx xx xx xx xx xx xx
00 = 00000000 = xx xx xx xx xx xx xx xx

42 = Control Module Voltage
43 = Absolute Load Value
44 = Commanded Equivalence Ratio
45 = Relative Throttle Position
47 = Absolute Throttle Position B
49 = Accelerator Pedal Position D
4A = Accelerator Pedal Position E
4C = Commanded Throttle Acutator Control

Hope this helps!

This is very usefull. I was able to determine what the timing map (for ignition advance) at various RPMS at WOT, Full load. :)

But then again, we are just dumb Aussies, right?

Cheers,
Hymee.

Is this project still in active?

I could contribute some programming if it has lapsed from a lack of time by its originators.

Could anyone suggest any vendors who sell hardware interfaces that are known to work with the RX-8's CAN?

I am still working on this when time permits...

Cheers,
Hymee.

Originally posted by JohnO
I just got told by Auterra (http://www.auterraweb.com) that their Palm scan tool doesn't support the RX8 either. And they've got a picture of the 8 ON THEIR BOX!

Jeez! They have agreed to give me back my money, but no mention of this limitation on their web site. I tried to find the thread where they were mentioned to post to, but I couldn't get any search results using Auterra.

I've asked the guy to let me know when they come out with a version that works...




The AutoEngineuity Scan tool does support Palm which makes the whole process of using the tool alot easier since there are no wires to get in the way of the driver.

Originally posted by Hymee
Multiplex sells a CAN interface. It works for me on my RX-8 :) and also on my good wifes Mazda 6.

The J1699 sourceforge project I looked at also required the interface to conform to J2354 specs, which is basically a software device driver layer. Multiplex interfaces do not come with any driver software, you need to write your own.

Cheers,
Hymee.



Could you detail the parts you are using from Mulitplex?

TIA

AT

OverLOAD,

are you planning on producing these units and software for sale when you complete development? If so, approximatly how much would the unit and software cost?

Thanks
-n

Originally posted by wolfbeast
OverLOAD,

are you planning on producing these units and software for sale when you complete development? If so, approximatly how much would the unit and software cost?

Thanks
-n

Possibly, The proto device is essentially finished and working. It's just a simple serial port to CAN bus interface. The interface itself doesn't have any high-tech features, but I've written a huge PC interface that can query most of the supported PIDS. That was back in october/november timeframe.

It's currently on hold pending the finalization of the AuxMod project. Hopefully we will be starting it up again in the next month or two.

As to pricing, and even if we will be selling it, I can't say here, due to the forum rules. Until we become an official RX-8club.com Sponsor, that is.

Regards,

OverLOAD

Thanks for the update, Overload.

I am in the Detroit area, and could help with the programming if this isn't intended to be a commercial product (or perhaps a customer when it becomes one).

Feel free to contact me.

Check out the CANScan OBD-II Scan Tool at www.ghg.net/dharrison. It supports Windows and Palm. I tested with the Palm version on my RX-8 this week and it works well.

That looks nice. Can you post some pics? I might have to get one. It's a good price.

I'll try to get some pix in the next couple of days. It works well on my Rx-8. The real time MPG display is helping me with my shifting and I'm excited to see what my gas mileage comes to.

If you have a palm, the web site has a downloadable Palm demo that generates faux data so you can get a feel for how it works without hooking to the OBD CANScan HW or vehicle.

which model did you get?

That looks pretty cool, and the price is extremely reasonable. I'd anticipate there'll be a flood of these SW solutions coming out over the next year or so.

Originally posted by Rx-Appreci-8
Check out the CANScan OBD-II Scan Tool at www.ghg.net/dharrison. It supports Windows and Palm. I tested with the Palm version on my RX-8 this week and it works well.

that looks great! Can you check some things for me...

- How many sensors is it capable of reading for the 8?
- Is it capable of logging data and dumping it into something like Excel?

- It says its possible to write your own applications, did you use it at all yet? I'd be really interested in writing a dyno program and maybe something that would tell you when to shift for best gas milage...

Overload -
I've owned the "OBDScan and Palm" combination for a couple of years. It works on standard (non Can Bus) post-96 OBD II vehicles.

The new "CANScan" hardware that I recently acquired looks just like the original OBDScan hardware and uses the same cables / Palm software that I already had, but CANScan works with the RX-8 and other CAN bus based OBD II vehicles. Windows software comes with the OBDScan and CANScan and the Palm software is a slight additional charge.

Prober -
The Palm software that I use has always been able to display ALL the PIDs defined in the OBD II ISO specification. The parameters displayed vary depending on what the vehicle ECU supports. In addition to normal "PID" values, if your check engine light (CEL/MIL) comes on, you can view stored trouble codes as well as freeze frame data (PID values present when CEL is asserted). If there are pending trouble codes present before the vehicle turns on the CEL/MIL they can be displayed too.

The list of standard parameters displayed with the CANScan HW connected to my RX-8 and Palm was approximately double what I'm used to seeing on typical OBD vehicles, so kudos to Mazda for expanding the supported PID list.

I may have missed it, but I didn't see a list of supported real time PIDs in the RX-8 repair manual, however there is an EXTENSIVE list of trouble codes supported by the RX-8 in the repair manual including non-ISO vehicle specific trouble codes in the P1XXX, CXXXX, BXXXX and UXXXX ranges.

To answer your specific question, I went out to hook up to my car and the Palm's battery was dead and my charger is at work. I'll charge it up Monday and get you an answer. If memory serves I'm thinking ~37 PID parameters displayed but I don't want to misrepresent the product. I did see "voltage", "time with MIL light on", and a few others that I've never seen before on other vehicles

To answer your other question - The Palm software supports data logging as a user selective option. Data is recorded to a Palm database (in Palm RAM) and the next time you hot sync a file gets created on your PC containg the data as tab and comma delimited ASCII text strings.

Regarding writing your own software, it's best to email dharrison directly about that. If you figure out a way to take the CANScan output and display it on my NAV screen I'd buy that from you -- if I don't beat you to it ;=)

it would be cool if someone would start getting data from the 4 wheel speed sensors, the steering input, and brake input... you could then combine that with the rpm's and throttle and theoretically make a program that you could go around a roadcoarse with, log all the data, come back and actually have the program spit out the coarse you traveled and the steering/braking/throttle inputs (possibly animated on the screen) and compare it between different laps...

... if only :o

pr0ber,

What you describe is roughly what I would like to do as well. The hard part is identifying the sensors that aren't in OBD II and decoding their data. I haven't found them in the service manual, either, so it would probably be quite difficult without assistance from Mazda.

I am thinking about installing a VIA Epia-MII board (small fanless PC-compatible) for data collection in my RX-8, but a laptop could be used as well. The computer wouldn't need an onboard display because the data could be stored on a small USB laptop hard drive and attached to another computer for data analysis.

If the VIA nano-ITX boards become available at retail, it might even be possible to fit one of these into the tape deck slot and interface it to the LCD display for real-time information display. I believe that someone was working on a board to allow connection of MP-3 players in this location.

BTW, there sure are a lot of "Probers" around here. I still have a 1989 Probe GT that has given me 15 years of excellent service.

As promised, here is the list of OBD-II PIDs that my RX-8 provided (data logged from my car this morning using my Palm). Not shown but still supported is the calculated MPG and my VIN which I deleted from the list.

Of course this list doesn't show all the trouble codes that can be shown as well.

The list looks better in WordPad when the Tabs are positioned properly.



8:49:34 am, ECU#, ECU#:, 10

8:49:34 am, MIL, MIL: , OFF

8:49:34 am, TITLE, CONTINUOUS TESTS...,
8:49:34 am, MIS_SUP, Misfire Supported, Yes
8:49:34 am, MIS_RDY, READY, Yes
8:49:34 am, FUEL_SUP, Fuel Sys Supported, Yes
8:49:34 am, FUEL_RDY, READY, Yes
8:49:34 am, CCM_SUP, Component Supported, Yes
8:49:34 am, CCM_RDY, READY, Yes
8:49:34 am, CAT_SUP, Catalyst Supported, Yes
8:49:34 am, CAT_RDY, READY, Yes
8:49:34 am, HCAT_SUP, H-Catalyst Supported, No
8:49:34 am, EVAP_SUP, Evap Sys Supported, Yes
8:49:34 am, EVAP_RDY, READY, Yes
8:49:34 am, AIR_SUP, Sec Air Supported, Yes
8:49:34 am, AIR_RDY, READY, Yes
8:49:34 am, ACRF_SUP, AC Refrig Supported, No
8:49:34 am, O2S_SUP, O2 Sensor Supported, Yes
8:49:34 am, O2S_RDY, READY, Yes
8:49:34 am, HTR_SUP, O2 Sensor Htr Support, Yes
8:49:34 am, HTR_RDY, READY, Yes
8:49:34 am, EGR_SUP, EGR Sys Supported, No
8:49:34 am, FUELSYS, Fuel System Status, 0200
8:49:34 am, FUELSYS1, Sys1-Clsd Loop, CL
8:49:35 am, AIR_STAT, AIR_STAT, OFF
8:49:35 am, O2SLOC, O2 Sensor Loc (2Bank)...,
8:49:35 am, O2SLOC, Bank1 Sensor 2, Yes
8:49:35 am, OBDSUP:, OBDSUP, OBD II,

ECU DYNAMIC DATA (ENGLISH UNITS):
8:49:34 am, LOAD_PCT, Calculated Load:, 27.5, %
8:49:34 am, ECT, Coolant Temp:, 109, Deg F
8:49:34 am, SHRTFT1, Short Term Fuel Trim B1:, -4.65529, %
8:49:34 am, LONGFT1, Long Term Fuel Trim B1:, 3.1, %
8:49:34 am, RPM, Engine RPM:, 1943, RPM
8:49:34 am, VSS, Vehicle Speed:, 20, mph
8:49:34 am, SPARKADV, Ignition Advance:, 33, Deg
8:49:35 am, IAT, Intake Air Temp:, 79, Deg F
8:49:35 am, MAF, Air Flow:, 1.4, lb/m
8:49:35 am, TP, Throttle:, 15.3, %
8:49:35 am, O2S12, Oxy B1, S2:, 965, mv
8:49:35 am, O2S12SHRTFT, Oxy B1, S2: (Fuel Trim), 0.0, %
8:49:35 am, RUNTM, Engine Run Time:, 104, sec
8:49:35 am, MIL_DIST, Distance with MIL On:, 0, mi
8:49:35 am, EVAP_PCT, Command Evap Purge:, 0.0, %
8:49:35 am, FLI, Fuel Level Input:, 15.7, %
8:49:35 am, WARM_UPS, Warm ups since TC clrd:, 28,
8:49:35 am, CLR_DIST, Distance since TC clrd:, 418, mi
8:49:35 am, BARO, Barometric Pressure:, 29.9, inHg
8:49:35 am, O2S11, Wide Range O2 B1S1:, 1.018 , lmda
8:49:35 am, O2S11, Wide Range O2 B1S1:, 14.90, A/F
8:49:35 am, O2S11, Wide Range O2 B1S1:, 0.047 , ma
8:49:35 am, CATEMP11, Catalyst Temp B1, S1:, 1338.1, Deg F
8:49:35 am, VPWR, Ctrl Module Voltage:, 14.141, V
8:49:35 am, LOAD_ABS, Absolute Load Value:, 26.3, %
8:49:35 am, EQ_RATIO, Comanded Equiv Ratio:, 0.996, x/y
8:49:35 am, EQ_RATIO, A/F (from Equiv Ratio):, 14.59, A/F
8:49:35 am, TP_R, Throttle Pos (Rel):, 5.9, %
8:49:36 am, TP_B, Throttle Pos B (Abs):, 32.2, %
8:49:36 am, APP_D, Accel Pedal Pos D:, 34.1, %
8:49:36 am, APP_E, Accel Pedal Pos E:, 23.1, %
8:49:36 am, TAC_PCT, Cmded Throttle Cntrl:, 5.5, %

did you happen to try and download the ford extended data software?? i have a hunch the latest ford ecu and mazda ecu are similar (they both go into diagnostics mode if you play with the trip computer button and ignition).

I see its a free download from that site so it might be something to check out... would turn the 40 or so sensors to over 200!!

Originally posted by Rx-Appreci-8
Check out the CANScan OBD-II Scan Tool at www.ghg.net/dharrison. It supports Windows and Palm. I tested with the Palm version on my RX-8 this week and it works well.

Thanks for the heads-up... that's a great price for a scan tool. I just ordered one myself.:D

Originally posted by 2rotors
BTW, there sure are a lot of "Probers" around here. I still have a 1989 Probe GT that has given me 15 years of excellent service.

Definitely a lot of former (and current) PGT and MX6 owners on this board. I just sold/gave my trusty 1993 PGT to my younger brother, who was in need of a good, fun daily driver.

it would be cool if someone would start getting data from the 4 wheel speed sensors, the steering input, and brake input... you could then combine that with the rpm's and throttle and theoretically make a program that you could go around a roadcoarse with, log all the data, come back and actually have the program spit out the coarse you traveled and the steering/braking/throttle inputs (possibly animated on the screen) and compare it between different laps...

... if only :o

An appropriate time of year to resurrect this thread from the dead...

Someone has done it, see http://blog.hiroaki.jp/2010/04/000469.html

Also see my blog for the details http://fastdruid.co.uk/wordpress/?p=116
but yes its there and it's fairly easy. Use an arduino, CAN shield and an LCD and you could display them in realtime for < £100.

CAN ID 00000201 for RPM, speed and throttle position.

CAN ID 000004B0 is the one you want for the individual wheel speeds.

Steering input I've not yet got, brakes I think I have (00000212) but need more testing (and binary).

Does anyone else have any translations of the CAN messages?

Druid

It looks like this was abandoned, my guess is it was commercialized or privatized.

Anyway: Some of the data mentioned here is handled by the ASIC in the BCM, The rest on the ECM, and not all boards are MIPS based.

If you are good with IDA both have SPI and simple buffer protocols to get code, whatever you do don't share code though, it's under DMCA. One chip on the BCM handles encryption for the transponders too.

ECM is hybrid ISO-15765 all the way up to 2011, and their is another protocol on BCM->ECM bus lines. The missing 12v+ is some pointless OEM thing.

http://www.madox.net/blog/projects/mazda-can-bus/

http://www.obdscan.net/obdscan_rx8_enhanced_data_viewe.htm

http://www.rx8club.com/showthread.php?p=3520268

It looks like this was abandoned, my guess is it was commercialized or privatized.

Anyway: Some of the data mentioned here is handled by the ASIC in the BCM, The rest on the ECM, and not all boards are MIPS based.

If you are good with IDA both have SPI and simple buffer protocols to get code, whatever you do don't share code though, it's under DMCA.

Can't be, DMCA covers essentially DRM'd systems, all the data is in the clear.
Possibly the keyless entry might be covered but I can't see how the rest can be (plus it doesn't apply to me as I'm in the UK).
Unless you mean to rip code from the PCM in which case I'd be inclined to kind of agree with their POV!

What is ECM, BCM and MIPS? I Presume ECM=PCM, BCM=HU/CM

Druid

http://www.obdscan.net/obdscan_rx8_enhanced_data_viewe.htm



I got a laugh out of this from the linked site:

No tool is worth buying if you can't use it.

since the CanScan I have fails more often than it works ... :icon_bs:

http://www.madox.net/blog/projects/mazda-can-bus/

From a Mazda 3, some applies, some doesn't and doesn't actually explain much apart from point to which bytes are used. I found http://blog.hiroaki.jp/2010/04/000469.html more use even though it only mentions a few pieces of data (and then going back to madox gave me more).

http://www.obdscan.net/obdscan_rx8_enhanced_data_viewe.htm

Only really of use as a data tool, not as part of making your own, also personally I'm not interested in OBD-2 just pure ISO 15765-4

http://www.rx8club.com/showthread.php?p=3520268

Great but Pieter for very understandable reasons is not sharing code atm, also I presume he is using OBD-2 rather than just listening on the CAN bus.

Druid

FWIW I've got most of the instrument panel decoded, or at least know what bytes do what even if I haven't figured out the bit mapping yet.

I'll update my blog later with what I've found but for proof see

http://i.imgur.com/EPIiVl.jpg

You can just see the PC PSU powering it and the Arduino sending the CAN messages. :-)

(petrol gauge is direct connect/resistor based, seatbelt warning I think is a direct connection to the SAS, not figured it out yet anyway)

Druid

seatbelt warning and the pre tensioners are a direct connect to the sas
OD

Hey guys, posted in my rxduino thread but wanted to post here as well incase someone knows, but I would like to know if anyone has the pid for the cruise control? I would like to know if the cruise is currently enabled or disabled, and if the user is pressing ACCEL or DECEL. Thoughts?

Cruise control PID is 650, 0xFF is green, 0x80 is yellow, 0x00 is off

AFAICT you can't detect the buttons without being hacking the wiring although you can get modules to connect to the buttons and pass on the messages to an arduino.

Druid

Got your PM, thanks a lot for the response man, thats brilliant that you had that. Unfortuanately I want some method to use available buttons to cycle through the display, looks like I will have to find other means then :(

Each of the 'buttons' connects a resistor to ground, 'reading' the buttons is therefore a matter of reading the resistance and working out which button (or combination of buttons) has been pressed.

You can get an interface board to read them (google carpc joycon) but not sure if that will disconnect the buttons totally or if you could connect inline.

Our RX-8 doesn't have the cruise control buttons[1] otherwise I'd scan the bus and see if it made any messages change.

Druid

[1] AFAICT the *only* difference between RX-8's with and without cruise control are the buttons themselves, the cruise control itself is in the PCM and all the other sensors (brake, clutch etc) are still there.

As fastdruid says -- and in the UK market for S1, one of the PCM updates disabled the CC for those who sourced and fitted the buttons after-market :-(

Is it possible to work out with an OBD-II interface if this S1 update has been applied?

I've got a UK RX-8 on a 53 plate and I was considering sourcing the buttons from the US and fitting them myself but I'd like to know first if they would work.

CAN data from S1 rom (referenced in subroutines which access the Hitachi CAN registers.)

ROM:0004BA14 stru_4BA14: hcanParam <h'201, 1, 2048, dword_FFFFBB2C, h'1000000>
ROM:0004BA14 ; DATA XREF: sub_DDDC+Co
ROM:0004BA14 ; ROM:off_DEF0o ...
ROM:0004BA24 stru_4BA24: hcanParam <h'203, 2, 1792, dword_FFFFBB48, h'1000000>
ROM:0004BA24 ; DATA XREF: sub_29DF4+2Co
ROM:0004BA24 ; ROM:off_29ECCo
ROM:0004BA34 stru_4BA34: hcanParam <h'215, 3, 2048, dword_FFFFBB68, h'1000000>
ROM:0004BA34 ; DATA XREF: sub_2A414+3Ao
ROM:0004BA34 ; sub_2A4A0:off_2A500o
ROM:0004BA44 stru_4BA44: hcanParam <h'231, 4, 1280, dword_FFFFBC90, h'1000000>
ROM:0004BA44 ; DATA XREF: sub_2CD60+24o
ROM:0004BA44 ; ROM:off_2CE00o
ROM:0004BA54 stru_4BA54: hcanParam <h'231, h'104, 1280, dword_FFFFBB18, h'1000000>
ROM:0004BA54 ; DATA XREF: sub_29A18+6o
ROM:0004BA54 ; ROM:off_29B24o
ROM:0004BA64 stru_4BA64: hcanParam <h'420, 5, 1792, dword_FFFFBADC, h'1000000>
ROM:0004BA64 ; DATA XREF: HcanParams?+32o
ROM:0004BA64 ; ROM:off_2965Co
ROM:0004BA74 stru_4BA74: hcanParam <h'620, 6, 1792, dword_FFFFC000, h'1000000>
ROM:0004BA74 ; DATA XREF: sub_32F08+20o
ROM:0004BA74 ; ROM:off_32FFCo
ROM:0004BA84 stru_4BA84: hcanParam <h'630, 7, 2048, dword_FFFFBFF0, h'1000000>
ROM:0004BA84 ; DATA XREF: sub_32E14+24o
ROM:0004BA84 ; ROM:off_32EC8o
ROM:0004BA94 stru_4BA94: hcanParam <h'650, 8, 256, byte_FFFFBC34, h'1000000>
ROM:0004BA94 ; DATA XREF: sub_2C164+4o
ROM:0004BA94 ; ROM:off_2C1D4o
ROM:0004BAA4 stru_4BAA4: hcanParam <h'41, 9, 2048, dword_FFFFC4C4, h'1000000>
ROM:0004BAA4 ; DATA XREF: sub_387E8+34o
ROM:0004BAA4 ; ROM:off_38830o
ROM:0004BAB4 stru_4BAB4: hcanParam <h'240, h'A, 2048, dword_FFFFCD30, h'1000000>
ROM:0004BAB4 ; DATA XREF: sub_4AFFC+34o
ROM:0004BAB4 ; ROM:off_4B0A4o
ROM:0004BAC4 stru_4BAC4: hcanParam <h'250, h'B, 2048, dword_FFFFCD44, h'1000000>
ROM:0004BAC4 ; DATA XREF: sub_4B0F8+34o
ROM:0004BAC4 ; ROM:off_4B194o
ROM:0004BAD4 stru_4BAD4: hcanParam <h'4B1, h'10C, 2048, dword_FFFFCD1C, h'1000000>
ROM:0004BAD4 ; DATA XREF: sub_4AEFC+6o
ROM:0004BAD4 ; ROM:off_4AF94o
ROM:0004BAE4 hcanParam <h'7DF, h'10D, 2048, byte_FFFFDBD8, 0>
ROM:0004BAF4 hcanParam <h'7E0, h'10E, 2048, byte_FFFFDBD8, 0>
ROM:0004BB04 stru_4BB04: hcanParam <h'7E8, h'F, 2048, byte_FFFFDBE0, 0>
ROM:0004BB04 ; DATA XREF: sub_66AE2+46o
ROM:0004BB04 ; ROM:off_66BB0o ...
ROM:0004BB14 stru_4BB14: hcanParam <h'201, 1, 2048, dword_FFFFBB2C, h'1000000>
ROM:0004BB14 ; DATA XREF: sub_D9F4+1Co
ROM:0004BB14 ; ROM:off_DB14o
ROM:0004BB24 hcanParam <h'203, 2, 1792, dword_FFFFBB48, h'1000000>
ROM:0004BB34 hcanParam <h'215, 3, 2048, dword_FFFFBB68, h'1000000>
ROM:0004BB44 hcanParam <h'231, 4, 1280, dword_FFFFBC90, h'1000000>
ROM:0004BB54 hcanParam <h'231, 4, 1280, dword_FFFFBB18, h'1000000>
ROM:0004BB64 hcanParam <h'420, 5, 1792, dword_FFFFBADC, h'1000000>
ROM:0004BB74 hcanParam <h'620, 6, 1792, dword_FFFFC000, h'1000000>
ROM:0004BB84 hcanParam <h'630, 7, 2048, dword_FFFFBFF0, h'1000000>
ROM:0004BB94 hcanParam <h'650, 8, 256, byte_FFFFBC34, h'1000000>
ROM:0004BBA4 hcanParam <h'41, 9, 2048, dword_FFFFC4C4, h'1000000>
ROM:0004BBB4 hcanParam <h'240, h'A, 2048, dword_FFFFCD30, h'1000000>
ROM:0004BBC4 hcanParam <h'250, h'B, 2048, dword_FFFFCD44, h'1000000>
ROM:0004BBD4 hcanParam <h'4B1, h'10C, 2048, dword_FFFFCD1C, h'1000000>
ROM:0004BBE4 hcanParam <h'7DF, h'10D, 2048, byte_FFFFDBD8, 0>
ROM:0004BBF4 hcanParam <h'7E0, h'10E, 2048, byte_FFFFDBD8, 0>
ROM:0004BC04 hcanParam <h'7E8, h'F, 2048, byte_FFFFDBE0, 0>
ROM:0004BC14 stru_4BC14: hcanParam <h'201, 1, 2048, dword_FFFFBB2C, h'1000000>
ROM:0004BC14 ; DATA XREF: sub_D9F4+20o
ROM:0004BC14 ; ROM:off_DB18o
ROM:0004BC24 hcanParam <h'203, 2, 1792, dword_FFFFBB48, h'1000000>
ROM:0004BC34 hcanParam <h'215, 3, 2048, dword_FFFFBB68, h'1000000>
ROM:0004BC44 hcanParam <h'231, h'104, 1280, dword_FFFFBC90, h'1000000>
ROM:0004BC54 hcanParam <h'231, h'104, 1280, dword_FFFFBB18, h'1000000>
ROM:0004BC64 hcanParam <h'420, 5, 1792, dword_FFFFBADC, h'1000000>
ROM:0004BC74 hcanParam <h'620, 6, 1792, dword_FFFFC000, h'1000000>
ROM:0004BC84 hcanParam <h'630, 7, 2048, dword_FFFFBFF0, h'1000000>
ROM:0004BC94 hcanParam <h'650, 8, 256, byte_FFFFBC34, h'1000000>
ROM:0004BCA4 hcanParam <h'41, 9, 2048, dword_FFFFC4C4, h'1000000>
ROM:0004BCB4 hcanParam <h'240, h'A, 2048, dword_FFFFCD30, h'1000000>
ROM:0004BCC4 hcanParam <h'250, h'B, 2048, dword_FFFFCD44, h'1000000>
ROM:0004BCD4 hcanParam <h'4B1, h'10C, 2048, dword_FFFFCD1C, h'1000000>
ROM:0004BCE4 hcanParam <h'7DF, h'10D, 2048, byte_FFFFDBD8, 0>
ROM:0004BCF4 hcanParam <h'7E0, h'10E, 2048, byte_FFFFDBD8, 0>
ROM:0004BD04 hcanParam <h'7E8, h'F, 2048, byte_FFFFDBE0, 0>
ROM:0004BD14 stru_4BD14: hcanParam <h'212, h'121, 1792, dword_FFFFBBF4, h'1000000>
ROM:0004BD14 ; DATA XREF: sub_D9F4+4o
ROM:0004BD14 ; ROM:off_DB24o ...
ROM:0004BD24 stru_4BD24: hcanParam <h'216, h'122, 2048, dword_FFFFBAF0, h'1000000>
ROM:0004BD24 ; DATA XREF: sub_29768+2o
ROM:0004BD24 ; ROM:off_29844o
ROM:0004BD34 stru_4BD34: hcanParam <h'430, h'124, 1792, dword_FFFFC00C, h'1000000>
ROM:0004BD34 ; DATA XREF: sub_3303C+6o
ROM:0004BD34 ; ROM:off_330F4o
ROM:0004BD44 stru_4BD44: hcanParam <h'4B0, h'125, 2048, dword_FFFFBBD4, h'1000000>
ROM:0004BD44 ; DATA XREF: sub_2B744+Ao
ROM:0004BD44 ; sub_2B79A:off_2B84Co
ROM:0004BD54 stru_4BD54: hcanParam <h'4C0, h'126, 256, byte_FFFFBC30, h'1000000>
ROM:0004BD54 ; DATA XREF: sub_2C0A8+6o
ROM:0004BD54 ; ROM:off_2C118o
ROM:0004BD64 stru_4BD64: hcanParam <h'47, h'127, 2048, dword_FFFFC4CC, h'1000000>
ROM:0004BD64 ; DATA XREF: sub_38838+6o
ROM:0004BD64 ; ROM:off_38900o