TODO LIST - VERSION 1.0

Preface

Liquid (version 1.0) is currently at the prototype stage of its development cycle. About 70% of its framework and functionality has already been implemented and successfully tested (enough to get a feel for what the finished product may be like).

This page lists the areas that need implementing/tidying up in the toolkits source code.

GETTING STARTED

Before attempting the list download the toolkit project spaces (Liquid and the LDD/LCA templates) from the following web page http://sensors.comp.lancs.ac.uk/liquid/downloads.html.

INFO: The Liquid, LDD and LCA source files are written in C and are provided with a VC++ 6 Project File.

LIQUID PROJECT SPACE

The Liquid project space is laid out as follows:

FEATURES LIST

Items as of yet to be implemented in the toolkit.

1. Implement a save feature for the options configuration.

2. Implement a save feature for the SM/DS session setup (save selected sensors list).

3. Implement a time-out configuration dialog (delay before sensor input is timed out, default is 400 milliseconds).

4. Implement an input comparison feature (for sensor accuracy analysis). The SM session should provide the ability to compare the input obtained from sensors of an identical class and sensors of the same purpose-property combination and output format.

5. Implement an input logging feature (save recorded sensor readings to a file).

6. Implement a selective LDD shutdown feature. Currently all LDD's must be shut down at once, this may cause problems during input visualization in the SM session because when a sensor/LDD fails Liquid retains a link to it.

TIDYUP LIST

Items of source code that require tidying up.

1. getLastError() in the LDD template doesn't reset after an error has been corrected. May cause inconsistent error messages to be retrieved by Liquid.

2. Loader.cpp (Liquid project space) locks all the .dll files that exist in the drivers folder on scanning for valid LDD's. If an LDD requires the presence of another .dll to access the sensor you mustn't store it (required .dll) in the drivers folder (LDD won't be able to access it). Instead the .dll should be placed in the Windows system folder.

3. Selection.cpp (Liquid project space) needs to be configured to reject erroneous sensors (currently only displays an error message advising not to add it to the session).

4. Remove the DOSFLAG from the LDD method openSensor(..).

5. Remove the DISPLAY_TYPES structure and supporting methods e.g. getParseTypeFlag(..). Simply stick with using the output type value in all instances were it is required. Was intended to support LDD's with multiple output formats (this feature was dropped midway into Liquid's implementation).

6. Remove the SENSOR_DATA structure, replace with a nondescript buffer. The buffer must be capable of handling input of any kind, possibly model as a character buffer (this is done when input has to be passed over a network, see Network.cpp of the Liquid project space). Remember to pass the buffer byte size before passing the contents of the buffer (see item 9 of this list).

7. Remove the visualization mode declarations from the Liquid source code (see Vis.cpp). Model each mode as a Dynamic Link Library (akin to an LDD) so, the supported library of vis modes can be extended at will. Package the methods beginning with the prefix collectXX(..), drawXXX(..) and networkXXX(..) with the respective .dll file (see Vis.cpp and Network.cpp respectively).

8. Provide ability to change the recommended input range.

9. Remove the output format (type) declaration stored in the LDD template and place it in Liquid's sensor class library. The sensor class declarations in class.ini should link to the relevant output format and mode of visualization (rather than relying on the LDD to link the output format to the sensor class).

Was intended to use type declaraction as a backup feature (never finished), to make sure the LDD knows what format sensor input should be delievered in. Possibly set buffer mentioned in item 6 of this list to start with the type declaraction followed by the buffer byte size (this also links with item 7 of the review list).

Figure 5 of the What is Liquid? page (LDD illustration) uses the current interpretation of an LDD. Would require modification on carrying out this item (remove output format).

10. Network.cpp is unable to transmit input beyond the maximum packet size.

11. Modify LDD getSensorInput(..) so operates as a callback function.

12. Liquid stops collecting input if minimized, correct Main.cpp (Liquid project space) so it carries on data retrieval.

13. Current implementation of collectArray(..) does not support any error checking (before solving see item 1 of the review list).

14. Remove the System Test->System Status->Test Driver sensor class. Used for demo purposes.

15. Enhance the error checking facilites used to monitor the network connection between Liquid and an LCA e.g. to detect when the connection is dropped.

