Looks like there was indeed a problem with zoom. This has been addressed and a fix has been deployed. Thank you for bringing this to our attention.
Global Moderators
Forum wide moderators
Private
Posts
-
Timelapse customization and video saving -
Timelapse customization and video savingHi 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.
-
Embedded real time tracking in webpage -
Discontinuous position - speed without dampingWhat 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.
-
Discontinuous position - speed without dampingDiagnosing 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.
-
Discontinuous position - speed without dampingYou 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.
-
Discontinuous position - speed without dampingSaillogger 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.
-
Real time wrong position -
Real time wrong position -
Want to mix different data types in "Real time monitoring" section@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.