QA401 on Linux desktop

I’m evaluating QA401 for usage on Linux. Is all the functionality currently available from the REST API of QA401H so that a web based UI could be created to “replicate” the Windows software?

Hi @blurpy, almost all of the functionality is there, but not quite. For example, SNR is missing. But the “engine” used in the QA401H will replace the engine used in the QA401 application in the future and the SNR will be added. In short, the QA401H path will be the direction moving forward. And that should remove the final true Windows dependencies from the QA GUI app and hopefully allow it to run cross platform.

2 Likes

Oh, that’s even better than I had hoped for! Would be really nice to have the official GUI running on Linux. And using the API might be a good temporary solution, and of course nice for automation in any case.

Just a follow up question. I’m thinking that the changes you mention probably will take some time, so I’m wondering what the product support would look like after a potential successor arrives? In general, and especially if the successor arrives before those improvements are implemented. Will the QA401 software still get those improvements?

Yes, the aim is that both the QA401 and any successors will run in the same app. But, certain things that the QA401 has today, like DotNet Remoting, will go away. So, if you have written applications that talk to the current QA401 app to automate your testing, then upgrading the app means your old code won’t work anymore. REST as implemented in the QA401H (headless) app is the way forward Tractor and all the QA401 plug-ins will be changed to that REST interface. My guess is that this is all late 1Q2021 stuff.

Thank you matt, that sounds good to me.

I got the QA401 up and running on Linux (openSUSE Tumbleweed) with QA401H.

There is a mistake in the instructions though. The guides says to run the following command to “make it known to Linux”:

sudo sh -c 'echo "SUBSYSTEM==\"usb\", ATTRS{idVendor}==\"16c0\", ATTRS{idProduct}==\"4e27\", MODE==\"0666\"" > /etc/udev/rules.d/51-qa401.rules'

This rule should make the usb device readable and writable by everyone, but notice the “MODE” parameter uses “==” there, which is a comparison operator. So it doesn’t actually set the mode.

Here’s what happens when using this config:

$ cat /etc/udev/rules.d/51-qa401.rules 
SUBSYSTEM=="usb", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="4e27", MODE=="0666"

Lets plug in QA401 check the usb device permissions:

$ ls -la /dev/bus/usb/001/025
crw-rw-r-- 1 root root 189, 23 okt.   9 17:39 /dev/bus/usb/001/025

Does not look correct. Lets try anyway:

$ dotnet QA401H.dll
Version: 0.995
Exception in Usb.Open: Device Not Found.
Server started listening on port 9401

Not working so well. So lets change it so “MODE” uses “=” instead of “==”:

$ cat /etc/udev/rules.d/51-qa401.rules 
SUBSYSTEM=="usb", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="4e27", MODE="0666"

Replug QA401 and check permissions:

$ ls -la /dev/bus/usb/001/026
crw-rw-rw- 1 root root 189, 25 okt.   9 17:41 /dev/bus/usb/001/026

Looks promising. Lets try the app:

$ dotnet QA401H.dll
Version: 0.995
Loading FX2 with file 16C04E27.hex [b58731ad] (Match)
Server started listening on port 9401
Usb re-opened
Loading FPGA File:  qa401.bit [eeba84b2] (Match)
FPGA File DateTime: 4/4/2019 11:32 AM
..........................................
Done loading FPGA
===USB DESCRIPTORS===
        Endpoint: 0x1 Max Packet Size: 64 bytes
        Endpoint: 0x81 Max Packet Size: 64 bytes
        Endpoint: 0x2 Max Packet Size: 512 bytes
        Endpoint: 0x4 Max Packet Size: 512 bytes
        Endpoint: 0x86 Max Packet Size: 512 bytes
        Endpoint: 0x88 Max Packet Size: 512 bytes
Waiting for HTTP...
From your web browser, go to http://localhost:9401
Press 'X' to exit

Perfect!

A different version that is more restrictive is this, which I use currently:

