I’ve been wondering whether this is worth doing.
A fuel totaliser transducer is a rotating turbine. This should be measuring volume flow (not mass flow). But at a low temperature the fuel will have shrunk in volume, so the transducer will be under-reading the actual volume which has passed through.
Temperature expansion of Avgas is around 0.1%/degC. So if say you have 100 litres in your tank(s) at +20C, you climb to -10C, the tank cools to -10C, you have a 3% volume shrinkage, then when the transducer says 97 litres have passed through it, your tank is actually empty.
It is like a delivery of 100 litres at -10C is worth 3% more to you than a delivery of 100 litres at +20C. And they do show the fuel temp on the pump ticket…
And 3% is not abnormal in GA.
Admittedly anybody cutting things this close is going to get into trouble one day, but why have such an inaccurate instrument, when adjusting the pulse rate for the fuel temperature would eliminate this?
For actually making use of this you not only need to adjust the flow rate but also enter the fuel temperature at start. That (and the temperature measurement in the transducer) adds another possibility for error/failure.
It is extremely rare that you fuel up with 20 deg fuel and then fly at the levels long enough that the fuel cools down to -10 during the flight – and even then only a fraction of the fuel will pass the transducer at -10. Therefore the assumption that the majority of the fuel will pass the transducer roughly at the temperature it was tanked at is not too bad.
Improving the accuracy for quite rare situation by adding a potential for error on every flight is typically not a safety enhancement measure…
A flight departing in +20C and spending 5hrs in -10C is not at all uncommon.
Also the fuel will cool down to the OAT very quickly, due to the high airflow velocity.
My maths is not good enough for this; maybe @DavidS might be able to make an estimate 
I know someone that was flying an Extra 500, which has a fuel temperature gauge. He says it very rarely went near/below 0° C (which is why he was not very worried/diligent in putting FSII in the fuel). My guess was that the composite airframe was a far better thermal insulator than my metal one, and thus continue to religiously put FSII, always, even though the planes are otherwise broadly similar in mission profile.
Also seeing how frost and icing clings to the bottom of my wings when (after a high altitude flight) flying through (non-freezing) moisture, makes me think that the freezing energy of all that water is what has heated my wing, and my fuel within it.
I don’t see this as much of an issue, the numbers quoted are the most unfavourable and yet we get a 3% error.
As most of us operate well away from the quoted temperature extremes and I would guess most like me put a contingency of 5% into fuel calculations so a 3% error at the far ends of the operating regime is only of academic interest.
Just as a point of interest the fuel flow indicators on airliners are probably the most accurate indicators on the aircraft with calculated fuel uplifts being within about 1.5% of actual uplift ( even when another 40 Kg is pumped on the round up the numbers ). Airlines keep a very tight eye on individual aircraft fuel burn as irregularities point out other problems with the aircraft it is usual to base these calculations in the fuel flow numbers recorded in the Tech log rather than the bill from the fuel company simply because the aircraft fuel flow indication is considered to be the most reliable data.
My incentive in this is to get the system as consistent as possible. This thread refers, mainly.
It is probably the absence of temperature correction which is responsible for most of the annual variation shown here.
The above chart is old: 2013. If/when I get time, I might update it to see if the annual pattern continues.
The implementation would be interesting. A totaliser just counts pulses. The transducer emits say 28500 pulses per USG. Simple! How would one apply say a 2.3% correction on that? In a hardware implementation in the frequency domain, you would upconvert the pulse frequency to something much higher and then have a counter which counts off pulses to be dropped. In this time domain pulse counting scenario one would probably implement a 2.3% delta by counting off 100/2.3=43 pulses and then add one or lose one.
Isn’t that what the reserves are for?
The main reason that it is a massive no-no to dip into the final reserve (and a mayday if your estimated landing fuel on board at the alternate drops below this) it that even with all the real-life errors you may encounter you are still safe.
So I would definitely correct a known fixed error (as you did when you moved the transducer) but not really worry much about a small variable temperature error.
Sure, but why not make something better (by up to a few %) if it is just some software?
I’ve been wondering how to implement that. Obviously you want a temperature sensor on the flow transducer itself, which is easy. Then you want to add or subtract some % of pulses, with the % of pulses added or removed depending on the deviation from (say) +15C.
