03' Classic Prius and scanguageII

Can we get one data point, say the combined MG1 rpm and torque, in hex and then translate to numbers?

If I can get MG1 rpm, torque in one data read followed by ICE rpm and MAF, even if video recorded, we can use the ScanGauge for Brake Specific Fuel Consumption mapping. We would have to record the data using a video camera for offline analysis, still, it would provide an approach.

Thanks,
Bob Wilson

 

MG1 rpm and torque are having the same RXF so can't be read together. However, you can calculate MG1 rpm from MG2 rpm & ICE rpm.

I still can't read anything from ECM but the address seems to be 10h according to this thread:

http://priuschat.com/forums/generation-1-prius-discussion/86129-master-warning-no-mil.html

If that is correct, you can try this for MAF:

	Column 1	Column 2	Column 3	Column 4	Column 5	Column 6	Column 7
0	XGauge	TXD	RXF	RXD	MTH	NAME	Notes
1	Air Flow rate into Engine	8210F10110	031044410510	2810	000100010000	MAF	XX.XX g/s

 

The part that interested me was seeing that it actually does do something useful for overflow on the positive side: it automatically changes from XXX.X format to XXXX and drops the tenths digit. (If that's not what yours does, maybe there's been a firmware change?) If it would do even just that same thing for overflow on the negative side, there should be plenty of room for -100 amps, right? That's just effectively the same format as your alternative without the RXF[2]&0x80 mode.

-Chap

edit: hmm, on the positive side I don't really think it's changing from xxx.x to xxxx; it seems to be changing from xx.x to xxx, because I didn't have to approach mach 1 to see it change, and it went from "99.9" to "100" when I hit 50 mph (because of the factor of 2 I threw in).

 

It is, and I have a list of some PIDs. Film at 11.

-Chap

 

The full story as promised (and it is about 11 here)....

A couple years ago I exchanged some email with Graham Davies of ECROS technology miniscanner fame, who was not quite eager at that time to publish the Gen 1 PID tables that he had worked out for the miniscanner.

But this past weekend I contacted him again, since Vincent has made such progress working out the same stuff, and asked him if he'd be ok with publishing a merged file of the PID tables from his and Vincent's work, and he agreed. So I wrote a little C program to link with his miniscanner table sources and dump the tables, and a little bit of Python to generate a similar format from Vincent's XGauge tables, normalized the conversions (e.g. putting mul and div always in lowest terms) and merged the tables into the attached xml file.

Each list has some things the other lacks. The miniscanner tables include some engine PIDs for the ecm at address 10h. Vincent included more battery stats. In the overlap, there are a few - remarkably few - cases of disagreement in the math conversions. I've flagged those places with comments to make it easy to improve the database by resolving those questions.

My thinking with the xml format was to be able to write snippets of XML Query or XSLT to generate any tool's desired table format from this one source. I'll attach an xgauge.xq script that does that to regenerate xgauge tables matching the format Vincent used.

I also annotated a lot of items with Unified Code for Units of Measurement syntax, so that it should be possible to use software that groks UCUM (say in a laptop-based scanner) to generate conversions for desired display formats automagically.

I hope this will be useful for those hacking on Gen 1 OBD stuff.

-Chap

p.s. please forgive the .txt extensions I had to add to the file names to be able to upload them.

 

Thank you so much! I knew there are bound to be errors since my calculations are based on observations.

Looking at your annotations on WOUT/WIN Control Power, I discovered the error in WIN which should be negative since charging is represented in -ve value. I figured out the scaling from this link:

http://priuschat.com/forums/generation-1-prius-discussion/79261-hv-ecu-auto-enginuity.html

	Column 1	Column 2	Column 3	Column 4
0	WOUT Control Power (W) (0 - 40800)	40800	40800	40800
1	WIN Control Power (W) (-40800 - 0)	0	0	0

This PID is a single byte therefore the multiplier should be 40800/255=160. I divided it by 1000 to convert to kW and added a decimal place. So, the final scaling should be 160/1000*10=8/5. The correct WIN Control Power should be:

	Column 1	Column 2	Column 3	Column 4	Column 5	Column 6	Column 7
