FirmwareWebsite
The logger's firmware provides (if enabled) a web server implementation that is used to provide a command API using the command set also provided on the serial interface. So that the logger's management can be conducted without any specialist software, the web server also provides a website that uses a combination of HTML, CSS, and JavaScript to provide a graphical interface for the core facilities of the logger (configuration, status, and data transfer) along with a general command interface that allows the user to send any valid command to the logger.
The website is defined in the directory tree rooted at LoggerFirmware/website, with directories for HTML (actions), CSS (css), JavaScript (js), and core assets (images). Due to a limitation of the web server implementation in the current Arduino stack, pages that require multiple loads (e.g., for a linked CSS and/or JavaScript) can fail randomly (specifically, if the server is still writing the output for one request when the second arrives). Consequently, the Python script in LoggerFirmware/website/inline_flatten.py is used to inline all of the resources required for each page, minimise the included files, and then re-write them in the PlatformIO staging directory (LoggerFirmware/data/website) used to make the flash filesystem image that's written to the logger on setup. This script should be executed after each change to the website; see the installation instructions for more information. If you have Google's Closure Compiler (and a Java runtime) installed, you can also use the shell script in LoggerFirmware/website/compile_website.sh to automatically minify the JavaScript before embedding it into the HTML document (this has the advantage of also copying over required images).
The website's default index page provides quick-link buttons for the various actions that can be taken in management of the logger, along with quick status information (versions, uptime, total file size, etc.). This index page, and the sub-pages are described following.
The main index page (index.htm) provides shortcuts for the most commonly used functionality, and then core status information on versions, uptime, total file space being used, etc.
The status information is generated dynamically by the JavaScript for the page (js/status.js) based on sending a status command to the logger and interpreting the resulting JSON. Note that like all of the other command-sending code in the website, there is a 0.5s delay (js/common.js, using after(delay, callable)) between the page loading and the command being sent. This allows the webserver to complete the page (and potentially a load for the icon) before the command is sent, avoiding overlaps in requests which have the potential to fail in the current implementation of the Arduino webserver.
The configuration page provides access to all of the key parameters associated with the real-time running of the logger (e.g., WiFi parameters, unique identifier, ship name, etc.)
The parameters shown are those returned by a setup command sent to the logger, and therefore reflect the current configuration. Command buttons at the bottom of the screen provide the means to load a JSON configuration from local storage, and to write the configuration on screen to the logger either as the running configuration ("Set Working Config") or as the "lab default" configuration ("Set Default Config") that can be used as backup if the current configuration fails for some reason. The "Download Working Config" and "Download Default Config" buttons can be used to snapshot the current configurations, and automatically download them to the browser's download cache directory (in JSON format). Details of the configuration parameters and process can be found here.
The logger maintains a real-time update of the current status, including the elapsed runtime (in milliseconds), the file information for the current log files that have been completed (the currently open file is not reflected), and the versions of the various components of the logger. The file ID numbers shown in the last table are hyper-links to the log files; clicking on the link will cause the file to be downloaded to the browser's download cache directory.
When the system is observing data on NMEA0183 and NMEA2000 interfaces, information on the critical data sentences on each interface, including what was observed and how long ago is shown in the "Latest NMEAxxxx Data" tables. This is current at the time the page is generated (i.e., when the automatic status command is sent to the logger), but can be updated manually using the button at the bottom of the page. The "Download Catalog" button will generate a catalogue of all files on the logger, and download to the browser's download cache (in JSON format).
In addition to the basic metadata on the logger (unique identifier string and ship name), the logger can also store arbitrary JSON-format metadata that will be included in the header of every log file generated by the system. In post-processing, this information is merged into the converted GeoJSON format file, and therefore can provide all of the IHO B.12 metadata for the host ship. Note that the logger does not mandate any particular format for the file provided, but stores and reproduces whatever the user provides. This might result in bad metadata being generated, and the use of the CSBSchema Validator is recommended. This is an automatic part of the cloud processing.
In order to allow each logger to maintain information on specific processing steps that might be required for its data, each logger can store a list of algorithm names and parameters that should ideally be applied in post-processing. The logger does not check the validity of the algorithms or their parameters, storing only what the user provides. These values are stored in each log file when it is created.
The list of algorithms shown is updated live from the logger using the algorithm command; when changes are made, the logger responds with the current list of algorithms. Note that it is not possible to remove individual algorithms from the list; the "clear list" button removes all algorithm requests.
By default, the WIBL logger will store every NMEA0183 sentence provided to it on both channels. On a busy network, however, this can result in a lot of information being saved to the limited resources of the SD card. The logger can, therefore, limit the list of sentences being recorded to those specified by the user. This page provides an interface to this functionality.
The list of sentence identifiers is updated live from the logger using the accept command; when changes are made, the logger responds with the current list of sentence identifiers. Note that it is not possible to remove individual sentence identifiers from the list; the "clear list" button removes all identifiers. More than one sentence identifier can be specified in the input box if required.
Any text entered into the "Command" input is passed to the logger as if it had been typed on the serial console connection; any output from the logger is displayed in the "Output" widget. The logger always provides output in JSON format over the WiFi interface, although the contents of the JSON can change depending on the command. On error, or if there is no formal JSON format for the output, a general JSON scructure with a "messages" array is provided.
In order to allow for authentication and/or handshaking with an upload server (e.g., when the logger is attached to an Internet-connected network in Station mode and can auto-upload its files), the logger can store an arbitrary ASCII string in the logger, which is used as the password for HTTPS BasicAuth authentication (the logger's UUID is used as username). The authentication page allows the user to specify the plain text token to store. Note that the logger does not attempt to validate the contents of the string (and neither does the website); it is simply stored on the logger.
The logger also uses TLS to secure the connection to the upload server, and therefore needs to store the Certificate Authority (CA) certificate for the CA that signed the server's certificate. This can be uploaded from a simple ASCII file (typically a base-64 encoded version of the certificate in X.509 format). Details of how to generate a self-sign certificate can be found in the firmware description. Depending on the browser, you may have to rename the certificate to a .txt ending for it to be selectable in the file browser.
The state of the currently stored token and certificate can be determined by the auth command.
The "Reboot" page's button executes the restart command, rebooting the logger. Note that this will cut off the WiFi network that your development computer is attached to, and therefore you may need to rejoin the network once the logger has completed rebooting, depending on the settings of your system.
