Beaglebone Black vs Analog Discovery 2

[Ronnie]

Hi, I am running Debian on a BB Black (Linux BeagleBone 5.10.168-ti-r71 #1bullseye SMP PREEMPT Fri Sep 1 04:05:07 UTC 2023 armv7l GNU/Linux) and am seeing some weird results as well as some usb_submit_urb errors in dmesg. I wanted to verify that there is not an issue with BB Black and Analogy Discovery 2.  We have written custom Python using the library, which works great on a Windows laptop but when running on the BB Black, I got weird results from acquisition.  I noticed the following messages in dmesg repeating.  

[ 2720.547605] usb 1-1: usbfs: usb_submit_urb returned -121

Some more debug info when plugging the USB Device in:

[ 2736.867432] usb 1-1: new high-speed USB device number 3 using musb-hdrc
[ 2737.022005] usb 1-1: New USB device found, idVendor=0403, idProduct=6014, bcdDevice= 9.00
[ 2737.022032] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 2737.022043] usb 1-1: Product: Digilent USB Device
[ 2737.022053] usb 1-1: Manufacturer: Digilent
[ 2737.022062] usb 1-1: SerialNumber: 210321AF1D19
[ 2737.033208] ftdi_sio 1-1:1.0: FTDI USB Serial Device converter detected
[ 2737.033519] usb 1-1: Detected FT232H
[ 2737.034636] usb 1-1: FTDI USB Serial Device converter now attached to ttyUSB0
[ 2737.108703] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
[ 2737.109616] ftdi_sio 1-1:1.0: device disconnected
 

would we have better luck with Analog Discovery 3 in BB Black?

[attila]

Hi @Ronnie

Probably the BB USB port can't provide sufficient power. Try using powered USB hub or 5VDC supply for AD2.

[Ronnie]

Hello,

