jglot project overview

nakterhus collects the data of a sailing boat and presents it as charts, instrument displays, dashboards and a logbook. It runs on a Raspberry Pi 4 on board and subscribes to the boat’s SignalK server. Every received delta is written to SQLite, so a passage can be examined after the event. The name is the Swedish word for binnacle.

The command tree is defined once and is available both in a shell and in a console in the web interface. Dashboards are written as HTML fragments and rendered by two renderers, the browser and a native renderer for the e-paper panel; a test compares the two results.

The system is designed for a metered 4G connection. A camera stream is an ffmpeg process that runs only while a client is viewing it, clients outside the boat’s network receive a lower frame rate and resolution, and a phone page that is not visible stops polling.

Features

• Charts based on OpenStreetMap and OpenSeaMap, with route overlay and AIS targets. For each target the closest point of approach is calculated.
• Seven workspaces: Navigate, Helm, Plan, History, Voyage, Dashboards and Sail. They are selected with the digit keys and remain mounted when another workspace is shown.
• Playback of recorded data. The graphs and the track on the chart are positioned by a common time cursor.
• Sail trim guidance: the current point of sail, a reefing recommendation, and an ordered list of trim steps with the reason for each.
• The data source, boat or simulator, is detected and cannot be set. Simulated data is marked in the interface.
• A phone page that can be installed as an application and keeps the display on.
• An e-paper repeater of 800 × 480 pixels at one bit per pixel, updated once per second.

jsail simulates a sailing yacht and shows the quantities it has computed. The model covers the aerodynamics of the sails, the hull, keel and rudder, and the wind, current and waves acting on them. In motion the boat is integrated in six degrees of freedom. The rudder angle is solved together with yaw, so weather helm and broaching are outcomes of the model and not parameters.

The simulation does not depend on the display. A headless build provides the same computations as a command-line program for polars, timed runs and checks of boat files.

Features

• Force display: the load on each strip of sail, the pressure distribution along the luff, streamlines coloured by speed relative to the wind, and the righting and heeling arms in metres.
• Eight trim controls, each with an Auto option. Controls left on Auto are optimised around the values that were set manually.
• Instructor mode for a poorly trimmed boat. It gives one correction at a time, with the reason, the expected gain in knots and a marker on the control concerned.
• Trim changes are applied at the speed of a winch, and the speed lost in a tack is a result of the model.
• Boat files record the origin of every value as declared, calculated or estimated. jsail boat check lists the estimated values.
• Conditions outside the limits of the boat are reported as such, for example that no sail configuration can be carried in 14 m/s of wind.

rakemooner records what a Klipper printer does during a print and keeps the record for later review. Moonraker reports the current state of the printer; rakemooner adds the history. A daemon samples temperatures and their targets, heater power, fans, speed and the humidity of the filament enclosure once per second, and stores the console output, the bed mesh and the webcam video with them.

The web interface replays a print from a single time cursor. Moving the cursor in a chart also positions the readouts, the current G-code line, the 3D toolpath and the video.

Prints are assigned to projects automatically. A model version is identified by a hash of its meshes. The settings that changed between two prints are read from the configuration block that the slicer writes at the end of the G-code.

Features

• 3D toolpath drawn as boxes with the actual width and height of each extrusion, in a single draw call. A ten-hour print has about 1.5 million of them.
• Toolpath colouring by feature type, speed, height, filament slot or any other recorded field.
• Comparison of two prints, with a list of the settings that differ.
• Slicer workspace: slices the slicer project of a print again with changed settings, using the OrcaSlicer command line, and compares print time and material.
• Workspaces remain mounted when another one is shown. The webcam stream continues and text that has not been saved is kept.
• Dew point calculated from the temperature and humidity in the filament enclosure.

bidibok controls the Qidi Box, the unit that feeds a Qidi Q2 printer from four spools and dries the filament. It provides the functions of the printer’s touchscreen as commands, so they can be used in scripts, and as a library crate for other programs.

A simulated printer is part of the project. It executes the G-code it receives against a model of the box, with the timing of the firmware: a load operation blocks for several seconds, a drying cycle heats the box, and the humidity falls. The tests and the screenshots on this page use the simulator.

Features

• Reports the state of the box and of each slot, including sensors, endstops and heater.
• Loads and unloads filament; starts and adjusts drying cycles.
• Reads the RFID tag of a spool and assigns filament type, colour and vendor from it.
• Shows filament colours as 24-bit swatches. They are omitted when the output is not a terminal.
• User-defined filaments are kept in a local file and overlaid on the printer’s list by index. After a firmware update has replaced the printer’s list, preset sync writes the user’s entries back and leaves the stock entries unchanged.
• Exit codes separate failures that may succeed on a later attempt (1) from failures that will not (2).

jbuilder is a development tool for solid models that are defined as Python scripts using build123d. It watches the script and rebuilds the model whenever the file is saved, from any editor.

While the script runs, a trace hook records which source line creates each face, edge and vertex. This record connects the geometry in the viewer to the source code. A face that later operations do not change keeps its original line through subsequent cuts and fillets.

Features

• Source navigation: selecting a face, edge or vertex in the viewer shows the line of the script that created it.
• Selector suggestions for the selected shape. Candidate expressions are generated and evaluated, and only those that resolve to exactly that shape are returned: at most three, the simplest first. The suggestions come from a deterministic algorithm.
• Selector input with highlighting of the matching shapes and a match count while typing.
• Line preview: selecting a line number displays only the geometry created by that line.
• Checkpoints: a call to show() in the script defines a named, coloured intermediate state. It is rendered only when it is selected.
• Constraint sketcher that can be opened on any planar face.
• Scratch buffer that shares the namespace of the model.
• Neovim plugin: build errors are reported as diagnostics, and the viewer follows the cursor.

