Ok, The first step is to have a copy of the programming instructions. This doesn't mean understanding all aspects but without it, XGAUGE programming will not make sense: http://www.scangauge.com/support/pdfs/XGaugeCoding.pdf The overall flow is: Start car and wait for "Connecting" message to go away. Push red circle MODE button - the lower right hand button. Push MODE button until "XGAUGE" with a number shows up. Push the upper right hand button to increase the "XGAUGE" number or the upper left hand button to decrease the "XGAUGE" number. Look for one that is unprogrammed. Push the button next to EDIT Use the left hand two buttons to change the first, hexadecimal number until it matches the TXD string, a hexadecimal pattern. Push the right hand button to go to the next hexadecimal position Program each TXD character Save and enter the RXF matching, hexadecimal string Save and enter the RXD data extract matching string Save and enter the MTH data calculation string Save and enter the three character NAME identifier Save To test the XGAUGE, use the MODE button to move back to select "TRIP." Then use one of the four data mode buttons to cycle through until the NAME shows up. Sorry for the grainy image: Don't worry if nothing shows up. In all likely hood, there is one or more errors. So just go back to the XGAUGE edits and audit all fields. I screw up every 3-4th attempt and have to go back and put in the right values. Bob Wilson
Thanks Bob that's pretty much what I gathered from reading my book. Now I just need to jump in and try a code and see if it works. All the ones listed here have those 3 codes and it should be "simple". Maybe I'm just a bit apprehensive becasue I haven't tried it yet. Thanks
Have you guys uploaded/posted this master XGAUGE list anywhere, or have it where one can purchase it with updates as more gauges are added over time?
Here are revision 3: ECM ($10 - for North America and EU only) MIL illumination - new No. of Engine DTCs - new Fuel system status #1 - new Calculated Load - Graham Engine Coolant Temperature - Graham Short term fuel % trim—Bank 1 - new Long term fuel % trim—Bank 1 - new Engine Speed - Graham Vehicle Speed - new Ignition Advance - Graham Intake Air Temperature - Graham Air Flow rate into Engine - Graham Throttle Position - Graham Oxygen sensors present - new O2 Sensor, Bank1 Sensor1 - Graham O2 Sensor, Bank1 Sensor2 - Graham OBD standards this vehicle conforms to - new Fuel Injection time for cyl #1 - Graham Abnormal Revolution Variation Cyl 1 - Graham Abnormal Revolution Variation Cyl 2 - Graham Abnormal Revolution Variation Cyl 3 - Graham Abnormal Revolution Variation Cyl 4 - Graham Engine DTC 1 (emission related) - new Engine DTC 2 (emission related) - new Engine DTC 3 (emission related) - new Engine DTC 1 (emission & non-emission related) - new Engine DTC 2 (emission & non-emission related) - new Engine DTC 3 (emission & non-emission related) - new HV ECU ($16) MG2 Torque - value need to divide by 8 manually Regen Brake Execution Torque - Graham Regen Brake Request Torque - Graham MG1 Torque - value need to divide by 8 manually Master Cylinder Control Torque - scaling 1 changed to 4 WOUT Control Power - scaling 16/10 changed to 8/5 WIN Control Power - scaling 16/10 changed to 8/5 and offset 408 Discharge Request to adj. SoC - Graham Auxiliary Battery Voltage - new INFO. Code 1 - new INFO. Code 2 - new INFO. Code 3 - new INFO. Code 4 - new INFO. Code 5 - new HV DTC 1 (emission related) - new HV DTC 2 (emission related) - new HV DTC 3 (emission related) - new HV DTC 1 (emission & non-emission related) - new HV DTC 2 (emission & non-emission related) - new HV DTC 3 (emission & non-emission related) - new Bty ECU ($D5) DC Inhibit Time - Graham Ignition Off Time - Graham Auxiliary Battery Voltage - Graham Battery DTC 1 (emission related) - new Battery DTC 2 (emission related) - new Battery DTC 3 (emission related) - new Battery DTC 1 (emission & non-emission related) - new Battery DTC 2 (emission & non-emission related) - new Battery DTC 3 (emission & non-emission related) - new
Purchase? :madgrin: We've open-sourced it, as part of the PriusChat OBD-II Apps effort. See: https://sourceforge.net/apps/trac/obdchat/wiki/VehicleDatabases I've updated the master XML file to reflect Vincent's "version 3" changes in the post above. There's an exporter that can be used to produce an up-to-date XGauge list from the XML at any time. Vincent, could you be persuaded to use a free sourceforge account and svn to make future changes directly in the XML file and use the exporter to make XGauge lists from that? That would make sure everything stays in sync, and be less error-prone than deciphering changes in an XGauge list and making the corresponding changes in the central file. Please also feel free to add your name to the authorship notice at the top of the XML file (I couldn't because I don't know how you would want it to appear), and if you like add to the history and credits for the file. I would love to see more about when you actually started working on your list, and how long that first 70 really took.... Cheers, -Chap
Vincent, What character set is your computer set for when you make your txt files? Is it Windows-1252? There's a character that appears in your short- and long-term fuel trim descriptions as #151 and I am wondering what character it should be. Did you type an em dash? Thanks, -Chap
Question, I'm trying to see if there are any codes on the Engine ECU. Could I use the below CMND string and replace the 16 (address) with 10? Would that read the codes on the Engine ECU? Just thought I'd ask before I try it! I had to replace the HV ECU to get rid of the Hybrid warning lights on my 2001, now all I have is a check engine light but no codes. Car won't start. Thanks! Gerry
Hello, I believe that you can use the standard xgauge set to get engine codes, most of this discussion is for battery, HV , and ECM as these are not very well documented - only by us trying them out etc.. and of course thanks to vincent1449p for his greatly informative posts. The engine ecu should be covered in the standard toyota xgauge set using the generic xgauge set downloaded from many places. You should also consider the AE software and Toyota enhanced interface, it can read dtc's much more accurately than scangauge ever could, but it still is a handy monitoring device.
Thanks, but I did figure this one out! Searching the internet I found if you replace the HV ECU you need to put a charger on the 12V battery and turn the key to the on position for 30 minutes. This allows the new HV ECU to recognize the key, sync itself with the key, and reset the immobilizer code. I did this and the car started right up. I've been driving it since but still have a rolling noise I'm trying to figure out. Gerry
While the mass-produced cable that came in the box with my scangauge had a molded J1962 end, which pretty much rules out mods, it turns out that the modified Classic-Prius cable they sent me for free when I asked uses an assembled J1962 connector. The cable still has all 8 wires, with an orange and a purple cut off inside the connector housing. It wouldn't be hard to use those two, plus repurpose one other wire the Classic doesn't use, and then at the RJ45 end provide switches to ground any of Ts, Tc, or AB, which pretty much covers all the non-THHT diagnostic procedures in the manual. The third pic below is of a box I built a couple years ago using the same idea, but an OBD scanner attachment for a Handspring Visor. I never had much success extending the software, but I could add switches to the cable. For Ts and Tc, some of the procedures in the manual require a sustained connection to ground, and for others you just pulse the line to ground, so both of those toggle switches are center-off, with an ON that's up, and a spring-return momentary ON that's down. So you can switch either signal on for the procedures that want that, or key it like a telegraph for the other kind. The antilock brake diagnostic procedures never want anything but pulses on AB, so that's just a pushbutton. The one thing about that box that didn't work out so well is that I put the box right at the J1962 connector and it's too wide to fit in the recess in the finish panel where the connector is in the car. The car connector only snaps into that panel though, so it's no problem to pop it out so it hangs behind the panel, and plug on to it there. -Chap
I had an idea for trying to determine the address of the EMPS ECU. It didn't work for me, but I'll write it up anyway either to save somebody else time, or so Vincent can possibly spot a mistake in what I did and see how to correct it. First I dropped the glove box and pulled the torque sensor plug from the ECU. Drove around the block. Later had the torque sensor plugged back in and the assist motor unplugged. Drove around the block again. Interestingly, either one naturally results in a manual-steering Prius, but neither one caused the MFD to display a PS code. Still, using the blinkenlight, I was able to confirm that codes ...11, ...13 (both torque sensor codes) and ...24 (a motor code) were present. Then I just imitated Vincent's CMND above, only with target address FE (which I gathered from somewhere is an 'all nodes' address) and waited to see what address the response came from. There wasn't any response. I also tried the same CMND with target address of 30, 31, 32, 34, 35, 36, and 37 which I understood to be a standardized address range for steering controllers. Also no response. What could be wrong here? Do I need to change something else in the cmnd? Would a brute force search of all target addresses (except 10, 16, and d5 which we already know) be sensible? Is it possible the EMPS ECU shares the same bus but uses a different comm protocol than the engine, HV, and battery ecus? Techstream talked to it when Vincent tested that, so we know there's some way of talking to it. -Chap
Sorry, I've not checked back for a while. The character should be a dash or hyphen. The txt files were exported from Excel as CSV (Comma delimited). The "," were then replaced by "|" to conform to PriusChat table format. Anyone interested can import into their own spreadsheet. Here are some new updates rev. 4. ECM ($10 - for North America and EU only) Short term fuel % trim-Bank 1 - Corrected hyphen Long term fuel % trim-Bank 1 - Corrected hyphen HV ECU ($16) Motor Current V - Value need to multiply by 2 Motor Current W - Value need to multiply by 2 Generator Current V - Value need to divide by 2 Generator Current W - Value need to divide by 2 Bty ECU ($D5) No. of Battery Block - New Onboard Charge Time - New Battery Low Time - Corrected PID, should be 98 instead of 97 Estimate of Ex Chrg Hour - New No. of Battery DTCs - Wrong, deleted Ignition On Hour - New WIN Control Power - New WOUT Control Power - New I don't know svn and may not help much. Anyway, the updates are not so frequent so I think it should not be a problem.
I've read that you've solved your problem. Thanks for sharing! To answer your question and others who like to know, yes, you should be able to read the ECM codes with addr 10. I 've not documented much on ECM because my Singapore version is different from US version on the ECM addr. I believe my ECM addr. is 13 on Right Hand Drive version but it is on 9600 baud rate. There is no setting for SGII to change baud rate.
I 've already tried the brute force search method some time back, it only found 16 & D5 for me. So, I think you will only find those 3 addresses. I believe all the rest of the ECUs are running at 9600 baud just like my ECM. I've built the Jeff Noxon's interface some time back and using 9600 baud, I was able to scan 13, 16, 29, 32, 33, 55 and 58. There are more from 80~FF but the software I used only scan up to 7F. Techstream has an OBDII Generic mode where it can only detect 16 & D5 just like SGII and any other Generic OBDII scanner.
UPGRADING the SCANGUAGE II with a 3.51? firmware .. does scanguage want to charge you a fee to upgrade to the 4.x firmware ???? has anybody done it ? i understand some of the Xguage commands can't be entered on the older fw ...
hello vincent! are these the most current and working PID's that will overcome the limitations you mentioned if i were to program xgauge?
Hi slimfrancis, Yes, the new RXF overcome that limitations, please find the most current list at this sticky or Google document. I already traded-in my '03 so some of the PIDs are incomplete. Vincent
Hi chronon, I think you meant firmware 3.15. According to their website: Firmware 4.x has support for multi-frame CAN messages which your Gen2 uses. Vincent
great thanks vincent! i programmed these into my scangauge 2 yesterday and they work fine. i appreciate the help!
Ok, it has taken me four years to follow up this fairly broad hint from Vincent, but I did try today with an ELM327 and confirmed that if you tell the 327 to use protocol 4 (ISO 14230-4 KWP 5 baud init), and tell it to run 9600 baud (IB 96), and give it an explicit address to init with (e.g., IIA 29), the init succeeds. I haven't achieved anything more in the way of conversation, but at certain addresses something is there. So far I've only tried the addresses Vincent suggested, and I did not find a 13, 33, or 55 (his Prius was Singaporean, mine US), but the other 4 were there. This may be partly moot in 2015 with so many people satisfied with MiniVCI/Techstream clones, but could still be of interest to people wanting to do less Techstreamy things, or just ambivalent about the cracked Techstream copies. (Also slightly OT for a ScanGauge thread, as direct ELM327 protocol commands aren't things you can do on a ScanGauge, but Vincent's post was here and there's probably no better place.) I also confirmed that the three ECUs we've already been happily talking with (engine, HV, and battery) are using ISO 9141-2 5 baud init/10.4 kbaud, not ISO 14230 as I had mistakenly believed at one time (even putting it in the NHW11 database on sourceforge ... will have to fix that). If you try talking 14230 at them, they'll have none of it. -Chap