• View
• Edit
• History
• Print

June172008

Email summarizing the meeting:

Hi all,

I thought I would send out an email recapping what we talked about during today's meeting after Fred left. I took pictures of the whiteboard, but they were pretty unreadable. Instead, I wrote everything out again and put the pictures on the wiki. They are available at:

 http://www.cs.uml.edu/isense/pmwiki.php/Development/June172008

After a long discussion, we came up with a new work flow for session creation. It is a four step process like before, but we changed a few things around. Here is a brief outline of the new work flow:

• Step One: Select an experiment

This is just like the old step one, except the "Join" button is replaced with a "Details" button. We replaced it with "Details" because in the next step, experiment details are shown, along with an option to join the experiment.

• Step Two: View experiment details (and decide whether or not to join

it) This part shows the experiment's title, owner, date of creation, and description. It also lists the fields that are part of the experiment, along with the type of sensor each field requires. The biggest change in step two is that sensors are not detected or assigned there. The fields are merely listed along with the rest of the experiment's details, nothing more. If the user clicks the "Join Experiment" button, they will have a chance to detect and assign sensors in step three.

• Step Three: Fill in session details and assign sensors to fields

Here is where most of the work is done. There are two parts to this step. Part A is where the user fills in the session's title, description, and address (using Google Maps to geocode it). That's the same basic stuff that happened in old work flow.

Part B of step three is where the user will detect the attached sensors and assign them to fields. There will be a faceless applet that we decided to call the "Detector Applet" that will detect all of the attached sensors when a "Detect Sensors" button is pressed by the user. The detected sensors will be put into a Javascript array. At that point, the job of the Detector Applet has been performed, and it will not be used again.

The Javascript array of sensors will be returned by the detector applet using the method call "detectSensors()". It will be of the form:

 var sensors = [
   {
     kind:'Cricket', // Could be: Cricket, Super Cricket, Vernier,

Pasco, etc.

     port:'COM1',    // Could be: COM1 (Windows), /dev/ttyUSB1 (OSX/

Linux), etc.

     channel:'A'     // For example, you might have channels A and B

on a Cricket

   },
   {
     kind:'Cricket',
     port:'COM1',
     channel:'B'
   },
   {
     kind:'Vernier Go! Temperature',
     port:'/dev/ttyUSB1',
     channel:null
   },
   ...
   ...
   ...
 ];

Once the sensors have been detected, the user can match up sensors in a combobox to a list of fields displayed on the page. Once we get the manual input and store-and-forward stuff going, we will probably have "Manual Input" and "From file..." options in the combobox as well. For now, we decided to concentrate on getting "real" sensors to work. Once the user has mapped each field to a sensor, they will click the "Next" button to proceed to step four, where the actual data recording happens.

• Step Four: Data recording

The final step in the process is the data recording step. The sensor- to-field mappings from step three will be handed to what we are calling the "Recording Applet" using a method called "addSensorMapping(String kind, String port, String channel, int field_id)". The method will be called for each sensor-to-field mapping that was made in step three. Once the mapping has been loaded and the devices have been opened, the data can be recorded. There should be methods such as "setExperiment(int experiment_id)" and "setSession(int session_id)" so the details can be set in the recording applet. There should also be methods like "startRecording()" and "stopRecording()".

The pictures on the wiki describe things a little better than I did, so check them out. I don't think we reached a decision on what to do about giving the user feedback while recording data. We talked about giving feedback using HTML and a faceless recording applet, but we also talked about showing feedback in a visible recording applet. I think we deferred discussing that until we get the rest of the process implemented. Personally, I think that as long as we have a minimum interval of one second, we could do it all using Javascript and a faceless applet.

Now for the new idea. Using Javascript and a faceless applet also opens up some interesting possibilities in the future (once we have the basics working). We could eventually map sensors to Javascript variables and map Javascript functions that use those variables to fields in the experiment. For example, we might have the following mapping in an experiment that measures the difference between indoor and outdoor temperatures:

1. "Cricket on COM1 (Channel A)" mapped to variable "INDOOR_TEMP" 2. "Vernier Go! Temperature on USB1" mapped to variable "OUTDOOR_TEMP" 3. "function() { return (OUTDOOR_TEMP - INDOOR_TEMP); }" mapped to field "Temperature Difference"

I think that might be the way to go in general because it would make the system a lot more flexible. For example, I think in the meeting Ivan brought up the problem of making sense of accelerometer data. In that case, you could map the different axes of the accelerometer to variables, and then map a function that uses those variables to a field. The function could process the raw accelerometer values and produce a meaningful result, such as a measurement in degrees or coordinates in space. Something to think about anyway...

-Will

Pictures from the meeting: