Real time data capture

These pages are intended as a living way of developing a specification for an on-competition-site data capture system as [outlined in the paper|cimaPlenaries:2012 documents & reports^CIMA_2012_Plenary_real_time_data_collection_proposal v1.pdf] presented to the 2012 CIMA Plenary.

Refer to the ABG system for a working demo of something which inspired the idea.

The app

• Core to the system is an app which works on common hand-held devices, primarily tablets, but should also be functional on smaller devices like phones.
• It is proposed the initial work should be directed at Android devices since this is an open-source OS and the hardware is generally much cheaper than the equivalent offerings from Apple, but there is no reason why the same thing can't be ported to iOS at a later time.
• The app should be capable of:
  • Displaying means of collecting all the data as may be required to score all pilots in a task. (except, for the time being, logger derived data).
  • Interacting with USB connected hardware designed as alternative means of collecting data (eg button-box for stopwatch-like timing functions).
  • Sending that data in near-real time to a remote server which can further process it into a score or result.

Functional overview

The ABG system was disadvantaged by being very hard-coded, which made it only usable in a very specific set of tasks. This system must be as 'universal' as possible, it is therefore proposed that the app is arranged in the form of a 'framework' consisting of:

• Overall graphic layout
• Universal settings, communications and other core services
• Many data-collection / graphical sub-components;
  • Task name and description
  • Pilot start list
  • Active pilot display
  • Count-up timer
  • Count-down timer
  • Strike counter
  • Distance input
  • Penalty selector
  • Button-box input translator
  • Etc.

The idea is that it should become possible to collect all the data as may be required to score a task by applying a configuration script to the app which sets the app up to display all the required sub-components in the right place within the overall graphic layout, that those sub-components know how to interact with each other, and what data to collect.

Configuration scripts are in xml to a precisely defined format which implies there should be an online task builder which can be used to interactively build suitable scripts, and a library where scripts known to work with a particular task can be saved for re-use.

Scripts are saved from the builder or library to each device to be loaded into the app ready for the start of a task.

Communications The core app should be capable of communicating with a file system on the local sub-net (classically using the wi-fi capability of the device) or via http to a server, either through the local wi-fi system to a local server, or wi-fi and a router on the local network to a remote server, or (if fitted) via GPRS / 3g / 4g data connection with a mobile network to a remote server.

Data-in

Some sub-components must be capable of collecting external data such as a start list. (Names, comp no., task start order). This implies there must be a standard data-format (again, xml) with a detailed specification for each sub-component of this type, which in turn means there must be at least one simple method of generating it. It is proposed that the simplest way of initially achieving this is to produce an Excel add-in similar to the one already demoed with the WLC results, but other systems could be made available at a later time as necessary.

Data-out

This requires a standard data specification (in xml) which is managed by the app in association with its communication protocols, but the sub-components must know what data they need to supply so the data is complete.
The app is useless unless the data it produces can be read by something. As with data-in, it is proposed an Excel add-in is produced which is capable of reading the supplied data and inserting it into the appropriate place in the scoring spreadsheet, but but other systems could be made available at a later time as necessary.

Licensing

It is proposed CIMA invests in the the original work required to get a basic system up and running. It might therefore wish to retain the source code and even charge a licence fee. While there are quite a few components to the basic system, the overall design is intended to incorporate the core functionality but be expansible from the very beginning. (other OS's, other scoring systems Etc)

By far the best way to achieve this is to make the entire system open source from the very start which might encourage other developers to contribute to the success of the system without the complications of licensing Etc.