I have the SOC and BTA working but not the soc and bta (passive) working. I am going to try to reset the xgauge feature as you suggested, but the car is off with the CEO at this time. I will have to try later.
Regarding version 1.4: On my 2006 Prius, with a current SG2, the mph and kph give readings that increase with speed, but appear to have scaling problems. mph reaches 1.00 at about an indicated 17 mph (possible factor of 16 error?). kph reaches something between 3 and 4 at the same real speed. Of course I may have entered the code wrong, but I compared it closely after observing trouble. Possibly it could be an interaction. Brake pedal position worked nicely, but was quite flickery--possibly a modest reduction in resolution would be perceived as an improvement. Observed range was 0 to 99.4--looks good. Four of the five "German" entries look good, and have plausible-appearing values. Both "Catalyser" values, ICE on time, and Mass Air Flow. Although at one time I saw flickery implausible values for MG2 torque, in the last few trials I see no displayed values at all. As I have not experimented with removing all other XGauges, this could be an interaction. But so far I've seen nothing plausible from the MG2 torque XGauge. Much thanks to Dan, and to others contributing.
Rats... I hadn't tested that 4 bit clip, so I was afraid of messing something up. If you look back in the thread you can get the original code for KPH and see if it works. 11011011
I just started adding some of the passive codes to my gauges... here's something interesting: so far the codes work on my from-the-"factory" SG+XGauge... but on the one I sent in to be *upgraded* to XGauge firmware I'm not getting any displayed values. This is independent of how or if I have them chained.
Ohh... I'll start... I'm testing this on a '07 Prius with ScanGauge Firmware revision 3.15. The unit was born with 3.15 and has never been upgraded. 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 v1.5 - 07-01-08: Found numerous MTH errors. Corrected conversion factors for kph to mph Corrected conversion factors for °C to °F I'm [post="114728"]mothballing my Prius tomorrow[/post], so unless the TCH has these codes, I'll have to shelve this for a while. After all the hacking and testing, I've settled on the following 15 XGauges in my tool chest. I have a uppercase/lowercase convention. All lowercase XGauges are the ones I've been playing with. HPR - Always wanted to watch this in a SHM glide. BTA - The AMP meter that SG originally published is the best I've found bps - Always cool to see the pedal sensors flicker kph - The car's speedo rounds up, this raw data is closer to actual mph - Sometimes I have to get off metric gps - Everything you ever hoped TPS would be but isn't. Stick this [post="116606"]at 14% and SHM is a breeze.[/post] rpm - Prevents the delay. You get real-time feedback before the engine does. soc - Using this one allows BTA and soc at the same time. buc - Finally, I get to read my battery temps. blc - The low reading of my battery temp. evb - There are times I can't remember if I have EV engaged. Now SG will tell me. wtc - Greater resolution than the default one, with faster refresh gas - No more guessing on the guess gauge. Much better granularity at your fuel level. cfe - Everyone needs there current FE on the SG. dfe - Everyone needs the daily FE on their gage as well. This leaves the other 10 empty gauges for me to start watching various bytes for MG1-rpm, MG2-rpm, and inverter-temp. These are the only three I would still like to have , well those and GForce, but I can't convince my SG to register it. 11011011
You might want to note if your version is 3.15 or 3.15*, because the asterisk makes a big difference. BTW, the MG2 torque xgauge someone provided in an earlier post won't work correctly. The MTH yields a range of -4 to +61.5 (not +/- 400) and the TXD and RXF are a mixture of PID request and bus sniffing. Also, 2's complement math won't work unless the scaling can be accomplished with the decimal point mover.
Interesting. I'm "3.15" - not "3.15*". Haven't tested any of the German XGs. I've kinda got what I'm interested in with the exception of inverter temp, MG1-rpm, and MG2-rpm. Yeah, 12bit signed numbers are causing grief for me right now. If I could be assured that the nibble following the 12 bits were zero'd I'd just gobble them up to convince the FW to sign extend. Looks like sign-extending is only happing on 8bit and 16bit numbers (unless my binary is phooey). I hear you on blowing the decimal in the MTH functions. I'd debated reworking all my MTH for prime-based ration reductions. Do you know if the MTH functions are being done in a 16, 20, 24 or 32bit register? What's the "popping" point? Is it using IEEE floating point notation? 11011011
Not IEEE floating point, at least not to the xgauge coder. If, after the MTH, the MSB (b15) is set, it assumes this is a negative number in 2's complement format. As far as overflow, bits greater than b15 are ignored but do not cause problems that I have noticed. But to be safe, I generally try to reduce the MTH multiplier, sometimes at a slight reduction in accuracy. Also, the decimal point mover does not round up. For 12 bit signed values, stuffing the lower nibble probably wouldn't help much since you're stuck with a multiplier of 16 that can't be dealt with using the decimal point mover. Unless, by sheer serendipity, the scaling works out to .1 or .01 after the lower nibble stuffing.
I don't know if I made a mistake in copying or if the provided numbers were just different at the time. My apologies Here are the values copied a moment ago from priusfreunde.de: Torque MG2 Value: -400 – 400 Nm TXD: 07E221C3 RXF: 056106C30000 RXD: 4010 MTH: 0001000AFE70 NAM: TM2 From what I understand of the conversation on priusfreunde.de it still seems a bit questionable what the gauge will display exactly. It's still in an experimental phase Regards,
The TXD and RXF make sense, but the MTH will yield a range of -400 to +6513, which could be correct. To debug this, change the MTH to 000100010000 and see what is displayed when MG2 is not turning. For the FEH, the "creep" feature results in a small amount of traction motor torque when stopped in D, which goes to zero when shifted into N.
As I understand it, this is asking for PID 0xC3, in MODE 0x21 from ECU 0x7E2. Any chance of finding the PID/MODE/ECU for MG1 torque? Ditto for MG1/2 rpm as well as (perhaps) inverter temp. 11011011
I'm afraid that's all the data I could find. To display MG2's rpm there's been some experimenting with 07E221C3 | 056106C3 | 3010 | 00010001C001 but the results are questionable to say the least. The result is more likely to be a product of some values of MG1 and MG2 combined and maybe not even speed related. Regards,
I think someone posted a way to handle 12 bit signed values in the priuschat thread that I started ahwile back... No idea if it works or not.
I'm getting dizzy just reading this! Makes me appreciate my CAN-View ... all I gotta do is push a few soft buttons on the MFD and I get everything you guys are having to work so hard for ... and then some. I respect what you're doing, and keep up the good work! Jay, I have a question for you, just curiosity: What are you hoping SG to do for you that CAN-View doesn't? Dan (and others): This may be elementary and I'm sure you know it, but in case not: MG1 and MG2 RPM can be calculated from ICE RPM and speed. Does the device give you that ability? The formulas: MG2 = MPH * 57 (Sorry, Dan, I know you speak metric, but I'm too lazy to convert it. ) MG1 = (3.6 * ICE RPM) - (2.6 x MG2 RPM)
