Using Waveforms to connect to Analogue Discovery 2 on an Ubuntu VDI image

[John Williams]

I am using Waveforms on Ubuntu with Analogue Discovery 2 hardware. All works well on a local Ubuntu install. However in order to roll this out for student laboratories we will be using a Ubuntu image on a VDI and the VMWare Horizon client on Windows for access. When I attempt this the Waveforms application runs does not see the Analogue Discovery 2 Device. The Analogue Discovery USB device has been attached/connected to the VDI client and is listed when I type lsusb on a linux terminal. Is this something that should work, or are there any known solutions? If not what are the recommended workarounds?

The context of what I am trying to do is use the Analogue Discover 2 as a test instrument for DSP hardware practicals for my students. My preference is to use Ubuntu as the C/DSP development platform and therefore also to have Waveforms running on Ubuntu as the test instruments. At my university Ubuntu is provided over the VDI - they don't want to support dual boot as this disables the secure booth facilities (aparently). Any suggestions welcome. A fallback is to do it all on Windows but this would, in my opinion, be very much second best.

 

Regards,

john

 

[Lloyd Parkes]

I don't have an Anaolg Discovery 2 and I don't have a Linux VDI, but I do have an Analog Discovery PRO and a lot of experience with Linux.

When I plug my Analog Discovery PRO into my latop, I get three new devices showing up in lsusb. Do you get all three in your VDI?

Bus 003 Device 011: ID 0403:6001 Future Technology Devices International, Ltd FT232 Serial (UART) IC
Bus 003 Device 010: ID 1443:0007 Digilent Development board JTAG
Bus 003 Device 009: ID 0424:2512 Microchip Technology, Inc. (formerly SMSC) USB 2.0 Hub

The lsof utility tells me that waveforms is accessing the Analog Discovery PRO via /dev/bus/usb/003/010, which lines up with the middle entry above. I had a quick look at that device entry and got this. 

$ ls -l /dev/bus/usb/003/010
crw-rw-rw- 1 root root 189, 265 May 24 15:06 /dev/bus/usb/003/010

Do you have that in your Linux VDI?

Cheers,
Lloyd

[attila]

Hi @John Williams

Try reinstalling digilent.adept.runtime under Ubuntu.
https://digilent.com/reference/software/adept/start

[John Williams]

On 5/25/2023 at 10:42 AM, attila said:

Hi @John Williams

Try reinstalling digilent.adept.runtime under Ubuntu.
https://digilent.com/reference/software/adept/start

Hi @attila,

Thanks. I have tried this but still to no avail. Does the Waveforms App have a timeout for response on scanning the USB ports and could that be causing a problem? I have been able to get this to work with other USB devices such as embedded development boards, so am at a bit of a loss.

Regards,

John

[attila]

Hi @John Williams

There is no USB enumeration timeout option.

You could try running the /usr/share/digilent/waveforms/samples/py/Enumerate.py which will call a lower level library.

[John Williams]

On 6/5/2023 at 8:41 AM, attila said:

Hi @John Williams

There is no USB enumeration timeout option.

You could try running the /usr/share/digilent/waveforms/samples/py/Enumerate.py which will call a lower level library.

Thanks. Here is what I see report when I run this file - not sure what it should be.

FTDI Version: 0x10424
Devices: 1
 1. SN:b'' b'' flags: 0x1 type: 0x3 id: 0x0 locid: 0x0

DMGR Version: b'2.11.9'
Devices: 0

DWF Version: b'3.19.5'
Devices: 0
 

[attila]

Hi @John Williams

The device serial number and other info are not listed. This could indicate that some other process or application is taking control over the USB device, probably the default USB serial service.
The udev rules installed by adept.runtime should prevent this. Have you tried reconnecting the device after installing this ?

As an intermediate solution, after connecting the device try:
sudo rmmod ftdi_sio
sudo rmmod usbserial

[John Williams]

Thanks Attila. I have tried what you suggested but it still gives the same result showing 1 device under FTDI corresponding to the device being connected and 0 under DMGR and DWF. As far as I am aware the VDI requires VHCI drivers for USB which have to be rebuilt every time the kernel is updated. Could this be causing a problem? I would like to know if anyone else has got this software working on a VDI to find out a solution. Otherwise I guess we will have to have the students doing their courseworkr on the VDI Ubuntu image but using the Windows host OS to run the instrumentation software which is not ideal.

 

[attila]

Hi @John Williams