$ cat /etc/udev/rules.d/51-qa401.rules 
ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="4e27", TAG+="uaccess", GROUP="plugdev", MODE="0660"

The permissions end up looking like this:

$ ls -la /dev/bus/usb/001/028
crw-rw----+ 1 root plugdev 189, 27 okt.   9 17:43 /dev/bus/usb/001/028

I am a member of the plugdev group of course, otherwise I would not have access to the device.

It’s probably a good idea to update the readme and the blog posts, at least with the fix to “MODE”.

There is also a mistake in the API documentation.

  1. The description is exactly the same for both graphs.
  2. The link in the second graph displays /Graph/Frequency/In/0, and points to /Graph/Frequency/In/AWeighting/0, and both are wrong. The working path is as it says in the title: /Graph/Frequency/AWeighting/In/0

I see there is an outdated example in the readme:

# Set Audio Gen 1 to ON, 1 KHz and -1 dBFS level
curl -d "" -X PUT http://localhost:9401/Settings/AudioGen/1/1/1000/-1

The api returns the following when trying that url:

---                                                                                           
Time 15:34:46.975                                                                             
PUT     Request:http://localhost:9401/Settings/AudioGen/1/1/1000/-1                           
Generator OnOff must be 'On' or 'Off'
Exception encountered: Exception has been thrown by the target of an invocation.              
Status: 400 (Elapsed: 2.90 mS)                                                                
---

The example in the api doc works:

First, we'd want to set Audio Generator 1 'on', at a level of 0
 dBV and a frequency of 1 KHz. That is accomplished with the following 
PUT command
HTTP PUT localhost:9401/Settings/AudioGen/Gen1/On/1000/0

Result:

---
Time 15:36:03.174                                                                             
PUT     Request:http://localhost:9401/Settings/AudioGen/Gen1/On/1000/0                        
Return: { "SessionId":"0" }                                                                   
Status: 200 (Elapsed: 0.95 mS)                                                                
---

Hi @blurpy,

Thanks for the reports. The doc error will be fixed in the 1.0 release of QA401H. Hopefully in the next 2-3 weeks.

For the 1.0 docs, I think it will move to github Wiki, and then the referenced blog posts will stay the same but have a note to refer to the wiki, and the wiki will have the most current syntax with repeated examples.

Also, the Linux setup issues you highlight can be put there. I personally don’t understand the subtleties, but I think your fellow users will and will appreciate.

1 Like

Great! Good idea to use the wiki, much easier to keep up to date.

Hi @matt

Having implemented the full API now with the exception of A-weighting and reset to default values I have some feedback and questions.

First, it’s a bit of a hassle to use the API from the browser due to missing CORS headers. I made a feature request here: https://github.com/QuantAsylum/QA401H/issues/4

Do you think it could be included in the next release? That would make it much easier to use.

From the doc:

GET /Data/Freq
Returns the frequency data of the prior acquisition, with the data representing dBV.

Looks to me like this is returned as volts, and not as dBV, so I had to do a conversion to get dBV.

From the doc:

PUT /Settings/Window/{WindowType}
WindowType: Valid values (case senstitive) and are Rectangle, Bartlett, Hamming, Hann, FlatTop and Kaiser7

Kaiser7 does not work:

Time 16:12:40.983
PUT Request:http://localhost:9401/Settings/Window/Kaiser7
Illegal Windowing value specified.
Exception encountered: Exception has been thrown by the target of an invocation.
Status: 400 (Elapsed: 0.61 mS)

It’s also not documented in the manual for the Windows software. Is this a reference to a future windowing type?

One of the steps in the manual for verification of the device requires generating a fixed tone, but that’s not possible. Is that on the roadmap for 1.0 of the API? What about the frequency response graph data?

I am pretty happy with what I have been able to achieve so far, so looking forward to more improvements and features.

The discussion on many of these items has shifted over to github (see here)

What Blurpy has built with an HTML version of the GUI that runs in your browser is very, very cool

1 Like