ScanGaugeII work on 2010?

It definitely can suck quite a bit of power, however, the 10A number above is a worst case scenerio... 90+ degrees outside and a car that had been sitting in the sun so the interior was probably well over 100.

But the amazing part (to me, at least) is that the Prius uses a variable compressor, so after the interior had cooled down, even though it was still 90+ outside the compressor was only drawing around 3A.

On the way in to work this morning it took even less power because the interior was already cool because the car spent the night in the garage and it was only in the 80's outside. The compressor cycled on and off, taking 0A at times and only 1.8A while it was running.

I posted another thread here and did a bit of research and it looks like the compressor runs at the battery's nominal voltage of 201.6, so that's what I used in the formula. I verified this by turning the car on, but leaving it parked and watching the total draw on the battery as I turned the AC on and off. When I turned the AC off the total draw went down by about the amount it was showing the AC compressor was using.

Also note that this number only shows the current draw for the AC compressor... the blower motor can take up to an additional 2A when it's running on high. But again, because it's variable it only draws a fraction of an amp at the lower speeds.

 

Brett, thanks for sharing your findings! That is really useful to know that the AC compressor power usage is related to the difference between set temp and room temp.

I'll feel less guilty about AC dragging down my FE now.

 

I notice there are Xgauges for ICE RPM and MPH. Is there any difference between using these or using the RPM and MPH gauges that are already in the ScanGaugeII?? I have been using the SGII gauges and they would seem to be correct, should I enter the Xgauges and use them instead?

 

I use the built in ones too. The codes in the spreadsheet where extracted and all were logged.

 

The ones on the spreadsheet are passive xgauges, meaning they update at around 60fps. I use the RPM passive Xgauge and I love how it has a very high refresh rate. But really there is no difference other than that.

 

What you are saying then is the passive Xgauge updates faster than the stock RPM gauge? Sorry if I seem a little dense. I am on quite a learning curve with this tool, but I am enjoying it.

Dave

 

Normal gauges on the SGII work be sending a command to the car to query a value then waiting for the response. That's why they come in about once per second. Passive XGAUGEs work by just snooping on information that is already present on the car's network. Speed and RPM (And many other things) are constantly flowing across the network at a very high refresh rate, so the SGII listens for the information and displays it in realtime. RPM and the Speed update about 60 times per second as that information is constantly flowing. Other information like individual wheel speed, steering angle and g-force flows at a very high rate of speed because this and other information is used by the stability control computer to determine what you and the car are doing -- once it figure you are skidding it sends commands to the brake computer to apply individual brakes to help control the car, etc.

The car's network is constantly abuzz with massive amount of data being shared among the computers.

There was a passive XGAUGE on the old Prius to read battery state of charge because the computer that controlled the battery was connected directly to the shared CAN BUS (network) but on the Gen III they hooked the battery computer directly to the hybrid computer so you can no longer just snoop on the signal. On the old car the hybrid ECU was constantly getting updates about battery condition so you could just listen in on that traffic.

The Gen III must have some kind of battery information on the bus already because the battery level is shown on the gauge cluster ... The gauge cluster either queries for the batter level or the Hybrid computer sends up regular updates to the cluster. Either way we should be able to monitor that -- but with so much data flowing it's hard to decipher what is what.

Luckily we now have a XGAUGE for that anyway that queries the value from the hybrid computer.

Your speedometer on your car reads the same speed information off the network ... in fact, I'm sure you could take a gauge cluster from a car like the Toyota Corolla and hook it up to the CAN bus on the Prius and it would work, with the gauges showing RPM, Speed, coolant temp, etc etc. The information is there but the Prius gauge cluster does not display it.

Toyota uses many of the same codes from car to car to simplify components across different car lines. Like the Tire Pressure Monitoring computer on the Prius is probably the nearly identical part to one used on other cars.

 

Thanks for your very good explanation. It was very helpful. I did enter the Xgauges and saw the refresh rate being significantly faster. Now I guess I need another ScangaugeII as I want to monitor 7 or 8 gauges and am having difficulty choosing which 4 to choose. :doh:

 

