No subject
Sun Jan 16 06:41:43 UTC 2011
but<br>
it still uses RTAi and a kernel module for data acquisition. From how many<=
br>
channels can you record? Do you use comedi's comedi_data_read and _writ=
e<br>
functions, or do you use streaming acquisition with callbacks?<br>
<br>
Jan<br>
<br>
<br>
<br>
On Friday 28 January 2011 09:51:35 Yury V. Zaytsev wrote:<br>
> Hey!<br>
><br>
> Just saw you bounced half of your mailbox to the list and felt a sudde=
n<br>
> urge to chime in...<br>
><br>
> On Fri, 2010-11-19 at 09:33 -0500, Yaroslav Halchenko wrote:<br>
> > Have you seen other interesting Linux-based RT electrophysiology<=
br>
> > acquisition/analysis projects at SfN10?<br>
><br>
> Disclaimer: I've NOT been to SfN.<br>
><br>
> It depends on what do you mean by realtime. I think a rough<br>
> classification would include "soft" realtime which can be ac=
hieved with<br>
> non-RT kernels and "hard" realtime which you can only achiev=
e by using<br>
> the RT patchset and what follows.<br>
><br>
> >From what I know, there is a number of realtime EP acquisition sys=
tems<br>
><br>
> available under FOSS licences which have been around for quite some<br=
>
> time. Of course, there are also some commercial systems developed for =
a<br>
> very particular task or having some special hardware in mind.<br>
><br>
> There have recently been a small meeting of the developers of such<br>
> systems at my institution:<br>
><br>
> <a href=3D"http://neuralensemble.org/trac/cole/wiki/COLE_2010" target=
=3D"_blank">http://neuralensemble.org/trac/cole/wiki/COLE_2010</a><br>
><br>
> There is not so much to see there, but you can download the list of<br=
>
> participants and get an idea on who is involved.<br>
><br>
> I can mention at least three systems without doing any prior research:=
<br>
><br>
> 1) NeurOnline (developed at my institution)<br>
> 2) RELACS [1] appears to be the oldest out there<br>
> 3) MEABench [2] more geared towards MEAs<br>
><br>
> The main goal of the meeting was to mitigate the NIH syndrome and<br>
> concentrate on developing common standardized components instead of ke=
ep<br>
> on re-inventing wheels of different calibers.<br>
><br>
> [1]: <a href=3D"http://relacs.sourceforge.net/" target=3D"_blank">http=
://relacs.sourceforge.net/</a><br>
> [2]: <a href=3D"http://www.its.caltech.edu/%7Edaw/meabench/" target=3D=
"_blank">http://www.its.caltech.edu/~daw/meabench/</a><br>
><br>
> > It was our impression from SfN10, that there exist various very<b=
r>
> > interesting but disjoint efforts which might =A0benefit greatly i=
f forces<br>
> > get joined or at least centralized to some degree.<br>
><br>
> This was our impression as well, hence COLE was created.<br>
><br>
> I will forward the link to this thread to some of the attendants. Mayb=
e<br>
> if they are interested they can join the discussion or otherwise just<=
br>
> have a look at it.<br>
><br>
> > On our hand we could help making Debian (and thus its derivatives=
such<br>
> > =A0as ubuntu) convenient out-of-the-box for such kind of research=
.<br>
><br>
> Well... I am not sure that apart from RELACS there is other software<b=
r>
> that is so to say deployment-ready. From my experience, compilation an=
d<br>
> installation is actually the least complicated part of getting the set=
up<br>
> running, what is really challenging is the configuration process.<br>
><br>
> Often, the hardware is working somehow differently depending on the<br=
>
> platform and you often need to re-compile after you figure out what th=
e<br>
> differences are etc.<br>
><br>
> So in this sense I am not sure if the packages as such are going to be=
<br>
> of huge help, since it's generally easier for users to install to =
/opt<br>
> instead of learning how to rebuild the packages.<br>
><br>
> What would really need packaging in my opinion are libraries. Having a=
ll<br>
> dependencies and pre-requisites packaged would definitively help a lot=
.<br>
><br>
> HTH,<br>
<br>
<br>
<br>
--<br>
---------------------------------------------------------------------------=
<br>
<br>
Dr. Jan Benda<br>
Biozentrum der LMU =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
phone: +49 / 89 - 2180 74805<br>
Department Biologie II =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
FAX: +49 / 89 - 2180 74803<br>
Grosshaderner Str. 2 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0room: D01 043<br>
D - 82152 Planegg-Martinsried<br>
Germany =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 web=
: <<a href=3D"http://www.bio.lmu.de/%7Ebenda" target=3D"_blank">http://w=
ww.bio.lmu.de/~benda</a>><br>
<br>
---------------------------------------------------------------------------=
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
Neurodebian-upstream mailing list<br>
<a href=3D"mailto:Neurodebian-upstream at lists.alioth.debian.org">Neurodebian=
-upstream at lists.alioth.debian.org</a><br>
<a href=3D"http://lists.alioth.debian.org/mailman/listinfo/neurodebian-upst=
ream" target=3D"_blank">http://lists.alioth.debian.org/mailman/listinfo/neu=
rodebian-upstream</a><br>
<br>
<br>
End of Neurodebian-upstream Digest, Vol 5, Issue 1<br>
**************************************************<br>
</blockquote></div><br>
--90e6ba6e84f010ce8e049af0a6c4--
More information about the Neurodebian-upstream
mailing list