WetPC P/L has developed a number of unique chordic graphical user interfaces (CGUI) for mobile applications using its patented Kord® Interface Technology. Some of these are standalone products, others are concept demonstrators for assessment and trial. The latter can be readily developed in consultation with the end user. We can provide customised solutions using our in-house R&D tools and know-how.

Sendword 

Sendword interface for forming and sending messages
This concept demonstrator interface was developed for the Special Recovery Command Support System (SRCSS) of the Australian Special Forces. It was intended to be used by a Sniper or Lookout (fitted out with a head-up display HUD and a 5-button Kord® Pad mounted on the rifle, during a hostage or terrorist situation. Pre-formatted messages can be quickly formed and sent (as digital information) without the need for the sniper to put down his weapon or make undue noise. The current version provides up to one hundred (10 x 10) different choices of words (all configurable by the operator either in the field or back at base before the operation). Further versatility is provided since the messages can be composed and stored prior to a known event occurring and then sent once the event has taken place.

Quikscout 

This demonstration interface was developed so frontline soldiers could send pre-formatted messages back to their command or to headquarters. The content of the interface is heavily based on terminology used by the Australian Army. The interface resembles a "Notebook" - providing the soldier with a familiar environment in which to develop their messages.

The interface works in conjunction with synthetic voice. Pushing the "Alert" button sends a signal over the radio to other platoon/section members (who hear the signal using ear pieces). This then opens the Notebook for the soldier to fill in the fields. Once completed the "Send" button is pressed to transmit the information back to the Commander. The synthetic speech reads the information out before the message is sent. Changing to the Commander's screen one can then see the message coming in as digital information on the Commander's HUD. Note that the interface mostly uses the first three fingers of the hand - and hence could be operated using buttons on the stock of a rifle. The interface could be easily reconfigured "on the fly" to take into account soldiers that may be missing a finger.

CScore 

CScore was designed to run on Hand Held Data Rekorders (HHDRs) which use the Windows CE Operating System (V 2.1). It was developed for use by Observer/Controllers during combat training exercises conducted by the Australian Army. It enables them to enter and display information on soldier performance using one hand. Information is input by either the computer’s stylus or by chording combinations of buttons of the Kord® Pad.

Main Menu of CScore
The interface consists of a hierarchy of screens (maximum of 4 levels) which are accessed though a main menu by chording or tapping buttons. Users can enter ordinal data (1-4, -) or record time (by running stopwatches) on up to 10 separate activities and sub-activities (3 levels). Only three of the former (Patrol, Attack, and Defence) were implemented for field trials conducted by the Army in May 1999. The interface is fully configurable and up to 10 fields and 6 serials (replicates) are available per screen. Notes and textual information on major activities and individual performances can be made using the stylus. All data is stored in memory which can be easily downloaded to a desktop computer using the HHDR’s in-built docking procedures. Users can choose to delete the data file and create a new one, as well as enter general information about the training exercise (ie. time, date, location, name of user). These setup options are accessible through the main menu.

CSearch 

CSearch interface showing diver's swim path

This program was designed to run on prototype SeaSlates (see below) which were developed for the Royal Australian Navy (RAN). It takes output (NMEA stream) from an underwater GPS (with surface antenna) and plots a clearance diver’s position (as a continuous track - see Figure) within a search grid (obviating the need for divers to use jack-stays, marker buoys, etc). The program also provides divers with their distance (in x,y metres) from the datum.

The parameters of the search can be manually entered by the diver prior to the mission. They include: datum (latitude, longitude), bearing ( o true North), search width, lane width, box length and width (maximum 480m x 480m), and position in search lane (centre, left, right). Divers can also log the position and depth of objects that they may encounter during a search. For this version of CSearch divers are given 3 choices of objects from which to choose: mine, non-mine, and unknown. If a mine, then the diver can consult an Explosive Ordnance Disposal (EOD) Reference Database to verify the type. Once this has been done the mine type can be logged and the search continued.

The search grid has 5 levels of zoom so that divers can focus on either their current lane through to several lanes at a time. The data logged during the mission can be transferred to a RAN Database with the push of a button.

WetCOM 

This simple CGUI was designed to also run on the SeaSlate underwater computer and enables RAN clearance divers to formulate and send messages underwater by choosing from either one of 7 pre-programmed statements or by building a simple message from a dictionary of up to 20 key words. The messages provide information in relation to: (1) Arrival at datum point and time of starting task; (2) Description of bottom type and visibility; (3) Occurrence and description of any obstacles on swim path; (4) Detection of mine and description of type; (5) Arrival back at datum and completion of task. The message is sent to a surface vessel via an underwater transmitter which was developed by Nautronix Ltd.

Kord® Kernel 

The Kord® Kernel is a low-level software component; in essence a device driver that connects the Kord® Hardware to the software. Its capabilities will be extended to include new hardware, however it is not anticipated that the programming interface of the Kord® Kernel will be enhanced to provide much new functionality.

Chord enabled applications receive chord events through the Kord® Kernel layer. Loosely coupled applications will receive Window messages while tightly coupled applications can use either the callback event mechanism or Window messages. The Kord® Kernel layer contains an API (Application Programming Interface) that can be called from procedures defined in Visual Basic, C, C++, Toolbook and Pascal.

In tightly coupled applications, the Kord® Kernel can be configured to modify messages differently on a per application basis. Separate configurations are possible since each application must use the API to first identify itself and then specify how it expects to receive chord messages. Tightly coupled applications receive chord messages through a callback event handler. As the applications receive messages through the callback event handler or via Window messages they don’t need to poll for chord events and can perform other foreground or background processing while waiting for the events to occur. Multiple Kord® Drivers can be registered with the Kord® Kernel.

The Kord® Kernel is not considered a building block upon which a programmer can construct chordic applications, it is merely one component of a larger system called the Kord® Operational System (Kord® OS) - which is under development. Applications that have been built using only the Kord® Kernel are "rogues" in that they implement all chordic functionality and settings from within the program.