
ContinuousWave Whaler Moderated Discussion Areas ContinuousWave: Small Boat Electrical Indirect Fuel Tank Level Method

Author  Topic: Indirect Fuel Tank Level Method 
jimh 
posted 02282013 04:32 PM ET (US)
In an earlier article, Fuel Tank Level Measurements I described a general method for calculating the fuel level in a fuel tank based on monitoring and accumulating information about the rate of flow of fuel from the tank. At initial glance this process sounds simple. I began to design a method for monitoring fuel tank level using fuel flow information, collecting the steps necessary into an algorithm. I immediately began to see how complex the algorithm would become. My initial plan for the process is very simplified compared to what I would call a FUEL MANAGER function would actually need to accomplish. The steps are described only in general terms. The process would flow like this: Algorithm for a FUEL MANAGER function Initialize Phase Get capacity of tank from stored value TANK_CAPACITY Get present level of fuel in tank from stored TANK_LEVEL (range 0 to 100) Compute present TANK_VOLUME from TANK_CAPACITY x TANK_LEVEL/100 Fuel Run Loop Get flow rate from engine as FLOW_RATE Start timer countdown for interval TIME When timer expires, compute FLOW_VOLUME from FLOW_RATE x TIME Subtract FLOW_VOLUME from TANK_VOLUME and save as new TANK_VOLUME Compute new TANK_LEVEL from TANK_VOLUME/TANK_CAPACITY x 100 Store new TANK_LEVEL. Loop back to Fuel Run Loop, until user breaks into process This basic method omits many important details. Many additional functions not shown would have to be handled. An initial additional function is needed to handle in a consistent manner the units being used. The volume and flow rate data would need to be maintained using consistent units. The device sensing the flow rate would likely be calibrated in specific units. For example, in the case of a modern outboard engine with NMEA2000 data source, the modern outboard engine will be sending the flow rate in units specified by the protocol. NMEA2000 specifies the flow rate data be sent in units of 0.0001 cubicmeters/hour. The FUEL MANAGER algorithm can either maintain those units as the base for fuel volume, or convert them to a different unit for the base unit for volume. When data is to be displayed, there is usually an option to change the unit of measurement onthefly. This means that all displayed data is obtained by taking the actual stored values and processing them through another algorithm before displaying the values. The display process handles conversion of the units used so that the operator can change, say, from gallons to liters, whenever desired, and then change back from liters to gallons at some later date. All during this time the stored values remain in the base units. Other functions to be provided might be to track fuel usage over certain intervals, such as per day, per trip, or per season. These function requires additional stored data values which have to be incremented with fuel used volumes. In the main loop of the algorithm above it would be necessary to add a step like Increment FUEL_USED_TODAY, FUEL_USED_TRIP, FUEL_USED_SEASON with FLOW_VOLUME in the loop. These new values would then be stored and made available for display. Another function to be included in a FUEL MANAGER is the option to manage data for more than one engine. And, as a corollary, the option to manager data for more than one tank should be considered. Of course, the FUEL MANAGER needs a whole set of algorithms to permit the user to break into the execution and change certain values. For example, there must be some way for the user to enter the amount of fuel added to a tank. There also must be some way for the user to set the tank volume. And the user needs to be able to select the preferred units for the measurements. It takes only a few moments of thought to see how complex the algorithm for a sophisticated FUEL MANAGER function might become. There is a mistaken belief that seems to be widely held that modern outboard engines provide all of this functionality in their own electronics. This is typically never true. The modern outboard engines usually only provide information about fuel flow rate. All calculations of volumes used, tank levels, and other management is accomplished in an external electronic calculating device that provides this FUEL MANGER function. 
jimh 
posted 02282013 09:06 PM ET (US)
To compute the volume of fuel that flows in a particular time, we get the flow rate from the NMEA2000 engine sensor. The flow rate is given in units of 0.0001cubicmeter per hour. The volume unit of onecubicmeter is equal to 1,000liters. The flow units are thus more commonly expressed as (1cubicmeter/10,000hour ) x (1,000liters/1cubicmeter) = 0.1liters/hour The flow rate tells us the volume of flow in one hour. An hour contains 3,600seconds. If we integrate the flow rate every 36seconds, that is equivalent to 1/100th of an hour. This makes our math very easy. As an example, let us suppose the engine sends a NMEA flow rate of "378". This means the flow rate is 37.8liters per hour. (Or, in units of GPH, 10GPH.) If we integrate at a time interval of 0.01hours, we just divide the flow rate by 100 to get the volume. In 36seconds at a flow rate of 3.78liters the flow volume will be 0.0378liters. The fuel volume consumed in 36seconds at a flow rate of 37.8litersperhour will be 0.0378liters. This is the FLOW_VOLUME that is deducted from the TANK_VOLUME and added to the FUEL_USED_TODAY, FUEL_USED_TRIP, and FUEL_USED_SEASON accumulators. The process repeats every 36seconds. 
jimh 
posted 03012013 11:58 AM ET (US)
In the example above the incremental fuel used volume is 0.0378liter (or about 0.01gallon). This is a rather small amount of fuel. I believe that the normal MNEA2000 protocol parameter group for fuel tank volume may not be able to handle that sort of resolution in volume. I notice that devices like the Lowrance EP85R data storage device mention that the data they store is a proprietary highresolution fuel used parameter. The EP85R also stores proprietary parameters for TANK FUEL USED, TRIP FUEL USED, and SEASON FUEL USED. It seems like a sophisticated FUEL MANAGER function using the indirect method of fuel tank level calculation and tracking the fuel used volumes may have to resort to using proprietary parameter group number data to support all the functions they provide. Because these parameters are maintained in proprietary PGN's, they may not be shared among display devices from different manufacturers. For example, if you have a system using the Lowrance EP85R to track your fuel usage, you should not expect that this data would necessarily be able to be displayed on a Garmin multifunction display, and it would not be likely that you could manipulate the data, say reset a FUEL USED parameter to zero, on the Lowrance storage device by using a Garmin multifunction display. 
Powered by: Ultimate Bulletin Board, Freeware Version 2000
Purchase our Licensed Version which adds many more features!
© Infopop Corporation (formerly Madrona Park, Inc.), 1998  2000.