Members Login
Username 
 
Password 
    Remember Me  
Post Info TOPIC: SDS protocol


Senior Member

Status: Offline
Posts: 123
Date:
RE: SDS protocol


Yes, the GSXR1000 03-08 is listed. I didn't see it originally because their GUI had cropped off everything past "GSX-".

In your local ID file, you found 50 responses for the 21,08 command. Yet only 32 bytes could be returned from the ECU based on the packet size. Even if you skip the 13 nulls, there are 37 locations to report on. I wonder if the ECU is programmed to skip certain locations for that command.

Do you have any idea what the other changed bytes are for? If those are changing in addition to the proper sensor byte, then there are even less than 32 memory areas that could be reported on in that packet.

Then there's the addition of that 60 or 71 byte. When it repeated as 60 I thought it might be a count of the # of online sensors, but then 71 showed up while there was still just one sensor connected. Hmmm....

__________________


Guru

Status: Offline
Posts: 963
Date:

------------01-02-03-04-05-06-07-08-09-10-11-12-13-14-15-16-17-18-

80 F1 12 34 61 08 0C 16 50 E0 17 50 E1 FF FF FF FF 00 00 01 80 00


19-20-21-22-23-24-25-26-27-28-29-30-31-32-33-34-35-363-7-38-39-40-

00 FF 00 FF 00 FF 60 7C FF 00 00 00 00 00 00 00 00 FF FF 40 40 40

41-42-43-44-45-46-47-48-49-50-51-52-chksum

40 FF 00 FF FF 26 00 00 01 22 FF FF 51

Packet size is 0x34 or 52 decimal. Unless your confusing the base of the length I'm not sure I understand what your refering to when you say only 32 bytes can be returned.



__________________


Senior Member

Status: Offline
Posts: 123
Date:

Confusing Hex with Decimal I am. In the words of Gilda Radner, "nevermind".



__________________


Guru

Status: Offline
Posts: 2338
Date:

This is extremely good news allowing us to build tools for tuning the maps. Looks like I have spent few nights for nothing on this topic because did not find this thread earlier. Anyhow everything I have read from the Busa K8 programming code supports the story in here.

I am still puzzled by the full protocol regarding the following:
- What is the physical interface ?
- How does the initiation of the communications happen
- How does the communication protocol itself happen (format of sending request bytes, format of received packages)

I shall be receiving SDS hw in a week or so for some time so hope to be able to contribute more then.





__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Senior Member

Status: Offline
Posts: 123
Date:

The physical interface is assumed to be a K-line using the KWP2000/ISO-14230 protocol. Right now I am using inverted RS-232 to read the data on that K-line as it's exchanged between the SDS box and ECU.

The initiation has not been determined yet. The protocol spec on the swiftcomm site shows the following for initialization, but I've been letting the SDS box take care of this so far.

Fastinit:
______            _____         ____           ____
----------\_____/         \/\/\/\/        \/\/\/\/
300ms    25ms  25ms  packet     response

1) Wait for 300ms with K line high.
2) Pull K line low for 25 +/- 1 ms
3) Let K line rise high and wait 25ms
4) init serial connection to 10400 baud, 8N1, 1=0Volt 0=12Volt, least significant bit first
5) send package c1 33 f1 81 66    33=dest, f1=our tester id, 81=start comms
6) wait for response 83 f1 01 c1 e9 8f ae   01=physical address, c1=response ok (7f=fail), e9=kb1, 8f=kb2


Slowinit:

_______ S ___ 2 3 ___ 6 7 ___         ___        ____
------------\_/0 1\___/4 5\___/P  \/\/\/\/    \/\/\/\/
300ms  200 400 400 400 400 250 packet     response

1) Wait for 300ms with K line high.
2) send a byte 33 hex at 5 baud. 200ms per bit
startbit:      200ms low
databit0,1:    400ms high
databit2,3:    400ms low
databit4,5:    400ms high
databit6,7:    400ms low
stopbit+pause: 250ms high
4) init serial connection to 10400 baud, 8N1, 1=0Volt 0=12Volt, least significant bit first
5) send package c1 33 f1 81 66    33=dest, f1=our tester id, 81=start comms
6) wait for response 83 f1 01 c1 e9 8f ae   01=physical address, c1=response ok (7f=fail), e9=kb1, 8f=kb2

