ad7124_simple_capture.py does not find ad7124 device

Hi Jbeale,

I'm going to try to replicate what you're seeing here. There have been a few changes to the driver and pyadi-iio since that exercise was written, not sure which have made their way into the Kuiper image.

I've got the script running, just need to bias the inputs at a few mV to get a reasonable noise reading.

In the meantime, can you confirm you're using the latest Kuiper release, 2021_r1, from HERE,  (which, contrary to the name, was released this August)?

-Mark

Thank you very much for your reply! Yes, that is the link I used for the Kuiper image, and the device reports it is using a version from 3-Aug-2022:

analog@analog:~ $ uname -a
Linux analog 5.10.63-v7+ #1 SMP Wed Aug 3 14:47:24 UTC 2022 armv7l GNU/Linux

Are you able to remove/comment these lines and report back ?

https://github.com/analogdevicesinc/pyadi-iio/blob/master/adi/rx_tx.py#L337-L343 and replace them with 

x=data

The patch is a little bigger than this, but wanted to doublecheck that it works for you as well ... 

I made that change to /usr/local/lib/python3.9/dist-packages/adi/rx_tx.py  and re-ran the Python example code I listed above. The print(data) output now looks like what previously were all the same number in a text format, have become a binary representation of slightly different numbers:

bytearray(b'm \x00\x00p \x00\x00n \x00\x00k \x00\x00n \x00\x00n \x00\x00j \x00\x00a \x00\x00g \x00\x00l  [...and so forth]

Changing the last line of Python example code to print it in hex format, this looks promising. Looks like we now have 32-bit integers that look like real readings:

print( ' '.join('{:02x}'.format(x) for x in data) )

6d 20 00 00 71 20 00 00 6e 20 00 00 70 20 00 00 6b 20 00 00 6f 20 00 00 70 20 00 00 6f 20 00 00 6a 20 00 00 64 20 00 00 68 20 00 00 6c 20 00 00 6d 20 00 00 68 20 00 00 6a 20 00 00 70 20 00 00 71 20 00 00 6d 20 00 00 6b 20 00 00 69 20 00 00 67 20 00 00 6a 20 00 00 6e 20 00 00 6c 20 00 00 6b 20 00 00 72 20 00 00 70 20 00 00 6a 20 00 00 68 20 00 00 6a 20 00 00 6f 20 00 00 6c 20 00 00 6e 20 00 00 6b 20 00 00 6a 20 00 00 6e 20 00 00 69 20 00 00 6c 20 00 00 72 20 00 00 70 20 00 00 6d 20 00 00 6c 20 00 00 6e 20 00 00 73 20 00 00 71 20 00 00 6a 20 00 00 6c 20 00 00

[...and so forth]

An additional tweak to the display code shows that yes, the data now looks good:

fmt = "%dI" % (len(data) // 4)
print( list(struct.unpack(fmt, data) ) )

[8304, 8305, 8307, 8302, 8302, 8306, 8301, 8302, 8300, 8301, 8303, 8304, 8304, 8303, 8299, 8300, 8297, 8301, 8304, 8305, 8293, 8298, 8302, 8299, 8295, 8295, 8299, 8303, 8306, 8304, 8305, 8303, 8295, 8298, 8297, 8297, 8300, 8298, 8302, 8304, 8301, 8299, 8301, 8304, 8299, 8299, 8304, 8304, 8302, 8301, 8299, 8297, 8301, 8305, 8303, 8300, 8298, 8298, 8298, 8301, 8300, 8301, 8300, 8302, 8300, 8294, 8297, 8299, 8300, 8299, 8299, 8298, 8298, 8301, 8302, 8300, 8298, 8294, 8297, 8303, 8299, 8297, 8306, 8300, 8297, 8302, 8300, 8299, 8300, 8295, 8304, 8301, 8301, 8294, 8297, 8294, 8293, 8294, 8295, 8298]

Thanks, we will patch the library as soon as possible .. 

-Adrian

For reference, this code https://github.com/jbeale1/data-remote/blob/main/debug-plot-test.py  is now working to show me a live-updating plot of the ADC values.

I understand that the simple rx_tx.py fix of x=data may not be the final intended data format returned from my_ad7124.rx()  (or is it?)

Thanks for the plot app.

To answer your question: No, it is not the final intended data format .. The data format returned should be similar to:

[8304, 8305, 8307, 8302, 8302, 8306, 8301, 8302, 8300, 8301, 8303, 8304, 8304, 8303, 8299, 8300, 8297, 8301, 8304, 8305, 8293, 8298, 8302, 8299, 8295, 8295, 8299, 8303, 8306, 8304, 8305, 8303, 8295, 8298, 8297, 8297, 8300, 8298, 8302, 8304, 8301, 8299, 8301, 8304, 8299, 8299, 8304, 8304, 8302, 8301, 8299, 8297, 8301, 8305, 8303, 8300, 8298, 8298, 8298, 8301, 8300, 8301, 8300, 8302, 8300, 8294, 8297, 8299, 8300, 8299, 8299, 8298, 8298, 8301, 8302, 8300, 8298, 8294, 8297, 8303, 8299, 8297, 8306, 8300, 8297, 8302, 8300, 8299, 8300, 8295, 8304, 8301, 8301, 8294, 8297, 8294, 8293, 8294, 8295, 8298]

I think this is what people want .. 

We have to think about how to do the fix so it doesn't break other devices. The fix probably won't come for a week or so because of other commitments .. 

-Adrian

Thanks for looking into it. Just for fun, here's an example of a measurement running the chip at 100 sps that I made with the debug/workaround you mentioned. www.youtube.com/watch

This is pretty cool, thanks for sharing ! 

https://github.com/analogdevicesinc/pyadi-iio/pull/381 this is the pull request that will fix it. It changes quite a bit in the way data is acquired from the device. When this goes through, the fix will be part of the main branch and you will be able to use the mainline.

Thanks for reporting !

-Adrian 

Yup, what @asuciu said! Slightly off topic for the original question but since we're talking cool experiments, you might be interested in this paper that we wrote a while back that measures the AD7124's internal digital filter response, as well as its response to broadband noise:

https://conference.scipy.org/proceedings/scipy2021/adi_sdg.html

The code is up in our education_tools repo, and this reminds me, I'll go back and verify that everything still works after Adrian's fixes.

-Mark

Yup, what @asuciu said! Slightly off topic for the original question but since we're talking cool experiments, you might be interested in this paper that we wrote a while back that measures the AD7124's internal digital filter response, as well as its response to broadband noise:

https://conference.scipy.org/proceedings/scipy2021/adi_sdg.html

The code is up in our education_tools repo, and this reminds me, I'll go back and verify that everything still works after Adrian's fixes.

-Mark