GunLink Software Release Notes

Gunlink Software Release v 3.0.0

This release is a major update to the Gentoo operating system and all packages associated with it as well as significant advances in the Gunlink Software. This document will emphasise some of theses changes from the previous 2.5.2 patched system but for a full guide please see the updated operators manual available through Gunlink Web.

Linux Operating System

The host and display machines now run Linux kernel version 2.6 rather than the previous version 2.4. and a much more up to date version of the Gnome desktop software. Most of the enhancements to areas like memory stick handling should be obvious but you may find some items have moved in the main desktop menus. We have also pruned the collection of installed programs to remove obscure items not required on a gun controller and speed up installation times. There are also major changes to the way the node's (GCUs, IWMs, TEMs) file systems are arranged and they also now run Linux version 2.6. See here for a bit more detail on this. Further noticable changes are:

• PDF Printer driver has been added. You can now print directly to a PDF file which can then be transfered or stored as you desire. There are instructions in the full operators manual PDF.

Hardware Support

The much newer kernel and support software mean it is now possible to install on a much newer range of hardware. In particular the following are supported:

• SATA disks and CD/DVD drives. You can now install onto a disk with an SATA interface from a CD/DVD also on an SATA interface. Previous PATA interfaces continue to be supported of course and can be mixed and matched as required. This was a major limitation of the previous release due to the installation environment not being able to cope with these newer interfaces.
• Dual (and more) core processors. Using a dual core processor will make the system much smoother when using either SEG-D recording or Far-Field synthesis which are both processor intensive (the SEG-D for resampling data). A modern dual core processor with dual bank DDR2 memory has many times the performance of the hardware available and shipped when GunLink was first released.
• Monitors connected via DVI interfaces. Previously this worked eventually but caused long pauses at start-up and shut-down as the X server could not identify the monitor resolution.
• Operation with, and autodetection of, a wider range of modern graphics cards as well as the previously used Matrox 400/450/500/550 series. This includes many current NVidia and ATI cards which should work with acceleration (although this is of limited benfit for Java programs like 'display'). Support for PCI-E cards.
• Support for a selection of large/wide screen display formats without needing to manually edit the X configuration files. This includes the possibility of using a single 24 or 30 inch display instead of two smaller displays. Note 30 inch displays will require a 'dual link' DVI port on a suitable graphics card.

While this should make it possible to install on a much wider range of hardware it does not mean the system is supported on anything other than recommended configurations. Linux does not as yet have the same flexibility as some other systems in terms of downloading and installing new drivers for hardware not available at the time of installation and we cannot test an infinite variety of hardware for compatability.

SEG-D Recording

• SEG-D Files are now created for ALL shots when enabled - both real lines AND "Off-Line" data. Previously files were only created for real lines, the change is partly to assist when doing gun trials under local shot control and partly to ensure files are available for automated transfer to recording systems if required. As with database information Gunlink only keeps the 5 most recent off-lines of SEG-D files, older lines are purged.
• Automatic FTP transferring of SEG-D files to a server is now available through Host System Preferences. There are options available to aid interfacing with different expected filenames and formats.
• SEG-D Files can be automatically deleted after successful transfer if using the FTP 'sendSegd' program.
• The 'enable SEG-D recording' option in host prefs. has been removed and is now implied by any of the data-set recording options - sensors, raw hydrophone, notional near-fields or far-field - being enabled.

Gunlink Web

• System homepage removed as all web services are now available through Gunlink Web.
• System Docs removed as out of date and unneccesary.
• Delete data files removed as deletion is automated or covered by other programs / tools.
• View / Edit page will now load a read-only copy of the page if the system is active.
• Devices on the View / Edit page can be sorted by column heading instead of always being by serial number.
• Gun models can now be edited for in-use guns from the Edit Device page, a warning is issued about updating the Config through Configure for consistency. This was previously prevented due to the difference in electronics requirements between Bolt sensors and most other sensors. However it seems that the most common reason for a model change would be for altering a gun of type 'Unknown' that was not set in Configure. Note if for some reason you really do change a sensor type to or from Bolt the system will not change the enabled state of the Bolt sensor power supply on the affected guns until you run Configure, load the current configuration, 'update and send to host' and restart the host programs.
• Viewing options on Config Viewer are now saved for the browser session and default to showing Solenoids and Serial numbers.
• Better atmospheric transducer status reporting in 'live data' displays.

Host Programs

