Scangauge or Torque App?

Chap: Yes, that's my understanding. A is byte 1, B byte 2, etc. There are lots of experts on this including Vincent and lots of discussion on the forums for gen 2 and 3.

Bob: my understanding is that the adaptor handles the checksum generation, whether it's done in hardware or software doesnt much matter, it's invisible to the application. Based on my recent experience the adaptor also seems to handle the priority byte in Vincent's diagrams above. But again, I don't have the expertise and background that you guys have... Everything I think I know I've learned in the last week There are two pieces, the Torque application and the ELM327 adaptor, and it appears that most of the smarts in terms of assembling and disassembling the packets are in the adaptor.

 

I like that phrase

 

Yes, that is correct. A is the 1st byte immediately after the responded PID. For ISO9141/KWP2000, it is usually the 6th byte (RXD=2808). However, if the command do not have PID, just the Mode, e.g. DTC with Mode 03, A will be on the 5th byte and B on the 6th byte (RXD=2010).

For word-size data, e.g. (RXD=2810), you need to multiply the 1st byte by 256 and add it to the 2nd byte e.g. (A * 256 + B).

For bit-wise PIDs, you can use {DATA:Bit Position}, e.g {A:7} to indicate Most Significant Bit of A and {A:0} to indicate Least Significant Bit of A.

Lastly, the equations need to account for the multiplication factor in RXF.

Vincent

 

Vincent,

Thanks! Is there any official place this is documented? I spent some time poking around torque-bhp.com last night looking for something like a manual and the most I found was a wiki page about extended PIDs that told me less than I had already guessed. If there's a link to the real documentation I overlooked, I'd love to have it.

Thanks,
-Chap

 

I wish there is one but no, there is none yet. There are numerous requests to the owner of Torque and he himself has said he is only good at programming and not as well on documentation. If you go to his forum, you can get most of the answers from there.

Vincent

 

How original. I wonder how many programmers in history have ever not trotted out that one....

-Chap

 

I built a csv file today with about 40 PIDs and managed to load them to the app after a bit of fussing around. Most of them return data, although there are still lots of issues. I haven't done a detailed evaluation, but I'd say 1/3 of them pass the quick sniff test, and another 1/3 seem to be the wrong values but are moving roughly as I would expect them to be. No weirdness with the car. I feel like I''m making progress.

I'm not sure that I'm building the formulae correctly. Here's an example:

From the sourceforge database:

address id lbit rbit format mul div postadd ucum ns2:xga ns2:desc ns2:style
d5 a4 0 15 unsigned 1 1 0 cV V01 Battery Block 1 Voltage /100
d5 a4 16 31 unsigned 1 1 0 cV V02 Battery Block 2 Voltage /100

I converted this to use in Torquepro as follows:

Name,ShortName,ModeAndPID,Equation,Min Value,Max Value,Units,Header
Battery Block 1 Voltage,VO1,01A4,A*256+B,0,20,volts,D5
Battery Block 2 Voltage,VO2,01A4,C*256+D,0,20,volts,D5

My sense is that the addressing is working, i.e the header and mode/PID is correctly formatted, but I get back readings that are several orders of magnitude off.

Am I missing something? Is my interpretation of the xgauge parameters correct?

 

Sorry, the formatting on the xml didn't come out right. Here's the text of what I was referring to.

<p id="a4">
<field lbit="0" rbit="15" format="unsigned">
<calc mul="1" div="1" postadd="0" ucum="cV">
<show pcsg:notes="XX.X V" pcsg:xga="V01" pcsg:desc="Battery Block 1 Voltage"
pcsg:style="/100"/>
</calc>
</field>
<field lbit="16" rbit="31" format="unsigned">
<calc mul="1" div="1" postadd="0" ucum="cV">
<show pcsg:notes="XX.X V" pcsg:xga="V02" pcsg:desc="Battery Block 2 Voltage"
pcsg:style="/100"/>
</calc>
</field>

 

You are right about the 1st byte of the header. ELM327 automatically determines the number of bytes that you are sending and inserts that length for you. SGII does not do that so we have to add it ourselves.

I think your multiplication factor is not correct and you also left out the transmitter address. Can you try this?

Name,ShortName,ModeAndPID,Equation,Min Value,Max Value,Units,Header
Battery Block 1 Voltage,VO1,01A4,(A*256+B)/100,0,20,volts,D5F1
Battery Block 2 Voltage,VO2,01A4,(C*256+D)/100,0,20,volts,D5F1

Vincent

 

The pcsg:style attribute is specific to the ScanGauge II: "/100" sets bits in the XGAUGE that will make the SGII internally divide by 100 so the integer is displayed as a value with two decimal places.

Here's how you want to read the XML: a calc element tells you what arithmetic to do on a field to get a value in certain units. In the example you're looking at, ucum="cV" tells you that if you do the arithmetic shown in that calc element, the result you get will be in centivolts. The calc element is all you need for finding out what arithmetic to do and what the result units will be.

