Grey&Black Sub

Hello,

First, excuse-me for my poor english,
I've found that :
"The Subaru Service Manual (Impreza) listed the pins as:
Pin 1 - Power Supply
Pin 4 - Subaru Select Monitor Signal (ECM to Monitor)*
Pin 5 - Subaru Select Monitor Signal (Monitor to ECM)*
Pin 6 - Subaru Select Monitor clock*"
here :
http://groups.google.fr/groups?q=subaru+select+monitor&hl=fr&lr=&ie=UTF-8&selm=3BF5C442.1FA61789%40earthlink.com&rnum=2

Someone could explain me the role of the Pin 6 (Subaru Select Monitor clock) ?

Thanks.

AndrewC

Grey&Black Sub

I have not looked at a later car, however, on my MY98 pin '6' is empty. The Select Monitor can be read without so I am afraid I cannot comment on its purpose.

Also Subaru's pin numbering whilst being correct from a visual perspective (ie. counting left to right / top to bottom) is the reverse of the OBD standard as the Subaru socket is installed upside down!

Andrew...

totochris06

So nobody has find how select monitor works on my 99 and 00 ????
You all have < my 98 ????

I wonder the purpose of this pin 6 ....


HELP !!! ;-)

Chris

ScoobyDuck

iTrader: (1)

Chris,

I think on 98's they use the ODB plug, but it's still the select monitor. but after that, the ODB plug is PROPER ODB language, so it talks like any other car in the world should! So any gerneric ODB program will read from it. see somewhere like Andys Page for a bit more info (quite good page!)

This is the offical (as it gets!) page.

Steve.

totochris06

Steve, thanks for this very interesting link !

But in fact in Europe cars are not obd2 compliant before my01 ! So it's impossible (in my mind !) that select monitor uses obd protocol. I think there is a difference of protocol between 98 and 99 but always on pin 4 and 5 ! I heard that new protocol is faster. No ideas ????

Chris

P.S. : sorry for my bad english, i'm french ! ;-)

AndrewC

Sorry I haven't looked at this thread for a while (too busy decoding my ECU),

The physical connection between the Select Monitor and the 'OBD2' socket is identical between 98 and 99 cars, whether the parameters are in the same places I am not sure, however, the logs that myself and Steve are now producing from our 97/98 cars are very similar to what is being posted by people using DeltaDash.

The select protocol is faster than OBD2 on Scoobs but I don't think it is any faster on the Phase 2 engines.

AFAIK the Select Monitor still uses the proprietory protocol not OBD2.

Andrew...

Pavlo

I finally started to get some sensible info out of the select monitor last night. I will borrow lap top from work to continue doing it sensibly.

How are you getting on with the decoding? Are you looking for maps and so on, or looking for engine info output?

Paul

AndrewC

Paul,

Currently we (Steve and I) are just looking for monitoring info, although we have found virtually everything we want, we're just short of some of the conversions at the moment (Ignition Point Correction and A/F Correction to be precise) and a few of the switch locations (we have the addresses just need to confirm individual flags).

I have not debugged the code just done a lot of logging and piecing bits of information together.

Once I have all this done and finished my in car display, I will find and analyse the maps and possibly make an EPROM board, although I know that you are involved in doing that for the early cars at the moment, which I assume means that you have already found and analysed the maps?

Andrew...

Pavlo

Maps found. currently about 3 small maps unidentified, probably for water temp fuel enrichment etc.

If you had a dump of the rom image, it would be quite easy to figure out what was what now, especially as I know what to look for.

I should be recieving an eprom emulator this week, which means I can increment values on the fly.

Data logging is something I need to develop to be able to map a car effectively.

If you want to monitor a number of different addresses, is the easiest way to send a read then stop, for each memory address? I haven't played much yet. I wonder what happens if you send a read and stop in one go?

Have you done anything to synchonise between sending read command and reading data?

Paul

AndrewC

Paul,

The way I am doing it is to send a read command for a range of addresses, read the relevant number of bytes and then send a stop command before sending another read command for a different address range. This is the most reliable way I have found. The ECU starts sending data as soon as it receives the last byte of the read command and stops sending as soon as it receives the stop commands, however, I have found a problem if there is not at least a 10ms delay between the stop command and the next read command.

I keep meaning to dump the maps (8000h->8fff ?) and code (9000h->FFFFh ?) and send it too you, but haven't had the chance.

What format do the images need to be in?

Andrew...

ScoobyDuck

iTrader: (1)

Paul,

Im my program I send a read command, address, then number of bytes and my program wait for the reply & matches the 1st 2 bytes to make sure they are the same as requested, then takes the next bytes ( & the rest ,if any) as data.
then it logs it (if turned on) or displays it graphicly - which I'm working on at the mo (well - not now as I'm at work ! DOH!)

