More uses for SSM2

[cdvma]

I'd like to start a discussion on more uses for SSM2 than just reading and writing ROM or datalogging. There is the ability for technitians to do things like cycle the ABS pump ect that would be great for do-it-yourself-ers. Does anyone have information on these commands or ideas on how to go about discovering them?

[cboles]

The best way to go about this would be to befriend a technician with a SSM and "listen in" with an OpenPort while their device talks to the ABS control unit.

[cdvma]

Yea I always wanted to be able to use a serial Y-cable and just record the communication but I don't know anyone even remotely with one of them.

[Hitokiri]

could you write a program that uses two comm ports and passes the data through?? You could assuming that there isn't any baud rate switching that you couldn't anticipate.

I have a usb serial adaptor that has an awsome raw viewer that came with it. , but thats not really going to help.. Helps with other sniffing though.

[Spiider]

Can't you just use PORTMON?

[cdvma]

Just get a Y serial cable and put diodes on the TX ports of the "spy" end. No complicated software or anything like that. Run a program that dumps the transmission to a file or just use HypterTerm logging.

Hard part is finding a SSM!

[Spiider]

"Portmon" is free and records everything coming and going on any port you select to monitor.

Including rate changes, and what exactly is sent where.

[cboles]

I love portmon, but it is not very useful in this case since the SSM is not Windows based. Basically, you connect an OpenPort to the K-line of the car and write an app to listen in on the communications. The app needs to know what baud rate to listen at and notice when the baud rate changes (if at all). I usually start with a scope to pick off the baud rate and which character sequences precede baud rate changes, and then customize my app to listen to the protocol.

[Spiider]

Hmmm, I guess you are right the SSM2 is the older handheld.

I hear that the dealerships are getting the new pc based SSM3 though if some don't have it already.

[cboles]

That would make things easier!

[cdvma]

Its also possible to pull trouble codes via SSM, right? Leads on this end?

[calvinc]

DTC addresses in the attached txt file. i dont know yet which are current and which are historical.

calvin.

[cdvma]

I'll play with it and I have a list of which are current and which are historical in my ECU currently. I'll post my results.

[cdvma]

Ok so I executed a normal read (command A8) on the addresses posted in the DTC file above by cboles. I have currently 1 active trouble code P0102 which is MAF low input (a problem with the new UTEC firmware). I also have multiple historic codes (misfires on all 4...side effect of large injectors...and other codes). I got one responce from the ECU out of all addresses. Below is what I sent and what I got back.

80, 10, F0, 5, A8, 0, 0, 0, 8E, BB
80, F0, 10, 2, E8, 0, 6A

Thoughts?

[crazymikie]

Hi Chris-

How goes it?

I've played around with this a bit a while ago- I was going to see if I could remove teh CELs from the ROM, but I've gotten involved with too much other stuff and never got that far.

In any case, as you poll the trouble codes, you will get either a '0' as the value or a non-zero value, meaning there is a CEL at that location. I would have to dig the logs off of my laptop to remember exactly what is going on.

I think this means that whatever cell is represented by the SSM code 0x00008E is not thrown. I don't know if this is any use to you, however, there was a logger posted here that I modified to scan through SSM addresses:

http://mikeschear.com/SSM/logger_PROBE5.c

You just put in a starting address and it will read from that point on. It requires cygwin, though- I never figured out how to get it running natively under windows *sigh*

If only I had more time.....