0	XGauge	TXD	RXF	RXD	MTH	NAME	Notes
1	WIN Control Power	8216F101CA	0316844105CA	3008	00080005FE68	Pwi	- XX.X kW

There are also many differences on torque calculations. I 'll check it out.

 

I've already nominated this thread for "sticky" status and am willing to do it again. Unlike the Auto Enginuity, the $150-175, ScanGauge with vincent1449p, w2co, and now ChapmanF contributions has really opened up NHW11, user owned, scanning for both performance and maintenance. What I'd really like to see:

A ) consolidated HV, battery, and ICE table - master XGAUGE table

User 'vincent1449p' is the expert and a 1st post with this table that continues with update would be a great "Wiki-like" start. Like the 'stone soup,' the community can add additional data as time goes on.

B ) Early entry on ISO-9141 adapter

A collaborative effort, w2co, vincent1449p or I could provide a schematic and principles of operation description. This ensures anyone going with the ScanGauge would have the two key elements: adapter and XGAUGE programming.

Again, 'stone soup,' we would make sure folks are encouraged to add their experiences and feedback.

Now the simple answer is just make this thread a sticky as everything proposed is already here, although perhaps not as well organized as someone as anal-retentive like me would want. <grins>

Perhaps it is time to once again ask the moderators to make this the second 'sticky'. Heck, I'll even propose 'de-sticky' of the Auto Enginuity not because it doesn't have merit but rather this thread has more current and wider applicability to the NHW11 community.

Thoughts?

Bob Wilson

 

Thanks!

Let's be sure not to forget Graham Davies, who so kindly agreed to my including his miniscanner tables in the merged file, and that's a body of work obviously comparable in effort to vincent's. By contrast, there's really nothing in there from me except the conversion to xml, a bunch of UCUM annotations, and a couple alternative VehicleSpeed scales.

