Scanguage Xgauge how-to area (Please share your knowledge!)

[Bob64]

Ok, I hope that this thread will create some discussion on the how-tos of getting the scangauge to pull the data that WE want out of the prius's CAN network.

I believe I've managed to figure out how to decipher the PASSIVE messages that the battery ECU sends out. (Probably been done before, but hey, I don't see a guide to understanding it anywhere)

Apparent Disadvantages: We're totally at the mercy of whatever interval the passive messages shoot out at as opposed to the "ACTIVE" message AMP code that is already out.

For example: Battery Current (Amps)
Interval: 8 ms (Blurringly fast)
TXD: 0033
RXF: 0100823B0000
RXD: 140C
MTH: 0001000A0000

I did some quick testing, and it appears to match exactly what the other Scangauge code for amps gets, although the tenth place is blurringly fast.

A quick explanation on how the above code works:

First, lets understand exactly where the data is:
Prius PHEV TechInfo - EAA-PHEV

Lets look at the first row of data. First of all, I have no idea why they numbered the byte position the way it is layed out on the table... so I've simplified it a bit... Note: may not be accurate, but it's the best explanation I've been able to come up with.


http://i11.photobucket.com/albums/a1...ssivecan-1.gif

We're interested in Bytes 3 and 4. Note that Current is 12 bits and that it is signed.
Signing means that the most significant binary bit - when set - results in its value being negative.

For example, in an 8 bit binary number 1111 1111, to convert into decimal you add -128 + 64 + 32 + 16 + 8 + 4 + 2 + 1 = -1.

It also means that bits 16-19 are unneeded.

Anyway, on to the TXD of 0033.
First, because these messages are PASSIVE, it means that these are broadcast automatically by the battery ECU, which according to the above wiki, does not even listen to messages on the CAN - it only sends.

First, the ID of the passive messages is 03B.
In order to change this into a fake message that the scangauge sends - you invert the last character's most significant binary bit. REMEMBER that the ID is in hexadecimal. If you convert 003B into binary, it becomes: 0000 0011 1011
0000 0011 0011 (inverted last character's most insignificant bit)
Then convert back to Hex: 033
We need to first pad a 0 to the TXD, since the TXD field must be an even number of hex characters. Thus: "0033".

Ok, based on the TXD, the scangauge will look for ANY reply with the last character's most significant binary bit flipped, ignoring the last 3 binary bits.
This means that any replies with 0000 0011 1XXX will be accepted for further filtering, which is what the RxF (Receive Filter) does.

RXF: 0100823B0000
First, for simplicity's sake, lets separate them into 3 groups of 2 characters.
01 00 - 82 3B - 00 00
First lets take a look at the first two characters of group 1: "01"
The 1st character means something special: If it is equal to a 0, do nothing. If it is equal to an 8, then it is a scangauge trip gauge.

Since we're not making a trip gauge, we're going to leave it at 0.
Lets look at the 2nd character of group 1: "1"
This second character indicates to the scangauge where to look to match the other two characters with.
This means that byte "1" MUST equal "00" in order to be processed further. If it doesn't, the message is discarded.

The same concept applies to the other groups. EXCEPT the first character in the second group. If it equals an "8", it means that the FINAL value (after MTH is done) has a space after the decimal (for example, X.X). If it equals "4", it means that the FINAL value (after MTH is done) has two spaces after the decimal (for example, X.XX). If it equals "2" the final value is either "ON" or "OFF" depending on if the FINAL value is equal to a "1" or a "0".
Thus, byte "2" MUST equal "3B" in order to be processed further. If it doesn't, the message is discarded.

The first character in the 3rd group also means something special: if the value is 8, the final value is supposedly in hex (Have not gotten it to work yet).
The filter seems to do nothing if the 2nd to 4th characters are "0"



Now that we got a message that matches the filter, its time for RXD.
RXD: 140C
RxD tells the scangauge WHERE in the message our data is.
Separate the RXD into 2 groups of 2 characters.
14 0C
The first group tells where the data starts. 00 is the first bit in the string, 08 is the first bit in the second byte, 10 is the first bit in the third byte. In this case, we want the 20th bit onwards.

The second group is how LONG the values are. In this case, it is 12 bits long (C in hex).

Onward to MTH.


MTH: 0001000A0000
Lets seperate this into 3 groups of 4 HEX characters.
0001 000A 0000
The first group means how much to multiply the value by.
The second group means how much to divide the value by.
the third group means how much to add/subtract the value by (this is a signed field)

So in this case, we're multiplying by 1, dividing by 10 (A in hex = 10 in decimal), and then adding 0 to get the final amp value.

Then call the gauge something. AMP works good.

Observations with AMP values: (these numbers are off the top of my head at the moment and may be off)
You'll now notice that the prius supposedly takes ~.9 amps when sitting idle, slow acceleration in EV mode takes about 22+ amps, and stealth glide takes about 5+ amps to maintain, warpstealth takes about 15+ amps to maintain.
Other observations: You barely regenerate anything at 7mph, so best to shift into neutral and use friction brakes here to avoid use of creeping, which takes about 2-3 amps. Neutral = .9 amps, brakes brings it up to 1.3 amps. Headlights in neutral brings it up to about ~1.9 amps total.


Anyway, if anyone has a clue as to how to get the hex mode special value in the first character of the 3rd group to work in the RxF area, please post in this thread and share some knowledge!

My ultimate goal at this point is to pull inverter temp data, and I need help getting RAW hex data out of the CAN! It's being sent with an ID of 7E2 and a PID of C3 or C4!

Please feel free to correct me if I'm wrong! (I'm still struggling to learn this CAN stuff!)

