Here is a guest blog post by one of our contributors, Gil Markham. Wanting precise fuel consumption calculations to strategize pit stops, Gil integrated a precision fuel flow sensor into his RaceCapture/Pro telemetry system. In this article he describes how he developed it:
By Gil Markham
We’ve been racing in amateur endurance racing (Lemons, Chumpcar, Lucky Dog Racing) for the past four years. In that time we’ve had plenty of ups and downs but have steadily made progress on making our car faster, more reliable and easier to drive. In addition, as we’ve accrued more seat time and have become more competent drivers, we’ve been able to safely push our car closer to the limit.
We haven’t been good about analyzing telemetry data to improve our lap times, but it does play a big part in our race operations. Before installing a Race Capture Pro, the driver had the sole responsibility to spot issues with the car through mechanical gauges, if something seemed amiss then it generally meant a pit stop to see what was up. With the addition of a Race Capture Pro and live streaming to Podium, our drivers can now concentrate on what’s in front of them, using predictive lap timing to understand if and where they’re losing time. Instead of glancing at gauges every lap there is a warning light powered by the Race Capture Pro that indicates when something is out of line with our expectations. If that light comes on the driver can simply radio back to the pits where the problem can be identified through live streaming and appropriate measures, if any, can be used to remedy it.
Although we’ve felt comfortable with what our Race Capture Pro was providing us, there was one area that was costing us that the Race Capture Pro wasn’t providing much value. Fueling and fuel consumption was somewhat of a guessing game which depended on track conditions, yellow flags, the aggressiveness of the driver in the car and if we managed to actually get the tank full during the previous pit stop. Getting this wrong one time led to a car that ran out of fuel before making it back to the pits, costing us a race win. This led to us being more paranoid about getting the tank full which in turn increased our pit stop times costing us on track position.
In the off season we decided to fix that with a few changes. First, we fixed some venting issues with our fuel tank which was causing it to take fuel slower over the last few gallons. This would have solved the problem with guessing if the tank was full but it didn’t solve the risk of one of our drivers running out of fuel. Sure, we have a fuel light and a fuel sender tied to the Race Capture Pro but these have always proven to be an approximations at best, often times indicating that no fuel is left when there is actually two gallons in the tank. In addition, there has been more scrutiny over fuel spills by marshals during pit stops and our new filler has the propensity shoot fuel out quickly when full.
Telemetry to the rescue! Rather than approximate and guess our fuel consumption we added a new sensor to our telemetry arsenal, a FloScan fuel flow sensor. For those that aren’t familiar, a fuel flow sensor (or transducer) measures the amount of fuel that travels through the sensor on it’s way to the engine. Companies like Sentronics make high end motorsports fuel flow sensors for the likes of Formula 1 and the FIA World Endurance Championship, these are out of the price range of a low budget crap can race team. However, the marine and aviation industries also heavily use fuel flow sensors. The reason being, just like a race car, it sucks to run out of fuel and with your boat bobbing in the ocean (like a race car constantly braking, turning and accelerating) it’s hard to get an accurate measurement of what’s left in the tank. Instead, you simply total the amount of fuel consumed and compare that with how much you put in the tank to know what’s left.
Without getting into the specifics of how the fuel flow sensor works, there’s a few different designs, most generate a pulsed output where each pulse indicates that a specific amount of fuel passed through the sensor. The amount of fuel per pulse is known as the sensor’s K factor. In our case, we use a FloScan 201A-6 aviation sensor which has a K factor of 32,000 at 16 GPH. (An alternative part is the Electronics International sensor) This basically states that when 32,000 pulses are generated by the sensor, 1 gallon has passed through. To utilize this we provided power and ground to the sensor and plugged the sensor’s output wire into the Race Capture Pro’s second Pulse/RPM input (RPM is in Input 1). We also added a supplied pull-up resistor between the sensor output and the Race Capture Pro’s 5v reference. Then we proceeded to configure the second Pulse/RPM sensor input as follows
we also set the maximum value to 300 by clicking the gear icon next to the channel name. The actual maximum of the sensor is <max gph>/<seconds in an hour> * <k factor>, or 30 / 3600 * 32000 = 267 in our case.
Unfortunately, this only gets us part way to what we want, a running total of fuel consumed. While pursuing this I happened to know of an undocumented Lua script command in the Race Capture Pro, getTimerCount, that returns the count of pulses a Pulse/RPM input channel has received. I pinged the Autosports Labs team about it only to find that it was a feature that wasn’t fully implemented in the current firmware. Although it would be possible to approximate the total consumption using the pulse frequency, it would yield a less accurate result due to a few factors regarding how frequency is calculated. Being a software engineer by trade I rolled up my sleeves and implemented the missing code in the firmware, ‘getTimerCount’, along with ‘resetTimerCount’ should be available in current firmware releases. With ‘getTimerCount’ we can write the following in Lua script to create a running fuel total.
-- Fuel Totallocal fuelSensorChannelId = 1 -- Fuel Flow sensor Pulse channellocal fuelKFactor = 32000 -- K Factor of sensorlocal fuelTotal = 0 -- Running total of fuel consumedlocal fuelLastCount = 0 -- Previous pulse countlocal fuelTotalChanId = addChannel("FuelTotal", 10, 2) -- Create a fuel total virtual channel --setTickRate(10) -- Calculate the amount of fuel used since the last call.function updateFuelTotal() -- Get the current pulse count from the Pulse/RPM channel local timerCount = getTimerCount(fuelSensorChannelId) -- Determine if the pulse count was reset back to 0 since the last time -- we checked, if not calculate the number of pulses since the last update if fuelLastCount < timerCount then local countSinceLast = timerCount - fuelLastCount -- Update the current fuel total fuelTotal = fuelTotal + (countSinceLast / fuelKFactor) -- Set the virtual channel with the updated value setChannel(fuelTotalChanId, fuelTotal) end -- Update the last count value fuelLastCount = timerCountend function onTick() updateFuelTotal()end After this the next thing to do is test, fill the car full, run it for a duration and compare the fuel total provided by telemetry with the amount needed to fill the car. Although the manufacturer provided K factor should be a good starting point it’s best to test and adjust the value to get as accurate as possible. In our testing we found that our values were off, however this was due to the fact that we powered the sensor from the 12v provided by the car. A noisy alternator can cause erratic sensor output, which was visible in our Freq1 graphs, so we will be moving to the 5v output of the Race Capture Pro in the future.
What does all this provide? While the car is out on track we can easily determine how much fuel is remaining in the car. In addition we can calculate the average fuel rate of the driver and determine if he/she needs to change their driving to make the full planned stint. Finally, we can pre-stage our fuel jugs with the correct amount of fuel needed to fill the car. This allows us to pour fuel in as fast as we can with less risk of getting penalized by the marshals for leaking fuel as we top off the tank.
How do you subtract out what’s going back to the fuel cell on the return line? Or are you running a returnless system?
In this case it’s a returnless system. With a return based system, you would use two sensors and calculate the difference between the sensor flows.
Great article – Thx! We were just thinking about how to do this on our AER E36 M3.
Great write up! Any update on how this has been working out for you? Has there been any added updates for this sensor to the Racecapture firmware?
It’s been running great; we have extremely precise fuel level calculations, which was tested during the last race at Laguna Seca.
Since then we’ve had many firmware and app updates; see the recent blog posts: https://www.autosportlabs.com/blog/
So is this still required with the current firmware or can we rely on gettimercount?
Hi, getTimerCount is now available in the latest firmware. Thanks!