The comm protocol itself was figured out by RR several posts back. Basically its:
Command 80, destination, source, # of data bytes, data bytes, checksum.
The starting packet is a little different, using Command 81 instead of 80 and not showing a data byte count.


-- Edited by Gadget at 13:59, 2009-03-04

__________________


Senior Member

Status: Offline
Posts: 123
Date:

The white connector on the SDS board did not turn out to be as clear as I hoped. There are 9 pins:

Pin 9 - to SCK1, normally held high by 10k resistor to VCC.
Pin 8 - Ground
Pin 7 - VCC
Pin 6 - to Pin1 (A-Input) of dual OR gate, normally held low via 10k to Gnd. 
Pin 5 - to MD2, normally held high
Pin 4 - to MD1, normally held high
Pin 3 - to RES, normally held high
Pin 2 - no connect
Pin 1 - no connect

We have clock, ground, power, mode, and reset, so all we're missing is some data lines. Pins 1 and 2 are suspect (RxD1, TxD1) but I can't trace them to anything on the board.

Something that makes little sense is MD2. According to the manual, anytime it's not high the MCU is not in any acceptable operating mode. So what's the point to bringing it out to the connector? MD0 would have made sense, but I double-checked...it's MD2.

When I get some more time I'll see if I can find out where that OR gate goes.

__________________


Guru

Status: Offline
Posts: 2338
Date:

Just out of curiosity - have you tested what would happen if you connect a normal ISO software using a K-line interface to the ecu. Often in cars there is a subset which supporst std ISO protocol for reading key sensors and resetting DTC:s, even though the full implementation requires using car manufacturers own software.

I am really looking forward to figure how to read four parameters for tuning purposes:
- RPM
- TPS position
- IAP sensor reading
- Coolant temperature
Everything else is just an added bonus.

As the box is (supposedly) done by denso, would be silly for them to implement anything else than a std asian ISO implementation of the OBD protocol. Also as SDS is used with so many other vehicles (cars) that would support the assumption that the protocol is fairly standard OBD2.

With my cars I have used some of these succesfully with an ELM based interface. Possibly sourcecode is avail for at least some of those.

http://freediag.sourceforge.net/

http://sourceforge.net/projects/scantool/

http://www.qcontinuum.org/obdgauge/

http://pages.infinit.net/jsenk/obd_Win.htm

http://www.obdpros.com/obd_software.php

http://www.planetfall.com/~jeff/obdii/

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

http://www.obd-2.com/




-- Edited by PetriK at 06:35, 2009-03-05

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Senior Member

Status: Offline
Posts: 123
Date:

I haven't tried that yet. I have a K-line interface chip (L9637) and two OBD programs, just need to hook them up. Maybe tonight.

I wanted to copy all the commands I could from the SDS software first, but there are a few left I can't get to without an RPM signal. If I use a sine wave from my sound card, will a radio shack 1:1 isolation transformer be enough for creating the pulses or do I need to do something more?




__________________


Guru

Status: Offline
Posts: 2338
Date:

You may need both pulses for the ecu function correctly, but of course a stereo sound wave should do that.

If I recall correctly there needs to be at least 10-15V pulse on oscilloscope depending on RPM, so depends on what ratio of transformer you have. RR may remember better the actual thrashold.

I would be surprised if its very far away from obd2 - as sds is also used for cars what I have understood - just the interface harness has different connector. So the debugging of the protocol you do will serve anyone who is planning to implement an obd2 reader for suzuki cars. But like said I have proven to be wrong several times and this may just be another of those momens.


__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Veteran Member

Status: Offline
Posts: 35
Date:

Gadget wrote:

If I use a sine wave from my sound card, will a radio shack 1:1 isolation transformer be enough for creating the pulses or do I need to do something more?





I use a 1:2 Transformer with my soundcard.

regards, Torsten.



__________________


Senior Member

Status: Offline
Posts: 123
Date:

I only need a pulse for the crank, the bandit does not have a cam pulse. The crank pulse inputs are maked - and +, which confuses me about the sine wave and transformer.
A sine wave will generate impulses both above and below zero which would generate opposing polarity impulses at the transformer output. That means for half the cycle I will be applying + to + and - to -, but for the lower half of the wave I'd be applying + to - and - to +. That can't be good for the ECU.
I'm thinking a couple diodes on the primary side of the transformer should fix that and yield the strongest pulse. Or, am I not understanding this right?


__________________


Veteran Member

Status: Offline
Posts: 35
Date:

I think + and - doesn´t matter. Pulse is generated when it goes through "zero"- linie...but there was a discussion about a bike emulator for the hayabusa in this forum.

__________________


Guru

Status: Offline
Posts: 963
Date:

Because the crank uses an inductive pickup the ECU expects an alternating current signal from the crank sensor. The ECU circuit converts the AC signal into a square wave with the edges at the zero crossing points of the AC signal.

The + / - determines whether the square wave signal go high on AC rising edge or falling edge.

Here is the Crank Sensor Circuit for a ZX-12 ECU

Here is an example actual bike sensor waveform. (crank red, cam white)

r5graphus1.jpg

__________________


Guru

Status: Offline
Posts: 2338
Date:

No more good luck today... tried my ELM interface with ECU and did not connect straight away. Even tried 3 different OBD software packages. Pins Gnd5,7K-L,16Batt of the OBD2 interface were connected.

Dont know if everything should be configured somehow for one wire K-Line interface ?

Anyhow the SDS works very well helping in building the engine emulator for Busa gen2 ecuhack.


__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Senior Member

Status: Offline
Posts: 123
Date:

I had the same experience with the L9637 chip. I even connected the SDS box to it instead of the ECU hoping I would be able to receive the box's initial outbound transmission. I received nothing.
My next step is to put a scope on the K line and see if my chip is transmitting anything I send from the PC - just to see if the chip is working.

You mentioned pin "7K-L", are you connecting the L line to the K line? I don't think the L line is needed, and it might even be interfering with the K line.

__________________


Guru

Status: Offline
Posts: 2338
Date:

Hmmm... I thought 7 is single wire K-Line interface. Well i am very new to OBD comms so may have confused things.

The USD driver for "PC Diagnosis System Devices" says that the manufacturer is "Hitachi Car Engineering Co., Ltd."

Maybe there is more info somewhere on Hitachi Car Engineering solutions ?





__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Senior Member

Status: Offline
Posts: 123
Date:

When you say pin 7 are you talking about your ECU? What ECU?

On the 08+ Busa ECU, you want to connect the K-line (only) from your ELM chip to pin 32 of the ECU



-- Edited by Gadget at 19:39, 2009-03-09

__________________


Guru

Status: Offline
Posts: 2338
Date:

Was rferring to Pin 7 of the OBD std connector to SDS line 32 on ecu.

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Senior Member

Status: Offline
Posts: 123
Date:

OK, now I understand. You're right, pin 7 is just the single-wire K line, and I believe that's all you need. When you wrote "7K-L", I thought you had wired up your own ELM chip and tied both the K and the L lines from it to pin 32 on your ECU. That's why I was saying the L-line might be the problem.


__________________


Senior Member

Status: Offline
Posts: 123
Date:

Turns out my L9637 chip is not working. It's an SOP8 package and I didn't have a board for it, so I cut a piece out of an old video card that had the proper pin spacing. I must have missed eliminating a cross-trace somewhere, or maybe I burned the chip out somehow.

I've got another chip, but will need to find a new mount for it. I did find some software and source code (in C) designed to send the 5 baud 0x33 wakeup string. I can add our "81" init string to it so there's "clean" software and we know exactly what it's doing. Some of these freeware OBD programs are starting off with odd characters presumably to wakeup a commercial interface. I'm not sure what effect that has on the SDS. 


__________________


Guru

Status: Offline
Posts: 963
Date:

Gadget, check out this link for an SOP mount prototype solution

http://www.schmartboard.com/index.asp?page=products_so&id=56





__________________


Guru

Status: Offline
Posts: 2338
Date:

Just occured to my mind, that maybe we should analyze the physical interface of the SDS to ECU, is it really OBD 12v signal.

My scope is not fast enough detect the signal peak values but it shows +-2V max difference with a zero cross voltage - more like an RS232 signal rather than OBD or TTL signal. (On OBD2 spec I recall that 0-2v is low and 5-12v is high.)

EDIT:

...and on top of this page it already says "Inverted RS232" signal...

Just a very dummy question - why in earth inverted RS232 ?


-- Edited by PetriK at 15:21, 2009-03-10

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 963
Date:

I think it refers to inverting the output of the 232 - TTL converter.

The standard TTL output is idle at 5V and the start bit is 0V. By "inverted 232" I believe it means idle is 0V and start bit is high or 12V in the case of the SDS line.

