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

Scanguage Xgauge/CAN network research thread

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/a199/Bobc64/prius/priuspassivecan-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!)

 

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

 

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 :/

 

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

 

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.

 

the active code refreshes fast enough, about a second delay. Good enough if you want to monitor it. No downsides in using it. It works perfectly, as opposed to the passive method.

The passive code refreshes TOO fast. Every 8 ms. Good if you want to build a plugin prius perhaps?

 

I'm using an scangauge II with xgauge.

Trying to craft an xgauge to read raw data one byte at a time... working at the moment on a more detailed model of exactly what CAN traffic looks like so that I can figure out how to get the data I want from it easier.

 

Well, I don't really care at the moment about passive mode or not. I was just curious as to if it could be done or not with a scangauge.

I've actually found that CAN specs sheet linked from wikipedia before you posted, and judging by the content there. I believe the Data Bytes section of EAA-PHEV wiki is incorrect.

Prius PHEV TechInfo - EAA-PHEV

Specifically Byte 2, since an ID requires more then one byte (3 hex characters) to fit... so I don't think its physically possible to stick the ECU id into 8 bits.

I'm actually programming a simple "CAN packet" simulator thats slightly interactive. To help people visualize what is being sent... However I'm also trying to figure out if it also corresponds to the scangauge xgauge programming guide that linear logic has released. The part I'm a bit confused on is the RXF, since it doesn't seem to match up with the official specs of the CAN.

Work in progress:

http://i11.photobucket.com/albums/a199/Bobc64/prius/can.jpg