jcat displays images in a terminal that implements the kitty graphics protocol. It is an interactive viewer with zoom and pan, and it can also be called by other programs to place a single image.

modelrender is a second program in the same project. It renders a 3D model as a sheet of views with the hidden lines removed. A depth buffer is rasterised only to determine which edges are visible, and the result is written as vector paths.

When modelrender is installed, jcat opens model files in the same way as images, for example jcat bracket.stl. Progress is indicated while FreeCAD tessellates the model.

Features

• Zoom with the mouse wheel; pan by dragging or with the hjkl keys; n and p move between the files given on the command line.
• The image is transmitted once. Each zoom or pan step is a placement command of a few dozen bytes, and the terminal performs the scaling.
• Vector formats are rasterised at twice the screen resolution.
• SSH sessions are detected, and the image data is then streamed instead of being passed as a file.
• tmux is supported with a separate method: Unicode placeholder cells, an image pyramid, and two alternating image IDs so that no blank frame is shown.
• --place draws one image into a given block of cells and exits. Other programs use this to display images.
• modelrender produces up to nine views of a model on one sheet, with hidden lines removed. All views of a sheet have the same scale. The output consists of vector paths.

jpim manages todos, appointments and notes. It is designed as a layer over the directories, notes and source files that already exist, and not as a separate place for them. Items can be created through any of the interfaces or declared in a file.

All functions are provided by a daemon over HTTP, and every endpoint is available as a CLI command. The other interfaces use the same commands.

Features

• Directives in files: a comment such as @jpim { kind = "todo" } in any text file defines an item. The file remains the authoritative source, and editing the line updates the item.
• Files are modified only on request. jpim can then write an eight-character identifier into the directive, so that the item is still recognised after the line has been moved.
• One quick-add syntax in all interfaces, with #tag, @place, +project and due:. Example: varnish the tiller #boat @boatyard due:fri +marigold.
• A command bar, opened with :, in the terminal interface and the web application. It accepts any jpim command.
• A due date without a time refers to the end of that day.
• The calendar in the terminal interface is the output of the CLI and has no separate implementation. Its markers can be told apart without colour: a dot for an appointment, a diamond for a deadline, a triangle for an overdue item.
• Places are defined as named circles on a map. A todo can be assigned to a place.

jphone makes the functions of an Android phone available on a desktop computer: text messages, contacts, camera, location and device status. It consists of a command-line program, a terminal interface and a web application on the computer, and an application on the phone.

The phone does not connect to a dedicated server. The Android application logs in over SSH to a restricted login shell and keeps one long-running wait command open, which serves as the push channel.

The terminal interface and the web application do not read data files. Each view is built from CLI output and each action runs a CLI command, so every function exists once and can be used in scripts.

Features

• Five sections: Messages, Contacts, Camera, Location and Status.
• The SMS composer counts the parts of a message while it is typed. It identifies the character that changes the encoding and reduces a part from 160 to 70 characters.
• Photos are displayed as images in the terminal.
• Photos can be taken from the computer. Comments and tags are stored in the JPEG file itself.
• Location: a current position fix on request, recording of tracks, and a ring at full volume that also sounds when the phone is silenced. The ring is stopped with a button on the phone.
• Messages are marked as read only when they are displayed in a visible view.

jstatus shows status information as dashboards in a terminal. A dashboard is a tab, and a tab consists of widgets in framed panels that are arranged in nested boxes. Dashboards are defined per computer, because the relevant information differs between a laptop and a server.

A daemon monitors the configured hosts continuously. The duration of an outage is therefore correct even if no dashboard was open while it occurred. A dashboard reaches the daemon through an SSH connection, so access is controlled by SSH login.

Features

• Widgets for the local machine: processor load and its history, memory, sensors, disks and disk I/O, network, and processes.
• Widgets for other sources: reachability and latency of hosts, recent jlogger entries, the jpim calendar, a clock, and command, which frames the output of any program.
• Layout editor with the key bindings of a tiling window manager: v and s split a panel, HJKL move it, two marked panels can be swapped, and changes can be undone. A wireframe shows the layout at its size in terminal cells.
• Widgets reduce their content in a documented order when space is limited. A chart becomes a sparkline and is then omitted, and table columns are removed in a fixed sequence.
• The sensors widget does not query an idle graphics card, because the query would prevent the card from suspending.
• A configuration file with errors is shown as a tab with a warning. The other dashboards are not affected.

jlogger receives log entries from the machines and scripts of a private network and stores them in one place. Typical sources are scheduled jobs, backup scripts, sensors and printers.

Each entry is stored together with the hash of the entry before it. The chain starts at an entry whose predecessor is the string genesis. A change to any stored row invalidates the hash of every later entry, so the modification can be detected and located.

Features

• Verification: jlog verify checks the chain and reports the id of the first entry that does not match.
• Additional protection against modification: a second, append-only copy of the log, and a service account without capabilities.
• Any host on the network can submit entries. A client can sign its entries; the server verifies the signature before it accepts a signed entry.
• The command that submits an entry always exits with status 0. A log server that cannot be reached does not cause the calling job to fail.
• Log content is treated as untrusted. It is stored unchanged, and the viewers escape control characters and bidirectional override characters when they display it.
• The web viewer requests new entries every three seconds. When the list is sorted by a field other than time, new rows are not inserted; the viewer shows how many are waiting.
• Filters for host and minimum severity. The web viewer has seven themes.