From: Doug Sutherland (wearable_at_earthlink.net)
Date: 2002-03-01 13:01:23
John,
> Hardware(Class)
> :initialise - initialise the object but don't start sampling yet
> :start - Start Sampling
> :reset - Reset object (maybe just a call to initialise)
> :stop - Stop sampling
> :setSamplingRate - Set sampling rate
This looks pretty decent actually. We need to talk
to the hardware guys and figure out exactly what
is configurable in the microcontroller.
> EEG(Class) OPENEEG(CLASS) - Our baby :-)
> ECG(Class)
> EMG(Class) <-- these are our babies too
> GSR(Class)
Here is where things will change if we do object oriented.
All of the above are sensors, so we have a sensor class
Sensor (Class)
// all methods common to sensors go in super type, then
EEG (Class) extends Sensor
ECG (Class) extends Sensor
EMG (Class) extends Sensor
GSR (Class) extends Sensor
Each of these sub-types can override methods in the
super type (Sensor) if they need to, and they might
add extra methods specific to their type.
> getSerialData
> - a "protected" method used to access serial port data
> - there would be a whole range of "protected" Serial
> interface methods
> - Of course the library for Linux and Windows would be
> different
> - This way authors can write code for a piece of hardware
> without concern for the operating system
This needs to change a bit I think. This really needs to
be a listener, not a method that you invoke on a sensor.
Once you call EEG.start then data will be coming at us in
a stream. We have a six channel device in the works, some
may be EEG and some ECG or whatever, all will arrive in
the same serial stream. So we don't call a sensor to get
the data, it continually streams in on the serial port.
There we have a class that wraps the native serial code.
It will also have to determine which data is for which
hardware. There might be two options:
1) Some kind of configuration object specifies which
channel is for which devices.
2) Some protocol info in the serial stream determines
the type of data.
Here is where your framework idea comes in. The
listener needs to call something else to filter
the data, and eentually we want to render it. We
need to separate these things. This is where I
think something like MVC design pattern makes
sense (or some other design pattern).
> File(Class)
> :SetFileName - Set file name to read
We will have several different types of files.
Some will be log files, writing the samples to
disk. Others will be user configuration info.
We want the system to allow a user to save his
own setup and persist his settings, log his
data in a separate place. Maybe we have a
logging class and a configuration class.
> Processing(Class)
> :initialise - initialise the object
> :reset - Reset object (maybe just a call to initialise)
Processing is a bit too generic I think. Skip that.
> Filter(Class) - any sort of filter
Perhaps we can have filter supertype and several
sub-types. We need to understand the flow of the
data and events in terms of that framework idea
to figure this out.
> Trigger(Class) - Classes that provide an output
> (Digital) when trigger conditions are met
We also need to add some support for neurofeedback
training protocols in here, and triggers are part
of that. For example, when a user gets into the
target range they need to be notified. This is
another reason for abstraction: it may be GUI
or audio or some other method.
> UserInterface(Class)
We will probably have more than one class that makes up the
user interface. One type of class would probably be the data
displays (waveforms or bar charts or pie charts plus numerical).
Each represent the same data in different ways, so it makes
sense to have a super and subtypes. Others will associate
with configuration, others may control the overall program.
Back to the idea of Jim wanting console interface and others
wanting GUI ... in this paper on MVC design pattern, it says ...
Not all people can or prefer to operate a computer in the
same way. Therefore: Separate the controls of the computer
from the views it presents so that appropriate controls
can be selected by the user. A handicapped individual
would be an example of a user needing a different kind of
control.
http://c2.com/cgi/wiki?ModelViewController
http://rd13doc.cern.ch/Atlas/Notes/004/Note004-7.html
http://www.enode.com/xalt/markup/tutorial/mvc.html
If we want to make a flexible system, we need this kind
of abstraction, not only between the the GUI and data
but also between the process (filtering) etc. I'm not
sure if MVC is quite right for that, but something
similar probably makes sense.
-- Doug
This archive was generated by hypermail 2.1.4 : 2002-07-27 12:28:39 BST