Hi Jeremy,
This should work; we've just tested it. I suspect the issue might relate to how the customized Timelapse is being started. Could you try starting here: saillogger.com/timelapse/customize?
The Timelapse should display the same way in the recording as it does on-screen. However, please note that customizations you do on the map itself after the Timelapse has started (such as changing the base layer or zooming in) may not appear in the recording, that is expected.
What were the timestamps for navigation.position? Timestamps are critical here. Signal K may display positions even if they aren’t being refreshed, but Saillogger will only use positions if they are actively refreshed. When you encounter an issue like this, please verify those timestamps.
Generally, there’s no technical reason why a GPS position in Signal K wouldn’t appear in Saillogger. Saillogger retrieves data directly from Signal K, so as long as the position is present and refreshing (refreshing is essential), it should definitely capture it.
Diagnosing the root cause is challenging by reviewing the log alone. This log confirms that no position reports were received, but understanding why requires local troubleshooting on Signal K. It’s almost certain that Saillogger did not receive position reports during this period.
As you point out, possible causes include hardware issues or overheating on the Raspberry Pi, especially if it lacks heat sinks. The Cerbo GX and Ekrano GX have undergone more extensive testing for this purpose and are expected to be more reliable.
When plugin debugging is enabled, additional details will appear in the Signal K server logs. However, these logs aren’t accessible from the cloud instance, so you’ll need to review them directly on Signal K. If you can share the logs here, we’d be happy to provide further insights. Be sure to collect them while the issue is occurring, and check the Signal K status page for any indicators, such as a static number of entries in the queue.
You can simply share the link to the log. For this problem though, troubleshooting may be necessary when you're underway and lack Internet connectivity.
The Saillogger plugin displays a status on the Signal K home page, showing information such as, "1 entry in the queue; last connection to the server was 8 minutes ago."
Entries in the queue represent data cached locally until an Internet connection is available. When the plugin is working and connected to the Internet, the number of entries in the queue remains low—typically below 2 or 3—as data is transferred to the cloud every couple of minutes, which is dynamically adjusted. If there’s no Internet connection, the count will gradually increase. This isn’t an issue; those entries will upload to the cloud as soon as the plugin detects connectivity.
However, if there’s no Internet connection and the entry count isn’t increasing, there may be an issue—possibly with GPS availability or readings from NMEA 2000 instruments. Enabling plugin debugging for Saillogger can provide insight into the issue.
Saillogger does indeed buffer data locally when there's no internet connectivity, and this feature is widely used by many of our users. Could you share a bit more about what you’re observing?
Regarding the second point, we use some dampening to filter out outliers. However, its effectiveness can vary depending on the number of outliers and the precision of the instruments. So, while it helps, it may not be entirely foolproof.
@mshulman Unfortunately, that is by design for now. There are a couple of things that make it tricky. Units are shared across all values in a block, so displaying a 38 F and 32% in the same block becomes fairly complicated, both for conversions that need to take place (i.e. SK uses kelvin behind the scenes) and the display on the page. That is the reason blocks share a single unit at this point.
@Brazen-Article , that can be done but requires some thinking. We will file a feature for backlog.
Hi, the heading discrepancy you're seeing is likely due to the difference between navigation.headingTrue and navigation.courseOverGroundTrue as reported by Signal K. Monitoring and trip logging can use either value based on specific logic. Could you compare these two readings and check if they diverge? Assuming they do, check the sources they come from, there is probably a misconfigured device on the NMEA network.
As for speed, it should be synchronized. When reviewing your last log, we didn't observe the boat speed dropping to zero, although the wind speed was zero. Could you provide an example of a log where the boat speed reads zero? Both monitoring and trip logging rely on the same data keys for this, so there isn’t an apparent reason for them to differ.
