From: John Morrison (jmorrison_at_ahc.net.au)
Date: 2002-03-03 13:15:29
> --- In buildcheapeeg_at_yahoogroups.com, "John Morrison" <jmorrison_at_ahc.net.au> wrote:
> > (hands full anyway)
> > - Tell me about it I start tutoring a new subject tomorrow at Uni.
> > - I've got a project to finish that is part of a lecture on Thursday
> > - and my Tax is over due. :-(
>
> I note that you put the tax-return last
> on your list of priorities. ;-)
Yeah which is where it is right now. :-(
> > Could be as simple as
>
> ..
>
> > Any suggestions on weather this would be
> good/bad/indifferent???????????
>
> Rather than storing a single byte, interleave one-second blocks of
> data. That way different channels can have different sample rates and
> different samples can have different data types (doubles, ints, bools
> whatever).
>
> If one channel has a 256 Hz rate and another 73 Hz, for instance, it
> comes down to reading or writing a blocks of 256 samples followed by
> a blocks of 73 samples. I'm sure you can write the method that does
> that in less than 20 lines.
Yes I agree very simple but we should think of processing and reviewing the
data later.
A file for each sensor would make reading a lot easier.
Anyone got any idea what over head writing and reading say 8 channels of
data to 8 different files would cost the system?
If it costs to much then single file is the way to go if not KISS is the way
to go.
> > Oh, and Andreas (welcome to the software discussion :).
>
> Thanks. I'll try to stay out of your way as much as possible though,
> and not get into specifics.
>
> However, I know that laying down a good foundation is vital and saves
> countless hours of future work, even if it is boring to sit down and
> learn MySQL or the standard template library. :-) The time spent is
> repaid many *many* times over.
> > While it is true that a database would afford more flexibility in
> > terms of what we can store, it also introduces more complexity right
> > now (especially since we are going to be coding across platforms).
> > 'Course, there are probably several open source database projects
> > that might make this feasible. But, for now, I feel this is a
> > later-date issue since the real-time data would not be stored in
> > such a way.
>
> Well, there's always MySQL...
> You're right, we don't have to worry right now, but as soon as the
> need to save settings and sessions and so on, please consider it. It
> really removes most of the grunt work of reading and writing files,
> so I can't agree with you on it being more complex. :-)
BTW I LOVE SQL!!!
BUT we will be relying on another outside program that can be messed with
and messed up.
If we loose SQL (OR the user can't install it for some reason) our program
doesn't run!
> Here's an example stolen (and edited for size) from the MySQL++ docs:
>
> Connection con("mysql_cpp_data"); //Open database
> Query query = con.query(); //Create a query object
> query << "select * from stock"; //Ask the DB a question...
> Result res = query.store(); //and return the result
>
> Row row; //Create a row object
> Result::iterator i; //And an iterator
>
> //Walk through the rows, printing the contents of the "weight" column
> //defined in the "stock" table.
>
> for (i = res.begin(); i != res.end(); i++) {
> row = *i;
> cout << row["weight"];
> }
>
> Unlike working with objects in C++ this piece of code reads data from
> the hard drive, so it is "persistent". And that in just 12 lines of
> code including comments.
Is easy isn't it. :-)
> Johns suggestion to use XML is also a good one, especially for saving
> the state (window positions, colors, etc) of a session or any kind
> of hierarchial information. There are a bunch of open-source projects
> that does that for you too.
I've worked with XML before and it's great for things that don't change
often.
The major drawback is that you have to write the whole file every time you
change something.
Though the impact can be reduced by using small XML files not 1 big one. :-)
> Regards,
>
> Andreas
Thanks Andreas
John
This archive was generated by hypermail 2.1.4 : 2002-07-27 12:28:39 BST