I have actually seen this bidirectional, 12V hardware configuration before in a Yamaha Mitsubishi ECU. I'm not that familiar with the OBD protocols either but this looks to be some kind of standard interface.

__________________


Guru

Status: Offline
Posts: 2338
Date:

Excellent - all this means that the signal is std RS232 !!! Sorry fot being so slow.

Now I have a RS232 monitoring up and running on the line, exept that the baud rate is not standard for the interface (10.4K???) and need to find software that supports non standard baud rates.



__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Senior Member

Status: Offline
Posts: 123
Date:

Yes, I meant inverting the TTL when I said inverted RS232.

When you apply power to the ECU the SDS line jumps high to 12v. This is the idle voltage. When bits are passed, the voltage drops for each bit.

Do you think that inverting the TTL to the Max232 would not only invert the RS232 signaling, but would also change the 232 idle voltage? I didn't think it would. I was thinking the "inverted" 232 worked to recieve only because both the ECU and SDS box were holding the line high for the Max.

I figured that was the case, because it did not work to transmit. When I was transmitting, the SDS line had just the Max232 and ECU on it. I thought the Max pulled the SDS line down and prevented communication. Although I'm having big doubts now about the software I was using.

I'll check that out tonight. If the voltage is pulled down by the Max, I'll try a pullup resistor as well as the new software before going back to the L9637 chip.


__________________


Guru

Status: Offline
Posts: 2338
Date:

Hope you dont mind me almost hijacking the thread and making some more thinking aloud here...

Possible protocols that are 10.4 are:
SAE J1850 VPW: 10.4 kbaud
ISO 9141-2: 5 baud init, 10.4 kbaud (max 12 bytes/message including crc)
ISO 14230-4 KWP: 5 baud init, 10.4 kbaud (max 255 bytes/message)
ISO 14230-4 KWP: fast init, 10.4 kbaud

Based on what I read above that SDS/ECU comms have 5baud init and 10.4kbaud comms and the packages are longer than 12bytes then the it leaves only ISO 14230-4 KWP as a potential protocol.



__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 2338
Date:

Did some more reading of this thread and noticed that you guys on the previous page come to same protocol conclusion.

Then started to google about possible interfaces and found this:

http://www.alfa145.co.uk/dl.html

which looks somewhat promising in this context.


AJ-OBD-Interface_2.jpg



-- Edited by PetriK at 18:42, 2009-03-10

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 2338
Date:

I think that this document may be very close to the protocol SDS is using...

http://www.alfa145.co.uk/obd/14230-2s.pdf

Quit (disconnects from ECU)
From SDS: 80 12 F1 01 82 06
From ECU: 80 F1 12 01 C2 46


ISOprotocol.jpg


__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 2338
Date:

RidgeRacer wrote:

On command 21 Read by Local ID supports the following arguments

0x08 (returns 50 bytes)
0x80 (returns 100 bytes)
0x90 (returns 70 bytes)
0xC0 (returns 60 bytes)

0x40 (returns 16 bytes)
0x41 (returns 16 bytes)
0x42 (returns 16 bytes)
0x43 (returns 16 bytes)
0x44 (returns 16 bytes)
0x45 (returns 16 bytes)

0x50 (returns 16 bytes)
0x51 (returns 16 bytes)
0x52 (returns 16 bytes)
0x53 (returns 16 bytes)
0x54 (returns 16 bytes)
0x55 (returns 16 bytes)

Here are the lists of addresses read by each argument

SDS_001.txt



The RLI_ (return local identifier) service seems to be desribed in chapter 7.1. of this http://www.alfa145.co.uk/obd/14230-3s.pdf document. It also says in paragraph 7.1.5.1 that each parameter is abbrefiated with RV_??? where ??? is the SAE J1930 definition abbreviation (just like TPS, MCU,ECT etc...). The suzuki manual has a paragraph of these SAE abbreviations now so I would guess that they are strict on using those.

Anyhow I think I am done with SDS for today.

The big question that arises is if the RLI_??? abbreviations are somehow stored into the ECU as standard identifier positions defined by yet another document. If any of you guys can make any sense out of this and find out what is it that is missing to figure out the identifier bytes for RLI_??? services that would be highly appreciated.

I am just trying to find a shortcut to name all the variables in the ecu by knowing their names from the protocol description for Busa K8/K9.




__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 2338
Date:

While working on IDA come to read this when thinking about 0x40-0x4F and so on...

