Reverse engineering suzuki serial data line

[thatdevsherry]

Problem statement

EDIT: There has been success in communicating over SDL protocol! See post 17 for a video showcase.

I am not too happy on spending 1000-1500Rs each time I want to hook up a scanner to my baleno for getting live engine params.

Overview of interacting with ECU

Scoured through forums and it's pretty much clear that ELM327 chips cannot work with baleno.

There are two wires provided by suzuki in baleno:

• Serial Data Line (SDL) (Proprietary)
• ISO 9141 (k-line) (Open standard)

However, these two wires are both present only in ECU that uses O2 sensor. Mine is basic and has trimpot, so they use another ECU (mine is 33920-65GP), which only has SDL.

All would've been good if ISO 9141 wire was present. ELM327 and generic handheld scanners would've just worked fine.

So we only have one data wire i.e. Serial Data Line (SDL) coming from A3 (ECU) to pin 9 of J1962 (OBD) connector.

Expensive scanners are able to interface with the ECU on this proprietary protocol. Since there's no documentation, not sure if it's even possible to reverse engineer alone w/o having spare ECUs and a test bench to spend time on.

Some hope (sort of)

In old suzuki forums there was someone by the name "rhinoman" who created "rhinopower" and he had figured out the protocol and was able to extract live engine params. Sort of everything that the expensive scanners do. He had made his own hardware and software.

Hardware link has been dead.

Some differences about SDL and ISO 9141

• ISO 9141 works on 12V, SDL works on 5V
• ISO 9141 by standard is present on pin 7 of OBD, SDL is on pin 9
• ISO 9141 was not present in wiring diagram for immobilizer equipped baleno (like mine is)
• SDL is connected to ECU, ICM (immobilizer control module) and finally to pin 9 of obd, which is why expensive scanners can do immobilizer related actions since it's linked to ICM

Own assumptions and shenanigans

I have a feeling I won't be needing to build my own circuit or something. I had bought this weird cable called VAG KKL FTDI, which is made for audi, GM etc. Reason I still went ahead and ordered it is because it allows serial communication.

I couldn't have use wired ELM327 since it is an abstraction over open protocols. The only way I have a possibility of interacting with SDL is to get raw access to SDL wire. This cable seems to let me do just that.

But the cable works on pin 7 of OBD connector. There was nothing on pin 7. So I uh... yoinked SDL wire from pin 9 to pin 7.. in hope that the cable could communicate over the SDL wire. I have also ordered a 1 male - 2 female OBD extension in case I can read SDL wire data, I can try hooking up an expensive scanner and seeing what data is being sent back and forth.

I have yet to confirm that this even works. But opening this thread in case I go on a tangent idea e.g. making a breakout harness and reading ECU wire voltages and converting that to useful data.

[Hassan1991]

I have shared that many times. ELM327 with PIC controller works on every car. Why do you want to make custom hardware when a cheap controller does it for you?
Let me give you something that you aren't going to find online. Suzuki doesn't work on the generic OBD-II protocol, i.e., 01. It works on 21 and Single PID contains every sensor data. (Can be decoded.)
You can use any application as long as you initialize the communication. Every Android application lets you do that.
I haven't worked on the suzuki CAN bus yet; on local cars like new alto, wagonR and Swift. Other than that, I've been able to communicate with mostly every car. JDM Toyotas are also a pain to deal with.

[thatdevsherry]

Thank you for letting me know about this.

Could you elaborate a bit on this? As in how is the SDL protocol supported by ELM327?

I had tried with cheap obd scanners and didn't find any application to work with it.

Didn't know about modes until your reply. I'm guessing cheap scanners only support mode 01, and suzuki works with mode 21?

EDIT: I browsed through the forums. Will order an adapter that has the PIC chip. Current one displays "?" for AT command and "OBDII - RS232 interpreter" for "AT@1", which means it's a clone.

[Hassan1991]

After you get a PIC controller, ELM327.
Install car scanner obd2 application. In the connection profile you need to select either Grand vitara , XL7, Swift var.1 or 2. One of these will work. If it doesn't, let me know.
SZ-viewer application also works and picks more parameters than any other application.
If you want to get the same number of parameters in car scanner obd2, then you need to add them. Kind of difficult for a newbie. Because you need to get on the ELM terminal. Manually initialize the communication, send the PID, and then decode the complete response.
Cheap scanners have clone Chinese controllers that cannot communicate with K-Line but do work fine with CAN bus systems.

[thatdevsherry]

Got it. Ordered a PIC controller elm327.

Already have car scanner app installed as I've used it on other cars before.

SZ viewer was taken down by the author, but can still get an apk if need be.

I'm a software engineer so I'm interested in manually getting as much params as possible through ELM terminal and not being bound by a single app.

