Re: Strangeness with cb_pcidas and 1602/16 board

On Thu, 8 Aug 2002, Frank Mori Hess wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Thursday 08 August 2002 16:44, you 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?

The pigs of the world are looking to you as their savior, Frank! :)



>
> >
> > At first I thought that maybe this was because my two comedi_data_read()s
> > were issued one after another, and I was hitting some limit on how fast
> > you can talk to this board.  However, introducing some usleeps in the two
> > successive comedi_data_read()s for the two channels doesn't help matters,
> > so it isn't the fact that the comedi_data_read()s were happening one after
> > the other....
>
> Yes, the multiplexer is not changed until you call comedi_data_read() and
> there is no settling delay between setting the multiplexer and starting the
> conversion.  comedi_data_read_hint() can be called to set the multiplexer
> before you do your usleep, or comedi_data_read_delayed() will delay for the
> specified amount between setting the multiplexer and doing a conversion.

Ok, thanks for the advice.  I think the pigs of the world are grateful, as
am I.  I will try using comedi_read_delayed() for this particular board
and see if that solves my interaction problems...

It's still weird though, that I have to make special cases in my code
depending on which driver I am using.  Oh well.. *shrug*

Thanks a lot for your advice,

-Calin

Received on 2002-08-09Z14:04:45