ScanGaugeII work on 2010?

Good luck. I have not had any luck with the 2010. If you find a code that works on the 2010, post it for us.

Thanks!

 

Yeah, everything I've found on PriusChat states we don't have any X-Gauge codes yet for the 2010. Is someone actively working on it? Anything the rest of us can do to help?

 

Thanks for the reply. I too ordered the scangauge & it was also 3.17.
I did call Linear-Logic and they said that x-gauges do not work on 2010 Prius at this time and could not give any time frame. I was interested in injector timing.
Thanks again.

 

I wonder if these codes would be listed in the 2010 Service Manual? Bob W. said we could pose questions and he might be able to answer them. Bob, what do you say?

 

There is no code is shown on the Service Manual.

Speaking of CAN messages (Xgauge function), Japanese folks are trying to decode them.
So far, there is no message about BTA in the passive mode.

The active mode (request/response) behavior between Gen2 and Gen3 are different.

To see the BTA on Gen2 is simple:
request: 7E30221CE
response: 7EB+(some data for BTA, SOC and others)

To see the BTA on Gen3 is complex:
BTA request: 7E2806A1069802010200
request received: 7EA806E1069802010200
data request: 7E2802A2060000000000
data response: 7EA804E2068092000000
(the second 0x8 shows discharging and the 0x092 shows 146 in decimal which means 1.46A)

I believe the Xgauge supports a single request/response communication, but it does not support the multiple request/response/request/response communication on the current revision.

Ken@Japan

 

Bummer. Thanks for the information. Please let us know when they crack the codes!

 

I know nothing about scangauge, but I have some experience in analysing the OBD2 data.

To see the BTA on Gen3 :
It works perfectly this way with a single request :

BTA request: 7E2802218A0000000000
a few times, here are different responses

t7EA804618AADD2000000 t7EA804618AA849000000 t7EA804618AA93D000000 t7EA804618AA785000000 t7EA804618AA62F000000 t7EA804618A748C000000 t7EA804618A6E3F000000 t7EA804618A635D000000 t7EA804618A6299000000 t7EA804618A6515000000 t7EA804618A6143000000 t7EA804618A5D10000000 t7EA804618A64B3000000 t7EA804618A6080000000 t7EA804618A6420000000 t7EA804618A67F2000000 t7EA804618A70BA000000 t7EA804618A79E4000000 t7EA804618A8093000000 t7EA804618A8093000000 t7EA804618A8093000000

giving the following values (in Amp)

117,3 103,13 105,57 101,17 97,75 -29,32 -45,45 -73,31 -75,27 -68,91 -78,69 -89,44 -69,89 -80,64 -71,36 -61,58 -39,1 -15,64 1,47 1,47 1,47

(the second 0x8 shows discharging and the 0x092 shows 146 in decimal which means 1.46A) : same coding

This result is definitely true.

I am using a canusb for logging the full traffic and another device for comparing.


I found also some other codes...
but it is just the beginning....

 

The "pre-programmed" gauges are OBDII codes sent full time on the buss. They are mostly mandated codes to be the same on all cars. The "XGAUGES" are mostly CAN messages that require a request, then watch for a response. There are only a "few" OBDII codes, but there are -many- possible CAN messages. There are also a few different ways those messages could be prompted. Hints to this are in the messages above.

I suspect there will be a few "XGauges" that will work, but not many without a full update of the Scangauge II. Technology marches on. The current Scangauge II is a few years old, and showing it.

 

It may be possible to set the backup beeper status with a Scangauge. I've been studying a trace of the parameter being set, and I think I've identified the relevant messages. But I don't currently have access to a 2010. So if some brave soul wants to check it out, here is an xgauge setup to query and set the backup beeper.

The commands are:

Single backup beep: 07 c0 3b ac 40
Continuous beep: 07 c0 3b ac 00

You may be able to set these commands into a memory location and send from there. I've never seen any responses from memory sends on my Gen2, so this is just an idea.

If sending from a memory location doesn't work, then the following are Xgauges that use the same command. It's probably safer to try the query function first.

Query beeper status:
TXD: 07 c0 21 ac
RXF: 05 61 16 ac 00 00
RXD: 28 10 (show "ac 00" or "ac 40")
MTH: 0001 0001 0000

A reply of "ac 00" means that the beeper is continuous.
A reply of "ac 40" means that there is a single beep.

If either reply is received, then we're cooking...
A brave soul may want to try changing the status.

Set beeper status to single beep:
TXD: 07 c0 3b ac 40
RXF: 05 7b 06 ac 00 00
RXD: 2808
MTH: 0001 0001 0000

This message only needs to be sent once, but the scangauge will send it continuously if you leave the xgauge active. So just blip it, and change to a different gauge.

 

Bummer. Maybe it's a multiple message setup. Here's the monitor data that I collected. Interpretations are all WAGs - if there is an official specification, I sure don't have it.

Notes: This data shows an initial "00 00" on each message. I'm guessing that the scangauge hides this from the user interface.

The general format of the data is:

00 00 07 c0 ...... The address of the ECU (Body?)
00 00 07 c8 ...... ECU address in reply (modified by "8")
​

3e ............... init request
7e ............... init reply

21 ............... query request
61 ............... query reply

3b ............... set request
7f ............... set reply

21 a7 ............ query parm a7
61 a7 c0 ......... reply that parm a7 is c0 (unknown)

21 ac ............ query parm ac (beeper)
61 ac 00 ......... reply that parm ac is 00 (beeper continuous)
​

61 ac 40 ......... reply that parm ac is 40 (single beep)

21 a1 ............ query parm a1
61 a1 10 ......... reply that parm a1 is 10 (unknown)
​

