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.
- The description is exactly the same for both graphs.
- 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: Support CORS headers · Issue #4 · QuantAsylum/QA401H · GitHub
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
Considering that the QA402 is soon to be released, any chance that there will be an official Linux software release for it?
Hi @rsbonini,
The first release should run on Linux as-is under Mono. That is, the same binary on Win and Mac and Linux. However, there will be some artifacts that will probably limit the practical utility. I just tried on Ubuntu yesterday and the front-panel is drawn slightly weird (tiled), an exception was thrown when the panel was scrolled, and acquisition hung after a few dozen cycles.
So, obviously these will all need to be fixed before we can claim cross platform. But the pieces are there. The first goal is a viable replacement for the QA401 on Windows. That is the sole focus at this point and once that is met, we’ll expand out from there.
Thanks for the info. Really appreciate your responsiveness!