I'm trying to construct a custom PID for my Ram promaster diesel (fiat ducato).
In OBD Auto Doctor (another android app), it reads egt1,2, and 4. When I did a test this morning it showed -7.3, -8, and -6.2 (C). This is ambient, engine was off so this is reasonable. I've checked it with engine running and it is reasonable then too. I can't read it with torque tho.
The standard PID for EGT is 0178, there are 9 bytes. https://en.wikipedia.org/wiki/OBD-II_PIDs#Mode_1_PID_78
using the equation: (((b*256)+c)/10)-40
Testing:
Result for equations: 2059.2
Command 0178
Response: 18daf110100B41780D014700
18daf1102100014001520000
This is from a screen shot of the test. It's possible the screenshot caught the data in the middle of an update?
I assume one of the data words is current and one is previous?
The response has 12 bytes. What are the extra 3? Is A the LSB, furthest to the right?
5200 decodes to 2059.2, what torque is showing.
0152, 0140, 0147 decode to values exactly, or very close to what it should be.
Quote from bradrh on February 26, 2015 ...
Response: 18daf110100B41780D014700
18daf1102100014001520000
This is from a screen shot of the test. It's possible the screenshot caught the data in the middle of an update?
I assume one of the data words is current and one is previous?
I'll answer some of my own questions. I don't think the screenshot caught it in the middle of an update, or current and previous. I checked again and they seem to be the same for the 1st 8 nibbles, but different thereafter. Note that I assumed that the screenshot wrapped the 1st data work, it actually looks like this:
Response: 18daf110100B41780
D014700
I made an extended PID csv file and loaded it and logged the data from bytes A through I. A is always 1, B is always 82 (0x52 hex).
"egta","egta","0178","A",0,256,"","" "egtb","egtb","0178","B",0,256,"","" "egtc","egtc","0178","C",0,256,"","" "egtd","egtd","0178","D",0,256,"","" "egte","egte","0178","E",0,256,"","" "egtf","egtf","0178","F",0,256,"","" "egtg","egtg","0178","G",0,256,"","" "egth","egth","0178","H",0,256,"","" "egti","egti","0178","I",0,256,"",""
What protocol is your vehicle using...
Your response may not be parsing correctly.
Can you find the variable which returns the
hex values beyond 41 78 in your response?
Response:
---------------------------------- v - v - v
18daf110 10 0B 41 78 0D 01 47 00
------------------v - v - v - v - v
18daf110 21 00 01 40 01 52 00 00
Multiframe response.
10 first frame?
21 second frame?
0B eleven data bytes following?
0D sensors supported binary 1101?
01 47 egt1?
00 00 egt2? (not supported?)
01 40 egt3?
01 52 egt4?
01 47 ... 327/10 ... 32.7 - 40 = -7.3°C = 18.86°F ?
01 40 ... 320/10 ... 32.0 - 40 = -8.0°C = 17.56°F ?
01 52 ... 338/10 ... 33.8 - 40 = -6.2°C = 20.84°F ?
Does this seem reasonable?
Looks like an encapsulated message.
(message within a message).
What protocol is your vehicle using...
ISO 15765-4 (CAN 29/500). I found this with another app, how do you get it with torque?
Your response may not be parsing correctly.
Can you find the variable which returns the
hex values beyond 41 78 in your response?
I don't know what you mean?
Response:
---------------------------------- v - v - v
18daf110 10 0B 41 78 0D 01 47 00
------------------v - v - v - v - v
18daf110 21 00 01 40 01 52 00 00
Multiframe response.
10 first frame?
21 second frame?
0B eleven data bytes following?
0D sensors supported binary 1101?
01 47 egt1?
00 00 egt2? (not supported?)
01 40 egt3?
01 52 egt4?
01 47 ... 327/10 ... 32.7 - 40 = -7.3°C = 18.86°F ?
01 40 ... 320/10 ... 32.0 - 40 = -8.0°C = 17.56°F ?
01 52 ... 338/10 ... 33.8 - 40 = -6.2°C = 20.84°F ?
Does this seem reasonable?
Yes, so can torque interpret this?
Looks like an encapsulated message.
(message within a message).
I left the 'header' parameter blank, is this OK?
My 3rd post above was wrong, I'm going to delete it
Sorry, I'm not the developer... just
another user trying to assist.
I believe there is a selection for your
protocol under the vehicle profile which
you can specifically select if Torque is not
using the correct protocol already.
Should be able to look under the adapter
status icon functions for protocol in use.
Cannot answer whether Torque is properly
parsing the encapsulated message correctly
as I drive an OBDI Jeep and cannot test.
Normally with other protocols Torque seems
to be looking for specific response bytes... i.e., 41 78
and then begins assigning variables to the bytes
that follow beginning with "A".
I was trying to understand which variables
represented the bytes following 41 78 hoping
that Torque had parsed them into variables that
could be read.
Your earlier post said variable "A" mapped to
byte 52 in the second frame which would not
be correct.
i did some test at the beginning to
to find wich bite was A
when you do a test
you can see the full response
but it show the result of the equation at the same time
so if you put A, then B, then C
you can see witch bite is A,B,C ect if you have a multi frame response
here is one of my exemple