SDS_service_identification.jpg

Which obviously raised some curiostity about SAE J1979. When reading about that come to think about that the common role of the hardware module like SDS box seems to be a protocol converter for the PID messages into KWP2000 or alike protocols.

A sample of SAE codes and related DTC codes as responses to PID requests are in this document, obviously Suzuki lists much less Test ID:s, this is just a sample.
https://techinfo.honda.com/rjanisis/pubs/MO/BMO27081.pdf

Just a thought... if we want a ready made OBD program to work on the bike, propaly there is a way is to find a chip that supports KWP2000 - if the above assumptions are somewhat right ? Or ?





__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Senior Member

Status: Offline
Posts: 123
Date:

The interface circuit you posted has got me thinking PetriK. When we're receiving from the ECU the data coming into the interface from OBD connector Pin7 is logically the same as TTL, just at a higher voltage. Assuming I'm understanding that right, it seems we could add the yellow receive wire of a TTL-232 adapter to the circuit right where the Max's pin 10 connects. Resistors R3 and R4 would have already reduced the voltage to TTL levels in order to feed the Max.

The only remaining job is to increase the voltage on the Tx side of our TTL-232 adapter. Q1 might do that for us with the right R5 value, but it's going to invert the data which we don't want. What's a good amp design to replace Q1 with, that will raise our 5v TTL to 12v OBD?


-- Edited by Gadget at 04:43, 2009-03-11

__________________


Senior Member

Status: Offline
Posts: 123
Date:

The reason I'm looking for the TTL option is so that we can have one cable that does both the flashing and SDS. I thought about the schematic a little more and I think I have a solution. Q1 works to invert the 232 data as well as raise the voltage a bit. If we put our TTL Tx through the Max, the data will be inverted from what we need and run about -7 to +7volts. Q1 will fix the inversion and raise the voltage. The value of Q5 is still in question though, I think it should be less than what it is.
What's great about this is we don't have to use Mprog to invert the TTL data, since we're not going through the Max on the RX and Q1 is inverting on the TX. This means the factory TTL-232 driver install will work for both flashing and SDS.

AJ-OBD-Interface_4.jpg

__________________


Guru

Status: Offline
Posts: 2338
Date:


Maybe something like the below ?

Btw - noticed earlier that I can not get my AGV3100 adapter to stay in KWP2000 compatible mode (=protocol 5), it always returns to protocol 3 mode when using any software. Looks like its not too well supporting KWP2000 or there is still more into this.

Need to buy / try out an ELM interface which also has the AT commands very well documented.

obdii_avr.gif



-- Edited by PetriK at 10:17, 2009-03-11

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Senior Member

Status: Offline
Posts: 123
Date:

Of course! If one CE transistor will invert, then two in a row will negate the inversion. I'll give it a try.


__________________


Senior Member

Status: Offline
Posts: 123
Date:

It works!

It's tiny too, it can be built flat and shrink-wrapped right to the TTL cable.

I attached it to the K-line with just the ECU. The freeware programs did not work, but VAG-COM at least reported that it found the interface this time.

I added the SDS box so it could initialize a conversation with the ECU, and I was able to monitor the data they exchanged. While they were idle, just sending keep alives, I sent the 80 12 F1 02 21 08 AE command through the TTL adapter to monitor all sensors. The ECU responded with it's normal "no sensors connected" 0x34 string!

The C software I found and modified is not working as expected. I'll have to work on that next. But, it seems we have the physical connection out of they way. biggrin


__________________


Guru

Status: Offline
Posts: 2338
Date:

That sounds very promising...

Just out of curiosity, is your interface ELM237 based that you tried with your ECU and did you try the following from the terminal:

ATZ
AT SP 5


That should instead of timeout make a connect if Suzuki has made it KWP2000 quick init compatible - i think.


-- Edited by PetriK at 20:02, 2009-03-11

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Senior Member

Status: Offline
Posts: 123
Date:

My interface does not use the ELM. All it is, is the transistors and resistors you posted above connected to the end of a TTL-232 cable. So, no AT commands for me. I can only send and receive Hex.

I'm having trouble with the 0x33 wakeup at this point. I'm going to modify another standard baud rate on the TTL-232 so I can run hyperterminal at 5 baud. Then I'll watch the SDS to ECU wake up and see if it follows the KWP2000 rules.

__________________


Guru

Status: Offline
Posts: 2338
Date:

