Saillogger Community

Hi @Andrea, not sure if I could fully follow. Do you mean propulsion.port.runTime was available in Signal K with fresh data and it didn't show up in Saillogger?

Could you capture this when it happens?

Hi @Andrea, it is hard to debug this from the screenshots, as it appears there may be multiple factors at play. I am not entirely sure Smart Battery Sense works with Signal K, since we do not have one to test, but one thing to check is the frequency of its updates. Something feels off there.

For Saillogger, it watches these signals and checks their age. If they are fresh, it processes them; if not, it ignores them. Saillogger uses one-minute granularity for data but allows a bit of buffer time since not every source emits data regularly. That said, any reliable source should definitely send data every minute; otherwise, it is not ideal for monitoring purposes.

Hi @Andrea, when you see these in Data Browser, how fresh is the data? In other words, can you confirm the timestamps are being updated and are recent? It’s possible the data you saw was older and retained in Data Browser history. Saillogger normally only logs data that is fresh (less than about a minute and a half old), so if the data is stale, Saillogger won’t pick it up.

Hi @Andrea unfortunately no, all custom monitoring values are displayed in the same format like the second one. The latter one is specialized for reporting the house/main battery.

There is a monitoring option that will automatically convert these to hours, just choose "Duration" while you are adding it.

@Andrea you should be able to use /vessels/<RegExp>/propulsion/<RegExp>/runTime which is the total running time for engine in seconds. This will show up as something like propulsion.0.runTime in your Signal K. You can add this to your custom monitoring and look at the delta between the last tracepoint and the first one. Not the ideal UX but it will be automatically logged for you.

Hi @JeremyJed and @Andrea, Saillogger can track engine hours by adding them manually to your monitoring data, and they will be part of your trackpoints. This way you can see the engine hours at the beginning and end of the trip by clicking on those trackpoints.

However, this can certainly be improved. We always aim to provide the best UX, and it is important for Saillogger that things “just” work. We are working on making this an integral part of the log that works automatically (for example, Saillogger can detect when you are sailing or motoring, handle multi-engine scenarios, and give meaningful stats). Creating the right experience is a bit involved, and we did not have a good test bed for this until recently. We finally installed sensors on our twin Yanmars (running the N2K cables was the hardest part), and this is now at the top of our list of new features. It needs proper thought and testing since it is an important feature.

Automatically tying it to fuel consumption is more complex. The math is simple, but there are many scenarios that must be accounted for in order for it to work well. For example, fuel sensors are not always precise, logic must account for multiple tanks, transfers between tanks, additional equipment like generators drawing fuel, or swells causing fluctuating readings. We aim to provide a great UX, so this will likely not be part of the initial version. A better approach may be to rate the engines’ consumption and associate it with conditions like those above. This aligns with @Andrea’s note. It is possible but not a trivial implementation.

Taking a step back, and to summarize, you can already monitor engine hours and tank levels, and we will improve the experience as soon as we can run experiments on our test bed. Fully automated stats that provide smart insights into fuel consumption will likely take longer, until we can convince ourselves that the data is really good.

Thank you for your interest and for such an insightful discussion!

Hi @Andrea , looks like Victron is not sending that reason. Are you sure it is available in your NMEA 2000?

Hi @jimholthaus, moorage name lookup in Saillogger is a multi-layer process. It uses four to five different types of logic to identify a moorage name, which can come from GIS sources, community-added moorages, or external references like Wikipedia.

Moorages are created automatically, but once they exist, renaming them is straightforward as Kevin mentioned. Please let us know if you’d like any help with that.

Hi @Sparohok , @jimholthaus 's suggestion is a good one. Please try it.

Beyond that, the behavior is definitely not normal. We will need to simulate your account here and run some tests. I will see what we can do about it but please try the above suggestion first.

Hi @stiggy, do you see the paths available on Cerbo’s Signal K? You can check in the data browser. If they show up there but not in Saillogger, make sure Signal K is configured with an MMSI and restart after making any changes. If it still doesn’t work, enable debugging in the Signal K Saillogger Plugin and check the logs.

Hi @Sparohok, thank you.

This is definitely unusual, Saillogger normally eliminates all those starting points automatically and works without any issues. You’re clearly observing something different.
Having a position all the time is actually a good thing, so that won’t cause the issue, but I suspect it has something to do with that USB GPS.

I presume you have a GPS source on your NMEA network (chartplotter, AIS, etc.) that comes online before you start moving. If so, can you configure a priority so that your USB GPS is always the lowest priority and only used when nothing else is available?

Go to Signal K → Server → Data Connections and, using the Priorities table at the bottom, configure priority for your navigation.position and give higher priority to NMEA sources (make sure your instruments are on while you do this). Put the USB GPS at the bottom, and set a timeout of 5 or 10 seconds.

It will look something like this:

Make sure you restart Signal K afterwards and let us know what happens on your next trip.

Hi John, this is a great catch. It was actually updating the starting log, but the track you were seeing was from the cache. In other words, it would have started showing correctly once the cache expired in approximately an hour. Anyhow, it was a bug and we’ve just deployed a fix. Thank you for the report.

Hi Bill, thanks for pointing this out. It turns out that this was a logic issue on the server side, we just fixed it. Please try again and let us know if you see any issues.

Hi Thomas, it is indeed what is mentioned in the FAQ. It takes an hour to finalize a trip, so if you turn on your Raspberry Pi for just a few minutes, it will autocomplete. Alternatively, keep the Raspberry Pi on a bit longer after you complete your trip.

Hi @TargaDriver and @Voodoo, thank you both for the suggestion.

We understand the desire for more granular tracking in certain situations. That said, a key part of Saillogger’s design is full automation, sampling frequency is part of the core logic and is dynamically adjusted based on context.

That said, we recently deployed updates to improve how frequency adapts, including better handling of maneuvers beyond just speed changes. Let us know how it helps you. We’ll also log a ticket to explore additional enhancements, such as incorporating vectored charts to help Saillogger recognize when maneuvering occurs near islands, ports, channels, and other complex areas.

Hi Brian, thanks for the note.

There’s no direct way to link a missing track, but we may be able to help. Have you added any monitoring logs since the last missing segment that’s covered by the GPX file? If not, please send us the file and we’ll see if we can import it for you.

If you’ve already logged anything since that missing segment, unfortunately this won’t be possible, as Saillogger’s state will have changed and will require deep surgery to import that track.

Hi Brian, replied over e-mail but I suspect Venus 3.63 upgrade will not help as Signal K configuration is persisted across upgrades. There is no harm to try though.

Hi @SV_Atlas, a factory reset should be the last resort. First, try a clean install of Signal K—step‑by‑step instructions are in this post: https://community.saillogger.com/topic/111/new-install-wont-start/2?_=1753236272577

Let us know if that doesn’t resolve the issue or if you need help with any of the steps

Hi John, I thought we had addressed this as part of this thread. Isn't it working as expected?

In general, if you are moving fast, the granularity is automatically adjusted and can be as high as every minute.