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

Post New Topic  Post Reply
search | FAQ | profile | register | author help

Author Topic:   Indirect Fuel Tank Level Method
jimh posted 02-28-2013 04:32 PM ET (US)   Profile for jimh   Send Email to jimh  
In an earlier article,

Fuel Tank Level Measurements
http://continuouswave.com/whaler/reference/fuelTankLevel.html

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 NMEA-2000 data source, the modern outboard engine will be sending the flow rate in units specified by the protocol. NMEA-2000 specifies the flow rate data be sent in units of 0.0001 cubic-meters/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 on-the-fly. 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 02-28-2013 09:06 PM ET (US)     Profile for jimh  Send Email to jimh     
To compute the volume of fuel that flows in a particular time, we get the flow rate from the NMEA-2000 engine sensor. The flow rate is given in units of 0.0001-cubic-meter per hour. The volume unit of one-cubic-meter is equal to 1,000-liters. The flow units are thus more commonly expressed as

(1-cubic-meter/10,000-hour ) x (1,000-liters/1-cubic-meter) = 0.1-liters/hour

The flow rate tells us the volume of flow in one hour. An hour contains 3,600-seconds. If we integrate the flow rate every 36-seconds, 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.8-liters per hour. (Or, in units of GPH, 10-GPH.) If we integrate at a time interval of 0.01-hours, we just divide the flow rate by 100 to get the volume. In 36-seconds at a flow rate of 3.78-liters the flow volume will be 0.0378-liters. The fuel volume consumed in 36-seconds at a flow rate of 37.8-liters-per-hour will be 0.0378-liters. 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 36-seconds.

jimh posted 03-01-2013 11:58 AM ET (US)     Profile for jimh  Send Email to jimh     
In the example above the incremental fuel used volume is 0.0378-liter (or about 0.01-gallon). This is a rather small amount of fuel. I believe that the normal MNEA-2000 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 EP-85R data storage device mention that the data they store is a proprietary high-resolution fuel used parameter. The EP-85R 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 EP-85R to track your fuel usage, you should not expect that this data would necessarily be able to be displayed on a Garmin multi-function 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 multi-function display.

Post New Topic  Post Reply
Hop to:


Contact Us | RETURN to ContinuousWave Top Page

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.