What I'd kind of like is for the xml file to be checked into a collaborative version control system somewhere, so there's one copy somewhere that people can add to and beat on. (The alternative of reposting slightly changed copies as later attachments to a forum thread doesn't seem as tidy somehow.)

Any thoughts on where such a version-controlled copy could be hosted? I do have a sourceforge account I haven't used in a couple of years and was only using to work on other people's projects, but I suppose if I can remember how to get into it I could create a new tiny project consisting of NHW11obd.xml and xgauge.xq, and it would be there for the community to contribute by adding to the xml file and/or adding additional scripts to generate tables from it for other tools besides the scangauge. I can look into that unless someone has a preferred place in mind for hosting it.

-Chap

 

I 've tested MG1 & MG2 Torque. It seems SG2 can't divide a negative no. correctly. When the torque is -ve, I'm seeing a very large no.

Example
SG2 reads -16 (FFF0h). After divided by 8, it should be -2 (FFFEh) but it is showing 8190 (1FFEh).

Can someone pls help to verify?

 

Ok, that may explain it. I programmed an XGAUGE to display MG1 torque but never got a value back. I bring it up but nothing. You're just showing the hex values, versus the decimal, right?

Thanks,
Bob Wilson

 

Thanks If it shows blank, pls check that MG1 or MG2 RPM is not selected at the same time.

Here are the Xgauges based on Graham's scaling:

	Column 1	Column 2	Column 3	Column 4	Column 5	Column 6	Column 7
0	XGauge	TXD	RXF	RXD	MTH	NAME	Notes
1	MG1 Torque	8216F101C4	0316044105C4	3810	000100080000	M1T	+/- XXX Nm
2	MG2 Torque	8216F101C2	0316044105C2	3810	000100080000	M2T	+/- XXX Nm

 

Urff, that's going to be a problem. 1FFEh is the correct answer when the value is assumed to be unsigned rather than twos-complement signed. Addition and subtraction are the same operations for both signed and unsigned, but not so for division; that's two different operations (for example, IDIV vs. DIV on an i386) and you have to know whether the parameter is meant to be unsigned or twos-complement to know which one to use.

That's why Graham's tables indicate the format of the parameter (actually he seemed to indicate it in two places, which I extracted as 'format' and 'ecros:kludge' and never figured out why he had both since they always matched). But if the xgauge programming format doesn't have any way to indicate whether to do signed or unsigned arithmetic, it seems like a serious oversight by Linear Logic that might just not be fixable without new firmware from them. All it would take is another magic bit in RXF. Without that, I'm not sure there can be a general way to get scaling right for twos-complement values given only one multiply, one divide, and one add to work with.

Phooey.
-Chap

 

So the divide by 8 turned out to be a shift >> 3 bits. including the sign bit?

This can be a little tricky to interpret. Say we divide by 2, all negative numbers become positive as the sign bit shifts down. Then the mapping gets weird:

• 0 == 0 :: thank goodness or we'd be going crazy
• 1<n<16383 :: positive torques, use as is
• 16385<n<32767 -> 32768-n :: negative torques

Well this could be a nice distraction while driving down the road.

Bob Wilson

 

Right, except for the torques we're really dividing by 8 so it's 8192-n for 4096<=n<=8191 and given the choice between doing that in my head or just leaving the display in hex I'd have half a mind to just show hex.

I think I probably will write to Linear Logic. There are two things now I think they could easily fix that would make the gadget a lot more useful:

• Define another special bit in a high nybble of RXF to specify that the MTH should be signed
• Support simultaneous display of xgauges with the same RXF

Maybe if they received enough suggestions to that effect, they'd make an upgrade available on the same $25 mail-in basis they used when they introduced xgauges.

-Chap

 

Feel free to use my name too:

Robert J. Wilson
625k Inc.
9011 Randall Road
Huntsville, AL 35802

I would add that programming should not require initialization of the vehicle OBD controllers first. Programming should work with a simple 'wall wart' power supply. This would avoid the diode and 9 V battery hack we're using to carry them into the house.

Finally, horse power is a function of torque times rpm and a constant. We get both torque and rpm in the RXF from MG1 and MG2. We need someway to do math from two fields in the same RXF to directly read out horse power.

Bob Wilson

 

Ok, let me try to get the wish list straight in one place:

• Please assign a bit in RXF (or some other way) to flag a value as twos-complement and do the MTH accordingly.
• Please support simultaneous display of xgauges with the same RXF.
• Please make the /10 and /100 display modes overflow gracefully (dropping the decimal places) for negative values the way they already do for positive ones. (Just remembered this one from earlier this thread.)
• Please allow programming menus to be used whenever power/ground are present whether or not communication is initialized with any ECU.
• Please allow an xgauge to be defined as a mathematical function of other xgauges.

I think these are pretty much in order by the most important (and by coincidence easiest) toward the top. I'd bet they can do the first 4 without any radical rethinking of their design. I wouldn't be surprised if they balk at the 5th one (they'd need to figure out the UI for programming it, and the basic operation of the scangauge would then have to allow for possibly more than 4 values to be polling for, not just what's on the display, etc.) and I don't know what sort of uC they're using or how much memory they have to play with, etc. But we can always ask.

Am I leaving anything out?

-Chap

 

This is one of the better threads for an affordable, scanner.

Bob Wilson

 

This is the key to reading NHW11 codes from the Prius:

The other night I threw a code but only had my Scangauge, not the Auto Enginuity. This would have quickly shown it was the same, intermittent code that I had gotten before.

Bob Wilson

 

I've looked over a good amount of this threads history and my head is spinning. I am an education person I will say but some of this seems WAY over my head. I have a scanguage II I havent looked at the maual is a LONG time. I have called Linear Logic several times and they've always been most helpful. I do belong to the Milwaukee Hybrid Group and have access to a number of very helpful individuals but I have not been able to attend many of the meeting lately. So this chat forum really helps me out. So that being said I really do need some more advice about the xguage part of the scan guage. I think before I sound stupid I better read my book again. I'll check my firmware and all sorts of stuff. In the guage mode I rum RPM, MPG, ft, and LOD. With a hybrid that's 9 years old what else should I be looking for? Is monitering the SOC with scanguage essential at this stage in the cars life. I want ot drive my car till it doesnt drive anymore so if I can moniter it better please let me know. Thank you.