Sorry, I thought that the interface that was tried earlier was ELM. Well I should receive an ELM one on friday or monday so I relly hope that the KWP2000 rules are followed or otherwise I just spent 150usd for nothing.

Do you happen to know is VAG-COM is also a protocol chip based protocol or something else ?

I think that the Alfa software where the KWP documents were found may contain the KWP protocol so that it could work with your current interface.

EDIT, here: http://www.alfa145.co.uk/dl.html

-- Edited by PetriK at 20:28, 2009-03-11

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Senior Member

Status: Offline
Posts: 123
Date:

I don't know much about VAG-COM other than it did not mention the ELM chip so I thought it might work directly connected. They had a couple versions which might have worked, but didn't.

I tried the Alpha software, but it did not work either. What's interesting is that it seems to be sending the ECU id during the init. None of the other programs asked for the ECU id.

The problem I'm seeing with the init may be related to the TTL-232. These programs are all designed for true serial ports and are setting the odd baud rates through windows' control of the UART. I'm not sure if it's having trouble doing that with the TTL-232 USB "software" serial port.
Maybe I'll have to tell the software to use my modified .inf file baud rates instead. IE: I'd tell it to use 110 and 57600, knowing they were actually set for 5 and 10,400.


__________________


Veteran Member

Status: Offline
Posts: 74
Date:



-- Edited by ffaspector on Sunday 18th of October 2009 03:00:44 AM

__________________


Guru

Status: Offline
Posts: 2338
Date:

ffaspector wrote:

I'm not really into this stuff anymore, but I'm always happy to see people making progress.

Just thought I'd offer, I have a serial ELM interface that I never use. Up for grabs, cost of shipping. :)


If that is ELM 327 which supports KWP2000  I a happy to refund the postage (over paypal) when you send it to Gadget.



__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Senior Member

Status: Offline
Posts: 123
Date:

That's very generous of both of you.

ffaspector, if you're not using it I could make use of it while we're experimenting with the SDS. Should you ever need it back though, just let me know and I'll return it to you. Sound okay?

PetriK, I appreciate your offer but it's only right that I pay for the shipping. Besides, in the 3 minutes you save not sending a Paypal, you could be doing something much more important - like hacking!

__________________


Veteran Member

Status: Offline
Posts: 74
Date:



-- Edited by ffaspector on Sunday 18th of October 2009 03:04:21 AM

__________________


Senior Member

Status: Offline
Posts: 123
Date:

According to the datasheet, the lowest baud the TTL-232 can do is 182. That explains why the wake-up is not working. I imagine you can create an artificially slower byte send in software by holding the output low or high the required milliseconds for each bit, but we won't be able to hear the 0x55 ack from the ECU. I guess we can do without that though.

If I stick to 10,400 baud, the timing on the 00110011 wake-up packet needs to be 2,080 times longer to to simulate 5 baud. That plus a start bit. So, I think I need to send:
2,080 bit 0's
4,160 bit 1's
4,160 bit 0's
4,160 bit 1's
4,160 bit 0's

That is, if I can figure out how to send bits with VB...


-- Edited by Gadget at 01:14, 2009-03-12

__________________


Senior Member

Status: Offline
Posts: 123
Date:

Misconceptions -

All this time I've been thinking that 0x33 was the universal wake up byte for KWP2000. It turns out to be the device ID of the device used in the text which explained how to do this. Ours is 0x12.

In slow init, this is sent at 5 baud. The Alpha software uses slow init, that's why it asks for the device ID. The Alpha software will not work for us though, even if we did connect because all of its controls send commands to destination 0x10. Our ECU's are not going to respond to them.

Fast init is easier as it only requires a single 00 character for 25ms, but that's 40 baud and is still too slow for the TTL-232.

The VAG-COM software is sending A5 once it gets up to 10,400, rather than a string of hex characters. I'm not sure what it's hoping to communicate with by sending that.



__________________


Guru

Status: Offline
Posts: 963
Date:

Gadget, up thread you gave a sample timing diagram for initialization from a spec. Did you ever actually confirm with a scope that this is what your SDS box is using?

It sounds like what you need to send for a fast init is what as known as a Break Sequence.

A break is the opposite of idle. It is holding the line low for more than one character length to get the devices attention and cause it to reset all its conditions if by nothing else causing a framing error, a start with no stop. BTW break is part of the 232 spec, not an OBD anything spec.

If they are using a break I'm betting the 25mS isn't critical

