Currently, most of NeuroRighter's input stage is configured using the UI thread
in a single class file. Its stable, but pretty obviously the most poorly
written portion of NeuroRighter.
To make hardware configuration more
1. Readable
2. Modular
3. Extensible to support changes in DAQmx and support new cards
The input stage should be modularized. The nuts and bolts of configuration can
be built from large proceedural blocks of code with tons of exception handling,
but this part of the code base should be completely separated from what a user
has to configure in order to get their particular NI card to talk with NR.
Every card modal should have a provfile, derived from a base profile class
where the parameters relavant to collecting data with NeuroRighter can be
overriden a modified and the card model can simply be selected from a list.
This problem with the current handling of hardware setup is illustrated in a
recent conversation on the user forum:
https://groups.google.com/forum/?hl=en_US&fromgroups=#!topic/neurorighter-users/
ReOyirq1ADU
All that was needed here was for RTSI-based card sychnronization steps to be
removed since this user was using a USB card where RTSI is not an option. In
this case, the provide for this card should be something like
public static class NR_USB21x : NR_Card
{
N_V_CHANNELS = 16;
N_CARDS = 1;
USE_RTSI = false;
// else, revert to NR_Card defaults
}
Then, the NR_USB21x would appear in a drop down menu in the hardware config
dialog and hardware config nuts and bolts would be constrained to account for
these changes from default.
Original issue reported on code.google.com by jonathan...@gmail.com on 11 Jan 2013 at 3:35
Original issue reported on code.google.com by
jonathan...@gmail.comon 11 Jan 2013 at 3:35