0 RPMs

Yep.

Not sure what 'other' would be, but I'm sure there is something. Initial startup I guess, unless you have the EV button.

 

Along these lines I have noticed that when rpm goes to zero the MPG is often mph * 10 or in my case somewhere around 3300mpg and GPH = 0.01. If the rpm shows approx. 990rpm then MPH = 9999 and GPH = 0.0.

I'm still trying to figure out what causes this condition. I can't remember how the arrows are working in these conditions or if they are completely absent. This is after the vehicle has reach stage 4 (completely warmed up and over 180deg. F).

 

One thing to consider is that the ScanGauge is capable of displaying information with a higher resolution and a higher update rate than the MFD. So, for example, when the SG displays a mileage of 100 MPG or more, the MFD will clip it to 99 MPG.

Remember that the software that controls the MFD is using the same data stream as the SG, but the MFD software reduces the rate at which this information is presented to the user. This can sometimes be confusing, especially if you are trying to compare the MFD with the SG in real time. Being a non-critical operation, the engineers decided what they thought would be an appropriate update rate on the MFD without overburdening the processing requirements (in other words, too much information can just be a waste of processing power, especially if no one is watching it).

Many Prius owners aren't happy with the trade-off--we would like more information and more detail, which is why the SG works out for us.

- Doug

 

I've seen this sort of thing on my SG2. It appears to me that when the engine _actually_ goes to zero fuel flow that something in the update path ending on the SG2 display actually stops updating--so the last value transmitted is held. Often 0.00, sometimes 0.01, and occasionally 0.02. I think the right thing to do is to regard them all as meaning 0.00.

On some forum I've read someone with experience of multiple Scangauge models and firmware releases asserting that this has not been true of all firmware versions, but it certainly happens to many SG2 users with current firmware driving 2004+ Prius.

I'm not sure of this, but think that Xgauges installed (even ones not currently selected for display) may alter this behavior (i.e. what fraction of the times it goes to zero it displays zero). If you are curious, you might try deleting all current XGauge entries and reporting whether you see a change in how often this happens.

 

With no XGauge entries, both the two year old firmware and the current firmware will show 0.02 and sometimes 0.01 (and in my case it's l/hr), so I suspect it's in the Scangauge firmware to prevent divide by zero. Divide by zero is death for processors. It was Kirks favorite way to beat computers.

If the engine is spinning without fuel it will read 0.01 and if the engine is stopped it usually reads 0.02, in my case in l/hr.

Oh, and one "other" is the engine will be run to keep the cat. converter warm, if it cools off for some reason.

 

Well, not hardly. Even the lowly 8086 had a divide error interrupt. It was up to the software to bother building an error handler to service that condition appropriately, but certainly the processor did not even approximately commit suicide.

True it is that many pieces of software don't handle some overflow conditions properly.

For one particularly spectacular example, check into the chain of design decisions and development paths that terminated in the first Ariane 5 blowing up about forty seconds down-range. One (of many) links in the chain was a routine for conversion from a floating point value to a 16 bit integer. In this case the value to be converted went out-of-range, and no suitable error handler existed. The error _was_ actually caught, but lacking a suitable handler the generic response was to shut down the guidance computer and start transmitting diagnostic codes instead of navigation information.

The next bit of hardware/software upstream had no provision for noticing this condition and processed the diagnostic codes as if they were navigation information. After a very short period of very large deflection gimbal movement the vehicle developed enough angle with respect to the local air stream to fail mechanically--which was noticed by the flight termination system which finished the job by blowing it up in hopes that small bits would cause less damage below than would large bits.

Oh, and the decision not to build an error handler was a conscious one--they lacked enough spare resource to protect every case, and decided this one was safe--but conditions changed, and it became unsafe without anyone noticing.

As a USA resident, I leave my SG2 on mpg and gph. When gph displays 0.00 mpg displays 9999 and the summing stuff acts as though it thinks the real consumption is zero. the non-zero gph values are paired with less than 9999 mpg, and the summing parameters clearly act as though they think it non-zero.

I don't think this is a case of divide by zero avoidance deliberately undertaken.

(personal history note:I was a design engineer on the 8086, and got involved in fixing a divide error interrupt bug on the 8088 derivative part)