I’m exploring to use Raspberry Pi 4 to control QA402 in production line. I see QA401H has not been updated for 2 years. Does it work on QA402?
I noticed that QA402 has a different ID (16c0:4e37) compare to QA401 (16c0:4e27). I installed dotnet 3.1 on raspberry pi but it has problem when opening
the usb port. When I use browser to open localhost:9401, it shows the QA401H REST API correctly.
So, what tweaks I need to correct the usb port open issue?
pi@raspberrypi:~/Downloads/publish $ dotnet QA401H.dll
Server started listening on port 9401
Linux Detected
Version: 1.03
Exception in Usb.Open: Device Not Found.
Hi @Chris, the functionality in QA401H was rolled into the QA402 software and continues to be evolved there (for QA401 users, the QA401H is still used). So, for QA402 and QA403 HW you can run the QA40x application and then go to http://localhost:9402/ in your browser and you should see the ‘help’ page come up.
And you can launch the QA40x application from the command line with -c flag and you should get a console (see below) that can help you debug your code interactions with the QA40x app.
Hi Matt, we have no problem using the application QA40x on PC and use Labview to use REST API to automate testing in our production line. We are using this setup already.
For now, I’m considering to eliminate the PC and just use Raspberry Pi 4 to control the QA402 via REST API by Python code. According to the QA401 headless & Linus support instruction, I installed dotnet 3.1 on Raspberry Pi to run QA401H.dll. Exception error was found in USB.Open. I thought Libusb was not able to find (or open) the usb port which QA402 was connected to. When I started the Chrome browser on Raspberry Pi and open /localhost:9401, the RESP API help page showed up correctly.
So, I have two questions. Since QA401H.dll was released for QA401 and its product id 0x4e27 is different from QA402 (0x4e37), will this make Libusb not able to open the usb to connect to QA402? What should be done to fix this? The second question is when QA401H.dll is run on Raspberry Pi, localhost port is still 9401 instead of 9402. What should be done to correct it?
Any plan to release headless & Linux support for QA402/QA403?
Any plan to release headless & Linux support for QA402/QA403?
Hi @Chris, you should be able to run the same PC QA40x application (used for the QA402 and QA403 hardware) on RaspPI as-is, and then communicate with it just like you with your LabView just as you do today.
As a first step, you might try to get the QA40x app running in a VM on your PC running Ubuntu. See the first link below. That will familiarize you with the steps in an environment where it’s easy to go back to scratch and start over. And once you are able to get the QA40x app running under Ubuntu in a VM, then move to the PI. And repeat the same steps. Probably some more things will be needed as Ubuntu likely has some stuff in-the-box that isn’t there on PI. Or just install Ubuntu desktop on your PI
And once you have the QA40x running on PI, then you can just point your REST code to the PI and it should just work.
The QA401H app will not drive the QA402 or QA403 no matter what you do. The QA401H headless app probably won’t get any more attention except for fixing a serious bug.
PS. I added instructions to the wiki for running the QA40x on Ubuntu.
The following was needed for the QA403 to work on a fresh install Ubuntu 20.04 LTS in VirtualBox. Also, see the note in the linked post about updating the device firmware. Note that it might be different for other Ubuntu, even 20.04, because I ran the below before the various updates had been applied.
I just noticed I made a mistake to use mono to run the setup exe file. I copied the QA40x.exe from the Windows 10 program files folder to Ubuntu and run it with mono. It works!
I also tried on Pi and it works as well. I will do some more tests on Python later. Thanks so much for you help.
Hi @matt I got problem using the QA40x app on Pi. When I RUN it, the 1kHz tone at Gen1 was not displayed. I also tried with Python to post acquisition and measure PeakDbv. The 1kHz tone was not observed.
Hi @matt , on Pi, no matter I operate on the QA40x app front panel or control via REST API, I confirmed that there was actually no output from the source by connecting to oscilloscope. This problem was not observed when running the app on Windows 10 or Ubuntu VM.
Hi @Chris, I’m not sure where the breakdown might be. From your screen shot in the PI the status bar shows that the application can read all the registers in the QA40x hardware (voltage, current, firmware rev), but for some reason it cannot read the data (which comes across on another endpoint).
The most likely culprit could be something amiss in the libusb. Is there an alternate version of that library that works (maybe libusb-1.0-0.dev)???
Hi @Chris, I think absent some trace data this will be hard to figure out. Could you get a usb trace using USBmon or something similar that would show what the traffic looks like? Also, is it possible the PI is very slow and some of the USB timeouts are too tight? You can’t adjust those. But to try and get an idea, can you tell me how long it takes to acquire, say 10 captures with a 64K fft at 48K sample rate? You can set the FFT to 64K size, verify the sample rate, click the “Acq” box in the status bar at the bottom to reset it, then press space bar to start sampling and start a stopwatch. When the Acq status reports 10 samples, stop and report the number. I’d guess it’s pretty close to a desktop, but if not, maybe the timeout is the issue.
Also, run the QA40x app with the console option (-c) and maybe some more information will be shown there (such as USB timeout).
If you are under a tight deadline, we have four of these $93 Win10 machines running tests and they work well (albeit a bit pokey for browsing). They come with a kit that lets you mount the computer right behind a monitor. Amazon can ship them 1 day.
@matt I tried to do 10 captures (64k fft @48kHz) on different systems.
Windows 10 PC: 15.6s
Ubuntu 10 VM on Windows 10 PC: 16s
Raspbian on Pi 4: 20.2s
Kali Linux on Pi 4: 21.6s
My PC is i7-8850H with 16G RAM/1T SSD. Although Pi4 is slower, it’s actually not that bad. Can you tell from below figures if the problem is due to Pi4 is too slow?
On Pi4, I installed Wireshark to do usbmon. Attached is the captured data for a single sweep of 8k fft @48kHz sampling. QA402 is on Bus 1, Device 5. I hope this gives you some hints.
@matt After testing with different OS, I found 32-bit OS (Raspbian and Kali) had the same problem while Ubuntu 64-bit doesn’t have. Further checked that libusb-1.0-0 and libusb-1.0-0-dev installed are arm64 on 64-bit OS and armhf on 32-bit OS. So, maybe the libusb armhf has some compatibility issue. Then, I tried on 64-bit Raspbian which needs some tricks to install mono. Then, the problem is gone.
For anybody wanting to run the application headless on Linux (i.e. raspberry) in order to just access the rest API, my colleague showed me xvfb
I was having problems running the app because I did not have a X server running on my headless raspberry pi:
mono QA40x.exe
Unhandled Exception:
System.TypeInitializationException: The type initializer for 'System.Windows.Forms.XplatUI' threw an exception. ---> System.ArgumentNullException: Could not open display (X-Server required. Check your DISPLAY environment variable)
Parameter name: Display
at System.Windows.Forms.XplatUIX11.SetDisplay (System.IntPtr display_handle) [0x00435] in <a3daa9b84fd241a497578a25f68bc3c7>:0
at System.Windows.Forms.XplatUIX11..ctor () [0x00077] in <a3daa9b84fd241a497578a25f68bc3c7>:0
at System.Windows.Forms.XplatUIX11.GetInstance () [0x0001c] in <a3daa9b84fd241a497578a25f68bc3c7>:0
at System.Windows.Forms.XplatUI..cctor () [0x000e3] in <a3daa9b84fd241a497578a25f68bc3c7>:0
--- End of inner exception stack trace ---
at System.Windows.Forms.Application.EnableVisualStyles () [0x00006] in <a3daa9b84fd241a497578a25f68bc3c7>:0
at .Main () [0x00000] in <7d11ae3736bdf06f4a6eb0d7f9cc04b8>:0
[ERROR] FATAL UNHANDLED EXCEPTION: System.TypeInitializationException: The type initializer for 'System.Windows.Forms.XplatUI' threw an exception. ---> System.ArgumentNullException: Could not open display (X-Server required. Check your DISPLAY environment variable)
Parameter name: Display
at System.Windows.Forms.XplatUIX11.SetDisplay (System.IntPtr display_handle) [0x00435] in <a3daa9b84fd241a497578a25f68bc3c7>:0
at System.Windows.Forms.XplatUIX11..ctor () [0x00077] in <a3daa9b84fd241a497578a25f68bc3c7>:0
at System.Windows.Forms.XplatUIX11.GetInstance () [0x0001c] in <a3daa9b84fd241a497578a25f68bc3c7>:0
at System.Windows.Forms.XplatUI..cctor () [0x000e3] in <a3daa9b84fd241a497578a25f68bc3c7>:0
--- End of inner exception stack trace ---
at System.Windows.Forms.Application.EnableVisualStyles () [0x00006] in <a3daa9b84fd241a497578a25f68bc3c7>:0
at .Main () [0x00000] in <7d11ae3736bdf06f4a6eb0d7f9cc04b8>:0
however, you may use xvfb, which is an in memory “fake” display.
sudo apt install xvfb
Xvfb :1 -screen 0 1600x1200x16 # start a screen with number 1
export DISPLAY=:1 # tell the application to use screen no 1
mono QA40x.exe # run
However, I still think it would have been great to add a command line argument to run the application in headless mode, not requiring an x server.
Headless operation is now supported in 1.167. Use -headless on the command line. You can also specify a hardware model on the command line. So:
Qa40x -headless -qa402
will launch a console only and look for a QA402. Note the hardware must be attached before you launch the app.
Also, the -headless option doesn’t just hide the UI, it never starts it in the first place. However, is still a instance in the beginning when a messagebox could be called. Maybe that should be removed.