Is there a unique init sequence like I saw in forums for toyota? Also, do I need to rewire the SDL wire back to pin 9 as currently I had moved it to pin 7.

EIDT: You mentioned cheap chinese ones work only with CAN, but the adapter I currently have was using ISO 9141-2 to connect with honda city idsi. Isn't that also k-line?

[Hassan1991]

Sure. Get your hands on one. I will guide you through.
Yes rewire it back to oem.
Scanners tells you that as well.
Elm327 have AT commands. You can see which protocol is being used to connect. Get the manual of elm327.
Hondas are open. No initialisation required. Just send the pid and it will respond. Thats why it worked.

[TypeA]

[thatdevsherry]

So I got another scanner. Tried both vitara var 1 and 2. Did not connect.

Ran AT command (in car scanner terminal) and output was "?". Thought I got another chip. Opened it up and it has the PIC chip.

I'm not sure how ELM327 is supposed to work with SDL proprietary protocol. If it could've worked, it should've been talked about in the old suzuki threads

EDIT: maybe I should try to manually init. it.

EDIT 2: I tried manual init. for 9141 (also tried KWP2000) but couldn't get anything.

I'm not entirely confident elm327 has the capability of communicating over SDL. The last I saw on suzuki forums for this ECU and protocol, I had shared above. Biggest one being the non-standard 7812 baud rate which ELM327 does not support. And it doesn't have the other 9141 wire. So the SDL wire shouldn't work on 9141 as it's a separate wire which isn't present in this ecu.

[Hassan1991]

Install SZ viewer and see if it works.
If it doesn't, then the wiring isn't correct.
If it does go to the Car scanner obd2 > After selecting profile > Adapter setting > Advance settings > PID Command to Check > Write 2100 there.
In optimizations, select all options.
Uncheck " Use obd2 PIDs " .

You need to set the headers first. Then it will reply to 2100. Between 2101 is where all data will be.

[thatdevsherry]

Install SZ viewer and see if it works.

SZ Viewer wasn't able to connect with the wifi adapter. I also found out SZ viewer cannot work with SDL. Shown last.

If it does go to the Car scanner obd2 > After selecting profile > Adapter setting > Advance settings > PID Command to Check > Write 2100 there. In optimizations, select all options. Uncheck " Use obd2 PIDs " .

2100 already present.
2 optimizations were unchecked. Checked all.
Use obd2 PIDs was already unchecked.

If it doesn't, then the wiring isn't correct.

I appreciate your input, but this statement seems to be based on an assumption. The wiring is factory, as seen in the wiring diagram for immobilizer equipped vehicle.

A being baleno w/o o2 sensor i.e. trimpot present.

11 when viewed from harness side gives us SDL

As I mentioned in the first post, there are two variants of ECU in the car, with and without o2 sensor. The one with o2 sensor provides both SDL (pin 9) and ISO 9141 (pin 7).

What you're suggesting is to initialize 9141 communication (or any open protocol that ELM327 supports) over SDL, which doesn't make sense as it's a proprietary protocol. This comms is supposed to be done on pin 7 (9141) which is not present in this ECU variant, hence the reason for opening this thread to find a DIY solution for baleno.

This was also pointed out in an old forum as well referencing another manual.

Manual page

The wording of the page is not explicit. They're actually showing the 2 variants I discussed as seen by their ECM pinouts (o2 sensor variant has 3 rows). Hence missing to #7-pin data link connector wire from ECM.

O2 variant reference below showing 9141 and SDL as different protocols/wires.

I also saw a video of someone saying that ELM327 worked on their cultus and said it can work on baleno too. But if you look at their OBD pinout they have a k-line (9141) present at pin 7. Baleno (w/o o2) does not have any connection to pin 7, but pin 9 (SDL).

Even SZ Viewer says pin 9 (SDL) is unsupported.

If you have any reference for ELM327 working with the proprietary SDL protocol, I'd be interested in looking at that. But otherwise it is pretty clear ELM327 is not capable of communicating over the proprietary SDL protocol which is present in baleno (as I explained in first post and opening the thread to track my shenanigan with it).

[thatdevsherry]

Adding sources for info I'm gathering about the protocol.

The original Suzuki diagnostic interface used baud rates of 7812 and
15625 baud, these were used up to in North America and elsewhere up to
around 2001. This interface used pin 9 on the J1962 (OBD2) connector.

After that there were two different Suzuki protocols that used the 10400
baud rate, both of these used pin 7 on the J1962 connector.

ECUs used by The OBD2 Suzukis sold in the US between 1996 and around 2003 had a Suzuki proprietary protocol that used the same ISO 9141-2
interface that they used for OBD2, this was known as SDLJ1979.

From around 2001 onwards in markets that weren't OBD2 or EOBD there was a Suzuki proprietary protocol similar to KWP2000 called SDLKWP.

