Raymarine forum

Full Version: [TG11] Axiom fuel/trip manager resets erroneously
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
This is an Axiom 12, connected to a Cummins QSB through the factory Mercruiser NMEA2000 interface. The behavior is inconsistent, but consistently worng:

After power up the "Day" figures represent yesterday. After perhaps a minute gallons used and hours run reset to zero. Shortly after, the month reset to zero as well. Sometime after the engine is started, both change the gallong used to the amount in the "trip" line. This is fairly consistent, but with some variation. The engine sends only current use data (gal/hr).

Where does one report these bugs?
Hello jfitch,

This is the right place to report such problems.

My interpretation of what you're seeing is:
  1. At power up, display doesn't yet have time information from GPS, so uses the latest time that it had (yesterday's)
  2. Once the display gets a GPS fix, it has time info and so resets the day's data to zero. I am guessing that the update-rate on the trip info is only relatively slow in order to avoid unnecessary system load, hence taking a minute or so.
  3. (I'm not sure what's going on with the month data, unless the last-used date was last month - can you confirm that this is consistent even when the last usage was this month?)
  4. the Fuel Manager software updates the displayed values when the displayed value changes, which in metric systems is once 1 litre of fuel has been used. I don't know the increment when units are set to gallons, but I think that the trigger for the fuel-used values to change will be that a certain volume of fuel has been consumed. When you say that this is the same as is in the Trip line though, what is this value? Has the Trip been reset, is that today's usage or is this some larger, accumulated value? I have seen sudden, large fuel-usage increments based on misleading information coming from engines several times.

I would really need a recording of the raw NMEA3000 data in order to see exactly what was happening - good technical dealers have the hardware and software to look at/record that data, and if you can get a recording of the traffic, we'd be happy to have a look.

In the meantime, I'll play some fuel data into my bench test Axiom and see if I see any anomalies.

I've played with it a bit more, trying different power up sequences. It does take about a minute after a GPS fix is available for the day to reset. Though occasionally this reset does not happen. The GPS source (internal or external) seems to make no difference. The month fuel used usually resets to zero, then often resets again to the amount used for the trip. The daily sometimes resets to the amount used for the trip, but often stays at zero and accumulates usage as it should.

I've tried waiting to turn on the engine (which introduces its NMEA data). I've never seen the fuel values reset to the trip figure until the engine is on (however these changes sometimes occur many minutes after boot up, so I could be missing it). The gallons remaining estimate is always "-.-" until the engine is turned on - this is odd as the engine has no knowledge of this. The initial mistaken resets of fuel used will happen even with the engine off, so the engine NMEA data is not responsible for those - all Raymarine. There is some fundamental but in the initialization.

I have a Maretron NMEA2000 bus snooper, but it's on the sailboat, not here. I'll bring it next time but that might be next year. I' try to take a movie of what is happening.

I'd like to see this facility work, as it would be most useful for fuel management on the powerboat if only it did.
A video would be good, thanks. What would really answer the questions either way though would be a recording of the raw NMEA2000 data from power-up, covering the time when the problem occurs.

We come across problems every single day where what people presume is in the NMEA2000 traffic is not what's actually there, but perhaps that's not the case in this instance. If you can get some raw network traffic whilst the problems are occuring that would be great. In the meantime, I willl test this with simulated data tomorrow and see what I can replicate in controlled conditions.

Reference URL's