Recorded data:

send 00 00 07 c0 3e ............. some sort of initialization
recv 00 00 07 c8 7e ............. initialization reply

send 00 00 07 c0 21 a7 .......... query parameter a7 (unknown)
recv 00 00 07 c8 61 a7 c0 ....... value is c0

send 00 00 07 c0 21 ac .......... query parameter ac (backup beeper)
recv 00 00 07 c8 61 ac 00 ....... ac value is 00 (continuous beeping)

send 00 00 07 c0 3e ............. init
recv 00 00 07 c8 7e ............. init reply

send 00 00 07 c0 21 ac .......... query ac
recv 00 00 07 c8 61 ac 00 ....... ac = 00

send 00 00 07 c0 3b ac 40 ....... set parameter ac to 40 (single beep)
recv 00 00 07 c8 7f 3b 78 ....... delay
recv 00 00 07 c8 7b ac .......... reply to set parameter

send 00 00 07 c0 21 ac .......... query ac
recv 00 00 07 c8 61 ac 40 ....... ac = 40 (beeper at single)

send 00 00 07 c0 21 a1 .......... query a1 (unknown)
recv 00 00 07 c8 61 a1 10 ....... a1 = 10​

 

The various options are all set with very short messages, such as the 7 byte one for the beeper. It certainly doesn't require a $6000 piece of dealer test equipment to send the required message. But it does require the knowledge that is currently only available in that equipment. I was hoping that the Scangauge would be adequate, and maybe the next version will work. Another possibility is any ELM based scan tool. I got one off eBay for $30, and maybe it can be made to work. The keys are knowing what to send, and how to get a particular device to send it. I think I've solved what to send, but getting an inexpensive device to send it remains unsolved.

 

Isn't the problem that the GenIII using a "multi-frame" message as Ken@Japan pointed out? The SGII only capable of sending single frame message?

 

I have often seen 960rpm on my Gen III when in warp stealth....

1280 is the rpm it uses to warm up the engine below 103F

 

I put the entire sequence into memory locations 0 through 7 and send them in order. Didn't work. Got an OK on all of them.

I tried send some commands with the extra 0000's but that didn't help either. And then, just to see what would happen I changed the second 0 to 1 and send it, and a response came back. So responses are possible...... It was a full string of digits the width of the screen.

I'll try the xgauges now...

 

Ummm, guys, this worked!! I took a (crappy) video on my iPhone and posted it to Youtube:

Edit: Uploaded new video of me controlling it directly

I'm so surprised really. I tried sending commands and that did nothing. I also put in the XGAUGE to query the status and that didn't work -- just showing up blank.

This rocks!! Here's what I did:

Programmed XGAUGE
Had car in READY mode, driver's door closed
Activated XGAUGE for this and left it up for a couple of seconds.
Only showed up as blank
Switched to another XGAUGE
Put car into reverse -- only one beep!

RobH, I think this deserves a new post to get the word out.

Edit: Here are the two Xgauge's I used:

Query Reverse Beeper (shows 0000 is enabled, 0040 is disabled)
TXD: 07c021ac
RXF: 046115ac0000
RXD: 2808
MTH: 000100010000

Set Reverse Beeper Off
TXD: 07c03bac40 (change last 40 to 00 if you want to re-enable it)
RXF: 047b15ac0000
RXD: 2008
MTH: 000100010000

 

You rock if this is reproducible by others!

 

​

I would love to get the set bytes to disable panic on the remote, set the headlights to turn off after 0 seconds, and disabled the seatbelt reminder buzzer. I assume they can all be set the same way.

 

Good that you didn't actually back over the motorcycle...
.
Excellent stuff! I haven't dug into the strings folks have
been posting in detail yet [not that I'd even have a '10 to
apply it to], but y'all might find my packet breakdown somewhat
useful as all the other doc I've found doesn't seem to really
lay down the boundaries between CAN and lengths and the OBDII
encapsulated therein:
http://techno-fandom.org/~hobbit/cars/sgpkt.txt
.
People should think about mapping out which ECUs sit at what
CAN IDs, too, and possibly what data might be traveling on the
*other* networks that don't appear at the DLC.
.
_H*

 

I have tight parking spot and have been parking in it for 11 years -- so I'm used to not hitting things. LOL. But I must admit, having the backup camera on the Prius makes parking a cinch!

Playing around with the CMNDs function on the SGII, it seems it's very limited. It seems (to me) that is only always pre-pends 07 DE (broadcast), 08, the length of what you put in and then the user inputted CMD. So if you put in 010C is actually sends:

07 DE 08 02 01 0C which is the standard Mode $01 PID for RPM.
Because it always pre-pends the broadcast ID and other info, we can never talk directly to the MFD (7C0) like we need to. LAME!

It's not really useful except to pull things like 0902 for the VIN or other things that will be answered from the broadcast ID.

Am I correct in my analysis?

 

I created a gauge to read this on my car, but the results don't make sense.

TXD 07E22218A
RXF 0461158A0000
RXD 2816
MTH 0001 0001 0000

What this does is give me the two bytes that change from the results (7EA804618AADD2000000) ...

You are taking those two bytes, convert to dec, subtract 32768 and divide by 100. If I do that to all of your captured data, it matches what you write....

But on my car, the results make no sense.

"READY" but in park:
1E80

READY, in drive, foot off break, parking brake on
36C0

ICE running in park (charging)
EC40
1100
1D40
2980

Oh wait -- all of these end in 0, it should be 2810 to capture 16 bits... I've tried various combinations of offset 2 and subtracting 8000 (32768) in MTH, I still get strange readings. Whenever I get charging I get readings in the 640's which sounds like a sign problem to me.