[Neurodebian-upstream] [Neurodebian-devel] poster copy request (Mehmet Kocatürk)

Mehmet Kocatürk mehmet.kocaturk at boun.edu.tr
Fri Jan 28 23:44:35 UTC 2011 

Hi All,

I am new in this mailing list. It has been really great to discuss what can
we do for better. I hope we can get forces joined!!!

Before investigating NeurOnline, RELACS, MEABench and some others in detail,
I suppose I can answer questions of Dr.Benda to be quicker to provide some
info from my side.

As you told our software has a kernel module running in kernel-space. And,
it performs data acquisiton by 'comedi_map' ing and retrieving data from DAQ
card buffer every 1 ms with 'comedi_poll' to buffer it on a shared memory
section. Afterwards, it immediately performs digital highpass filtering
(150Hz cut-off) and spike sorting via template matching on that buffered
data. While one out of 4 cores of Intel i7 Processor is dedicated for data
acquisiton and DSP, the others are for management of experimental
environment (i.e behavioral cage) and models. It is known that it is
available to assign different scheduled tasks to other cores with different
hard RT timers.

To conclude, we dont use any callback or comedi_data_read. And this has been
just developed in the aim of recording of spike-only activity (16 channels,
40 KHz sampling rate each). What is more it is developed by using National
Instruments NI-6070E PCI card and currently it supports just one DAQ card.

The GUIs to control the tasks and visualize retrieved data for spike
sorting/viewing (10 frame/second) and recording run in user-space.

It is also great to be aware of COLE. I will be following it up!!!

Mehmet Kocaturk


On Fri, Jan 28, 2011 at 2:18 PM, <
neurodebian-upstream-request at lists.alioth.debian.org> wrote:

> Send Neurodebian-upstream mailing list submissions to
>        neurodebian-upstream at lists.alioth.debian.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>
> http://lists.alioth.debian.org/mailman/listinfo/neurodebian-upstream
> or, via email, send a message with subject or body 'help' to
>        neurodebian-upstream-request at lists.alioth.debian.org
>
> You can reach the person managing the list at
>        neurodebian-upstream-owner at lists.alioth.debian.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Neurodebian-upstream digest..."
>
>
> Today's Topics:
>
>   1. Re: [Neurodebian-devel] poster copy request (Yury V. Zaytsev)
>   2. Re: [Neurodebian-devel] poster copy request (Jan Benda)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 28 Jan 2011 09:51:35 +0100
> From: "Yury V. Zaytsev" <yury at shurup.com>
> Subject: Re: [Neurodebian-upstream] [Neurodebian-devel] poster copy
>        request
> To: Yaroslav Halchenko <yoh at dartmouth.edu>
> Cc: neurodebian-upstream at lists.alioth.debian.org
> Message-ID: <1296204695.6878.40.camel at mypride>
> Content-Type: text/plain
>
> Hey!
>
> Just saw you bounced half of your mailbox to the list and felt a sudden
> urge to chime in...
>
> On Fri, 2010-11-19 at 09:33 -0500, Yaroslav Halchenko wrote:
>
> > Have you seen other interesting Linux-based RT electrophysiology
> > acquisition/analysis projects at SfN10?
>
> Disclaimer: I've NOT been to SfN.
>
> It depends on what do you mean by realtime. I think a rough
> classification would include "soft" realtime which can be achieved with
> non-RT kernels and "hard" realtime which you can only achieve by using
> the RT patchset and what follows.
>
> >From what I know, there is a number of realtime EP acquisition systems
> available under FOSS licences which have been around for quite some
> time. Of course, there are also some commercial systems developed for a
> very particular task or having some special hardware in mind.
>
> There have recently been a small meeting of the developers of such
> systems at my institution:
>
> http://neuralensemble.org/trac/cole/wiki/COLE_2010
>
> There is not so much to see there, but you can download the list of
> participants and get an idea on who is involved.
>
> I can mention at least three systems without doing any prior research:
>
> 1) NeurOnline (developed at my institution)
> 2) RELACS [1] appears to be the oldest out there
> 3) MEABench [2] more geared towards MEAs
>
> The main goal of the meeting was to mitigate the NIH syndrome and
> concentrate on developing common standardized components instead of keep
> on re-inventing wheels of different calibers.
>
> [1]: http://relacs.sourceforge.net/
> [2]: http://www.its.caltech.edu/~daw/meabench/<http://www.its.caltech.edu/%7Edaw/meabench/>
>
> > It was our impression from SfN10, that there exist various very
> > interesting but disjoint efforts which might  benefit greatly if forces
> > get joined or at least centralized to some degree.
>
> This was our impression as well, hence COLE was created.
>
> I will forward the link to this thread to some of the attendants. Maybe
> if they are interested they can join the discussion or otherwise just
> have a look at it.
>
> > On our hand we could help making Debian (and thus its derivatives such
> >  as ubuntu) convenient out-of-the-box for such kind of research.
>
> Well... I am not sure that apart from RELACS there is other software
> that is so to say deployment-ready. From my experience, compilation and
> installation is actually the least complicated part of getting the setup
> running, what is really challenging is the configuration process.
>
> Often, the hardware is working somehow differently depending on the
> platform and you often need to re-compile after you figure out what the
> differences are etc.
>
> So in this sense I am not sure if the packages as such are going to be
> of huge help, since it's generally easier for users to install to /opt
> instead of learning how to rebuild the packages.
>
> What would really need packaging in my opinion are libraries. Having all
> dependencies and pre-requisites packaged would definitively help a lot.
>
> HTH,
>
> --
> Sincerely yours,
> Yury V. Zaytsev
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 28 Jan 2011 11:06:47 +0100
> From: Jan Benda <benda at biologie.uni-muenchen.de>
> Subject: Re: [Neurodebian-upstream] [Neurodebian-devel] poster copy
>        request
> To: neurodebian-upstream at lists.alioth.debian.org
> Message-ID: <201101281106.47518.benda at biologie.uni-muenchen.de>
> Content-Type: text/plain;  charset="iso-8859-1"
>
> Hi,
>
> one should really distinguish between real-time and online
> electrophysiology.
> Realtime would be anyting that uses a real-time kernel like RTAI and allows
> to
> make calculations on a per sample basis (kHz range). The software doing
> this
> and being out for quite some time is Rtxi http://www.rtxi.org. My RELACS
> www.relacs.net also supports this kind of realtime acquisition and
> computation.
>
> All the other data acquisition software seems to do online analysis, i.e.
> shows you some data and processed results on the fly. But this usually is
> done in user space by taking the data every few milliseconds.
>
> From looking what Bluespike does I would say it is an online type program,
> but
> it still uses RTAi and a kernel module for data acquisition. From how many
> channels can you record? Do you use comedi's comedi_data_read and _write
> functions, or do you use streaming acquisition with callbacks?
>
> Jan
>
>
>
> On Friday 28 January 2011 09:51:35 Yury V. Zaytsev wrote:
> > Hey!
> >
> > Just saw you bounced half of your mailbox to the list and felt a sudden
> > urge to chime in...
> >
> > On Fri, 2010-11-19 at 09:33 -0500, Yaroslav Halchenko wrote:
> > > Have you seen other interesting Linux-based RT electrophysiology
> > > acquisition/analysis projects at SfN10?
> >
> > Disclaimer: I've NOT been to SfN.
> >
> > It depends on what do you mean by realtime. I think a rough
> > classification would include "soft" realtime which can be achieved with
> > non-RT kernels and "hard" realtime which you can only achieve by using
> > the RT patchset and what follows.
> >
> > >From what I know, there is a number of realtime EP acquisition systems
> >
> > available under FOSS licences which have been around for quite some
> > time. Of course, there are also some commercial systems developed for a
> > very particular task or having some special hardware in mind.
> >
> > There have recently been a small meeting of the developers of such
> > systems at my institution:
> >
> > http://neuralensemble.org/trac/cole/wiki/COLE_2010
> >
> > There is not so much to see there, but you can download the list of
> > participants and get an idea on who is involved.
> >
> > I can mention at least three systems without doing any prior research:
> >
> > 1) NeurOnline (developed at my institution)
> > 2) RELACS [1] appears to be the oldest out there
> > 3) MEABench [2] more geared towards MEAs
> >
> > The main goal of the meeting was to mitigate the NIH syndrome and
> > concentrate on developing common standardized components instead of keep
> > on re-inventing wheels of different calibers.
> >
> > [1]: http://relacs.sourceforge.net/
> > [2]: http://www.its.caltech.edu/~daw/meabench/<http://www.its.caltech.edu/%7Edaw/meabench/>
> >
> > > It was our impression from SfN10, that there exist various very
> > > interesting but disjoint efforts which might  benefit greatly if forces
> > > get joined or at least centralized to some degree.
> >
> > This was our impression as well, hence COLE was created.
> >
> > I will forward the link to this thread to some of the attendants. Maybe
> > if they are interested they can join the discussion or otherwise just
> > have a look at it.
> >
> > > On our hand we could help making Debian (and thus its derivatives such
> > >  as ubuntu) convenient out-of-the-box for such kind of research.
> >
> > Well... I am not sure that apart from RELACS there is other software
> > that is so to say deployment-ready. From my experience, compilation and
> > installation is actually the least complicated part of getting the setup
> > running, what is really challenging is the configuration process.
> >
> > Often, the hardware is working somehow differently depending on the
> > platform and you often need to re-compile after you figure out what the
> > differences are etc.
> >
> > So in this sense I am not sure if the packages as such are going to be
> > of huge help, since it's generally easier for users to install to /opt
> > instead of learning how to rebuild the packages.
> >
> > What would really need packaging in my opinion are libraries. Having all
> > dependencies and pre-requisites packaged would definitively help a lot.
> >
> > HTH,
>
>
>
> --
> ---------------------------------------------------------------------------
>
> Dr. Jan Benda
> Biozentrum der LMU                             phone: +49 / 89 - 2180 74805
> Department Biologie II                           FAX: +49 / 89 - 2180 74803
> Grosshaderner Str. 2                            room: D01 043
> D - 82152 Planegg-Martinsried
> Germany                                 web: <http://www.bio.lmu.de/~benda<http://www.bio.lmu.de/%7Ebenda>
> >
>
> ---------------------------------------------------------------------------
>
>
>
> ------------------------------
>
> _______________________________________________
> Neurodebian-upstream mailing list
> Neurodebian-upstream at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/neurodebian-upstream
>
>
> End of Neurodebian-upstream Digest, Vol 5, Issue 1
> **************************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/neurodebian-upstream/attachments/20110129/2c8adbf6/attachment.htm>

More information about the Neurodebian-upstream mailing list