USB-1608FS (and others maybe?): algorithm for reading analog inputs is not considering packet index and device quirks

[zougloub]

At least on this DAQ, the received packets are 64 bytes of which 31 values, yes, and then there's one 16-bit packet counter.

And two things can happen (they do happen on mine, at least):

• At the beginning of an acquisition, residue from a past acquisition are available
• The packets may not strictly be ordered by increasing endpoint number, unlike what the code says

So obviously things may not be very reliable if switching channels or looking at a dynamic signal.

Examples:

[[0, 1, 2, 3, 4, 5], [6, 7, 8, 9, 10, 11], [0, 1, 14, 15, 16, 17], [6, 7, 20, 21, 22, 23], [12, 13, 26, 27, 28, 29], [18, 19, 32, 33, 34, 35], [24, 25, 38, 39, 40, 41], [30, 31, 44, 45, 46, 47], [36, 37, 50, 51, 52, 53], [42, 43, 56, 57, 58, 59]]
[[0, 0, 2, 3, 4, 5], [6, 1, 8, 9, 10, 11], [0, 7, 14, 15, 16, 17], [6, 13, 20, 21, 22, 23], [12, 19, 26, 27, 28, 29], [18, 25, 32, 33, 34, 35], [24, 31, 38, 39, 40, 41], [30, 37, 44, 45, 46, 47], [36, 43, 50, 51, 52, 53], [42, 49, 56, 57, 58, 59]]

The way I'm managing to properly acquire (not very portable) is to use this packet counter, and to perform a short dummy acquisition before the real one. This will ensure that the residual packet indices will be in an expected range of values. Doing 5 dummy cycles, which results in remaining packet indices certainly >= 18. Then when doing the real acquisition, for the first 3 cycles, watch for packet index >= 18 and discard those (it's impossible to normally get values >= 18 because best case we have 0..17).

[zougloub]

There's another issue in AInRead, but since according to this issue AInRead is inappropriate, that issue is kind of moot:

>>> list(range(1,6))
[1, 2, 3, 4, 5]

The range of endpoints is incorrect, so the raw data contains a streak of 31 zeros.