XGauge (CAN-bus) for Dummies...

OK... Here goes.

Pull up the XGauge PDF from the Research folder in my posted ZIP file. Follow along with that to get things going.

Passive CAN
TXD - Transmit Data - In a way in passive mode, this isn't used since there is no real "transmission" required in Passive CAN transactions. You just sniff the bus traffic. Convention dictates that you take the Passive CAN ID you want, and flip bit 3. Do do this from Windows:

1. Start the windows calculator.
2. Choose "Scientific" from the view menu.
3. Click the "HEX" button.
4. Enter the CAN ID from Atilla's spread sheet.
5. Click the XOR button.
6. Enter "8".
7. Hit equal "=".

That will flip bit 3 just as the XGauge PDF suggests.

RXF - Receive Filter - Best to look at this for examining the following pattern:

xA YY xB YY xC YY​

Those are the "matching" fields. For Passive CAN requests, you just match the CAN ID in Atilla's spreadsheet (in the Research folder in my Zip). So the CAN ID for passive data is two bytes (if it's only 1 digit, the first byte is 00). So A=1 for byte one, and YY equals the first byte of the CAN ID to match. B=2 for byte two and YY equals the second byte of the CAN ID to match. C=0 for ignore, we are done matching. If it passes the matting test, data is extracted from the packet. No the digits I didn't go over were the 'x' es in my example. These are used for formatting data and decimal point placement. The XGauge PDF covers this stuff better than I.

RXD - Receive Data - Tells where to extract the data from. Bit of confusion here. Remember that byte 1 and byte 2 (counting starting at 1 not 0) are the CAN IDs. This was covered in the RXF description. So byte 3+ contain the data we want. Now the format is to use bit numbering. This convention counts from 0 not 1 (ie first bit is bit 0, second bit is bit 1). So the first bit of byte 3 is bit 16. In HEX this is 0x10. The first bit of byte 5 is 0x20 and so one. So now look at the pattern:

XX YY
XX = The bit the data starts at.
YY = How many bits of data to extract.​

So 0x2008 means extract 8 bits starting at bit 32.

MTH - This is just the math to do to the data. There are three numbers, a multiplier, a divider, and an adder. The pattern looks like this:

xxxx yyyy zzzz
xxxx = Once you extract the bits from RXD multiply them by xxxx
yyyy = Once you have the results from the multiplier, divide it by yyyy
zzzz = Once you have the results from the divider, add zzzz to them.​

Now all of these fields understand 2's complement arithmetic. So this is how you define negative. Also the bits extracted from RXD are always assumed to be 2's complement signed, so you have to be aware of this when your coding your gauge.

I think thats about it. The Active (non-passive) CAN requests are the same as the passive with the exception of a different TXD and RXF. I can go over that if there is any real data found in Active CAN that we can extract.

Another thing to keep in mind is that much of the Passive CAN traffic happens in multiple frames per second. So you get new data every few milliseconds. The data is much more real-time, but can flicker the gauge since it comes through so fast.

11011011

 

Thanks. I'll look over you instructions and see if I can understand how the xgauge works.

I tried the new values for the g-force and it seem to only work when accelerating or turning left. If you slow down or turn right the values get stuck at 655 otherwise they are in x.xx values.

 

Dan, I want to thank you for posting the info on the Prius SoC and BTA. My SG now reads SOC and BTA!:woot::woot: I apparently was using the numbers from the SG site with the typo. I still can't get HVB to display but I may be able to live with that for now.

 

No problem... And the good news is the Passive soc bta and btv can all be displayed at the same time. The original SG Active ones can't. They SOC and BTA conflict. Hence the desire to "fix-the-problem"

PS... like my sig?

11011011

 

655 is a bounded binary value. Think 65.5k which is the largest 16bit signed value. Think there is defiantly some signed arithmetic I'm not comprehending. One thing I have noticed is that 12bit signed numbers are not handled correctly.

I must have typo'd something along the ways. Could you give me your GForce Gauge coding because I can't seem to get mine to register. Here are all the gauges I'm having trouble with. The rest I think are OK.

Code:

Fail	GForce to Right
Fail	GForce to Back
Fail	Stearing
Fail	Battery Current (bad MTH value)
Fail	Battery Temp (upper read)
Fail	Battery Temp (lower read)
Fail	Ignition degrees before TDC (bad MTH value?)

11011011

 

I thought I might add some XGauge settings I found on the German Prius forum priusfreunde.de . I haven't had the chance to test them yet myself but hopefully they are working and prove useful.

@ Dan
I hope you don't mind my taking the liberty of copying your previously posted table

Column1	Column2	Column3	Column4	Column5	Column6	Column7
GAUGE	TXD	RXF	RXD	MTH	NAM	Notes
Catalyser temp 1	07E0013C	0441053C0000	2810	0001000AFFD8	CT1	-40 – 6513°C
Catalyser temp 2	07E0013E	0441053E0000	2810	0001000AFFD8	CT2	-40 – 6513°C
ICE on time	07E0011F	0441051F0000	2810	000100010000	CET	0 – 65535 seconds
Air volume sucked in	07E00110	044145100000	2810	000100010000	MAF	0 - 655.35 grams/second
MG2 torque	07E221C3	010042230000	4010	0001000AFE70	TM2	-400 – 400 Nm

​

Great thread BTW :woot::woot:

Regards,

 

I'm using the the same one you made. I did not make any changes to it.

The ignition timing is in .5 degrees. To get the ignition timing correct you must divide by 2 and subtract 16. This will show the ignition timing like the can-view shows.

Steering gives me some weird numbers similar to the g-force.

I haven't tried battery current yet. It should be simple. Its in .1 increments. But it is a 12 bit signed number.

 

OK.. first commute in with the new gauges and I'm a believer. The gauges I was watching was "gas" (TXD: 05AC) which was pretty cool to watch at flashing pip. The SG "gas" gauge will give you the % full of your tank given in 2.5% increments. Pip flashes at 12.5% full, so I'll see what happens wen I get to 5.0% full.

Next gauge I watched was "gps" (TXD: 024C). This will give you the real gas pedal position (in 0.5% increments) as % of "floored". Points of interest... the dead band glide is at 7.0% gps. I usually pulse at about 30.5% gps.

The speed gauge is cool as well, "kph/mph" (TXD: 00BC). This shows speed down to a hundredth of the mph or kph (xx.xx). Neat, but noisy. I could clip off the last 4 bits and and that should filter out a lot of the noise. It's kinda cool to have a decimal point on speed though. Also found out that on the Prius, Speed is always rounded up (10.0 kph = 10kph; 10.1 kph = 11kph).

Moving from the "published" gauges to some of these is useful as well. The current published SG gauges conflict with each other. But using the SG published "BTA" (TXD:07E321CE) gauge, and my "soc" (TXD:03C3) can be displayed at the same time.

Other interesting gauges are "evb" (TXD:0521) which shows "ON/OFF" depending on whether you hit the EV button. Coolant Temp "wtc/wtf" is nice since it's in increments of 0.5 degrees, so you get greater granularity. Also all these new gauges are instantaneous. No delay. That's helpful when your chasing the normal SG 1-2 second delay. I may add RPM so I can get realtime data on that instead of suffering through the lag.

Good to know... I'll have to check my coding on the gauge.

I'll have to play with IGN... I'd like to get real-time data on this.

Hmm... What year is your car. I'm getting no data of steering either. I'll check my work on the gauge here too!

Kick a$$! Thanks!

11011011

 

I have a 2006 #7 Prius. I get correct steering data when I decode my can-view data. I think it might be the limitations of the xgauge or the math or something. Same way with the g-force data.

 

Dan,

I tried the bta and it would not register. I have SOC working. Any ideas?

 

