Strange error on DAS 1002, and other similar cards with analogue input

[Massimiliano Chiandone]

Dear all,

here I describe this strange error.

I have two analogue lines. I use ch2 and ch3.

Channel are setted on range -10 : +10v

I put the same value on each: 5 v.

The read is correct o both channels:

inp -f /dev/comedi0 -s 0 -c 2

3084

inp -f /dev/comedi0 -s 0 -c 3

3084  

Now I put one of the two to 0 v.

 inp -f /dev/comedi0 -s 0 -c 2

2050

Now the first read on ch3 is wrong

  inp -f /dev/comedi0 -s 0 -c 3 

3072

If I repeat another read it is correct

inp -f /dev/comedi0 -s 0 -c 3   

3084

What happens is that each time I read ch 2, after this the first read on ch3 that follows is wrong. 

This happens with different versions of Linux kernel and comedi drivers. Last version used is Ubuntu 16.04 and comedilib 0.12.0.

I discovered this in real time with RTAI but as you can see is seems not to be a problem on RTAI. It happens with the simple inp demo program.

Maybe I am doing something wrong,

Thank you for any help.

Massimiliano

[Ian Abbott]

That is actually fairly typical. Most cards do not have an individual
A/D converter for each channel. They have a single A/D converter and an
analog MUX to switch the input. Also, the A/D converter does not
respond to changes in its input voltage (such as will occur when
switching channels on the MUX) immediately. There is a maximum rate of
change of voltage that it can track, known as the "slew rate".

When reading an analog input channel on a card with a MUX, the Comedi
driver first switches the MUX to the desired channel and then triggers a
conversion. Due to the slew rate, the A/D conversion can happen before
the A/D converter has settled down to the new input voltage.

When you read the same analog input channel a second time, the A/D
converter input has already settled down to the new input voltage, so
the reading is more accurate.

There is a function `comedi_data_read_n` that reads the same channel
multiple times. If you call that on a new channel, you should see the
data gradually settling to the final reading.

There is also a function `comedi_read_data_delayed` that adds a delay
between changing the channel and reading it. (In reality, it reads the
channel twice with a delay between them, but discards the first reading).

There is also a function `comedi_data_read_hint` that supposedly changes
the channel but does not read it. (In reality, it does read the channel
but discards the data.)

--
-=( Ian Abbott <abb...@mev.co.uk> || MEV Ltd. is a company )=-
-=( registered in England & Wales. Regd. number: 02862268. )=-
-=( Regd. addr.: S11 & 12 Building 67, Europa Business Park, )=-
-=( Bird Hall Lane, STOCKPORT, SK3 0XA, UK. || www.mev.co.uk )=-

[Ian Abbott]

On 26/02/2021 19:05, Ian Abbott wrote:
> There is also a function `comedi_read_data_delayed` that adds a delay

Correction: that should be `comedi_data_read_delayed`.

[super...@gmail.com]

On Friday, 26 February 2021 19:07:24 GMT Ian Abbott wrote:
> On 26/02/2021 19:05, Ian Abbott wrote:
> > There is also a function `comedi_read_data_delayed` that adds a delay
>
> Correction: that should be `comedi_data_read_delayed`.

Also check the spec of the card - you may need a low impedance driver/buffer
for the input ro overcome the MUX capacitance and to read multiple channels
quickly.

[Massimiliano Chiandone]

Thank you very much.

The comedi read_data_delayed seems not to give any better behaviour.

I try to double the read.

Massimiliano

--
You received this message because you are subscribed to the Google Groups "Comedi: Linux Control and Measurement Device Interface" group.
To unsubscribe from this group and stop receiving emails from it, send an email to comedi_list...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/comedi_list/e16da13c-d8e6-7a05-db35-2e4c40309d06%40mev.co.uk.