From: John Morrison (jmorrison_at_ahc.net.au)
Date: 2002-02-28 00:05:59
> John Morrison wrote:
> > I'm just trying to collect the necessary documents so that module
> > authors had access to it! And we can start with the same
> > environment and reduce wasted time form inconsistencies! Do I have
> > permission to use your document?
>
> Okay, so you're talking about getting the SDL and FFTW libraries
> installed, rather than the specifics of building BWView ? In that
> case, the best thing would be to look at the docs on those two sites:
>
> http://www.fftw.org/
> http://www.libsdl.org/
>
> For MinGW and MSYS, look here:
>
> http://www.mingw.org/
>
> If there is anything that is of any use within the build instructions
> or build scripts within BWView, please use it. If Doug is going to
> give it a try, he can probably come up with some hints too.
THANKS that is all I wanted. :-)
> > I understand that, it was just a suggestion it would all depend
> on HOW we
> > send the data and what is on the other end analysing it.
> > With the proper receiving system a single packet loss could be "guessed"
> > from the previous packet and it maybe quicker to do this then
> to ask for a
> > resend!
> > THIS IS ONLY A POSSIBILITY........it all depends on how the
> system shapes
> > up.
>
> It isn't a possibility, sorry! No guessing of packets is going to
> work reliably. Perhaps, for another solution, each packet could be 4
> times the length, and transmit the current data and the previous 3
> packet's data as well. That way we could lose 3 packets without
> noticing. The amount of data we are transmitting is tiny, so this is
> no big deal. However, if your networking experience tells you this
> wouldn't work, forget that idea.
Not a bad idea!
Hmm have to have a think about this. For further down the track.
Seeing as the data stream is tiny the REAL time component is the major
consideration.
Large packets are not a good idea though as they may get split up and
delayed.
MAYBE just sending the same packet multiple times would provide the solution
to a bad connection.
Start with 1 packet if packets are lost them start sending twice, etc......
Very inefficient but workable
A simple serial number would work for synchronisation and duplicate packet
removal
> Why not stick to TCP/IP ? I was piping data sampled at 5kHz over my
> ethernet via TCP/IP between my laptop and desktop without problems.
> Why make it more complex if the simple option works ? It would be
> better to delay the analysis than to try and patch up a stream with
> holes in it.
Well as the data stream is tiny TCP would work very well.
I thought from the way Dave suggested UDP that there was a LOT of data.
> Either that or have the user end do the analysis, and just send
> packets of analysis data over the network. It might be more
> permissible to drop packets of analysis data.
I'd prefer to send "raw" data as you can do whatever you could normally do
such as recording.
One PIE-IN-THE-SKY use is that you could have a class wired up to EEG
sending data to a central recorder.
After a guided meditation session the instructor could look back and see if
it went right and who needs to do more work. :-)
> > I've just Graduated (with distinction) a bachelor of information
technology
> > majoring in "Data Communications" and "Software Engineering" backed by
17
> > years working for a Telecommunication company working on Computerised
> > exchanges and the network data that connects them. One of the
> major things
> > they teach for bigger projects is to plan first and hack latter
> or never.
> > Sure you can jump right in and get a program that looks great in a short
> > space of time. BUT 6 months down the track when you've added 20 more
> > features to the system you find that it's a hoch poch of code and no-one
> > including you knows how it works anymore!
>
> Take a look at my code. There are two parts with a strong
> object-oriented well-defined interface: "analysis.c" and "file.c".
> The other parts are clearly segmented, but the interface to those
> parts has not become well-defined yet because I didn't know exactly
> how I wanted them. Now I'm more aware of how things have turned out,
> those areas are probably going to get some reorganization.
Yep I've had time to look over your code and it looks great.
The interface is where I'm working. Get a well defined interface and
someone can pick up your code someone else's and combine it in ways neither
ever envisioned. :-)
When you've got the kinks worked out I'd love to see them so we don't miss
something in our design!
> My memory span is zero -- I have to document my code or else I would
Join the club. :-) I have to do the same, when I look back at some of my
eerier work I shiver......... :-\
> never be able to work on it again. Just because it is a hack doesn't
> mean it's sub-standard!
Sorry if you got the opinion that I think it's sub-standard.
Quite the opposite it's a great bit of software!!
> > I have not denigrated you or your design path so please reciprocate!
> > It just wastes SO Much TIME. :-(
>
> No problem. I think it's best that I let you get on with your plans,
> whilst continuing with my own research and development. If you try to
> pull me into your "plan", it is asking for problems, so better let me
> work independently.
I wasn't trying to pull you in!
I was just asking for a little help in an area that you had already work in.
IE Cross compilation.
I wouldn't presume to think that anyone would help with the plan.
I hope that I can ask for help from you in future in areas that you have
covered and would be a waste to cover again.
There will be NO presumption that I'm trying to get you over to the "DARK
SIDE". :-)
Just a simple request ever so often!
> Jim
Just a final note.
I'd love to see great open-source software coming out of this project.
We have great hardware coming along.... my hat goes off to you guys!
I don't really care how that software is arrived at (there are many paths)
but it would be great if the projects were compatible and parts could be
mixed an matched. :-)
Happy NF
John
This archive was generated by hypermail 2.1.4 : 2002-07-27 12:28:39 BST