Gm bcm and cluster can bus messages through eml327 script

[kur4o]

A question for the elm gurus.

Is it possible to configure elm to send data with 7e0 header and get responses with 5e8 header. 7e0 can be formatted or not formated, 5e8 will always be unformatted.

[ironduke]

A question for the elm gurus.

Is it possible to configure elm to send data with 7e0 header and get responses with 5e8 header. 7e0 can be formatted or not formated, 5e8 will always be unformatted.

Yes..
atz // r eset
atsh7e0 // set header.. if you don't it'll still work sending the 7df
atcaf0 // turn off can formatting
atcm5e8 // set can mask
then you can send 03a981da for dtc request and get data back.. Below is the termite log..

>atz


ELM327 v1.3a

>atcaf0
OK

>atcm5e8
OK

>03a981da
81 01 07 00 6F 00 00 00
81 01 22 00 DB 00 00 00
81 02 23 00 DB 00 00 00
81 02 30 00 6F 00 00 00
81 03 15 00 FF 00 00 00
81 04 49 00 FF 00 00 00
81 04 52 00 6F 00 00 00
81 04 63 00 6F 00 00 00
81 06 15 00 7F 00 00 00
81 16 82 00 FF 00 00 00
81 21 22 00 DB 00 00 00
81 21 27 00 DB 00 00 00
81 24 32 00 6F 00 00 00
81 C1 01 00 6F 00 00 00
81 C1 40 00 7F 00 00 00
81 00 00 00 FF 00 00 00

This is my log with a gm mdi..

09:31.395 : 7DF03A981DA00000000
09:31.412 : 5E8810107006F000000
09:31.425 : 5E881012200DB000000
09:31.438 : 5E881022300DB000000
09:31.450 : 5E8810230006F000000
09:31.462 : 5E881031500FF000000
09:31.475 : 5E881044900FF000000
09:31.488 : 5E8810452006F000000
09:31.500 : 5E8810463006F000000
09:31.512 : 5E8810615007F000000
09:31.525 : 5E881168200FF000000
09:31.537 : 5E881212200DB000000
09:31.550 : 5E881212700DB000000
09:31.562 : 5E8812432006F000000
09:31.575 : 5E881C101006F000000
09:31.587 : 5E881C140007F000000
09:31.600 : 5E881000000FF000000

[kur4o]

Thanks ironduke,

Tested on obdlink device, will test it generic fake elm crap later.
Initial testing proved that it will work that way, opening some limited high speed Can logging with elm.
Now I need to figure how to set a little longer messages for initial pid configuration.
With current formatting turned off, will elm respond with 30 and take second message, or I need extra settings. Initial configuration will use 7e0-7e8 node.

[ironduke]

Thanks ironduke,

Tested on obdlink device, will test it generic fake elm crap later.
Initial testing proved that it will work that way, opening some limited high speed Can logging with elm.
Now I need to figure how to set a little longer messages for initial pid configuration.
With current formatting turned off, will elm respond with 30 and take second message, or I need extra settings. Initial configuration will use 7e0-7e8 node.

Biggest problem with the elm is the baud rate is 38,400 or 115,200 baud by default.
Some of them can do 500,000 but out of 4 elm devices I have one that can do 500,000. USB plug in elm, none of the bluetooth ones are remotely capable.

If you turn off can formatting BUT have flow control on(by default) you can send a 021a90 and the elm will send the 30 reponse to the ecm for you.
below is the termite log.
ELM327 v1.3a
>atz
ELM327 v1.3a
>atcaf0
OK
>021a90
10 13 5A 90 31 47 31 5A
21 42 35 45 42 33 41 46
22 31 30 30 36 31 32 AA

below is the mdi log.

00:11.390 : 7DF021A900000000000
00:11.392 : 7E810135A903147315A
00:11.393 : 7E03000000000000000
00:11.399 : 7E82142354542334146
00:11.405 : 7E822313030363132AA

Sending multiline messages is possible with can flow control turned on. Just tried it.. originally my code had it turned off but it does make for a pain receiving multiline since my code had to inject the 30..
so.
atz // reset
atsp6 // set canbus com pin 6&14
atcaf0 // can formatting off..
After that setup you can either request something like the vin with 021a90 or program the vin with a multiline vin write command..