the main problem is if you want REVs, @0x0007h and say Boost, @ 0x0020h. this makes it akward, as you either have to say

READ REVS
STOP
READ BOOST
STOP

and repeat, or get the whole range from 7 -> 20 .. which slows things down A LOT! (not done any workings out including 10ms delays etc etc.)

my program is going to get most data all in one go and display it. Refresh wont be amazinly fast, but if you want to explicitly monitor one in particular, then you can (as you know as you've seen the basis of the program already!)

Like Andrew, I'm mainly interested in some kind of electronic readout device that will display things on an LCD in-car all the time. more of a gaget really. something Scoobys are missing! (usually coz they get thrown round the car on cornering! ;-) )

But I also want a DeltaDash type equivilant for PRE flashable ECU's. which at the moment - doesnt exist, apart from at your local dealer ! :-(

Mapping and the EPROM daughter board thing is a little bit scarey for me - dont think I'd trust letting my programming loose on my cars critical fueling maps etc!
haven even worked out the courage (or knowledge) to use the WRITE command with the SELECT PORT. I wonder what would happen if you wrote a 1 to the cooling fans flag ?!?!

Steve

[Edited by ScoobyDuck - 7/16/2002 5:36:36 PM]

AndrewC

I wouldn't worry about the cooling fan, what about the Knock indicator, you could hole a piston without even starting the engine!

Andrew...

PS. Steve, have you got the latest Email I sent you?

ScoobyDuck

iTrader: (1)

Andrew,

yes m8. . got it when I got home .. cant read those emails at work. can only post on ScoobyNet.
Very interesting & I agree with most of it & good work too!

hve done NOTHING to my setup AT-ALL. been doing too much other stuff - all dull of-course!

The trouble I have with my setup is that I cant get enuf control over the Comms. all I get is 'told' when a character arrives & then have to reliquish control to Windoze once again.. so I'm for ever going back into the same piece of code - which makes it a bit messy!

I need to tidy my program up a bit & get more of the data & logging shown right, mayb writing it out as already converted CSV as well.

then make it do graphs real-time (well -sort of!) for things like speed&revs&boost etc etc ... but that's a bit more complex !

As I said - will return a better email than my return to yours later!

ttfn
Steve

Pavlo

I started to play with labview now. I can send read commands, and it spews back the results. With the basic example VIs (program in Labview speak) the read will only read a certain number of bytes then stop (according the com debugger).

I am wondering if the VI set the com port not to receive.

Anyway, I can do a lot more, just need to get into it, as I've never programmed for serial comms before.

I know what you mean about the messy reads Andrew, just wondered if you found it easier to read blocks of memory or not.

I think if you can set up option channels to log, then the smart thing to do is work out the quickest way to read the memory depending on the combination of adresses. But thinking about it, even blocks of memory reads spew back each individual address.

My other complication is buffers I think. At the momeny, if I send a read command, and set the port to read only 3 bytes, I get a different response each time. I think I am reading bits of previous reads still in the buffer, but the example programs run at a high level, whereas i will have much more control once I use the base functions.

Enough rambling.

Paul

David_Wallis

never really done serial port stuff.. but can you not just have one process listening on the serial port and then pass this data where ever and possibly have another thread processing and another writing??

Is the serial port sycronous? (its late, and ive been drinking stella (normally drink bitter or spirits or both )

David

ScoobyDuck

iTrader: (1)

Paul,

I think what you need is to
a) clear the buffer as soon as you send a new command,
or better still
b) look for the address bytes comming back after u've sent a READ, then that way you will discard any data that the ECU _may_ be still sending out from a previous command (if you havent STOP'ed - which u DONT have to do ! )

or just thought of another combination..

Send a STOP, clear buffer. then READ. that way the data you do get back should be ok... but only working it out & testing it will tell !
good luck!

Steve

Pavlo

I played around a bit further. I realised you can send a read command, then just read info from the serial port buffer as long as you like.

The problem is in a constant stream of data, how do you pick out the address? I think your idea of using the address from the read command is currently the best.

I can check the buffer to see how many bytes are remaining, generally I can do:

Send READ command
Read DATA from serial port buffer.
Send STOP command
Measure data in buffer, read all data (clears the buffer).

I think the best way is possibly to send a READ, then wait some small time, send the STOP, and thatway the buffer wont get too full of crap.

Other thing I noticed, is the 94-96 ecu doesn't seem to let you read blocks of data, I always get a single byte of data, regardless of the 4th byte, but I do have to sent a 4th byte.

I also checked a couple of addresses from the Koshi site, and they seem to check out. When I read a manifold pressure, it seems to be in mmHg/8 as I read 5Dh without engine running which would be 744mmHg, or just a little under standard atmospheric. I will confirm with a pressure gauge and syringe a bit later.

Paul

