I'm using gr-iio to read from an ad7768. The ad7768 is 24-bit, but the gr-iio block returns shorts. Are the results packed in to two shorts?
any thoughts on the missing data problem?
IIO-Scope only looks at individual buffers, so discontinuities between buffers will not appear. You can see from the tags that you have two separate buffers in the GR plot.
You are likely not pulling data fast enough from the device.
I was thinking this as well, but a couple things don't make sense.
If I set iio-oscope to capture 65536 samples I will get that many samples without any drops.
If I set gr-iio to a buffer size of 65536 then a notice a couple odd things. First, there aren't 65536 samples between each buffer_start tag, and second, there is dropped data in between these tags. The drops appear to occur around 8192 samples, which is very close to the gnuradio buffer sizes. SO it seems like the data might be getting dropped in the gnuradio world.
The buffer size I am refering to is the one that the gnuradio scheduler tells me.
In this flowgraph the the gr-iio block is configured for a buffer size of 16384. But the amount of data that gnuradio tells my block, ('typecast'), is a number determined under the hood by gnuradio not by gr-iio (i think). In looking at the source for gr-iio it seems that it correctly reports 'items_in_buffer' as the number of elements its going to return. I haven't dug through this code enough to figure out what's going on, but are you saying that the number of elements that gr-iio reports to gnuradio might not match the number of valid bytes it actually returned?
I'm not exactly sure why, but I haven't been able to make my typecast block work as expected.
The only thing that has worked is modifying the gr-iio source code to output int instead of short.
I have a feeling that the issue is related to the channel_read function which has awareness of the underlying data size.