If you have can formatting turned on you can request the vin but the multiline write command failes..

[kur4o]

Success,

>10 0a 2C FE 13 1F 00 44
7E830000A

>21 32 98 11 23
7E8026CFEAAAAAAAAAA

This was done with manual entering commands, So timing can take some punishment.

With longer messages, where you need to send some on a row, some specific settings will be needed to tell elm it won`t expect an response.

Receiving long messages is definitely better with formatting on, even that on very long ones there is buffer full error, so it is not good for pcm reading.
But for configuration I need only sending long ones.

I think 115000 baud will be sufficient enough for some logging, since bus load is not that much during logging, for raw bus log is out of questions, I got buffer full error almost immediately. Elm specify that the issue is pc-elm and not elm processing speed.

I do have one fake elm that is bluetooth only and is set at 500k baud, It is the newer design that runs for $5 on chinese crap sites, but it can`t do any other protocols[missing components] only CAN 6&14, Will make it suffer some now.

EDIT:
>10 14 2C FA 11 24 20 D4
7E830000A

>21 14 2C FA 11 24 20 D4
NO DATA

>22 14 2C FA 11 24 20 D4
7E8037F2C31AAAAAAAA
It seems to work with longer messages too.

Test are done with genuine obdlink device, bluetooth at 115000 baud, commands are manually send through a stn terminal.

[kur4o]

Chinese crap with 1.5a elm doesn`t want to play that nice. Everything seems to work unless I can`t send more than 4 bytes.
You can send multiline but the crap accept only 4 bytes and pad the other 4 with 00s, no matter formatted or unformatted.

Maybe it needs some settings, Will play with it later.

[ironduke]

Chinese crap with 1.5a elm doesn`t want to play that nice. Everything seems to work unless I can`t send more than 4 bytes.
You can send multiline but the crap accept only 4 bytes and pad the other 4 with 00s, no matter formatted or unformatted.

Maybe it needs some settings, Will play with it later.

Try logging what is being sent with the multi line commands..
With mine the first line starting with 10 gets sent ok. But the next ones that start with 21, then 22 and so on fail to send the first digit. I end up just sending an extra byte at the start of all the multi line messages.. say send 221 then message, then 222 and message, so on.. I forgot to mention that before, kind of surprised you have an elm that doesn’t need that, so far all of mine need that extra byte in front of the counter on the multi line.
For me at least the only way I could send multi line was to turn off can formatting.

[kur4o]

I did all kind of tests with the 1.5a
Upto 4 bytes, and they are send on bus without issues, if more than 4 bytes without header, the elm just echoes back and nothing get send on bus.

What I think is that the tool is made compliant to j1979 and nothing else. It reads perfectly multiline responses, it is just crippled to 4 bytes messages. There may be some settings but not found yet.

The one that work is an old genuine obdlink $100, so it is no wonder it works. On vpw it can take upto 3k long messages. But for CAN is not that good. I try to set it to send longer formatted messages but it gave me some errors. And not all commands are available. Some firmware upgrade may fix it.

[ironduke]

I did all kind of tests with the 1.5a
Upto 4 bytes, and they are send on bus without issues, if more than 4 bytes without header, the elm just echoes back and nothing get send on bus.

What I think is that the tool is made compliant to j1979 and nothing else. It reads perfectly multiline responses, it is just crippled to 4 bytes messages. There may be some settings but not found yet.

The one that work is an old genuine obdlink $100, so it is no wonder it works. On vpw it can take upto 3k long messages. But for CAN is not that good. I try to set it to send longer formatted messages but it gave me some errors. And not all commands are available. Some firmware upgrade may fix it.

I’m not sure I know what you mean by the 4 bytes? The first line of a multi line sends 4 bytes, right? Do you mean you can only send those 4 bytes? Do you mean the next lines you sent aren’t sent?
Edited… never mind. I went back and read the posts again.. now I know what you mean.. weird..

[MudDuck514]

Have any of you tried using a NON v1.5 ELM device?
My understanding is that ALL of the v1.5 devices are actually v1.0 (or 1.1) code.

Mike