^ link

I've gone down a rabbit hole. Someone linked rhinoman's website in web.archive and I'm trying to browse through it. Got some basic info on SDL but looking for more.

[Hassan1991]

SDL is not a protocol; it's just a pin.
SZ viewer does connects with wifi obd2 scanner.
Your car works on one line communication which is K-line. Find it's wire and connect it to the pin of obd2. There's also a way of communication called as L line. Some cars have both.

[thatdevsherry]

SDL is not a protocol; it's just a pin.

I literally shared a screenshot from SZ viewer saying "SDL protocol". Yes it's a different pin, but it also is a different protocol. Call it a protocol, interface whatever. It's all of those. Saying it's not that is blatantly wrong. SZ Viewer supports the protocol that came after SDL which was SDL/KWP, but not SDL itself.

SDL/KWP is present on pin 7, which SZ viewer supports. In other words, all protocols after SDL used pin 7. Only SDL used pin 9. In some newer variants there were both SDL (pin 9) and an open k-line (pin 7), just like in the baleno variant with o2 sensor.

SZ viewer does connects with wifi obd2 scanner.

It does. I meant it wasn't able to connect to mine. I also have the SZ viewer linux variant installed which I'll also test out (and am confident it will not work as SDL is not supported).

The SDL is also k-line. It connects b/w ICM and ECM. I was able to read initial communication b/w ICM and ECM when key was moved to ignition ON. SDL is also bi-directional one-wire interface.

Your car works on one line communication which is K-line. Find it's wire and connect it to the pin of obd2. There's also a way of communication called as L line. Some cars have both.

My man you're going on a tangent. I shared entire diagrams for the ECM wiring. ECU of baleno w/o o2 sensor does not provide the ISO 9141-2/SDL-KWP protocol wire (12V). Only SDL is provided. Nothing more. No other K-line. No L-line. No oh-ping-me-i-work-with-elm327 line. I can't connect a wire out of thin air, as much as I want that to be true. We only have the SDL wire to interact with.

I'm actively researching/working on this. Please present valid evidence with your claims like I'm doing. Perhaps we'll figure it out together

[thatdevsherry]

Good update (sort of)

So I didn't want to keep rewiring pin-7 and pin-9 of the obd port back and forth for testing with the VAG KKL FTDI cable (which works on pin-7). I had ordered a 1-male to 2-female obd adapter which I received. I swapped the wires of pin-7 and pin-9 in one of the female connectors which I'd connect to VAG KKL cable.

I tested out my setup:

OBD port <-> (male side of extension) <-> VAG KKL cable <-> laptop
                                      <-> unused (for hooking exp. scanner)

I had found the SDL structure and a table (not of baleno) but it felt like it should work for me. I requested a few params and got data from ECU!

So there was some progress. The data felt good but it seemed to be invalid sometimes because sometimes it requires calculation etc.

The main reason for getting the male to 2 female extension was so I could connect an expensive scanner on the other female port and then passively listen on the SDL line and see what data is being sent between scanner and ECU. Professionals that tried to decode it before had a bench rig setup and they could keep all params constant except one and figure out which obd address changed what. I have to go by what's present on internet.

If I'm able to send individual values from scanner (e.g. selecting show RPM only), I should be able to see the data going back and forth and figure out which one is going from scanner, and then see what data is being sent by ECU, and the actual value being displayed on scanner to figure out the calculation.

End of yapping.

EDIT: documenting in detail here

[thatdevsherry]

another good update

The forums and pages I scoured told me that the number of obd parameters you can query on SDL depends on ECU. From 1 to max of 8.

I was coding it up and got issue where i would request/response fast and it sometimes failed.

I had written up code to send X amount of parameters in a single request. I thought I'd try that for fun and see if ECU responds or dies. It responded with all!

Basically from my knowledge there are total of 32 parameters that we can query. I queried them all (0-31) and not knowing maths and stuff, I just used reference values from the expensive scanner I had hooked up some time ago.

e.g. desired idle on expensive scanner at warm engine was 706, the value ECU responds with for it was 90. So I just did scale = 706/90 and then 90 * scale gives desired idle

jugaar style reverse engineering. Although not accurate because some calculations require division etc and I can't just derive a scale value and call it a day. Actual calculations need to be found out somehow. If I had a schematic of my ECU maybe I could somehow figure it out.

I learned that the ECU on SDL does not really provide separate parameters for say AC switch ON, PSP on etc. They're all shown by a single parameter and depending on the permutation of things on/off it shows a number. Spent time going over each permutation to try and figure it out.

Progress

