Any time that you find discrepancies in calculations versus measurements it is progress! I spent nearly a year on a project that offered many many learning moments for me recently. Rather humbling that even after doing a lot of something you can learn a lot, or be rather puzzled as to why you have results as you do!
I still find that graph interesting.Well, with these 4 situations I cannot improve below 6.5kHz. In that sense it is as good as it gets, but it is not good enough and way worse than what Klippel claims.
It raises so many unanswered but important questions.
Does that for example means that Klippel measurements are unreliable below 40Hz?
Also, what is that 120Hz peak in the noise all about?
Are those standing waves in the room (aka room modes)?
If so, does that affects the fitting error?
Is this error SPL specific, does it change vs SPL?
I can go on for a little longer with this.
Most important take-away is that anything less than N=5 is basically not giving many benefits anymore.
As well as, since the error goes up again, we still need to stitch the measurements with gated measurements.
But to get enough frequency resolution there, we need again a long time window.
REW does not detect the correct start. In the thumbnail of the complete signal you can see that it is not at the start. So this seems not to be a problem.
The signal to noise is very low. That probably simply means that the speaker under test in unable to produce a significant amount of sound at these low frequencies.
Don't now, but everything below -20dB is good enough, so no problem. It does affect the fitting error. It is especially clear for N=5 and N=10 where the noise limits the fit_error for 120Hz.
Correct. Klippel shows this:
Error goes up again but stays below -20dB so it is OK. Having said that, I suspect that Klippel is actually using gated measurements for higher frequencies. 'Stitching' these is no problem. Just has to be done/implemented.
That's no problem for high frequencies. For these gated measurements in a reasonable room are perfectly fine.
I understand, but the point I am trying to make, is that there isn't that much to be gained with in this case?
Gated measurements can be easily done above 150Hz
Even 100Hz is doable.
You don't want to go higher than say 300-400Hz, otherwise the freq resolution is bugger all even for the higher frequencies.
So although that graph looks impressive, but the actual usable area we are looking at is basically roughly from 40Hz - 300Hz
Probably yes, but it's not clear from their graphs or papers?
There is a huge difference between probably, surely and factually.
It's about predictability here.
Sure, it's not a problem in this extremely particular case.
That is pretty obvious from the graphs.
How do we know how representative that is for other cases?
More importantly, what are the borderline cases?
And like I said, there are plenty of more questions to be asked here.
To be already ahead of that "smart-person", yes I do read their stuff and papers almost on a regular basis.
Amazing work @Tom Kamphuys ! I find it very inspiring to see this kind of progress.
Correct, Klippel's documentation states that they are using gated measurements above 1.5kHz (or there about).
This may or may not be a useful comment, but what about a driver in a baffle? It could potentially put more space between the source and reflective surfaces, and the only functions that would need to be computed would be those corresponding to 2pi radiation modes rather than 4pi. Klippel has an add-in for measuring a driver in a small baffle on their NFS.
You want to measure the speaker as a whole, not (one of the) the driver(s) in another situation.
Does that mean they just stitch above 1.5kHz, or actually only use a time window that's "equivalent" to 1.5kHz?
It's a bit of a rhetorical question, because looking at their data we kinda can guess the answer to that.
Which makes more sense than just measuring bare drivers.
A small baffle can je be simulated and eventually be corrected.
I have tried this myself and is even with a simple setup doable.
Probably even easier than the big massive AES baffle.
Even a bare drive will have the same diffraction issues.
But in that case the how and where becomes totally unpredictable and will differ case by case.
Totally undesirable in a test setup.
The AES up to 200mm size baffle is good, but it provides an unrealistic loading to the driver that is never going to occur in the real world unless you are soffit mounting flush into a wall your loudspeakers. As close to the actual baffle in your design leaves no issues at all.
I stumbled on this;
an very interesting approach of the 3D positioning device
A similar ideas has been mentioned in this thread before. The design in the video doesn't work for the current processing. It needs the speaker to be stationary.
Having said that, this is very nice for the test scanner I sometimes envision. A portable Hardware-In-the Loop solution to check everything is working. Python is great, but sometimes I miss the compiler to tell me my code isn't working instead of running into the bug runtime. Of course I should add more tests, but I don't like writing them...
Having said that, this is very nice for the test scanner I sometimes envision. A portable Hardware-In-the Loop solution to check everything is working. Python is great, but sometimes I miss the compiler to tell me my code isn't working instead of running into the bug runtime. Of course I should add more tests, but I don't like writing them...
I haven't used much Python, but there's Pycharm that looks like it could help with that. There's a free "community edition."
https://www.jetbrains.com/pycharm/
https://www.jetbrains.com/pycharm/
Not sure I would agree with the greatness of python but if you add type annotations then a linter should find pretty much all that a compiler of a typed language would find. Writing a few tests before coding can be a good habit to get into for many programs because it helps with the structure.
I am using PyCharm.
I have mypy in pycharm. I just installed pylint. It didn't find the type error I introduced on purpose. It mostly complains about lines being 2 characters too long and missing doc strings...
I am not a fan of all the on-top-of-Python faff. Just any old ASCII editor and a shell to run Python is good for me.
This might be useful for debugging: https://docs.python.org/3/library/pdb.html
This might be useful for debugging: https://docs.python.org/3/library/pdb.html
That is because it is not a linter that performs type checking. Mypy type checks as does pyright (microsoft), pyre (facebook), pytype (google) and no doubt plenty of others. I just looked this up and have no experience with any of them. Did mypy pass your type error test?
Personally I only use python for short scripts when I want to use a particular package with a python interface. This is fairly often though because for reasons beyond me python seems to have been adopted by much of the scientific, engineering and data processing communities as their main scripting language. Writing large programs in a scripting language like python seems unwise to me just as it is in a scripting language like javascript but at least python hasn't yet reached the nuttiness of something like typescript. It probably will though.
I have a background in C++ and a little bit of C# (and Java, although that's a while ago).
I don't program that often anymore, but can follow it on a higher level.
Personally, I find python really hard to follow mostly because the format isn't very consistent.
It's very different in that regard compared to most other languages.
To me it feels more like a scripting language and not a programming language.
I would also never use it for an entire program because of this reason.
Mostly because it seems to be very difficult to keep a clear overview about what is going on.
It's still only pseudo-portable, but it's something:
I'll see if I can print a neat box for it.
I moved the complete setup to a barn to do measurements in a space with more reflection free time, trying to use the gating method for the higher frequencies. Unfortunately the scanner stopped functioning every time in a scan. I've had that at home every now and then, but now it was every time.
I'm now trying to replicate that with an ever increasing test setup, trying to find the cause. The rotation table and audio is mocked at the moment (configurable via the config file). Until now everything works fine.
So progress is a bit slow as I'm hunting for bugs/problems.