@malexander may have more ideas to try, next week when he returns.

On Window it is working well with VirtualBox/Linux.
Now I tried VMWare/Ubuntu. The AD2 is detected but the software connection to the device takes about 1.5 minutes.

[attila]

Hi @John Williams

It also works well with WSL.

[malexander]

@John Williams

I don't have any experience running our software in a VDI setup but have successfully used it with VMWare and VirtualBox, where the VM is hosted on the local hardware. I quickly skimmed a description of how VDI works and was given the impression that it involves one or more servers hosting the virtual machine with clients connecting remotely with through a local client running on their own hardware. Is this correct? Is the Analog Discovery connected to the server running the VM, or is it connected to a local desktop / think client that remotely connects to a server hosting the VM?

Maybe the UDEV rules are being applied correctly. If that's the case RW permission may not be assigned to the files created for the USB device. Have you tried running the software with "sudo" to see if that makes any difference?

Thanks,
Michael

[John Williams]

Hi all,

Thanks for the replies.

@malexander - Yes the VDI is as you described - the Ubuntu image is running on the cloud and we use a client (VMWare Horizon) running on Windows to connect to it. THe client can pass through USB. This is how our IT department set it up so they don't have to manage individual local lab images.

@attila I already suggested using WSL 2 or even using Docker images but they won't have this due to security concerns. In the past I have used VirtualBox successfully but this also isn't supported now we have the VDI which was introduced during the COVID lockdowns to support students working from home..

I already use the VDI to connect to USB development boards (Xilinx Vivado connecting to an FPGA and gdb connecting to an ARM Embeddded DSP board)  successfully so I don't think it is the UDEV rules. What I am trying to do is also use the Analogue Discovery boards with Waveforms software to provide the diagnostic tools for the DSP work instead of oscilloscopes and signal generators. My backup plan would be to run Waveforms on the Windows host with the development on the VDI but I would still prefer an all VDI solution - just as it would be more convenient for the students.

John

[Jeremy LAURENT]

On 6/14/2023 at 9:03 AM, attila said:

Hi @John Williams

@malexander may have more ideas to try, next week when he returns.

On Window it is working well with VirtualBox/Linux.
Now I tried VMWare/Ubuntu. The AD2 is detected but the software connection to the device takes about 1.5 minutes.

Did you ever figure out why it took so long to connect on VMWare/Ubuntu ? We are currently seeing the same issue with our AD2 running on VMware vSphere 6.7. The issue is not present before Adept 2 runtime version 2.18.3 as far as we can tell. 

We noticed that with Ubuntu and Adept runtime > 2.17.1 the read speed is way down and connecting to the AD takes ~ 2 min.    

[malexander]

Hi @Jeremy LAURENT

I looked back at the changes that were made between 2.17.1 and 2.18.3:

Adept Runtime for Linux 2.18.3 (07/13/2018):
    1. Updated FTDI driver to version 1.4.8.

Adept Runtime for Linux 2.18.2 (06/22/2018):
    1. Added support for FTDI FWID 0x61, which is used by a future product.

Adept Runtime for Linux 2.18.1 (06/14/2018):
    1. Added support for FTDI FWID 0x58, which is used by the Zuca.
    2. Added support for FTDI FWID 0x59, which is used by the OpenLogger MZ.

Adept Runtime for Linux 2.17.1 (12/15/2017):
    1. Added the ability to configure the XC7S25, XC7S50, and XCZ007S.
    2. Extended the DSTM API set to include the following functions:
       DstmTransfer

I suspect that the issue may be related to the FTDI driver (libftd2xx.so). You could try downloading the tar.gz for Adept Runtime 2.17.1 that matches your platform and use the FTDI driver from that version to replace the library installed on your system. If that resolves the issue then we know it's being caused by something FTDI changed in their driver.

Thanks,
Michael

[Jeremy LAURENT]

Thanks for the quick answer, I'll try that. BTW all the old download links for older version of adept seem to be broken 

[artvvb]

We'll take a look at the downloads. In the meantime, this link could be used as a workaround for that specific file: https://digilent.s3.us-west-2.amazonaws.com/Software/Adept2+Runtime/2.17.1/digilent.adept.runtime_2.17.1-amd64.deb

Thanks,

Arthur

[Jeremy LAURENT]

Thanks @artvvb 👍

 I changed the symlink in /usr/lib64/digilent/adept from 1.4.24 down to 1.0.4 (the version bundled with adept 2.17.1) and now it works much better (connecting takes les than 3-4sec) .

 

