Re: Strangeness with cb_pcidas and 1602/16 board

On Fri, 9 Aug 2002, Ray Kelm wrote:

> Calin A. Culianu wrote:
> > On Thu, 8 Aug 2002, Frank Mori Hess wrote:
> >
> >
> >>>However, if I disable channel 1 in software, the interference pattern
> >>>disappears.
> >>>
> >>>***Even though channel 1 is still physically connected to its signal
> >>>source**.
> >>>
> >>>Basically, the simple act of issuing a comedi_data_read() on channel 1
> >>>affects/modifies the waveform I get out of channel 2.
> >>>
> >>>Is this odd or what?
> >>
> >>It is how the software is currently designed to work.
> >
> >
> > Hmm.  Frank.. while I respect your tremendous prowess as a programmer and
> > designer, and consider you tremendously gifted in all matters of the
> > cb_*.c files, I want to ask you if it's possible to reconsider this design
> > (is it possible from a technical standpoint to change the driver file to
> > remove unwanted channel noise).... ?
> >
> > This behavior isn't exhibited with other drivers for other boards
> > (ni_pcimio, for one, doesn't have strange interactions between channels).
> > What's more, when using this board for things like scientific experiments,
> > the level of 'noise' you get due to the interactions between channels for
> > this card is unacceptable.  We had to discard megabytes upon megabytes of
> > heart ECG data from one of our pig experiments because the ECG from the
> > pig's heart was unacceptably noisy.  The pig died, Frank!!  How many more
> > pigs must die before we can finally rid the world of heart disease?
> > What's more, how many more pigs must die senselessly due to noisy data?
> >
>
> Go back and look at the specs for your board. You can only get fast
> readings if you don't switch channels. The multiplexers on that series
> of boards seem to be really slow. That is the exact reason I switched my
>   systems from those boards to the NI boards.
>
> -Ray
>

Yeah you're right.  Hmm, I guess there is a reason this board is like half
the price of a comparable NI board.

However, we should still consider tweaking the cb_pcidas driver to
correctly compensate for this situation by doing a udelay() inside the
cb_pcidas_rinsn() function whenever the multiplexer state has changed...

-Calin

Received on 2002-08-09Z15:59:12