16. Remove obsolete dynamic memory allocation procedures.

17. Add time-outs to network commands e.g receive(..) in Network.cpp. Should prevents system from hanging if connection disrupted or lost.

18. Allow the DS servers to be reset for another LCA session on completion of current one (see source file Network.cpp). Currently requires application restart.

19. Loader.cpp does not check if all the LDD methods are loaded correctly. Finish implementing success checks for all the loaded LDD methods (the LDD Test Program has this already implemented).

20. drawArray(..) does not allow for horizontal scrolling when more than 3 numeric values require displaying, as said would be allowed in Output Descriptors for Casual Users.

PROBLEM LIST

Items that require solving.

1. Liquid and LCA RELEASE MODE compilations fail to function properly. Unknown cause, backtracking reveals network code is the source of the problem.

2. collectGraph(..) fails if input is made available at a rate higher than 33 new entries per second. LDD's that support the GRAPH output format should be designed to return data once every 100 milliseconds (10 new entries per second). At all other times the method getSensorInput(..) should inform the method collectGraph(..) no further input has been retrieved by the sensor.

Any data that requires to be sent in the meantime can be buffered, as each entry is time stamped the effect of the low poll rate is neglible.

3. During a DS session if a sensor fails and then reactivates itself the LCA may not register it activate again until the sensors are deactivated and subsquently reactivated (currently only the complete activation/deactivation of sensors is supported, not individual activation/deactivation).

4. Sometimes the C&C server fails to close down because one of the LDD closeSensor() methods failed. For example the WaveRider LDD requires the presence of another application to run (WaveWare) which sometimes fails to kill itself and so freezes the application.

5. LCA template has difficulty disconnecting from the DS servers (disconnects automatically if Liquid is exited).

REVIEW LIST

Features that may require reviewing, possibly leading to insertion/removal or overhauling of program source.

1. Overhaul the ARRAY output format as its currently geared for only videogame controllers. Possibly introduce ability to declare central/neutral points in order to handle input collected in a similar fashion to videogame controllers.

2. Possibly remove openSensor(..) constraint parameters e.g. maximum acceptable input value. Developers would be required to read the documentation on Sensor Class Output Formats and make sure their input assumes the correct shape. Liquid is already set-up to check data follows the constraint parameters.

Output Descriptors for Developers will need to be modifyed in light of any changes made under this item.

3. Timestamp all input entries (rather than just with input of type GRAPH).

4. Review frameworks ability to extend sensor classes and output formats. Possibly model each output format as an ini file inside a folder designated formats.Each output format would be represented as a text file going by the same name as the output format (so can be easily identified). The constraint parameters would be listed inside.

5. Allow LDD's to support more than 1 sensor at once i.e. for multi-sensor devices.

6. Overhaul EXIT CODES described in Device Driver.h. Make positive states return positive numbers and negative states return only negative numbers. Currently everything returns a negative number unless the method was a success in that case it returns TRUE.

7. Overhaul DS communication protocol. Possibly develop personalised data packets.

EXTRAS

Misc items.

1. Means of sensing for an MS SideWinder Force Feedback Wheel may be wrong (currently described as a slotted disk).

2. Provide COMM port / channel selection in the configuration dialog of the WaveRider ECG LDD.

3. Implement input validation in WaveRider LDD (currently does not check if input value is valid, leaves for Liquid to carry out).

4. The WaveRider ECG LDD is highly unstable when run under Win NT/2000/XP. Supplied sensor-specific API was developed for use on 16 bit platforms. Although the instructions included with the LDD/LDD source indicate that the driver requires manual configuration when run under the fore mentioned operating systems that is not necessarily true.

The LDD will work function correctly when used in an SM session, although not in a DS session (fails to turn on the power).

5. The WaveRider ECG LDD is unable to locate sensor faults (requires modifications to wwddle32.dll, upgraded version of the 16 bit sensor-specific API).

6. The WaveRider ECG LDD has difficulty closing the instance of WaveWare (sensor-specific monitoing software) it spawns when used in a DS session. Before running a new SM/DS session open the task manager and manually close WaveWare.exe.

. . back to Manual Index