• Stats checks the current database version against the latest installed update to see if there is a new version available, if so a warning message is issued.
• Stats now executes summarising code with postgres running at a lower priority, this should help prevent freezes at End of Line / Start of Line.
• New shot error limits available for standard deviation and average error. Parameters are in 'host params' / 'specs' as expected. These additional QC tests can be defeated in the same way as the spread error test by setting the paramater to zero. These new errors and spread errors are now counted as bad timing shot errors in the database.
• Multiple TCU support. You can define up to two additional 'remote' TCUs. These could be used on remote vessels to issue synchronised pulses. Currently this only works in two cases, in internal cycle if you enable the 'use gps for internal' option in host prefs., and in external if the navigation system is capable of supplying a GPS fire time rather than a fire closure. The latter is the preferred 'clean' option, but in future it may be possible to have the system create a fire time delayed from the arm message or event and distribute this as a gps fire time to all TCUs. Currently to reduce the number of options all TCUs share the same pulse time and width parameters. Remote TCUs are assumed to have local GPS receivers configured via the TCU front panel or auto-recognised, the 'host prefs' settings apply only to the local TCU. If you define multiple TCUs you will get multiple icons on the status panel but only the local TCU needs to be ready and enabled to allow shot firing.
• Panel applet TCU status window shows more internal data.

Far-Field Synthesis

• If a multiple core CPU is detected far-field processing will ignore the 'give up one in' option in 'host prefs' and run at full speed for minimum processing time.
• The farfield algorithm has been revisited and improved roughly by 20%

Display

• Line stats, gun error table display now shows a table of line statistics as well as a table of per gun statistics. The line bad shot counts show percentages of the total shots on the line if the related error count is not zero.
• The status at the bottom of frame windows has been replaced with status shown in the frame title. 'Freeze' and 'New Data' statuses have also been replaced with icons.
• The graphing mechanism for Line Stats and detailed Timing Error Histograms has been changed to use the main signature window code. The behaviour is consistent now between graph types and the results are much cleaner.
• Channel editor for GL2000 systems. You can change channel assignments on a GL2000 system without the need to restart everything - if you need to patch around a wiring fault for example. The other obvious use is if you manage to swap solenoid cables on a G-Gun and only notice after deployment. If you want to make these changes permanent then when you next run configure you must select the 'get current configuration' option, not load it from the list of configurations in the data base. This is because the channel editor only updates the configuration on the host, not the previously identical copy in the database.

Configure

• Added 'ClusterDev Connection Side' as a Node Parameter for Gunlink 3000 and 4000 nodes to support electrically reversible GFSMs and GPMs. You may need to scroll the table sideways to see all the node options. Here you specify which end of your modules are closest electrically to the TEM. Note that only newer devices are actually reversible and if not specified it will default to the working setting for non-reversible modules which is 'DT and PT side' for GL3K modules and 'Gun Connector side' for GL4K modules. This is nothing to do with whether the array is classed as front or rear entry, the configuration must still be built with the cluster nearest the TEM electrically at the top of the string layout. It is required to cope with the bus wiring cross-over of the GPM unit in each GFSM, and with the same issue in GFSMs that contain only one gun firing module. The cross-over in the wiring means that the GPM or single GFM appear on different busses when viewed from one connector or the other. All GFSMs or GPMs on a string must be connected the same way around and you should not try to mix reversible and non-reversible units on the same string without consulting Seamap.
• "New" devices can no longer be created directly into your Inventory through Configure, you can only use new devices directly in a configuration. If you wish to add new spare devices into your inventory you are encouraged to use Gunlink Web.

Nodes - GCUs, IWMs and TEMs

As well as the operating and file system changes discussed here there are changes to the way nodes connect and run.

• With the introduction of working hot-swap redundant Ethernet links on those node types with multiple Ethernet ports (GL3000 and GL40000) the previous concept of 'primary' and 'secondary' network links has been removed. It was always confusing and was aimed at an alternative method of achieving redundant links which is not now being used. The 'nodeAD' program that does all the work on the node (together with the real-time module 'ad') now only makes a single socket connection to the host. This connection should be maintained by the Ethernet redundancy which operates at the network driver level and is invisible to the application programs.
• The nodes check the status of the redundant links if available and the status of each, plus which is actually in use and which is a possible hot spare, is reported in the panel applet node status if the node type supports it. Link failures will be reported as error messages to the logs even if the other link takes over. A dead link does not turn the node status icon amber due to the probability that some nodes may have a dead link for extended periods of time.
• The demultiplexing task that unscrambles the multiplexed data from all the data channels has been moved from the real-time task into 'nodeAD' where it runs in a separate thread. This should reduce the time when Linux cannot service interupts and should reduce or prevent the occasional loss of characters on the serial ports connected to the depth and pressure cards.
• As discussed below the nodes now share all libraries and nearly all files with the host. Previously the node was running a cut down version of Red Hat 7.3 which was substantially different to the host 'Gentoo' environment. This means that if you need to telnet to a node the environment is very similar to on the host with the same programs available. The monitor program now runs correctly for example having been broken on nodes for some time due to a library difference. The one drawback is that the overlayed file system adds an extra layer of complexity which may make graphical programs a little slower to launch when run from a node, but this is not a common operation.
• You can use ssh to connect to a node which avoids the need to enter a user name and password since you can now be any user on the node, not just 'root'. But telnet is still preferred option as ssh connections are considerably slower if running a graphical process due to the slow node processors, and if you really need to connect to the node with a command line you probably need to be root anyway so need to do 'su' after opening an ssh connection.

