Klippel Near Field Scanner on a Shoestring

[b_force]

I knew responding was a bad idea but I did it anyway, silly me. That situation is now rectified and you hold the bronze medal position on my ignore list.

I am honored 👍😄😄

Strange response after not coming back with just arguments?

 

[b_force]

Depend’s on the Audio Interface and particularly the desired input for that Audio Interface. Notably most will want the by-passed input that does not offer attenuation.

With most, you mean most people?

Can you explain why an attenuator would be a bad idea?

 

[aslepekis]

Tom is correct: export to other programs (modeling program’s in particular) should be the priority. After that, sure Octave (for those that want to put in the extra development).

I may very well be misunderstanding what you are saying here, but we do need Octave (or similar software) for the mathematics and processing of the "raw" data since REW, ARTA, HOLMimpulse and other measurement suites don't have the ability to perform modal analysis or sound field separation. So some kind of mathematics package or custom software is going to be necessary. But I do certainly agree that export to other programs is also necessary, after all, getting all the fancy data doesn't do me much good if I can't design a speaker with it.

 

[mbrennwa]

The choice of the software should be based on (i) what you want to do and (ii) what you like to work with. I won't comment on (ii) because that's different for everyone, but (i) means that conventional audio test packages like REW etc. won't work because they do not allow you to do the sound field separation.

 

[Tom Kamphuys]

I'm currently doing my stuff in Octave, mostly because SFS and MATAA are available and I'm familiar with matlab (of which Octave is a clone).
Python would have been another option as SFS is also available in python and although I don't know much Python I seem to get things done. Kudos to python.

All I want to do is give people a choice how they do the measurements and how they do the postprocessing. I've imported manual angular measurements done using REW into Octave as test data for 2D model fitting and reevaluation. Now I can take automated measurements in Octave, but would like to use REW as a UI to see what I got. Later I hope to measure in Octave and process in Octave (2D) and (much) later full 3D SFS if we get the hardware in place.

 

[Tom Kamphuys]

Putting the impulse response in a .wav file is fine for output towards REW. That wat simple.

Now I have pre-ringing:



A measurement done in REW doesn't show this.

@mbrennwa : any idea what I'm doing wrong?

 

[mbrennwa]

@mbrennwa : any idea what I'm doing wrong?

Not sure. Can share a minimal code example?

 

[Tom Kamphuys]

Not at the moment. Full code is in GitHub: https://github.com/TomKamphuys/Audio/blob/main/angular_measurement.m

I tried fade in, fade out. REW seems to use that. I tried continuing to the Nyquist frequency and putting zeros from the last zero crossing onwards. All to no avail.

 

[mbrennwa]

What happens if you use an MLS or pink noise instead of the sweep?
What happens if you don't use loopback?
What happens if you don't use a calfile on line 41?

 

[ScottG]

With most, you mean most people?

Can you explain why an attenuator would be a bad idea?

It goes through the preamp section which often isn’t linear.

 

[b_force]

It goes through the preamp section which often isn’t linear.

preamp of the mic itself or audio interface?

 

[Few]

I usually see pre-ringing explained as resulting from the type of filtering applied. Here's a synopsis from Sound on Sound:

Pre-ringing​

Pre-ringing refers to an inherent character of the impulse response of linear-phase filters employed in D-A or A-D converters. In a conventional analogue or minimum phase filter, an input impulse signal will generate an output impulse response with a strong initial spike followed by a string of ripples of decrasing magnitude. In a linear-phase filter the impulse spike is preceded by a build-up of ripples in advance of the impulse arriving, and a symmetrical string of decaying ripples afterwards.

Might there be different filtering buried somewhere in the two processes?

Few

 

[Kravchenko_Audio]

What's wrong with keeping the data in Octave for automated processing and plotting? I feel that's 1000x more convenient than exporting the data to many files, importing each file to some other software, and process each and every file there, possibly manually.

Many of us old guys like a GUI. And that is not exactly available in Octave/Matlab.

 

[Kravchenko_Audio]

Anybody post this yet?

High-Accuracy Full-Sphere Electro Acoustic Polar Measurements at High Frequencies using the HELS Method

 

[mbrennwa]

Many of us old guys like a GUI. And that is not exactly available in Octave/Matlab.

A GUI can be added, if/where needed and suitable.

 

[ScottG]

preamp of the mic itself or audio interface?

Audio Interface.

ex. the excellent id24 that fluid just purchased:

 

[ScottG]

..getting all the fancy data doesn't do me much good if I can't design a speaker with it.

After getting the ”massaged”/processed data. (That data is not what I think of with respect to post-processing.)

 

[Tom Kamphuys]

What happens if you use an MLS or pink noise instead of the sweep?
What happens if you don't use loopback?
What happens if you don't use a calfile on line 41?

MLS : pre ringing present
no loopback : different, but still looks like ringing
no calfile : pre ringing present

 

[fluid]

Tom one thing you can do to look at it in REW is to change the window settings to only look at the response before the peak. By looking at the frequency response or filtering the IR you can see the spectrum of the preringing. If it is an antialias filter or similar linear phase induced bandwith limit it should show around the Nyquist frequency.

I have seen a similar thing in REW when the timing is slightly off from where it thinks it should be. You can manually change the T=0 time and see if it changes anything.

 

[mbrennwa]

no loopback : different, but still looks like ringing

Please try using the mataa_measure_signal_response(...) function for audio I/O instead of the mataa_measure_IR(...) so you can take a look at the data you get from the microphone and from the loopback channel. Check for things like clipping or cutoff at the beginning or end of the signals, or other undesired effects.