MC_Rack suggestion thread (please discuss)

Hi

first of all:

greetz to the community and everybody I met at SIMEA 2004 (we had a really nice time)

In Reutlingen I talked to a MCS-software-engineer (sorry forgot your name :-/ or didn´t you wear a name tag?) and made some suggestions concerning MC Rack, so he told me to open a thread at the forums to have a broad community discussion on the further devlopment. So here are my suggestions:

1. Split MC Rack into a server-side and a client-side application (like in MEA Bench. >> long-time records are not affected by performance limits caused by high noise, also the monitoring could be independent from recording)

2. Recording from 2 amplifiers should be indepedent from each other. this would give more flexibility, you could stop one recording while the other one still runs.

3. The replay function should also get the possibility to load sequences of mcd-files (they are auto-numbered anyway).

4. Replay should use the whole cpu-power available (ok thats rather a bug-fix).

5. Instead of replay a simple "load complete and then scroll through"-function would be handy (including a zoom)

6. The Analyzer or the spike sorter could use a Hertz-counter for each channel (doesn´t need to be fully real-time, every second or so would be enough).

7. When you load an mcd-file into the replayer, it would be nice to have the rack-setup automaticly loaded

8. Another bug-fix: the lowest channel row of the analyzer is always half-sized. (not a real problem but looks weird).

these are a lot of suggestions and I hope the community (and the software developers as the most affected ones 8-D ) will discuss them and propably add some more.


greetz to all

christopher

Dear Christopher and MC_Rack users

thanks a lot for your detailed and excellent suggestions. The development of MC_Rack denpends on customer needs. Therefore, we
invite all MC_Rack users to send their suggestions and needs
to this forum, or directly to our support mail address.
We will gather your suggestions, publish a summary and a list of
suggestions which will be implemented in the next version of MC_Rack.

best wishes and thanks again to you Christopher


dieter

>1. Split MC Rack into a server-side and a client-side
>application (like in MEA Bench. >> long-time records are not
>affected by performance limits caused by high noise, also
>the monitoring could be independent from recording)

Hi,

I'm doing this already by using symantec pcanywhere - so I can monitor my my long-term measurements from bureau or home, if I want.
It works fine, but if you got a lot of activity on your Chips, you will get performance-problems with a CPU beneath 2 Ghz.

So a server/client application for mcRack would be nice...

>4. Replay should use the whole cpu-power available (ok thats
>rather a bug-fix).
>
>5. Instead of replay a simple "load complete and then scroll
>through"-function would be handy (including a zoom)

That would be a great help!


Thanks in advance,
sincerely Tom Wiegand

well....
thats actually not what i ment.
By serverside i thought of an application that just forwards the raw data via ethernet to another engine that does the spikesorting and anything else. If the server would broadcast the data (UDP would be best IMO) the client could filter out the packets for his part of the job and use them. this way you could work on two amplifiers independently and have independent mcd files. stopping one recording-session while the other one still runs would become possible. Since spikesorter and display are the most cpu consuming applications you dividing them from each other and the data acquisition process you would gain more system stability and flexibility (and lower the risk of data loss).

can you code that?

greetz and merry x-mas

christopher

I encountered a big problem with MCRack. While recording, the signals of the channels jumped to the next channels and were recorded there. You can see it when 4 good channels go dead. I also could tell this problem occured when my usual 5 trigger-events per file multiplied and there are thousands of trigger-events in a one minute-file!
It did only occur with very high spike rates or in longtime recordings, indicating a buffer overflow(?).

If a file showing that particular problem could be of any help to you, please contact me!
erich.diedrich@uni-tuebingen.de