From: John Morrison (jmorrison_at_ahc.net.au)
Date: 2002-03-01 14:00:19
> > 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.
This actually and internal SENSOR method in the super class so that the
sensor subclasses don't' have to worry about working with Linux serial
code, Windows serial code, etc.
> 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.
What about option 3 (I'm assuming you are talking about data from sensor to
processing)
3) The sensor object gives us just the device data we request.
- Listeners is the way I was thinking too!
- A setup call (for the listener) will designate the channel/device.
OR are you talking device to sensor code ??
> 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.
Make File a Super class so we can put generic filehandling functions there?
Configuration
- hmm we are going to look into this as various objects may have there own
configuration options?
- Maybe each object could register with the Config object and handle there
own sections......
- Something to think about
> > 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.
That is the idea behind Trigger!
We have various trigger classes to use.
When a trigger object hits the trigger condition it notifies a "User
Interface" object that gives the appropriate feedback!
> > 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.
I agree I think "User Interface" should be the last one we look at.
There are a LOT of traps in the user side!!!
> 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.
hmm needs some thought........
Thanks for the MVC links I needed a refresh on them. :-)
> -- Doug
Ok seeing as one Hardware device could have various sensors connected to it
we could break it down like this
Device(super-class)
:initialise - initialise the object but don't start reading yet
:start - Start Sampling
:reset - Reset object (maybe just a call to initialise)
:stop - Stop sampling
:getSerialData - internal method for subclasses
OpenEEG(class)
File(Class) - Replays recorded data
Sensor(super-class)
:setSamplingRate - Set sampling rate :-) Thanks Doug
EEG(Class)
ECG(Class)
EMG(Class)
GSR(Class)
Then we connect a sensor object (eg EEG) to a channel on a device (eg
OPENEEG). EEG being a listener!
Chan
OPENEEG --01--> EEG
\--02--> ECG
It's midnight here so time for bed!
C U all later
John
This archive was generated by hypermail 2.1.4 : 2002-07-27 12:28:39 BST