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 stock of 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 front-line 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. Note that the interface mostly only uses the first three fingers - 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(s).

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 on the Kord® Pad.

CScore is generated using 3 types of files (which reside in the computer’s main directory):
CScore.exe: an executable program (written in C++) which is accessed from the computer’s start menu, and which draws on information contained in the screens.ini file to generate button and screen labels and button sizes;

Screens.ini: comprises a series of hierarchical commands (modifiable) which enable the user to configure the interface (see below);
HTML files: referenced in the screens.ini file, these files are used to provide context-sensitive help (e.g. information on Standard Operational Procedures) to the user.

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 computer’s stylus. All data is stored in memory which can be easily downloaded (as a comma-delimited data file called CScore.dat) 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 which were developed for the Royal Australian Navy (RAN). It takes output (NMEA stream) from an underwater GPS 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 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 is able to 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.

FlatChat 
Is a simple Shockwave chat program that enables text communication over the Internet in a browser. It demonstrates how you can combine conventional typing and chording. Users can type normally or they can chord nearly 200 words, phrases or functions using the SPACE J K L ; keys. The “Speedwords” enable messages to be sent quickly without having to take one’s hands from the keyboard. Symbols show the user what to press. Users can define and save their own speedwords or phrases thereby creating their own personalised interface. FlatChat has numerous other features such as colour text, wait for user and pop-up alerts, etc. It is the only chat program of its type on the Internet.

The 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 call-back 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 call-back event handler. As the applications receive messages through the call-back 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 intended as 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. Current 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.