AndrewC

As I am using a uController to do all the low level stuff I have approached this slightly differently.

My code reads different sized blocks of memory from different locations based on a 'MAP' held in the uC EEPROM area, this allows me to optimise the reads. What is sent out on the RS232 port (at 19200bps) is a stream of comma separated Hex Codes.

for each memory block
get A and N from eeprom
send read command for address A and bytes N
read N+2 bytes (includes address)
send stop command
print N bytes (excludes address) on rs232
next

I do not bother checking the returned address against the requested address and so far I have not had any problems whatsoever.

What monitoring rate do we think is required, I am currently managing to read 26 addresses 5 times per second.

Andrew...

David_Wallis

that sounds pretty quick to me

ScoobyDuck

iTrader: (1)

Paul / Andrew /David / everyone !

the only reason I read & check the values is so that I know that when I've asked for data I get what I ask for back. I could just do a stop. clear buffer, READ & then discard the top 2 bytes (as Andrew does! although he doesnt have buffers to mess with!)

the buffer thing is anoying! I like to be in control a bit more. makes it easier for programming and timing too. you send a read, you know you're gona get 2 bytes - so loop until you do, then the rest N bytes is data & you can then sort / send that. then send a STOP.

my program just interrupts when a charater is received on the serial port. and due to windoze and its crappy timing that could be 1 byte, or 3, or 15, or MORE !
not sure what data rate I'm getting, but should be the same.
(I generally get 07-20h out in a block so thats 25 bytes. not sure how many times a second...but, unless I'm missing some - which I'm not, then should be exactly as fast. just depends on how fast windoze can process it all !)

as for >96 ecu's, they might be different! the addresses on that web site dont work for me and Andrew. hence we've had to work/find them all ourselves!

I can only read 127 bytes in one go. any more and the ecu then stops the data stream. you can get 127 to continuously send, but no more ! (must be an internal buffer / register restriction !)

think that's about all for now... roll on developement time (distinctly lacking in my case ! )

Steve

David_Wallis

what you doing your development in?? I can possibly help you there..

David

Pavlo

The buffer problem is annoing in windows, especially as you can never realy know when the data was received.

The uController idea might be worth doing in the future, especially if it's possible to log into the controller, and download to a desktop PC.

Anyway, I will have a go at trying to read individual values one at a time, using a STOP after a delay of Xms.

Paul

Pavlo

Okay, this is what I came up with that works

Send READ
Wait 25ms
Send STOP
Wait 12ms
Read Buffer, and there is always 3 bytes waiting for me.

If the serial port is asynchronous, can't read and write at the same time, and I need to send 4 bytes and recieve 3, thats 7bytes, each byte is 11bits (8 + 2parity + 1stop) giving 39.4ms. I think this is about right, seeing as the program will take a while to execute.

So the rest is easy, I can create address lists, and get it to string the read commands together, strip out the memory address as it reads (check them against requested address to be safe), and convert data to real numbers.

So it seems quite easy on the face of it.

Paul

Pavlo

okay, just managed to dump whole sections of the rom to disk.

Pushed the timings out to 25ms wait after a read 13ms wait after a stop and 13ms wait after next read after I noticed errors on streams of data.

Next step for rom dump is to put it in an error checked DO loop rather than a FOR loop. Use DO loop to check data received is 3 bytes long, and memory address returned is that requested, if not do it all again.

Paul

Pavlo

Had another go last night, almost got it finished before TV time.

Got it to check that there are 3 bytes in buffer, and that the first 2 are the address, otherwise read again.

This should allow 100% accuracy in reading the whole standard ROM.

However, during the waits, I am sure I could be reading the buffer from the previous read request, this should speed it up by at least 50%. Any pointers?

Paul

Nexxxus

Hi!

I have posted MY97 parameter addresses on my website
http://subaru.piim.ee/ecu_parameters.phtml

If u have additions PLEASE email me...
(Also for other MY?? models)

Nexxxus

ScoobyDuck

iTrader: (1)

Nexxxus,

We've got all our addressed at 0x0007 and up. Although we have found that there are similar ones in the ranges that you use!

How did u work out those addresses? is that what the Select Monitor actual device uses ???

Steve

Nexxxus

Yes those are the addresses i got from analyzing
communication routine between ECU and SelectMonitor
device.

Because i had SelectMonitor only for 10 minutes,
i dont know much more. Debugging ECU still takes time...

Can u please send me private email about the addresses
u have found?

Illimar

Illimar@piim.ee

Grey&Black Sub

Yes, it's true Andrew, the Subaru socket is installed upside down. I have a MY99 and when i try to send a command on pin 5, Pin 4 does not answer, it remains with 5V. I wonder if i must do something on pin 6 ...



[Edited by Grey&Black Sub - 7/9/2002 4:20:01 PM]