standard pid just have a request and an answer
but my custom PID have 6 line of response
10,21 to 25 so finding the right variable was a bit hard lol
was O and P in my case
so you try to find the first 01 in your response
if it B that gets 01 then you do
using the equation: (((B*256)+C)/10)-40
and you do another PID to find the other 01
could be F
then the other pid will be
using the equation: (((F*256)+G)/10)-40
That is correct for other protocols. An example
of the same can be found in the Ford 6.7 threads
for EGT.
For long multiframe responses Torque will assign
A, B, C,... Z, AA, AB, AC, ... etc.
The non data bytes are removed and the data bytes
are sorted in order of the frames then variables are
assigned.
moreause,
Which software package are you using to monitor the raw CAN messages with the timestamps that are shown in your post?
I'm in the middle of a similar project and I'm looking for a way to see the CAN messages with a time stamp.
Thanks
i bought a canalyst 2 on ebay
i already had a Y for obd connector
so i plug to obd port in one side and the analyser on the other side
other wise you can have a general idea when you check your log...
you can easely filter adress and some other simple stuff
Thanks for the info. Looks like a good deal...I may get one.
I have an old pcmcia CAN interface, but I don't have a notebook pc with pcmcia anymore.
Does the Canalyst come with windows software to monitor/log the CAN bus?
yep there is 2 of them
one you have to look carefully how to install
...
in short you have to install it and change one file
the file is on the CD
i just made a small vid
https://www.youtube.com/watch?v=gHxqTmRVwmg&feature=youtu.be
hum PMCIA adapter..i wonder how much kid these days would know what it is lol
Thanks for the info.
The video is good, but I couldn't stay focused because of the pic of the girl on the screen.lol
Yes, I have a bunch of old PCMCIA cards, but they're pretty much obsolete now, unless there's a USB to PCMCIA adaptor that actually works on any card.
Quote from bradrh on February 26, 2015
Quote from bradrh on February 26, 2015 ...
I made an extended PID csv file and loaded it and logged the data from bytes A through I. A is always 1, B is always 82 (0x52 hex).
"egta","egta","0178","A",0,256,"","" "egtb","egtb","0178","B",0,256,"","" "egtc","egtc","0178","C",0,256,"","" "egtd","egtd","0178","D",0,256,"","" "egte","egte","0178","E",0,256,"","" "egtf","egtf","0178","F",0,256,"","" "egtg","egtg","0178","G",0,256,"","" "egth","egth","0178","H",0,256,"","" "egti","egti","0178","I",0,256,"",""
I didn't explain myself very well. I logged A - I and A is always 1 B was alwas hex 52, the rest were always 0. This is consistent with what I got using single shot tests.
Still believe its not parsing variables
correctly since only byte with 52 is
in the second frame. IMHO.
Quote from Capp777 on February 28, 2015
Still believe its not parsing variables
correctly since only byte with 52 is
in the second frame. IMHO.
I agree, I sent the developer an email.
This problem seemed familiar to my
feeble memory...
http://torque-bhp.com/forums/?wpforumaction=viewtopic&t=4503.0
(bottom of page).
Hmm, So the bottom line from that thread is that it wasn't parsing the Volvo data correctly. He tried various headers, to no avail. It looks like the developer hasn't sorted it out. The OP from that thread gave up.
Bummer (:
Bump.
Still hoping to get a workaround or bug fix.
Torque may not function correctly with the responses to a few frames protocol ISO 15765-4 (CAN29/500)
you can watch torque only EGT11
https://yadi.sk/i/KiIJ3x07f9yT4
https://yadi.sk/i/yJXlFqvuf9zyW