To explain in more detail about the ERP-85R, I offer some additional remarks:
Fuel Flow Data from EngineThe fuel flow data being sent by a modern NMEA-2000 engine that sends NMEA-2000 PGN 127489 has no data about FUEL VOLUME. That PGN has no field for fuel volume, and the engine cannot send fuel volume in its data.
The data that comes from a modern engine is not a volume of fuel but a rate of fuel flow. In order to obtain a total volume of fuel used, the rate of flow has to be integrated into volume. This function is performed by an external device that is usually called a FUEL MANAGER.
With the (now obsolete) I-Command or Lowrance LMF series digital gauges, the FUEL MANAGER function was provided by a device that was separate from the display devices. This separate device was called by two misleading names. Lowrance called it a DATA STORAGE MODULE, and Evinrude called it a MEMORY MODULE. A few years ago Lowrance realized their name was misleading, so they renamed the device to be the FUEL DATA MANAGER.
The exact method used by the FUEL DATA MANAGER alias DATA STORAGE MODULE alias MEMORY MODULE alias ER-85R is not described by Lowrance anywhere. My GUESS is that the device periodically samples the data about fuel flow rate at a regular interval.
For example, let us say the sample interval is every 10-seconds; the integration of fuel flow rate into fuel volume would then work like this:
- the engine sends data that says the fuel flow rate is 4-gallons-per-hour
- this flow rate is assumed to be constant for the last 10-seconds
- the FUEL MANAGER takes this data and computes a volume of fuel consumed in the last 10-second as 4-gallons/1-hour x 10-seconds x 1-hour/3600-seconds = 0.011111-gallons
- this value is then added to a previously stored value of FUEL USED
In this way the external device called the FUEL MANAGER or other names, accumulates a totalized volume of fuel use, repeating the integration and totalization function every ten seconds (or at whatever interval the designer of the device decided to use).
As you can easily infer, the duration of the sample time can affect the process of integration of flow rate to fuel volume. The more often the FUEL MANAGER samples the flow rate data, the more likely the computer total volume of FUEL USED will be correct.
It should be clear that when the engine sends the flow rate data, it is done with its part of this function. The data from the engine is created by the engine's control system. The presumption is that the flow rate data is derived in the engine control system by using the stored fuel map algorithms that actually run the engine. The data derived this way should be very precise. There are only two ways the actual fuel flow might not match the expected pre-calculated fuel flow: if there is a fuel supply restriction, the engine might be running leaner than it wanted to run; or a fuel injector might malfunction and not spray enough fuel. In the other direction a fuel system leak could result in the engine using more fuel than it wants to. This could occur, for example, if a fuel injector malfunctioned and was spraying too much fuel into a cylinder, or if there were a leak at any point in the fuel system where fuel was spilling out.
Sensing or Computing Fuel Tank LevelNow none of this has anything to do with how much fuel the instrument tells you is in the fuel tank. There are two methods to deduce tank level:
direct tank level measurement, and
indirect tank level measurement by monitor outflow of liquid.
Direct Tank Level Measurement by SensorThe tank level can be deduced by direct measurement of the level of the fluid in the tank using a sensor. The calibration of this actual tank level sensor is outside of anything to do with a modern NMEA-2000 engine. Usually the sensor converts an electrical signal such as current, voltage, or resistance into a NMEA-2000 digital datagram. A NMEA-2000 sensor will typically be capable of being calibrated to associate the input electrical signal with a certain tank level, such as empty, full, and one or more partial-full steps in between empty and full. The calibration of the sensor is typically provided in a gauge or display that is made by the same manufacturer as the sensor, and the gauge or display will have a software routine to perform the calibration with input from the user.
Indirect Tank Level Measurement by Flow Rate DataThe tank level can also be inferred by tracking the flow of fuel from the tank, and deducting fuel from the tank level as it flows out. The method can be implement in two ways: with a direct sensor that monitor fuel flow, or by using engine flow rate data.
Fuel flow on the output hose of a fuel tank can be routed through a flow sensor, usually a mechanical spin-turbine sensor which creates an electrical signal proportional to flow. This is converted to a NMEA-2000 datagram and sent as a fuel flow rate. Sensors of this type can often be adjusted or calibrated to improve their accuracy. The calibration process usually involves make adjustments to the firmware in the sensor that is converting the electrical signal into a flow rate, and typically the manufacturer of the sensor will also make a suitable display or gauge with a user interface so the calibration can be accomplished.
The fuel flow data can also be taken from a modern engine, for example, from an E-TEC. The engine sends a NMEA-2000 datagram that gives the fuel flow rate. (More details below about this datagram and its units.) The flow rate is integrated over time to get FUEL USED data. The FUEL MANAGER computes the TANK LEVEL by deducting most recent increment to FUEL USED from the previous tank level. Note that the previous tank level is just a value in software, which was initially SET by the OPERATOR. If the operator set an improper value of fuel in the tank, then all future calculations of tank level using this indirect method will be wrong. When fuel is added to the tank, the operator has to invoke a procedure to ADD FUEL, and then enter data into the FUEL MANAGER to tell it how much fuel was added.
For several years I have had an E-TEC engine and three ways to determine fuel tank level:
--a direct indicating tank level gauge operated by a float mechanism in the tank;
--a Lowrance EP-85F FUEL DATA MANAGER that used fuel flow data from the E-TEC to track fuel volume used and tank level; and
--an ICON Pro RPM gauge with its own FUEL MANAGER that also used fuel flow data from the E-TEC to track fuel volume used and tank level.
Of the three methods, the direct indicating gauge was always reliable and had good accuracy.
The ICON Pro RPM gauge was always accurate, as long as I, the operator of the boat, was 100-percent diligent and 100-percent accurate in entering data about the fuel level in the tank at the start and any fuel added to the tank.
The Lowrance EP-85R was generally not reliable at all until, after about a year of fiddling around with its software revision levels and its network power supply management, I finally got it to work reliably and accurately.
Now all three sources of fuel tank level on my boat agree quite closely. The Lowrance and ICON fuel managers differ about 1 to 3-percent in their calculations of FUEL REMAINING. I can only suspect that this difference is due to the difference in the algorithms being used, the difference in the sample intervals, and differences in their math routines to handle very small numbers.
Variation in FUEL REMAINING calculationsIf more than one device tracks the fuel remaining or tank level, the situation is like the old saying about a man with two watches: he never knows what the time is. That is, the two (or more) methods of tracking fuel used come up with different answers.
To understand why there could be two devices that track the FUEL USED using the same method (integration of flow rate data over time) and the two devices come up with different values for FUEL USED, I can see several variables.
The first is the time between samples of the flow rate. If one device samples every 60-seconds and the other every 6-seconds, the device with more granularity in samples might be more accurate.
Another possible cause of variation is the handling of the mathematics. The NMEA-2000 protocol calls for the flow rate to be sent in units 0.0001 cubic-meters/hour. There are 264.172-gallons in one cubic meter and 3,600-seconds in one hour.
If a modern engine engine is idling along at 0.2-GPH, the flow rate in cubic meter would be
0.2-gallons/1-hour x 1-cubic-meter/264.172-gallons
or
0.000757082506852-cubic-meters in one hour.
Now if the sample time is every 6-seconds, then the volume used would be
(0.000757082506852-cubic-meters/3600-second) x 6-seconds
or
0.000001261804178-cubic meters
The FUEL MANAGE has to do some addition, adding this value of fuel consumed to the running total of FUEL USED. This involves a lot of addition of really small numbers, and I suspect this is where some errors might occur. If the math is not done to many, many decimal/binary places, some rounding errors could occur. That is a rounding error every six seconds of running time. Over ten hours of running time that means 6,000-rounding errors. Maybe that adds up to a possible variation of a few percent in the outcome.
You might ask how can there be an error in arithmetic in a modern device? All this math is being done in binary arithmetic, and that means the numbers have even more places, more like 50-places. How accurate the addition and subtraction becomes depends on the algorithm used. Maybe the code in one device is more elegant and strict than the code in another device. And that accounts for a difference of one or two percent in their outcomes.
The other place were an error can occur is much easier to understand: the operator did not correctly input the initial tank level or any subsequent additions of fuel. This is more likely. This is particularly true because if a mistake is made in data entry of fuel added, there is no method to correct the mistake in the gauge's options. For example, if 10-gallons of fuel are really added to the tank, but the operator enters the fuel added value as 11-gallons, that mistake cannot be corrected. Or the mistake may go unnoticed.
The only error in fuel added entry that can be fixed (if the operator notices the error) is entry of a value that is less than actual; you just repeat the fuel added routine and add more fuel to make up the difference. If you make a mistake in data entry and enter too much fuel, there is no recovery. If you forget to compensate for this mistake, you eventually might run out of fuel because the FUEL MANAGER is working with bad data.