SV Portal Forums banner

Obd home made

9.1K views 17 replies 10 participants last post by  RecoilRob  
#1 ·
Hello friends,
I report all the information about Suzuki Diagnosis System version "home made"


Software (free download) http://www.ecueditor.com/
interface: FTDI USB-232R http://ecuhacking.activeboard.com/t39649986/ecueditor-25-with-gixxer-k5-k6-enginedata/

The program's ecueditor creatror PetriK would like to check if it is possible to convert ecueditor.com, a free diagnostic OBD program to suzuki sv 650-1000

Volunteers with the Suzuki sv 650/1000 Finland / Helsinki / Vantaa / Espoo willing to do some tests in reading values of the engine.

The Finns strommers interested can contact me in private

have a good work

Best regards

Maurice (Italy)
 
#2 ·
Be careful using these links just in case. He may be legit but he has no track record and you know what can happen downloading stuff.

Apologies to woba if he is legitimate.
 
#5 ·
Better safe then sorry, huh? :)

It seems legit. I followed both links and also went further as it is interesting stuff.


The program's ecueditor crearor PetriK would like to check if it is possible to convert ecueditor.com, a free diagnostic OBD program to suzuki sv 650-1000

Volunteers with the Suzuki sv 650/1000 Finland / Helsinki / Vantaa / Espoo willing to do some tests in reading values ??of the engine.
A K5+ will probably work as their ECU is very similar to a GSX-R ECU.

As long as I don't need to cut open my ECU I could do some tests.

D.
 
#4 ·
I opened them on my Windows work computer. The guy is legit from what I see. Just one of those crazy Euro's that love to hack the ECU on cars or bikes when they get the chance :bigclap: I think it's a great idea but a little over my head at the moment. Need time to read thru it all.
 
#6 ·
yair it is legit, this guy has been snooping around the SVDU site as well. Unfortunately he does not explain what is involved in testing so I will help ...

Petri (the author of the ECUeditor program) wrote his program to suit the OBD port on Hayabusas, and it relies on the ECU spitting out a series of bytes in a specific order, each byte more or less relating to one of the bike's sensors. It is possible to connect this program up to interface to the SV/DL ECU, but the order of the bytes is not the same, so some of the sensor values seem to be wrong. In essence, this guy needs someone to help to identify which bytes are associated with which sensors, so that the ECUeditor program can be modified to read the SV/DL ECUs correctly.

Unless you can vary each sensor individually without changing any other sensor, and monitor which byte in the output sequence changes when the sensor changes, it will be difficult to help out.

I helped Petri about 4 years ago when we were first working out how to download the contents of the suzuki ECUs, so I have some background in this, and if I can find the time I'll fire up my SV emulator (which will allow me to adjust one sensor at a time without affecting any of the others) and try to help.

cheers,
Mark
 
#8 ·
I still don't really understand what hes trying to do even when its in english.

But I'm glad we have a real live Italian on here as my daughter is doing Latin at school and he could help with her homework. (w00t)

We did have a few on here some years back but they faded away.
 
#9 ·
I still don't really understand what hes trying to do even when its in english.
.
Ho fatto una semplice richiesta di collaborazione per ottenere uno strumento di diagnosi gratuito per sv650/1000 ed è stata interpretata con molta diffidenza.Forse ho sbagliato forum,ci sono molte risposte fuori tema,dopo tutto se siete riusciti a creare un thread di 68 pagine per una semplice resistenza da 6,8 K ohm,credo che siate molto piu' bravi a chiaccherare ed a scrivere amenita'.
 
#11 ·
it took most of the day but I finally got a microprocessor to establish comms with the ECU via the dealer plug ... the biggest hassle is converting 3.3v logic (the microprocessor) to 12v logic (used by the ECU on this interface), and getting the timing just right ...

there's a wake-up sequence to prod the ECU interface into life, followed by an "initiate comms" byte sequence, and then a command is sent to the ECU to print out its sensor data

here's the results:

PART ONE:
I sent to the ECU: (initiate comms message)
81
12 (destination address = ECU)
F1 (source address = my microprocessor)
81 (message type initiate comms)
05 (checksum)

and I received from the ECU:
80
F1 (destination address - i.e. my microprocessor)
12 (source address - i.e. the ECU)
03 (#bytes to follow, excluding the checksum)
C1 (byte#1 = ok)
EA (byte 2 = Key Byte 1)
8F (byte 3 = Key Byte 2)
C0 (checksum)

now, the key bytes are: EA 8F, and if you have a copy of ISO 14230-2 handy, you can see in table5 that this means for all comms, our ECU:
- uses an additional length byte
- uses a message header that contains target and source address info
- uses normal timing

PART TWO:
I sent to the ECU:
80 12 F1 02 21 08 AE
(a message to ask the ECU to dump all its sensor data)

and I received back:
80
F1
12
34 # of bytes in response = 52
61 message type = sensor data
08 13 16 50 E0 01 05 A2
FF FF FF FF 00 00 00 FF
00 00 FF 00 FF 00 FF FF
FF FF 00 00 00 00 FF FF
FF FF FF FF 40 40 FF FF
FF 00 FF FF FF FF 00 00
42 FF FF
C9 (checksum)

now all we have to do is figure out which of the bytes in the main body of this message correspond to which sensor!!

cheers,
Mark