This seems to indicate an issue with libftd2xx > 1.0.4 indeed 

Edited July 21, 2023 by Jeremy LAURENT

[malexander]

HI @Jeremy LAURENT

Interesting. I wonder if it's all versions > 1.0.4 or just some of them. The release notes imply that there were a lot of releases between 1.0.4 and 1.4.24. We didn't test them all... only the ones we included in the installer. If you can find an old download link you might try some of the newer ones and see if it makes any difference. I think it's also worth trying the latest (1.4.27) to see if that resolves the issue. Please share any additional information you discover here.

https://ftdichip.com/drivers/d2xx-drivers/

https://ftdichip.com/wp-content/uploads/2022/07/release-notes.txt

https://ftdichip.com/wp-content/uploads/2022/07/libftd2xx-x86_64-1.4.27.tgz

Thanks,
Michael

[artvvb]

57 minutes ago, artvvb said:

We'll take a look at the downloads.

The links are fixed - thanks again for pointing it out.

[Jeremy LAURENT]

On 7/21/2023 at 4:09 PM, malexander said:

HI @Jeremy LAURENT

Interesting. I wonder if it's all versions > 1.0.4 or just some of them. The release notes imply that there were a lot of releases between 1.0.4 and 1.4.24. We didn't test them all... only the ones we included in the installer. If you can find an old download link you might try some of the newer ones and see if it makes any difference. I think it's also worth trying the latest (1.4.27) to see if that resolves the issue. Please share any additional information you discover here.

https://ftdichip.com/drivers/d2xx-drivers/

https://ftdichip.com/wp-content/uploads/2022/07/release-notes.txt

https://ftdichip.com/wp-content/uploads/2022/07/libftd2xx-x86_64-1.4.27.tgz

Thanks,
Michael

Hello @malexander, 

I managed to find a dowload link for older versions of libftdi2xx (http://www.ftdichip.com/Drivers/D2XX/Linux/libftd2xx%{version}.tar.gz only works for version < 1.2.0). Seems like the issue is found since the version 1.1.0 (the one right after 1.04) and is still present in the latest  (1.4.27). I tried a few versions in between and all of them and they all had the same issue. 

I'm currently testing this on a xubuntu 22.04 VM running inside Vsphere 6.7, waveforms 3.20.1 and adept 2.79.9

Here are the speed tests for the different versions of libftdi2xx: 

1.0.4: 

1.1.0 :    

1.1.12: 

1.4.24: 

1.4.27 :

 

 

Sources: 

libftd2xx release notes: https://ftdichip.com/wp-content/uploads/2022/07/release-notes.txt
libftd2xx1.1.0: http://www.ftdichip.com/Drivers/D2XX/Linux/libftd2xx1.1.0.tar.gz
libftd2xx1.1.12: http://www.ftdichip.com/Drivers/D2XX/Linux/libftd2xx1.1.12.tar.gz
libftd2xx1.4.24: https://ftdichip.com/wp-content/uploads/2021/09/libftd2xx-x86_64-1.4.24.tgz
libftd2xx1.4.27: https://ftdichip.com/wp-content/uploads/2022/07/libftd2xx-x86_64-1.4.27.tgz

 

Edited July 25, 2023 by Jeremy LAURENT

[malexander]

@Jeremy LAURENT

Thanks for taking the time to test all the different driver combinations and share your results. Can you get by using driver 1.0.4? We can reach out to FTDI about the driver issue in vSphere, but based on previous questions regarding driver issues in VM I'm not very optimistic about receiving help from them.

Thanks,
Michael

 

[Jeremy LAURENT]

On 7/25/2023 at 4:38 PM, malexander said:

@Jeremy LAURENT

Thanks for taking the time to test all the different driver combinations and share your results. Can you get by using driver 1.0.4? We can reach out to FTDI about the driver issue in vSphere, but based on previous questions regarding driver issues in VM I'm not very optimistic about receiving help from them.

Thanks,
Michael

 

Sorry for the delay, I got heavily sidetracked. I put the latest waveform version on our test machines with the swapped FDTI driver and it seems to hold out just fine.

I was trying to deal with a "Invalid device handle provided" error but it seems unrelated to the driver and caused by our own code which worked before the update and still seem to work but returns a non zero value which trips the check_error function I added while testing the driver. 

Thanks,
Jérémy

Edited August 23, 2023 by Jeremy LAURENT