Inside the calc element can be show elements, and these just add information on how the value could be formatted and labeled on different products. So a show element with a bunch of pcsg: attributes will be showing you how to display the reading on a ScanGauge II. In this case, instead of labeling the value as battery centivolts, the show element asks for the SGII's internal /100 and labels the value as battery volts.

If you look at some of the PIDs in the database that have show elements for both pcsg: and ecros: and you compare them, you'll see that the Ecros miniscanner had more of a printf-like formatting function rather than the ScanGauge's fixed /1, /10, /100 etc.

In any case, as long as you look at the calc element and what units it gives you, you'll know what you're starting with and you'll be able to work out any further arithmetic you might want to do to display the value the way you want to see it.

-Chap

 

You guys are doing awesome. Keep it up. I'm following this thread the best I can with the limited knowledge I have (remember, I'm from KY). I wish I could add something but sometimes its better just to encourage (especially if its over your head).

 

Excellent, thanks. One more question on signed vs unsigned results. How do you suppose the application and/or adaptor know which representation is being used? My only guess is that if the range specified in the csv file includes a negative number the application assumes a signed format. The only alternative I can think of would be if it is part of the obd communication but that seems less likely to me. Anyone know?

 

You just have to know, which is why that's explicitly indicated in the XML - it's not deducible from anything else that's there or anything you get from the ECU.

It turns out that not many, if any, of the OBDII standard PIDs use twos-complement. If they represent signed values they do it with a bias (say, the value is an unsigned integer representing the signed value plus 40, and you subtract 40 to display it). On the other hand, a bunch of the Toyota-specific signed PIDs are twos-complement.

One of the frustrations with the ScanGauge II (unless it's been fixed in newer firmware, in which case I should get mine updated) is that there isn't any way in an XGAUGE to flag that twos-complement representation is used, so the scangauge exporter can't correctly export such items and the ScanGauge won't display them right.

How you would tell Torque to use twos-complement would be something to find out from its, er, documentation or from the author. If there isn't a way, it would be worth asking him to add one so that such items could be correctly handled.

-Chap

 

If a Torque "equation" can use a rich enough set of operators (bitwise ops or a conditional) then it should be possible to just generate an equation that handles the value properly.

With ScanGauge II because the only operators available are a multiplication, a division, and an addition, that's not an option there.

-Chap

 

Torque has a function, SIGNED(), for this.

e.g. (SIGNED(A)*256)+B)/8

Forums &mdash; &raquo; Torque OBD ECU Scanner &raquo; Torque Discussion / Ideas &raquo; Extended PID's - Signed VariablesTorque

Vincent

 

Thanks. I was searching the Torque forum, but didn't didn't get an hits on "complement" - should have tried "compliment"!

But that doesn't obviously accommodate 16 bit two's complement representation, right? I'll send a note to Mr. Torque.

Vincent, re: "...you also left out the transmitter address" -- yes, but it seems to behave the same with or without. Looking at the PIDs for the gen2 I thought I saw references to F1, F0, and I think maybe F2. How do we know it should be F1, and should it always be F1?

 

After doubting for a moment, I seem to have convinced myself that 256*SIGNED(A)+B will indeed give the right value if A and B are the high and low halves of a twos-complement number.

-Chap

 

Strange, I would have thought, SIGNED((256*A)+B). First I would have converted the two bytes into the original 16-bits and then treated it as signed for subsequent conversion. Of course I've assumed 256*A would give at least a 16-bit result.

Bob Wilson

 

I believe that e.g. is an 8-bit representation. For 16-bit, I agree with Bob to include B inside the brackets. For mathematical expressions, the outer-most bracket is the last to be executed.

The default is F1 for ELM327. I think if you don't indicate, it will revert to default. Some other tester may use F0 ~ FD, not always F1. If there are multiple testers online, having a different tester address will prevent collision (something like IP address in networking). In such cases, you can use AT TA hh to change the tester address.

Vincent

 

That's the first and most intuitive idea, but on further reflection it requires us to know a lot about how the Torque author implemented the SIGNED function. Does it simply do an 8-bit sign extension, or does it somehow analyze its argument and know to do a 16-bit sign extension if you are passing it a 16-bit value? The latter would be pretty sophisticated so I am guessing the former. If we can't read the Torque source then we won't know unless the author has clearly documented exactly what SIGNED does. All I've seen is the forum post that shows it being applied to an 8-bit value and gives the example 256*SIGNED(A)+B for the 16-bit case and it could be risky to assume it would also work the other way.

As to why it 256*SIGNED(A)+B should work, picture taking a 16-bit quantity, masking off the low 8 bits, sign-extending the value (now with zeros in the low part), then adding the low 8 back in (they are still treated as unsigned so there should be no carry). Effectively that's what's happening.

-Chap