AnsweredAssumed Answered

ADIS16228 USB board - sampling speed different than expected

Question asked by gemmer on Feb 22, 2017
Latest reply on Feb 27, 2017 by gemmer

Here I am, back at it with an ADIS16228 question.

 

For the purpose of consistency checking the results from the ADIS16228 (which we have potted and placed inside an aluminum case), our group also picked up the interface board (ADIS16ACL1/PCBZ) and the USB connector board. The hope is that we can show, through data gathered with this known-working system, that the potting and additional casing of the 16228 along with some power isolation circuitry does not adversely affect the results.

 

Using the Analog Devices USB client (1.5.0.5251), we can do a data gather on one of the registers, which is great. However, we noticed that when you specify how many samples you'd like to collect, it auto-fills a field that says how many seconds of data this represents. The numbers seem off in two ways;

 

1) To gather 81920 samples is calculated to take 3.930902 seconds. That's at odds with the datasheet stated 20480 samples per second, and seems to imply that data is being gathered at 20840 samples per second. That doesn't really affect the quality of the data, though, so I'm not very concerned about it.

 

2) It takes about twice as long as stated to gather that many samples of data.

 

I initially assumed that this was due to some buffering that was taking place before the USB transmissions were made, but to confirm, I attached a logic analyzer to the !CS and the DIO2 line. Here's what I'm seeing out of it:

A logic trace of CS and DIO2 appears to show that two samples are taken every time the DIO2 indicates data ready.

 

It seems like the DIO2 line is showing data-ready, and then the board is double-reading the figure. I assume that this is to check data integrity - is that correct? Finally, when I look at the CSV that the logger produces, it has only the expected number of readings in it (well, something similar to it; 81920 samples produces 83360 rows in the CSV, corresponding to four seconds at 20840). But it took eight seconds to gather that data.

 

In short: it seems that the USB data gathering is making about twenty thousand requests for data per second, but only ten thousand of those are "unique" requests for data, with the other half occurring before a new data-ready signal. Because of this, when the client says it will collect N seconds of data, it takes 2N seconds to receive the data. Is all of this the expected?

Outcomes