[Bob64]

Ok, looks I screwed up a tad on the MTH somewhere - it doesn't show negative values right.

[ksstathead]

Glad to see your post. Just got my upgraded unit back & put trip FE in as a gauge. Ecstatic about that. Look forward to studying your post to start my learning curve on it.

[Bob64]

Argh, there doesn't seem to be a way to have the scangauge treat 12bit signed values right! It only supports 16 bit signed values :/

[dogfriend]

I don't know anything about CAN, but I just got a new ScanGauge so I was looking for info about the XGauge function.

Anyway, I can follow your discussion above, but I noticed that on the PHEV wiki site, they use a different set of parameters for Current, namely the TXD is different. Comment?


Prius PHEV TechInfo - EAA-PHEV

[icarus]

Bob64.

I don't know a bit from a bite from a byte. I glaze over reading your post, but marvel at the knowlege you have to do any of that. Congrats. If you get the inverter temp code unlocked, it would be great if you would post it for us non-techno types.

Thanks once again,

Icarus

PS. It took me hours to figure out that I had to enter some sort of code to get the scan to give me HV voltage and SOC. Once I figured it out it made sense,,,,sort of. Mostly black magic!

[RobH]

If the CAN protocol is only active in Ready mode, then what is used when they add a new keyfob? I watched a mechanic do it, and the scantool seemed to be interacting with the car even when it was OFF.

[Bob64]

Apparently theres two ways to get Current.

Active and passive.

The ECU passively broadcasts the current without request, as well as other data, which is what my "tutorial" attempts to acquire.

The active one that someone else figured out sends a message to the HV ECU or something, and requests the current data. Apparently that data is 16 bits, and not 12 bits when captured passively... which is why it appears to have working negative values. The passive message is broadcast every ~8ms, which is probably why the passive code is blurringly fast at refreshing when compared with the "Active" xgauge code - if you put the gauges side by side.

As for adding keyfobs... perhaps this may answer your questions:
Replacing A Lost Prius Smart Key

[Rokeby]

Good Lord above!

Bob64, how you and the other posters working on this can see your way through what is to me an impenetrable thicket of numbers and hex codes is beyond me. A tip of the hat to all of you.

What caught my interest in your posts was the mention of inverter temps. All the threads on grill blocking invariably say that being able to monitor them is of paramount importance.

I want to add my encouragement to you and the other posters. Go boys go!

My hope is that at the successful end of your efforts you will post the necessary numbers in the format given for the XGauge so plain folks like me, just a simple wooden boat builder, can put them into our ScanGauges. (What's the difference between being simple versus stupid?... You can brag about being simple!)

I take it that if I sift carefullly through your post I can get the numers to put HV amps on my ScanGauge. I think I'll call it HVA.

[Bob64]

Alas, but the above gauge is flawed: the scangauge does not handle negative values with the above "passive" gauge. I believe that its a limitation with the scangauge and can't be fixed at this point.
You'll notice with the passive gauge that when you regen, the numbers will go crazy (consequence of the values being signed).

Your better off using the "active" code that dogfriend mentioned in this thread. (It works with negative values, and it doesn't refresh blurringly fast.)

Right now I'm trying to obtain some raw data from the people that worked on this: The new 2004 Toyota Prius : My CAN Project

Since at this point, I'm unwilling to invest in the additional hardware to obtain it myself.