Tools

• Monitor and Gnits now have their terminals encapsulated so there is only one window.
• Monitor now restores process debug settings across host program restarts. This should enable the viewing of debug messages from the start-up phases of program execution.
• dumpHeader now quits if it is running in continuous mode and the host programs are stopped or restarted - rather than hanging
• Database management tools have moved from /opt/gunlink/scripts/setup/ to /opt/gunlink/db-tools.

sNetDaemon - Ethernet to Serial daemon

This new program offers a hardware free solution to outputting serial headers on a remote vessel connected by a radio network link. This may be required on for example OBC operations to record a header on the main recording system which will be on a different vessel to the gun boat(s). Previously this has been achieved using linked pairs of Ethernet to serial converter modules. Now you can select an additional header output from the host programs with a network destination, then run the sNetDaemon on a remote display machine installed on the recording vessel which is probably required anyway. This will take the network data and output it on a serial port. One instance of the program can handle multiple links from possibly different gun boats.

To configure the links:
On the Gun Boat

• On the gun boat select an extra header output in addition to any required on the gun boat (in 'host prefs' / ports) with the desired type of header. Select 'network', 'tcp', the host name or IP address of the recording vessel machine, a free port number greater than 1000 and the 'encapsulate' option for enhanced reliability. Repeat this if you need to send headers to any other destinations.
• Ensure the machine network config has suitable routing to be able to ping the destination machine on the recording vessel.
• Link status will be reported as normal GunLink error messages on the logs, display error window and via the 'monitor' program.

On the recording vessel

• On the recording vessel machine which will normally be configured as a 'remote display' machine ensure it has suitable network routing to be able to ping the gun boat host.
• Set the daemon to be started automatically at boot up by issuing the following command in a terminal as root 'rc-update add sNetDaemon default'. This only needs doing once after installation.
• Configure the program by editing the file '/opt/gunlink/var/INI/sNetDaemon.ini'. This contains instructions and comments. For each serial to network link you want this file needs a separate section containing a line for the network part of the link and a line for the serial port. The network line should contain 'tcp' the host name or IP address of the gun vessel system, the same port number as you used on the gun vessel and both the 'encapsulate' and 'listening' options. The serial port line can reference any port available on the machine and is also where you set the baud rate. The encapsulate and listening options are not valid for serial links. You can check suitable strings by using the display program 'host prefs' and editing a spare port value then cancelling.
• Start the daemon running by issuing the command '/etc/init.d/sNetDaemon restart' in a terminal as root. If there are any errors decoding the configuration file they will be reported to the screen. If you need to change the configuration edit the file and issue the command '/etc/init.d/sNetDaemon reload' or 'restart' if the previous attempt at starting the program failed due to an error.
• You can check for link errors by running the monitor program on the remote display machine - NOT via the host control panel as that would run a copy on the shooting boat system. Also issuing the command '/etc/init.d/sNetDaemon status' will show the current configuration, current connected status and data transferred counts.

Configured with the encapsulate parameter the programs will exchange regular 'ping' messages enabling the link status to be determined even when no headers are being transmitted. They will also acknowledge and retry transmissions although the use of tcp should make this unecessary. One end of a 'tcp' link needs to be listening and one not. The non-listening end is responsible for attempting to connect to the other which as it suggests 'listens' for connection attempts.

Node operating System

There are a lot of changes to the way the nodes obtain and run their operating and file systems. These should make things more consistent as well as making development easier. The amount of space required on the host disk and the size of any future updates is also greatly reduced. A full description requires a separate document but the main changes are:

• Nodes now run Linux version 2.6 the same as the host although a slightly earlier release since it needs real-time support and other special features compiled in so cannot actually use the identical files.
• The kernel downloaded by the node now includes an 'initrd' file which contains the programs required to start the initialisation process for the node. The main advantage of this is it allows the node to enable redundant Ethernet links (on GL3000 or 4000) before it connects to the host to mount NFS shares. Together with the ability to download the kernel on either link provided by the boot loader 'Etherboot' which is stored in the controller board this should result in full Ethernet hot swap capability for IWMs and TEMs at all stages of operation.
• The nodes now use an 'overlay' file system to share the bulk of their files with the main host system. This means the node processes use all the same libraries and files as the main host, so any utility available on the host is available on the node. The individual directories in /tftpboot/node1 etc. now need only contain copies of files that need to be different on a per node basis. These directories will also contain any files written by the node, so this is still where you look for node log files for example. The nodes still access their file systems from the host using NFS.