I have found that on my SG, that BTA and SOC won't display at the same time. I guess I'll have to get another now SG.

 

Yeah, there are known issues with BTA:TXD:0033. I'm working on debugging, but for now I'm labeling it "don't use". I'll update the spreadsheet tonight and label it as TESTED=FAILED for now.

There are now two ways to show BTA and two ways to show SOC

1. BTA:TXD:07E321CE
2. BTA:TXD:0033 ( <= buggy, need to work on it... don't use)
3. SOC:TXD:07E321CE ( <= conflicts with #1 )
4. SOC:TXD:03C3

I suggest using #1 and #4 from that list. #1 and #3 clash, and #2 is still being worked on due to some sign extension problems. That leaves #1 and #4 as the only combo to provide SOC & BTA at the same time.

11011011

 

Dan, does all of the other numbers stay the same when using the TXD numbers you listed? I just tried #1 & #4 and they both won't display at the same time.

 

Ohh... sorry... I think I've confused the masses. Go to the spreadsheet and code in the full gauge listed there TXD, RXF, RXD, MTH, NAM. I was just listing NAM and TXD to make sure you got the right one. You do need to fill in the other three values (RXF, RXD, MTH) as shown on the spreadsheet for it to work. I'd display RPM, MPG, #1, #4 (with all the values filled in) and that should work.

11011011

 

Dan,

I can't get any of the passive soc, bta or evb to work. Any ideas.

The other SOC and BTA work fine just not together.

 

Passive "bta" is broken... use the "active" one. Your driving an '07 so it should be identical to mine. I'm running ScanGauge FW 3.15, I'd assume you are as well. I'd try clearing all your XGauges and only programming in the following 3, then see if it works. To clear an XGauge look in your manual to see how to do it. Basically if you set TXD to "0000" that XGauge is cleared.

I know that Jay is getting some gauges working on his that aren't working on mine so there might be a missing link here that I haven't thought of. I suspect that some of these gauges clash with each other, but I know those three should work. I might need to clear my gauges and retest the "failed" cases in better isolation. This may be why Jay's are working where mine are not.

Good luck.

11011011

 

Updated the Excel file with all the codes.

Code:

CHANGELOG:

v1.0 - 06-29-08: Initial Release.
v1.1 - 06-29-08: Added Download Link.
v1.2 - 06-29-08: Corrected Brake Pedal Position
                 Added Jitter Reduction (clipped last bit)
                 Added Jitter Reduction (clipped last 2 bits)
v1.3 - 06-30-08: Added more Query PIDs
                 Added passive RPM
                 Corrected bps scaling
                 Clipped 4 bits on kph/mph to reduce jitter

Looks like some of the new query requrests I've added are basic PIDs. Searching for the tag "pid" find my old ODBII thread. These should all work, or we can regen the PID map for 0x07E0.

11011011

 

Just emailed ver 1.3 of the spreadsheet to Ron...

11011011

 

Updated the Excel file with all the codes.

Code:

CHANGELOG:

v1.0 - 06-29-08: Initial Release.
v1.1 - 06-29-08: Added Download Link.
v1.2 - 06-29-08: Corrected Brake Pedal Position
                 Added Jitter Reduction (clipped last bit)
                 Added Jitter Reduction (clipped last 2 bits)
v1.3 - 06-30-08: Added more Query PIDs
                 Added passive RPM
                 Corrected bps scaling
                 Clipped 4 bits on kph/mph to reduce jitter
v1.4 - 07-01-08: Corrected rpm, buc, blc, all are working

Battery Temps are working! Real-time RPM works too. No delay for a refresh, you get the new RPM value on the same millisecond that you move your foot. This is the "requested RPM" value. It's what the battery is telling the engine to rev to (before it does).

Can't get GForce working on my '07 or Steering (sld). Only thing else that I know of that I'd like to figure out is MG1-rpm, MG2-rpm and inverter temps.

11011011

 

Nice work Dan.