• (Working) Radiator fan (ON/OFF)
• (Working) Engine speed (calculation not SUPER accurate but it should be with error of +-25, will see how to confirm from expensive scanner)
• (Working) Desired idle
• (N/A) (STFT, LTFT, Current FT) value stays 0.0% as car is w/o o2 sensor variant
• (Raw value) Ignition timing, need to confirm if the value is actually BTDC degrees. Seems to be.
• (Raw value) Coolant temp
• (Raw value) Intake air temp
• (Raw value) Vehicle speed (need to confirm as i did not drive and see if value changes)
• (umm) Battery voltage. I mean I know exp. scanner reads 14V at idle, I can do the 14/(raw) like desired idle. Will confirm as I have range 12.6-14V
• (Raw value) MAP
• (Raw value) Unknown. Seems to fluctuate at idle and revs. Seems like a sensor. Currently it's unknown what it is
  ...

I'll go by the scan tool data present in the manual. Most of it has to be calculated from obd params so I'll make a checklist for that as well.

Tracking parity with AUTEL scanner here.

[thatdevsherry]

Things have been going in positive direction.

I was able to extract out a few params that weren't being shown on AUTEL (ac switch, radiator switch).

However some I don't seem to be getting (blower motor electric load switch).

I was not too confident changing code and then having to go to car to verify, so I wrote an ecu SDL simulator alongside so I could easily test out that my code actually works.

It became a real help because I could fix all params and only change one, then verify that the processed value looks ok.

Then being concerned about not getting few params that AUTEL did get, I got an idea which I'll test out sometime soon.

Idea being, i have the obd extension cable that I initially bought so I could passively listen and see what scanner and ecu comms looks like.

But what if, I turn off car totally (obd will still be powered), connect AUTEL scanner and then my laptop on other, and then run my simulator to act as the ecu.

The SDL protocol doesn't have any initialization and straight up returns responses to valid messages.

If AUTEL also goes straight to sending the request messages, my simulator should work with it. I could then freeze and change values and see what processed value AUTEL shows. or let my simulator die or alert me if AUTEL was querying a param I did not handle.

I maybe can then figure out if it's querying a param I was missing, and also throw any raw value i want to see RAW - PROCESSED relation to maybe help with figuring out calculations.

[thatdevsherry]

sdl scanner prototype in action.

temp reading verification using radiator fan

[thatdevsherry]

I was able to sniff the ecu comms with expensive scanner and figured out the following messages:

• ISC actuation test (change desired idle from 500 - 1800) (big help when adjusting base idle)
• Fixed spark test (lock ecu ignition advance to 5 btdc)

[thatdevsherry]

So my theory of hooking up scanner with my simulator has not yet worked out so well.

I'm able to communicate, but the scanner seems to send some weird messages that it does not send when I'm passively listening b/w the scanner and ECU comms.

Spent about an hour fiddling with it to get it to communicate with ECU and send fixed values, but all I got was me getting soaked in my sweat. Was a hot day and I was determined. But today was not it.

The gist was that there were some "invalid" messages that the scanner was sending. e.g.

scanner: hello, i am sending a message which has 3 letters

my sim: oki got it. *chomps*.  yup thats right. data is "WOW"

scanner: ok here's a another message which is also 3 letters.

my sim: noice. *chom-*. WUT???? data is "HELL". WHAAAA-
my sim: ok lemme read ahead what's next
my sim: oh next up was "O {next msg}". Oh so msg was "Hello", not "Hell".

SCANNER LIED about the length!

Similarly, scanner just randomly decides to send zeros without a checksum (a byte I use to know I got the right message).

It never does that when communicating with ECU. So not sure what to do with it. Maybe I need to set some delays because I could see the scanner querying A LOT of stuff (which includes the above weird crap), and since my simulator had no delay, it would respond in mere milliseconds. Will have to add some delays to make it realistic or something.

However some progress I got was that I eyeballed the data going back and forth b/w scanner and ECU and my prototype queries all 31 fields in a single message, while scanner queries I believe around 8 per message (not confirmed but it's near that number).

So that was not good because I don't really know which byte in the 8 bytes of the message corresponds to which parameter.

BUT, my hunch was right that selecting, say only 1 parameter and telling scanner to "Show selected" makes it query only those parameters. So e.g. I already knew engine rpm is made up of 2 param values, and selecting "Engine Speed" in scanner, I could see the scanner querying 2 obd addresses, while say for vehicle speed it queries only one.

So I went ahead and selected only 1 of the parameters and logged the communication going back and forth. Repeated with each parameter that works for my car.

This way I'm able to at least confirm which obd address is for what parameter. I can get rid of the "UNKNOWN_PARAM_X" from my code with this. I didn't bother logging the dead params that my car doesn't have (like oxygen sensor etc), only the ones I could see moving (or that the ecu can change in my car).

Helps me because I know the value I see in X address is for Y parameter. Will have to figure out calculation by trial though.