Deftige meetopstelling voor luisprekerparameters

[timpert]

De vraag is alleen niet of dat kan, maar of je op de juiste Re waarde uitkomt

Het meetprogramma voor lineaire parameters biedt nu aan om Re te bepalen uit modelfit, te meten voor de start van de AC meting of om gewoon in te voeren (bijvoorbeeld als je 'm al weet uit een eerdere meting). Omdat je voor de Re meting een extern stroombronnetje moet aansluiten kan je die meting alleen doen als je fysiek bij de opstelling in de kelder bent. Voor de rest kan ik al het andere doen met een remote desktop verbinding, en dat is wel zo prettig, want de testsignalen zijn niet fijn om van dichtbij aan te horen. Maar ik zie steeds een behoorlijke discrepantie tussen de gefitte en direct gemeten Re, en die is vervolgens weer direct van invloed op Rms, en daarmee dus ook op Cms en Mms. Ook mijn lineaire parameter meting is her en der nog voor verbetering vatbaar. Maar ik zorg eerst dat alles er is, dan ga ik knippen en scheren. Als laatste staat een nette GUI op de to-do lijst, maar die komt er pas als de fysica op orde is.

Is dan niet het nadeel dat de stijfheid zich heel anders laat gedragen bij lagere frequenties?

Ja, daarom kan ik deze methode alleen gebruiken voor BL(x) en Le(x). Ik wil de stijfheid op een andere manier gaan bepalen, maar daar ga ik komende vakantie over nadenken.

6Hz is alleen wel een HEEL stuk prettiger dan 200Hz

I know. Ik heb het een keer geprobeerd, en dat was te ruiken. Daarom gebruik ik eerst een Toptone breedbandertje van 2 euro om iets nieuws uit te proberen voordat ik een dure speaker inklem. Het ding doet het nog steeds...

[OWC]

Ja, daarom kan ik deze methode alleen gebruiken voor BL(x) en Le(x). Ik wil de stijfheid op een andere manier gaan bepalen, maar daar ga ik komende vakantie over nadenken.

Dat wordt een beetje lastig kip-ei verhaal dan.

Ik heb hier weleens direct met Klippel over gemaild, maar kreeg niet echt een duidelijk antwoord.

Trouwens even heel praktisch, maar mijn idee was om dit alles in een RaspPi of ESP32 te doen.
Met een beetje deftige ADC en leuk stroombronnetje kun je dan automagisch de DC stroom bepalen en dus Re waarde.
Het is niet heel lastig om dat allemaal automatisch te laten doen bij 1 druk op de knop ofzo

Om echter wel compatible te blijven met andere methodes, zou ik wel de daadwerkelijke Re DC waarde, alsmede de geëxtrapoleerde waarde weergeven. Laten we die dan Re_AC noemen (ja het spreekt elkaar een beetje tegen, I know)
Op dit manier kun je namelijk makkelijker datasheets en andere Klippel metingen vergelijken.

Je kunt het als een van de weinige wel juist doen, maar als niemand anders het op die manier gebruikt, is het weer niet heel zinnig als je snapt wat ik bedoel? Hoe frustrerend dat dan ook mag zijn.

[OWC]

Is er trouwens een specifieke reden om voor 6Hz te gaan of is dat gewoon een willekeurig gekozen getal?

[timpert]

Ik heb gekeken naar de DAQ mogelijkheden voor de Raspberry Pi, maar die vond ik onvoldoende voor deze metingen. De DT9837 die ik nu gebruik heeft helaas geen drivers voor ARM (zoals nog zo veel DAQ doosjes), dus vandaar dat ik een Windows laptop gebruik, dat werkt prima.

De signaalgenerator in de DT9837 is wat beperkt (kan alleen maar periodieke signalen genereren met een frequentie tussen 5,7 Hz en 10 kHz), maar deelt wel de klokgenerator met de vier simultaneous sampling ADC kanalen en dat is heel handig voor signaalverwerking met de diverse transformaties (Fourier, Hilbert etc). Veel DAQs hebben geen uitgang, of gemultiplexte ingangen (dus niet simultaneous sampling) en dat maakt ze minder geschikt.

Is er trouwens een specifieke reden om voor 6Hz te gaan of is dat gewoon een willekeurig gekozen getal?

Nee, behalve dan dat het onderin het bereik van de signaalgenerator ligt van mijn DAQ en dat 300 Hz er een veelvoud van is. De signaalgenerator heeft een vaste samplefrequentie van 46,875 kHz met een ringbuffer van maximaal 8192 bytes (ja, bytes) lang. Dat betekent dat een meertoons signaal alleen kan bestaan uit een grondtoon plus hele veelvouden daarvan.

[OWC]

Ik heb gekeken naar de DAQ mogelijkheden voor de Raspberry Pi, maar die vond ik onvoldoende voor deze metingen.

De RaspPi heeft gewoon een I2S poort, dus daar kan een mooie audio ADC/DAC/CODEC op
Het zou zelfs met een DSP kunnen, maar dat kan een RaspPi zelf ook wel handelen, dus ik zie daar niet helemaal het nut van in.

Maar volgens mij werken behoorlijk veel USB audio interfaces ook gewoon.
Uiteraard kan het ook gewoon op een normale Windows computer oid

Met op 6Hz is wel wat lastiger bij sommige audio interfaces.
Er zijn er die een HP hebben op ongeveer 7-15Hz.

[OWC]

Nee, behalve dan dat het onderin het bereik van de signaalgenerator ligt van mijn DAQ en dat 300 Hz er een veelvoud van is. De signaalgenerator heeft een vaste samplefrequentie van 46,875 kHz met een ringbuffer van maximaal 8192 bytes (ja, bytes) lang. Dat betekent dat een meertoons signaal alleen kan bestaan uit een grondtoon plus hele veelvouden daarvan.

Duidelijk!

Het is misschien interessant om hier een standaard voor te nemen.
Bijvoorbeeld Fs / 10 oid.
Of gewoon eerst eens sweepen en kijken waar de maximale excursie ligt.
In dat geval kun je op een wat meer efficiënte manier meten enzo.
Dan hoef je namelijk niet zoveel uit te sturen.

De vraag is alleen of dat nog eerlijk is bij allerlei verschillende soorten speakers?

Uiteindelijk is dat gewoon een kwestie van de methodes met elkaar vergelijken.

edit: daarnaast zorgt de stijfheid van de spider er ook nog voor dat de excursie gelimiteerd wordt.
In simulaties nemen we die zelden mee, maar er is dus een soort optimum zeg maar.

[timpert]

Bijvoorbeeld Fs / 10 oid.

Dat haalt mijn DAQ niet bij de meeste woofers, de laagste frequentie die ik er uit krijg is 46875/8192 = 5,72 Hz.

Of gewoon eerst eens sweepen en kijken waar de maximale excursie ligt.

De maximale excursie ligt bij f=0. Bij resonantie is de snelheid van de conus maximaal, maar de uitslag al aardig ingekakt.

[OWC]

Dat haalt mijn DAQ niet bij de meeste woofers, de laagste frequentie die ik er uit krijg is 46875/8192 = 5,72 Hz.

Ja daarnaast moet de FFT size ineens heel groot worden om überhaupt nog een beetje resolutie te hebben
Of de samplerate moet omlaag.

De meeste (bijna alle) 24bit ADC's zitten op een (kunstmatige) ondergrens van 44.1kHz.
Met een FFT size van 512K, is de resolutie 0.086Hz, laten we dat even afronden op 0.1Hz.

We hebben dan niet heel veel controle over de uitsturing van die lagere frequenties.

Er zijn 16 bits CODEC's die wel lager kunnen in samplerate.
Minimum is dan 32kHz, dan komen we uit op 0,063Hz resolutioe
De ondergrens van deze dingen ligt vaak ergens rond de 0.6Hz oid.

De samplerate van de ADC van die dingen kan (om een of andere reden) wel vaak een stuk lager, vanaf 8kHz.
Aangezien we echter naar die 600Hz carrier hoeven te kijken, schieten we daar niet zoveel mee op.

Ik zal eens kijken, volgens mij heeft TI namelijk een paar nieuwe IC'tjes die wel aan onze eisen kunnen voldoen

Maar goed, daar heb je op dit moment eventjes niets aan helaas.

[timpert]

Ja daarnaast moet de FFT size ineens heel groot worden om überhaupt nog een beetje resolutie te hebben

Dat valt gelukkig mee, omdat het signaal en de ADC met dezelfde klok getimed worden. In principe is een record lengte gelijk aan die van de signaalbuffer dan genoeg om alle frequentiecomponenten die er in het signaal kunnen zitten en hun harmonischen te pakken. Sowieso moet je een recordlengte gebruiken gelijk aan een heel veelvoud van de signaalbuffer, want dan vallen alle frequentiecomponenten precies in het midden van de frequentiebins en heb je geen spectrale lek naar de bins ernaast. Dat is iets wat met mijn DAQ heel goed kan.

Het enige gemis is dat mijn DT9837 geen arbitraire signalen op de uitgang kan streamen, dat kunnen de DT9837A en de DT9837C wel. Ik had nog even gekeken of ik met mijn functiegenerator de nodige testsignalen kan opwekken, en dat werkt ook. In arbitrary mode kan ik een golfvorm van 2 miljoen samples gebruiken, dat is bij 50 ksps een signaalduur van 40 seconden. Dat is meer dan genoeg voor een hele lange sweep, een sparse multitone signaal of een stukje muziek. Wel treedt een heel klein beetje spectrale lek op bij zo'n lang signaal doordat de klokken niet exact gelijk lopen, maar misschien is daar ook wel een oplossing voor. Ik kan namelijk mijn functiegenerator extern klokken met een 10 MHz signaal.

Wat betreft ingangssampling: de DAQ is vrij configureerbaar tussen 195,3 Hz en 52,734 kHz. Alleen de uitgang heeft een vaste samplerate. Voor mij was het een 90% oplossing voor een 5% prijs, dus de kleine beperking die ik nu heb daar werk ik wel omheen. En wie weet, misschien vind ik nog wel een -A of -C versie voor een schappelijke prijs. Zeg nooit nooit, dat heb ik met de sensorkoppen wel geleerd!

[OWC]

Waarom een DAQ en niet gewoon een audio interface als ik vragen mag?

[timpert]

Ik was al niet gecharmeerd van PyAudio, mijn Focusrite werkte er bovendien niet lekker mee samen. Eerder had ik gemerkt dat de kanalen bij lage frequenties wat uit elkaar liepen, daar heb je met een DC gekoppelde DAQ geen last van.

[OWC]

Ik wil de stijfheid op een andere manier gaan bepalen, maar daar ga ik komende vakantie over nadenken.

Toevallig ook even over zitten nadenken, maar ik denk dat ik er uit ben middels Hooke's law.

We weten namelijk dat F = k*x of in andere woorden F = Kms * x
Hierbij is F de kracht, x uitwijking en dan natuurlijk de stijfheid.

hieruit volgt dat:

Kms(x) = F / x = (M * a)/ x
Of in betere woorden Kms(x) = M * (d²x/dt²) * 1/x

Waar M = Mms en a is uiteraard de versnelling.

Edit:
En het lijkt erop dat het inderdaad de goede weg is;

https://www.klippel.de/fileadmin/klippe ... sensor.pdf

https://www.klippel.de/fileadmin/klippe ... lippel.pdf

Lees van de laatste ook even de appendix

Volgens mij houden we alleen ergens nog een constante over oid, die we moeten kalibreren?
Weet jij dat misschien @markbakk: ?
Het is alweer een tijd geleden dat ik zo heb lopen rekenen met integralen/differentialen, maar er staat me ergens van bij dat wanneer we van versnelling naar snelheid gaan er een constante oid bijkomt?

[OWC]

Overigens het niet-lineaire gedrag waar we het over hebben, heet het Payne-effect
zie:

Het is mij dan alleen nog niet helemaal duidelijk waarom we toch alsnog een lagere frequentie kunnen gebruiken om zo de Kms (Cms) te bepalen?

[timpert]

Ik ga die video maar eens bekijken.

[OWC]

Nog even wat verder erin gedoken.

In elk geval lijkt het op de Klippel in elk geval met hun oude systeem de microfoon hiervoor gebruikte.
Ik weet niet of ze dit inmiddels hebben aangepast.

Maar SPL is namelijk direct evenredig met de versnelling.

for_2_acc.png (2.17 KiB) 199 keer bekeken

for_1_acc.png (2.8 KiB) 199 keer bekeken

Toevallig kwam ik dit ook tegen op stackexchange, dus dat scheelt mij weer een hoop uitleggen;

https://physics.stackexchange.com/quest ... er-creates

en

https://physics.stackexchange.com/quest ... 877#367877

Het is mij alleen ook niet helemaal duidelijk of Novak hetzelfde doet?
Daarnaast zal er een soort van kalibratie moeten plaatsvinden.
Mijn Line Audio microfoon kan wel hard, maar niet ZZOOOOO hard
Dus met de grotere uitwijkingen zullen ze het toch uit iets anders halen.

Ik wacht overigens nog steeds met volle smart op mijn LDS!!

[timpert]

Die vergelijkingen zijn me bekend, maar ze gelden slechts onder bepaalde omstandigheden: de afstand tot de speaker is veel groter dan de straal van de conus, en de speaker straalt homogeen in het halfrond (dus in een oneindige baffle zonder te bundelen). Aan beide voorwaarden wordt in mijn opstelling niet voldaan.

Klippel biedt nog steeds de mogelijkheid om een microfoon te gebruiken, er zit een extra armpje aan de opstelling om de microfoon te monteren. Mijn opstelling kan dat nog niet, maar dat is een kwestie van een extra clipje of wat kauwgom. Je meet dan in het nabije veld, ik weet de exacte uitdrukking niet uit mijn hoofd, maar de afhankelijkheid van afstand is daar verdwenen zolang je flink dichterbij dan 1 golflengte zit, en dat komt door de grote mismatch tussen de akoestische impedantie van de lucht en die van de conus plus aandrijving. Maar ik ga me daar pas op storten als ik de niet lineaire parameters in orde heb.

Wat voor sensor heb jij aangeschaft?

[OWC]

Ja dat is waar ook.

Kunnen we in dat geval niet volstaan met a = w² * x ?

Wat er dus op neer komt dat Kms = Mms * w² = Mms * (2*pi*f)²

...... dat lijkt me ook niet helemaal juist
Volgens mij zie ik iets over het hoofd wat extreem obvious is , haha
We duiken er weer even verder in

De methode met verschuiving van Fs lijkt mij hier toch nog steeds de meest voor de hand liggende.
Alleen zit je dan met de freq sweep en SPL + het is duidelijk dat Klippel wat anders doet.

Ik heb een FSD23-35-AV

http://en.gzfuwei.com/ProductsStd_317.html

±15mm bereik

Deze heeft 6 micron resolutie, and 0.1% F.S , wat dus nog te verbeteren valt met kalibratie
Maar zelfs zonder zit je op maximaal ±0.04mm resolutie (iets beter zelfs)

500us sampling (2kHz), moet voor zulke dingen goed genoeg zijn.

[OWC]

Ik denk toch dat we het in de hoek van SPL meten moeten zoeken.

Ik zit nog even door wat Klippel papers te spitten;
https://www.klippel.de/fileadmin/klippe ... ent_01.pdf

pagina 3, dit is exact wat we eerder hebben besproken

Sound Pressure Prediction
Using the estimated transfer function Hx(s) the sound pressure in
the far field can be predicted easily. Assuming a radiation in a half
space (2π-sr free field) the following relation

holds where P, SD, r and ρ denote the sound pressure, diaphragm
area, distance and density of air. With X(s)=Hx(s)U(s) this
corresponds to

in the frequency domain. Figure 6 shows the estimated sound
pressure spectrum for a real driver.

Maar zoals je terecht zei, geld dit enkel in far-field (wat ik achteraf wist )

Hoe dit echter praktisch wordt geïmplementeerd is niet helemaal duidelijk.

Trouwens, ben inmiddels al bezig met een eerste opzetje voor een stand-alone PCB waar dit allemaal netjes mee kan.
Ik denk dat we hier het beste gewoon gelijk een RaspPi voor kunnen gebruiken, wat denk jij?
Naar mijn ervaring laat zich dat beter programmeren en implementeren dan dit proberen aan te sturen via een USB bridge via windows + ook nog eens extra programering nodig voor een stukje software ed.

[OWC]

En als we dan toch bezig zijn, heb ik eindelijk weer de paper gevonden van Novak, waar duidelijk te zien is dat de stijfheid afhankelijk kan zijn/is van de frequentie;

https://hal.science/hal-02504339/document

[OWC]

En blijkbaar zat ik er dus helemaal niet ver naast;

Dynamical Measurement of Loudspeaker Suspension Parts.pdf

(452.01 KiB) 748 keer gedownload

De stijfheid die we eerder beschreven is de effective stijfheid, zie pagina 18.
Die inderdaad gelijk is aan Keff(Xpeak) = w²*Mms

Wat dus dit soort plaatjes oplevert;

Ik zou dit persoonlijk eerder de gemiddelde stijfheid noemen.

Wat trouwens een absoluut fascinerend plaatje is;

Blijkbaar maakt het dus uit of we van onder-naar-boven sweepen vs boven-naar-onder.


Nou wordt de nonlinear compliance bepaald vanuit een behoorlijk complexe manier vanuit de harmonischen die gemeten worden.

Echter, even brainstormend, vraag ik mij af wat voor informatie we krijgen als we niet de piek uitwijking nemen, maar het (sinus) signaal dat we opdelen in enkel een positieve en negatieve output met een abs(Vout-Vout) en een abs(Vout+Vout) functie

Hier even gesimuleerd in LTSpice;

In dat geval kunnen we in ieder geval verschil opmaken tussen de richtingen.
Echter, als de stijfheid dus nogal afhankelijk is van de frequentie, kunnen we daar niet heel veel mee.

Misschien kan iemand dit uitleggen, maar ik zie ook niet helemaal waarom dat ook niet een probleem is met de distortion methode die Klippel gebruikt?

[OWC]

Ik schrijf lekker door hoor, maar volgens hetzelfde document;

Pre Measurement
A first measurement performs a wide band sweep (from 5 Hz to 100 Hz) to measure the transfer function H1(jω) in
the case of the Two Signal Method or just the amplitude response X(jω) for the One Signal Method as shown in Fig.
5. This data is used to find the resonance frequency and calculates optimal setup parameter.

The main measurement performs a narrow band sweep starting one-third octave below the mechanical resonance
and ending just after the jumping effect above the resonance. For the 4 inch spider the measured displacement x(t) is
shown in Fig. 12. If the peak displacement does not meet the target value specified by the user the main
measurement is repeated after adjusting the voltage of the stimulus. By using an automatic voltage control a
complete measurement can be accomplished in less than a few minutes.

Dus in dit geval wordt er blijkbaar wel gewoon gesweeped?

Ik zal Erin eens contacteren, aangezien hij zo'n systeem heeft staan, kan hij ook wel uitleggen wat precies de procedure is

[timpert]

Ik heb bij verschillende drivers gezien dat bij een hele lage meetspanning de resonantiefrequentie eerst vrij hoog is, dan afneemt wanneer de uitsturing toeneemt (materiaalhysterese) en dan weer toeneemt door progressieve veerkarakteeistiek. Ook heb ik al gezien dat de richting van de sweep uitmaakt.

Maar uiteindelijk wil ik een signaal gebruiken dat meer representatief is: roze ruis of sparse multitone. Beide signalen heb ik al geprobeerd, maar toen liep ik er tegenaan dat de klokken van mijn functiegenerator en van de DAQ niet precies gelijk liepen. Vlak voor ik vertrok was het me gelukt om het 24 MHz kristal in de DAQ te dwingen om gelijk te lopen met het tweede kanaal van mijn generator, een SDG2042X, maar daar heb ik verder nog niks mee kunnen doen.

Als je de uitwijking meet, dan kan je inderdaad de versnelling bepalen met a=-ω^2x. Je moet dan eerst de FFT nemen en dit toepassen over de hele transformatie. Bij het fitten van het lineaire model gebruik je alleen de componenten bij de grondtoon. Of je gebruikt numpy.diff

Waar je verder nog voor moet oppassen is wanneer je laser en de ADC niet met de gelijke frequentie bemonsteren, je een zogenaamde zero order hold hebt gecreëerd, en je daar nog voor moet corrigeren. Ik wil dat nu als volgt oplossen:

Mijn laser genereert in "free running mode" een strobe signaal met de sampling frequentie. Die gebruik ik als referentie voor een PLL die 10 MHz produceert als externe klok voor de functiegenerator. Die produceert vervolgens op kanaal 1 het meetsignaal en op kanaal 2 de 24 MHz referentie voor de DAQ. Op die manier lopen laserkop, signaalbron en ADC mooi synchroon en hoef ik geen rekening te houden met spectrale lek en zero order hold effect.

[OWC]

Nog meer redenen om het dus allemaal op een dedicated bordje te doen

Misschien zit jouw LDS anders in elkaar, maar daar komt toch gewoon een analoog signaal uit?
Als je die nog even door een filtertje gooit maakt de clock van dat ding niks meer uit?
Of lees je hem digitaal in?

[timpert]

Er komt een analoog signaal uit, maar hij is ook digitaal uit te lezen. Helaas wel via RS232 in ASCII, dus vlot gaat dat niet, maar de interne opslag kan 1,3 miljoen punten opslaan die je na het meten kan downloaden. Bij 50 kHz is dat 26 seconden meten, maar het downloaden duurt 22 minuten. De controller heeft ook een LAN en USB poort, maar het protocol om de data er via deze poorten uit te halen wordt niet door Keyence gedeeld Een alternatief is de parallelle uitgang gebruiken, die werkt tot en met 50 kHz en heeft een resolutie van 21 bits en braakt in real time meetwaarden uit. Data downloaden na een proef is traag, maar geeft wel veruit de beste resultaten. Het goed instellen en gebruiken van de controller via Python was al een project op zich. De manual heeft iets van 270 pagina's.

[OWC]

Waarom dan niet gewoon analoog uitlezen?