QuantAsylum QA400 and QA401

Thanks for the input, I guess it is a bit of an turkey shoot selecting the cable to use, I did get the hub that also worked for Demian so I guess it will work for me.
Considering all advice given I selected a TE-Connectivity(AMP) cable from the Mouser catalog, https://nl.mouser.com/ProductDetail/571-1487587-1/, I figure that with a brand like that you can not go wrong.
I will report back on how it all fits together but do not hold your breath. Nicole Scherzinger - Don't Hold Your Breath (Official Video) - YouTube
 
Member
Joined 2004
Paid Member
Long USB cables can work, especially if no buss power is used. I did some involved distortion testing with the USB hub at the far end of a 3M 50' fiberoptic cable and was really impressed at how well it all worked. A copper link would be less successful with all the signal loss. 5M is about as long as the system can handle since there are loop timing consideration as well.
 
@BlacK_Chicken: I haven't received your bug report yet, but I was able to reproduce. The issue is that QA401H uses the number format you have configured in the OS, and the browser does not.

How it looks for me:

Code:
curl [URL]http://localhost:9401/Phase/Seconds[/URL] 
{ "SessionId":"2290222104", "Left":"0.00020784909723370925", "Right":"0.00020576029083909996" }



This is how it looks with German language:

Code:
curl [URL]http://localhost:9401/Phase/Seconds[/URL] 
{ "SessionId":"3592625235", "Left":"0,0005415564663523863", "Right":"0,0005391615949382826" }


To get the German language number format I started QA401H like this:

Code:
LANG="de_DE.UTF-8" dotnet QA401H.dll



Maybe you can get it working better by starting it like this?

Code:
LANG="en_US.UTF-8" dotnet QA401H.dll



I created an issue here with all the details: Decimal number format changes with language * Issue #6 * QuantAsylum/QA401H * GitHub
 
I have to apologize for my late response.... i was quite busy these days. And to be honest The lack of a GitHub account was another obstacle that held me back from filing a bug report right away.

Yes, the English language format did fix it me. Only had few minutes to try, but it seems to work as expected. Tomorrow I'll give it a second look.

Thank you very much for the GREAT support. Please let me know, if the bug report is still needed.
 
No worries, thanks for testing! You don't need to create a bug report, since I figured out how to reproduce the issue.

QA has made a test release of QA401H already with a proposed fix. I can no longer reproduce the issue. Can you download v0.9991 from QAs comment in the GitHub issue and start it without the workaround to see if it solved the issue for you?
 
QA401H v0.9991 works!

I have read your QA401H issue report. The report describes exactly the erroneous behavior i have observed.

In the meantime I tried to change my number-format on a system wide basis (on XFCE: settings -> language -> regional format -> select 'English (United States)' and apply). But that was not sufficient to run the v0.999 without the added
Code:
LANG="en_US.UTF-8"
flag.

Testing v0.9991:
(1) without added LANG flag: works
(2) with added LANG flag: works

I noticed that it is beneficial to unplug and replug the QA401 when changing between the QA401H releases.

Thanks again to Matt and blurpy for this great tool!
 
Pardon the lack of segway to the recent discussions in this thread, but have a question.

I have an older QA400 that I run from an old Win 7 laptop and besides some minor GUI annoyances, I really love it. I've read on ASR, and even right on the top of the unit it says dynamic range is 105db(ish) or so.
Question:
If the range is is only 105 or even 110db, then what is the other information being displayed in the -120 to -140 range? It does show information, including what I would interpret as the noise floor and some spikes. Is everything below 110 to be disregarded? What is actually being displayed in those very low minus db areas?
 
Wow, interesting and yes a bit confusing as well. But thank you, very cool to learn about that.
But this describes differences due to bins and fft, bit my question I think remains which is what does the stuff in the minus 110 to 140 mean, when the capabilities of the unit itself only reach minus 110? I might have to read that link again though- maybe it's in there. That was admittedly a bit over my head
 
The apparent noise floor of an FFT plot can be misleading. It depends on the FFT length / bin width and window function used, if any.

FFT Scaling for Noise - Audio Precision

And as soon you scale for rt-Hz, the spurious/artifacts levels are gone & false :D

So be careful :

1) sample 64k & SR 64K with a -100dBFS signal, where we have rt-hz as 1.0

2) sample 64k & SR 256K with a -100dBFS signal, where we have rt-hz NOT as 1.0

rt-Hz can be re scaled but the spurious/artifacts levels will be fishy :D

Hp
 
That's the part I don't understand.

You can play the concept using a calculator such as the one linked here.

First, find the noise of a 1k resistor in a 1 Hz bandwidth. The calculator reports that is 4 nV.

Next, find the noise of a 1k resistor in a 20 kHz bandwidth. The calculator reports that is 0.568 uV. The ratio of those two (568/4) = 141, which is the square root of your bandwidth, of 20 kHz.

Now, if you have everything set up for 1 Hz FFT resolution on a perfect analyzer, if you measured the resistor you would see the FFT level at 4 nV = -168 dBV. And the RMS noise in 20 kHz would be reported as 568 nV = -125 dBV.

That is how your reported RMS noise ends up much higher than the noise you see. The noise you see is a single FFT bin. So, if every bin from 20 to 20 kHz was 4 nV and 1 Hz wide, then you have (19980 * 4n) / sqrt(19980) ~= 568n.

As your FFT resolution drops below 1 (larger FFT), then the noise floor will drop. But the RMS will stay the same--lower noise but more bins. And as the FFT resolution increases (smaller FFT), the RMS will stay the same--higher noise but fewer bins.

Noise and Root Hz (RtHz) Display Options - QA401 - QuantAsylum Forum

There are some pictures in the post above that might help too. It's a tricky concept, but a very important one.
 
Some more QA402 measurements:

Sneak Peek: The QA402 - #24 by matt - QuantAsylum Forum

The QA402 should measure quite a bit better than the QA401 in most all measurements at 48k.

There's a discussion in the post about making a THDN measurement as a series of measurements at different attenuator settings. This can only happen if the ADC noise doesn't go nuts at higher input levels. And the PCM4220 does does very well in this regard.
 
Thanks Matt for this. I have some homework and testing to really digest this. It seems it's saying that you can either measure (with extreme accuracy) noise or peak signal/THD, which I think makes sense. I'm still unclear how accurate or not all the stuff between -110-130db when doing a peak signal THD measurement though. I might just have to do some more reading, but if you can give me a holdover snack explanation just for now till I digest the real version that would be helpful.
And thanks again- really love this unit and will buy the 402 when it comes out.
 
Member
Joined 2016
Paid Member
> When will the plugins support 192k settings?



Which one specifically? Many (most?) already do.
In priority order.

AmpThdVersusFrequency
Is it possible to make the increment minimum 0.1dB even 0.25dB is better than 1.

AmpThdVersusInOutLevel
Is it possible to make the increment minimum 0.1dB.

Thanks @QAMAtt JPEG_20210118_063209_352846877653763429.jpg JPEG_20210118_063443_2030304862633685350.jpg