Another idea is since you have to make a custom circuit anyway is make one were you set up a logical AND gate with the RTS line. This way normally the K-Line is whatever the TXd logic is but when you force the RTS a particular way it forces the K-Line into a break state. Then write some software to force a break via the RTS for 25mS

__________________


Guru

Status: Offline
Posts: 2338
Date:


...command 21 Read by Local ID following arguments are possibly at least on Busa.

0x90 ECU ID in first 6 bytes (Busa 15H00=0x3138534530305778 or Busa 15H10=0x4a313853453131710D) please see RR:s thread on checksum for more info on this arcument (http://www.activeboard.com/forum.spark?forumID=99460&p=3&topicID=26032122)

0xC0
word[0] = RPM
word[14] = system voltage
word[15] = gear

Quite many of the arguments previously listed seem not be supported induvidually.

Please note that above index is [dec values].

Gadget - are you already able to test/monitor these with your setup to figure out some more information. If you can identify e.g. TPS, Intake Pressure etc. all other AD parameters then it will tremendously help in disassembling the subroutines.





-- Edited by PetriK at 19:39, 2009-03-12

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Senior Member

Status: Offline
Posts: 123
Date:

I can read the data between the SDS and ECU, so if there's a command the SDS software will send, I can monitor the command sent and the result. The SDS software does not send allow you to send individual 21 commands, it sends a request for all sensors and then parses the result into what you asked it to show. Take a look at the 5th post from the bottom of page 1 of this thread for some of those results.

Does that answer your question? I can't get into X, so I'm not sure if that's what you're looking for.

RR, I didn't verify the wake-up comms, I just accepted what the swiftcom document explained. I was going to check it with the TTL-232 connection but couldn't because of the baud issue. I didn't think of the scope. I'll check it and let you know what I find.




-- Edited by Gadget at 20:27, 2009-03-12

__________________


Guru

Status: Offline
Posts: 2338
Date:

As per KWP2000 standard command 21 read by local id, positive response service id (0x61) is also implemented on K8/K9 Busa ecu, I would guess it applies to all SDS suzukis too including Bandits. (sorry if writing busa disassembly discoveries on bandit thread is intrusive - but I believe that we all benefit from understanding sds).

The way how I interpret the positive response service id return code at first glimpse is: 0x64 is returned if service is available. 0x10 is returned if service is not available. 0x32 and 0x46 I am not sure of. The standard may describe the validation messages better, I just looked the command syntax, not so much of the semantics.

Anyway the more the disassembly is verified against KWP2000 standard the more I start to believe that Suzuki is using KWP2000 - but this maybe a self fulfilling profecy of course.





__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 2338
Date:

Gadget wrote:

I can read the data between the SDS and ECU, so if there's a command the SDS software will send, I can monitor the command sent and the result. The SDS software does not send allow you to send individual 21 commands, it sends a request for all sensors and then parses the result into what you asked it to show. Take a look at the 5th post from the bottom of page 1 of this thread for some of those results.

Does that answer your question? I can't get into X, so I'm not sure if that's what you're looking for.


I am sorry, but with my limited understanding of the KWP2000 protocol can not read that log very well. I can see 0x61 but thats as far as I can get by reading that package. I can just guess that:
aa=RPM
bb=TPS
cc=IAP
dd=ECT
ee=IAT

But I am not sure how to read that example.

Throttle position sensor

80 F1 12 34 61 08 0C 05 05 E0 16 50 E0 FF FF FF FF 00 aa bb cc dd

ee FF 00 FF 00 FF 60 7C FF 00 00 00 00 00 00 00 00 FF FF 40 40 40

40 FF 00 FF FF 26 00 00 01 22 FF FF F1


EDIT - so if this assumption is right, then e.g. GPS should be [8] and clutch/neutral should be [20] but I have no means to test that.
EDIT2 - and when reading the code there seems to be some odd values in between, like packet boudaries or something else.

Please see the below picture with some numbers at the right for explanation.

dsd_sensors.jpg

 



-- Edited by PetriK at 21:03, 2009-03-12

-- Edited by PetriK at 21:09, 2009-03-12

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom

«First  <  1 2 3 4 5  >  Last»  | Page of 5  sorted by
 
Quick Reply

Please log in to post quick replies.

Tweet this page Post to Digg Post to Del.icio.us


Create your own FREE Forum
Report Abuse
Powered by ActiveBoard