I believe the ScanGauge version of MPH does not have the high bias that the dashboard display is required to have.

 

I have found on my car that the ScanGauge MPH is fairly accurate whereas normal dashboard readout is about 4% fast.

 

Anyone know why the Cruise Set Speed was not completed? I don't have a Gen3 but I 've some experiences in creating Xgauge for the Gen1.

Below is what I think the values are:

	Column 1	Column 2	Column 3	Column 4	Column 5	Column 6	Column 7
0	Gauge	TXD	RXF	RXD	MTH	NAM	Notes
1	Cruise Set Speed	07E22121	02EA05610621	3808	3D09623A0000	CSt	MPH

 

I have also found the CAN speed to be spot on when compared to the GPS speed from my phone. I just don't get why Toyota would add on a percentage onto the gauge cluster. I have tested several other cars lately (with analog gauges and my phone's GPS) and usually they are spot on or maybe 1 or 2 mph fast at 70mph. It seems most of the rentals cars were spot on...

Was the Gen 2 off like this as well?

And I wonder if there is this problem in other localities -- or just the US? Clearly this is in the firmware of the gauge cluster as I'm sure the cluster is reading the same passive data on the bus as the passive XGAUGE. I wish there were a way to calibrate the the speedo to remove this error.

 

I never finished reversing the data... Your Gen 1 XGAUGE doesn't work on the Gen 3. 3808 seems to return something that changes depending if I'm in reverse or not. 4808 seems to have something to do with how hard I'm pushing the brake pedal.

Another byte returns the car's actual speed ... just matches the OBD-II MPH PID. I will have to check this more to see if it locks this byte when cruise is set to the set speed while MPH continues to fluctuate ..... hard to test without going on the freeway. I think it was 2008 though I can't remember right now.

Another the bytes seems to have at least 1 bit set when cruise is set or not set ...

Your math helped -- I will do a little more investigation. Thanks!

 

Yes the Gen2 was fast by about the same amount. I guess Toyota is just being extra careful not to violate the U.N. regulation that says speedometers can't read slow. Why the U.N. wastes our money promulgating such regulations is a discussion best reserved for the political forum.

Look at Specifications in section 5.2.5.

 

It is so much more convenient to whip the UN for European standards (notice the lack of anything from North or South America on the country list at the bottom of page 6) than to look at our own homegrown rules.

 

While configuring my new ScanGaugeII I came up with the following question.

For C to F temperature conversions the MTH is shown as:

00090005FFD8 for F and 00010001FFD8 for C

Reading the XGauge Coding manual from Linear Logic, this is interpreted as:

For F this is multiply by 9, divide by 5 and add -40 if I convert Hex to Decimal.

For C this is multiply by 1, divide by 1 and add -40.

What am I missing here ? I am just curious trying to remember my Hex to Decimal conversions from way back

 

Let V = Value read by SGII.

C = V - 40

To convert C to F,

F = 9 * C / 5 + 32

F = 9 * (V - 40) / 5 + 32

F = 9 * V / 5 - 72 + 32

F = 9 * V / 5 - 40

Vincent

 

Vincent,

Thanks so much for the explanation. At least it lets me know I was doing my conversions correctly

Any idea why V is reported in this format rather than directly in C units?

Dwight

 

If you look at the RXD, xx08, means this PID has 8 bits or 1 byte of data. The range of 1 byte of data can be from 00h ~ FFh or 0 ~ 255. If it were to report directly, the temp. range would be from 0°C ~ 255°C. So in order to represent negative temp., the offset of 40 (sometimes 50) have to be added.

Vincent

 

Yes, excellent explanation Vincent. I think they do this to facilitate easier conversion.

Otherwise if the car was giving you regular temp C (Tc):
Tf = (1.8)*Tc+32

Since the SGII doesn't support floating point, you would have to use:

Tf_10 = TC * 18 + 320

MTH 001200010140

So 20C would give you 680F. You could then use the RXF to move the decimal place over by one so you would end up to 68.0F It's just slightly less clean because if you are using a display device that doesn't have the ability to manipulate the decimal point or cannot do another math operation after the initial then you are stuck.