We are connected via power supply currently.  I just plugged in an AD3 as well and just noticed the error in dmesg as well.  Could it be related to this (https://forums.raspberrypi.com/viewtopic.php?t=168449)?  I am using a BB Black though.  This is the software I have installed

digilent.adept.runtime/now 2.27.9 armhf [installed,local]
digilent.adept.utilities/now 2.7.1 armhf [installed,local]
digilent.waveforms/now 3.21.3 armhf [installed,local]
 

[Ronnie]

Perhaps the usb message is normal in dmesg?  It happens constantly even with just running Waveforms

 

 

Edited December 12, 2023 by Ronnie

[attila]

Hi @Ronnie

Does the device work against the messages?

-121 EREMOTEIO can be caused by short packets URB_SHORT_NOT_OK. I don't understand why something so standard and commonly used is being logged. I don't yet know at which location/level is this message enabled.

 

[Ronnie]

It seems that everything still "works" like Waveform etc. but I get that error if you turn on kern.log in rsyslog.conf... every time I communicate with the AD2 or AD3 (tried both) on this specific OS: Linux BeagleBone 5.10.168-ti-r73 #1bullseye SMP PREEMPT Wed Nov 29 00:30:50 UTC 2023 armv7l GNU/Linux.  I had to turn off this specific logging because it happens so much.  I tried different cables and power usb.  Very strange issue.  

I do not get this error on another Linux Ubuntu load that I have.  I am not sure why so many -121 errors, as even basic commands cause it.  

I am getting some strange data on this same BeagleBone kernel, but might not be related to this... still trying to figure it out.  The data coming from this kernel is just a little bit off in comparison to Windows and the Ubuntu system.  

Edited December 13, 2023 by Ronnie

[Ronnie]

@attila you may be able to help me with one issue.  Its sort of strange and only occurs on the BB.  I'm going to insert some code to show you something interesting.  When I load my Voltage and Current data using AnalogOutNodeDataSet, some reason I have to execute this code twice in order to get visualization to (almost) properly work.  Do you know if I should be delaying somewhere or have any clues?  Could I be dropping data when trying to send to the AD2 and the second time around helps with that? This doesn't happen in Windows or Linux (64bit), but it does happen in BB Linux (arm 32bit).  

 

				# Voltage
                dwf.FDwfAnalogOutNodeDataSet(device_data.handle, ctypes.c_int(0),
                                             constants.AnalogOutNodeCarrier, voltages_buffer, ctypes.c_int(dac_points))
                dwf.FDwfAnalogOutNodeFrequencySet(device_data.handle, ctypes.c_int(0),
                                                  constants.AnalogOutNodeCarrier, ctypes.c_double(dacfreq))  # 10 Hz
                dwf.FDwfAnalogOutNodeAmplitudeSet(device_data.handle, ctypes.c_int(0),
                                                  constants.AnalogOutNodeCarrier, ctypes.c_double(voltage_absmax))  # amplitude=1
                dwf.FDwfAnalogOutNodeOffsetSet(device_data.handle, ctypes.c_int(
                    0), ctypes.c_int(0), ctypes.c_int(0))  # no offset

                # Currents
                dwf.FDwfAnalogOutNodeDataSet(device_data.handle, ctypes.c_int(1),
                                             constants.AnalogOutNodeCarrier, buffer_current, ctypes.c_int(dac_points))

                dwf.FDwfAnalogOutNodeFrequencySet(device_data.handle, ctypes.c_int(1),
                                                  constants.AnalogOutNodeCarrier, ctypes.c_double(dacfreq))  # 10 Hz
                dwf.FDwfAnalogOutNodeAmplitudeSet(device_data.handle, ctypes.c_int(1),
                                                  constants.AnalogOutNodeCarrier, ctypes.c_double(current_absmax))  # amplitude=1
                dwf.FDwfAnalogOutNodeOffsetSet(device_data.handle, ctypes.c_int(
                    1), ctypes.c_int(0), ctypes.c_int(0))  # no offset

Below is executing the above code once (bad data):

Next is executing above code multiple times (better data seems to occur the more times I run it, but still has a weird "tail/ending" part of the data stream):

[Ronnie]

Also if you know a way I can validate the data that was loaded from (FDwfAnalogOutNodeDataSet), is there an API that would give me the exact array I sent back to me?

[attila]

Hi @Ronnie

There is nothing wrong with this piece of code, but it could be somewhere else.
If you don't want to publicly post more script you could send it in private message.

Edit: There is not function to return the data.

[Ronnie]

@attila maybe you could help me re-create the situation with a simplified script rather than all of our other stuff mixed in.  I have an AD2 (and an AD3) that does "loopback" I believe from ch1 to ch2.  I have attached a picture.  I also modified an example py script that reads the third column in a CSV record and loads this.  However, I just need a little help "completing" the code to see if I can re-create and see it in the data response.  I have attached the Py Script and CSV file and the constants file I am using for the loopback test.  I am still learning about the SDK so any pointers could be useful.  See attachments.  PS: you can comment out numpy import

dac.csv dwfconstants.py simple_bb.py

Edited December 14, 2023 by Ronnie

[attila]

Hi @Ronnie

See the following: simple_bb2.py
- FDwfAnalogOutNodeDataSet expects data +/-1 normalized samples, this is multiplied by specified amplitude and offset added in the device
- adding AnalogIn capture configuration
- wait/sleep/delay should be used after offset/range adjustment for the levels to settle

[Ronnie]

Thanks @attila, this experiment helped a lot.  It seems that BB does give me the right results here, and so I started digging into our "bigger" python code to see why I am getting inconsistency with the data on the slower BB in comparison to Windows.  In our program, we basically setup everything and then have a loop that just scans data constantly.  If I add these two lines each time we scan, everything looks a lot better on the BB, but it adds so much latency.  If you don't have any hints of things to try, I could send over our full script but of course you would only be able to do code review (not run it).  I would have to send it in Private Message.  One more thing to add, we have autoconfigure on -- I really don't think I should need to Configure each time I scan... We our muxing between each scan though to switch a channel.    

        dwf.FDwfAnalogInConfigure(device_data.handle, ctypes.c_int(-1), ctypes.c_int(1))
        dwf.FDwfAnalogOutConfigure(device_data.handle, ctypes.c_int(-1), ctypes.c_int(1))

Edited December 14, 2023 by Ronnie

[attila]

Hi @Ronnie

For better performance turn off AutoConfigure, as it is in the earlier sample_bb2.py

Is the "wait" causing you 'much latency' ?
This is only needed for the first capture, after device connection, offset, range adjustment.

For the following captures you only have to restart the generator. 
dwf.FDwfAnalogOutConfigure(hdwf, channel, c_int(1))
The analog-in rearms itself so you only have to wait for the capture to finish. There is no need for FDwfAnalogOutConfigure.
while True:
    if dwf.FDwfAnalogInStatus(hdwf, c_int(1), byref(sts)) != 1:
(For other use cases the analog-out can also be configured to restart itself.)

 

[Ronnie]

Thank you, I did figure out one of the bugs. I found why I had to run FDwfAnalogOutNodeOffsetSet twice.  I guess the Offset is a c_double, but I was sending a c_int.  That seemed to matter on the BB more than others.  In Windows and 64bit Linux it did not matter, but in arm 32bit -- it did matter and didn't give me an error, just didn't work correctly.  

I am still looking into a difference in data on the BB, which seems to clear up if I run FDwfAnalogOutConfigure before each scan (very odd).  I am still wrapping my head around it.  

I sent you a private message to help with some more code review tips if you have some time : ) 

 

[attila]

Hi @Ronnie

In your project you are using the two AWG channels independently. The generates signals phase is given by the software start timing (FDwfAnalogOutConfigure)
If you want these to be perfectly phased, see the AnalogOut_Sync.py AnalogOut_Phase.py examples.

[Ronnie]

Thanks, I set it up this way as a test... but on BeagleBone (arm 32bit of software) only, I still needed to run FDwfAnalogOutConfigure after the first scan of the loop before it "stuck"... I am not sure why.  I guess we can live with it, just a strange behavior.  

Edited December 17, 2023 by Ronnie

[Ronnie]

Hi @attila -- Thanks for all the help, we got things working well for now on BB Black.  Out of curiosity, do you have any plans to support the BeagleV Fire?  It has a RISC-V CPU architecture so we couldn't get a waveforms that would install correctly.