Deftige meetopstelling voor luisprekerparameters

[Pjotr]

Ja, blijft een ketting van thermische massa's verbonden door thermische weerstanden. Waarbij sommige weerstanden nog eens gemoduleerd worden door gewapper. Lijkt mij lastig in kaart te brengen en denk ook wel wat te vergaand in dit geval. Maar het kan natuurlijk wel.

[timpert]

een meting van 1u

Mijn meting duurde maar 24 seconden, langer kon ik die køtplaat echt niet aanhoren. Veel te kort om de magneet iets te zien doen. We zien dus inderdaad alleen maar de tijdconstante van spoel naar magneet.

Ik heb geen idee? Het zou best kunnen dat je optimalisatie probleem niet convex is en dat je in een lokaal minimum eindigt i.p.v. het globale minimum.

Het zou kunnen, maar het zou ook fysische realiteit kunnen zijn: in dit model veronderstel ik het magneetveld constant, maar dat is het natuurlijk niet. Er vindt fluxmodulatie plaats door de stroom door de spreekspoel, en waar in het tweetoons signaal de helft van de energie rond de resonantie zit, zit bij Rick Astley de meeste energie ruim boven fs. Eigenlijk moet ik dezelfde fit eens herhalen met een tweetoons signaal en kijken hoe de resultaten veranderen.

Een ander probleem treedt op omdat de extremen in de positie slechts af en toe worden aangetikt. Dat betekent dat het gewicht van deze punten in de fit er eigenlijk niet meer toe doet. Kijk je bijvoorbeeld naar dit plaatje van de uitslag per punt:

dan zie je dat er, ondanks dat de meting 1,2 miljoen punten heeft, slechts 3 punten de uiterste uitslag van 7,7 mm aantikken. Als daar de polynoomfit niet klopt maakt dat voor de totale loss zo gek veel niet uit, het midden heeft ordes van grootte meer gewicht. Als ik geen lichte regularization op de polynoomcoëfficienten toepas, dan krijg ik aan de uitersten vaak een gekke "flap" in de curves.

[timpert]

Lijkt mij lastig in kaart te brengen en denk ook wel wat te vergaand in dit geval. Maar het kan natuurlijk wel.

Dat gaat voor nu inderdaad veel te ver. Het kan, maar wat schiet je ermee op? Als ik met enige zekerheid de gemiddelde temperatuur van de spoel kan bepalen en die gebruik om het signaal terug te draaien als de boel te heet dreigt te worden, dan is voor mij het doel bereikt. Uitgebreid modelleren kan je later nog in postprocessing doen mocht dat gewenst zijn.

[hidjedewitje]

Dat gaat voor nu inderdaad veel te ver. Het kan, maar wat schiet je ermee op?

Klippel heeft, inmiddels al weer een tijdje terug, een paper gepubliceerd over het nonlinear modeleren van het thermische domein.
In zijn grafiekjes zie je heel duidelijk een U-vorm tegenover frequentie (ik ben het niet eens met de vertegenwoordiging in frequentie domein maar dat is een ander verhaal). De verschillen in thermische weerstand varieren van ~20 [K/W] tot ~120[K/W].

Als je dan accuraat temperatuur wilt weten voor bijvoorbeeld control of veiligheids toepassingen, dan is het wel relevant. Je zal ook zien als je heel ver in de toekomst wilt voorspellen, dat je error groter en groter wordt. Als je geen toepassing hebt voor accuraat temperatuur te weten, dan heb je er inderdaad niet zo veel aan.

[timpert]

Tijdens het meten ben ik alleen geïnteresseerd in de huidige temperatuur van de spreekspoel, en hoe die uit zo'n kort mogelijk stukje metingen te bepalen zodat ik tijdig in kan grijpen wanneer de spoel te heet dreigt te worden. De lange termijn modellering kan je, indien gewenst, altijd nog achteraf doen. Het enige wat je nodig hebt is een meting bij significant vermogen die lang genoeg duurt om richting thermisch evenwicht te gaan.

Overigens is dat met name interessant voor drivers die zijn ingebouwd, want de driver is in "free field" condities natuurlijk een stuk beter gekoeld dan in een gesloten kast. In een basreflexkast kan, afhankelijk van de exacte oriëntatie van de poort, een woofer juist in een sterke stroming staan.

[hidjedewitje]

Tijdens het meten ben ik alleen geïnteresseerd in de huidige temperatuur van de spreekspoel, en hoe die uit zo'n kort mogelijk stukje metingen te bepalen zodat ik tijdig in kan grijpen wanneer de spoel te heet dreigt te worden.

Dan zou je eventueel het materiaal van de spreek spoel(meestal koper of alluminium) kunnen gebruiken als sensor. Het temperatuur coefficient van die materialen kan je gewoon uit een boek halen. De meting kan je doen met DC of LF signaal in de luidspreker sturen en de de stroom meten. Met een laagdoorlaat filter kan je dan de DCR afschatten en dus de temperatuur herleiden.

Hoe nauwkeurig dat is durf ik niet te zeggen, maar gezien je een termische camera tot je beschikking hebt, moet dit te checken zijn.

[Pjotr]

Overigens is dat met name interessant voor drivers die zijn ingebouwd, want de driver is in "free field" condities natuurlijk een stuk beter gekoeld dan in een gesloten kast. In een basreflexkast kan, afhankelijk van de exacte oriëntatie van de poort, een woofer juist in een sterke stroming staan.

Ehm ja. Geluid is een drukgolf geen wervelwind... De luchtmoleculen op zich, zullen ter plekke van de luidsprekerconus hooguit een fractie van de afstand van X_max heen en weer gaan maar verder nauwelijks door de kast gaan stromen. Dus bij zowel CB als BR zal de lucht in de kast gewoon statisch opwarmen bij de luidspreker en verder door evt. convectiestroming. Bij een BR is er wel wat uitwisseling met de buitenlucht naar dat is ook niet meer dan Vd van de poort en gaat de lucht op zich ook grotendeels alleen heen en weer in de poort.

[timpert]

Dan zou je eventueel het materiaal van de spreek spoel(meestal koper of alluminium) kunnen gebruiken als sensor. Het temperatuur coefficient van die materialen kan je gewoon uit een boek halen. De meting kan je doen met DC of LF signaal in de luidspreker sturen en de de stroom meten. Met een laagdoorlaat filter kan je dan de DCR afschatten en dus de temperatuur herleiden.

Hoe nauwkeurig dat is durf ik niet te zeggen, maar gezien je een termische camera tot je beschikking hebt, moet dit te checken zijn.

Je omschrijft nu exact wat ik hier heb gedaan. De nauwkeurigheid van de methode hangt nauw samen met de laagste frequentie in het meetsignaal. De test met Rick Astley laat al een veel strakkere temperatuurschatting zien dan de eerste test, omdat er in het gebruikte liedje geen heel diepe bas zit. De piloottoon van 1 Hz wordt dan minder beïnvloed door het meetsignaal en de resulterende schatting van Rdc is nauwkeuriger.

Om ook CCAW te kunnen accommoderen is het het handigst om een gewogen gemiddelde te hanteren tussen de temperatuurcoëfficiënt van koper (0.393% per °C) en aluminium (0.431% per °C) afhankelijk van de samenstelling van de draad. In de meeste gevallen ga je voor 100% koper, maar CCAW heeft typisch tussen 10 en 15% koper en de rest aluminium. Maar dat is triviaal om te implementeren.

Geluid is een drukgolf geen wervelwind...

Als je alleen rustig speelt wel ja, maar als je de volumeknop een beetje flink opendraait dan wordt bijvoorbeeld de stroming in je reflexpoort wel degelijk turbulent, en dat heeft gevolgen voor de warmte uitwisseling met de buitenwereld, die neemt flink toe. Maar het punt blijft: dat een ingebouwde luidspreker zijn warmte een stuk slechter kwijt kan dan een luidspreker in de vrije lucht.

[hidjedewitje]

Je omschrijft nu exact wat ik hier heb gedaan.

Dan heb ik niks gezegd!

Als je alleen rustig speelt wel ja, maar als je de volumeknop een beetje flink opendraait dan wordt bijvoorbeeld de stroming in je reflexpoort wel degelijk turbulent, en dat heeft gevolgen voor de warmte uitwisseling met de buitenwereld, die neemt flink toe.

Die turbulente flow is er wel degelijk en zorgt ook voor een nonlineare Rms (velocity dependent). Als je dat Klippel paper leest zie je ook dat de vorm van de thermische weerstand (die dus zo veel verandert) een beetje dezelfde vorm heeft als de inverse van de velocity curve (een dip rondt de Fs van de luidspreker, ipv een piek).

[timpert]

Tijdens een meting kwam ik er achter dat mijn versterker eerder tegen zijn limieten aanliep dan ik had verwacht, waardoor ik me afvroeg of het nog een onsje lomper mocht zijn. En dat mocht, deze zit nu in de opstelling:

De verkoper vond 'm te lomp voor op de carnavalswagen (hoe kan dat nou?), dus nu heb ik twee keer zo veel power ter beschikking. En in brug doet het ding bijna 2 kW in 8 Ohm, dus enige voorzichtigheid is wel geboden .

De opstelling lag uitgesmeerd over het hele bureau, dus bij het uitwisselen van de versterker heb ik de hele zooi naar de westkant verbannen om zo weer wat oppervlak terug te veroveren. Wat een ruimte heb ik ineens! Omdat alles veel dichter bij elkaar staat heb ik ook weer een aantal BNC en banaansnoeren over, en de speaker zit nu "proper" vierdraads aangesloten. Scheelt toch 0,18 Ohm in het meetresultaat.

Soms is een beetje opruimen en herordenen best prettig, zo kan ik weer verder

[Walt]

Prachtig, vooral die lompe drieklauw die dat woofertje vast heeft.

[timpert]

Daar had ik 'm ook op uitgezocht, deze drieklauw heeft tweedelige bekken zodat ik de originele bekken kon vervangen door niet-magnetische bekken van aluminium. Zo wordt de magneet niet beïnvloed door de methode van inklemmen. Omdat ik de Dayton Ultimax UM15-22 als bovengrens had gesteld van wat de opstelling nog moet kunnen hebben, en de opstelling zelf minimaal 100 keer zo zwaar moet zijn als de Mms van het DuT, kom je uit op een gewicht van minimaal 30 kg. Een 250 mm drieklauw alleen al weegt zo'n 25 kg, dus een basis van 30 mm V313 MDF bracht me voorbij het streefgewicht.

[timpert]

En ik heb nog even een meting gedan met een liedje. Dit keer geen Rickroll maar "Cherry Blossom Girl" van Air. Ik heb het nummer gekozen omdat het meteen met een bas-sweep begint en de bas daarna in het hele nummer op gelijke sterkte blijft. Het ziet er dan zo uit:



De ventilator in de versterker is aardig hoorbaar op de achtergrond, maar omdat er niet akoestisch gemeten wordt is dat geen probleem.

Als ik nu exact dezelfde analyse loslaat als ik hier heb gedaan (ik heb alleen de filenaam van de signalen vervangen), dan krijg ik dit Bl(x) plaatje:

En dat ligt zowaar al een stukje dichter bij de "officiële" Klippel meting die ik van dit woofertje heb. Ik durf wel te stellen dat het resultaat erg afhankelijk is van de frequentie-inhoud van het meetsignaal, wellicht omdat de kortsluitringen in de magneet effectiever zijn bij het wat bas-armere nummer van Rick Astley dan bij het bas-rijke nummer van Air. Ter vergelijk: hieronder de meting met Rick welke een volle millimeter extra x-max lijkt te suggereren.

Nog even beide metingen in een grafiek gestopt, waarbij de oranje lijn de meting met Air is en de blauwe met Rick Astley. Je ziet duidelijk dat de meting met Rick een vlakker Bl(x) profiel oplevert.

[timpert]

Na een tijdje er niet aan te hebben gewerkt heb ik nu weer een flinke stap kunnen zetten. Er is, na vijf maanden onderweg te zijn geweest, een nieuwe tweedehands DAQ aangekomen Net als degene die ik tot nu toe gebruikte een Data Translation, maar nu eentje met acht ingangen en twee uitgangen die onbeperkt kunnen streamen. Dat opent weer een boel mogelijkheden.

Afgelopen weekend heb ik de Python library ervoor geschreven, en ik ben best tevreden met hoe het heeft uitgepakt. Het streamen gebeurt nu met Python queues, als je iets naar buiten wil streamen dan zet de applicatie simpelweg de numpy arrays op de queue en die worden dan met de ingestelde samplerate afgespeeld in chronologische volgorde. Wanneer het tijd is om een nieuwe array op de queue te zetten krijgt de applicatie ruim van tevoren een seintje. Zo kan je voortdurend het signaal aanpassen zonder de generator uit te schakelen, een nieuwe file te laden en de generator weer in te schakelen. Het streamen van de ingangen gaat hetzelfde: de input queue wordt gevuld met arrays waarin de gemeten waarden zitten, en de applicatie krijgt een seintje wanneer een nieuwe array is geplaatst. Op die manier kan je de tijd nemen voor het vullen en legen van de queues, terwijl op de achtergrond de DAQ vrolijk doormarcheert zolang de queues maar data blijven slikken of opboeren. Ik moet nog her en der wat puntjes op de i zetten, maar de functionaliteit zoals ik die wil zit er helemaal in.

Ook handig: een digitale output achterop. Die kan je gebruiken om de opstelling te bedienen via relais, zodat ik voorafgaand aan een test één keer de luidspreker hoef aan te sluiten, en daarna nergens meer aan hoef te komen. JLCPCB is nu een printje aan het smurfen waarmee ik het ding kan synchoniseren met de laser sensor, zodat alle klokken binnenkort weer netjes in de pas lopen. Omdat er acht blindstopjes in het apparaat zitten kan ik de BNC voor de referentieklok zonder modificaties aan de behuizing toevoegen. Het aantal doosjes en apparaten in de opstelling gaat zo omlaag terwijl de functionaliteit beter wordt. Niemand wil dat niet

Dus: binnenkort meer in dit theater!

[Shadow]

Lekker hoor!

[timpert]

Ik heb de Python library voor de DAq nog wat verder gepolijst, en dat heeft zijn vruchten afgeworpen. Het gebruik is nu simpel geworden: de acquisitie snort in de achtergrond, en data wordt op een queue gezet (ingang) of van een queue af geplukt, de gebruiker hoeft alleen maar de queue te legen of te vullen. Ook het omrekenen van sensorspanning naar fysieke grootheid (spanning, stroom, verplaatsing, versnelling etc) wordt door de library gedaan en netjes in numpy-array formaat opgeboerd. Dat maakt het leven heel veel makkelijker als je met het meetprogramma bezig bent: geen gedoe meer met polling, tijdskritische callbacks, conversie tussen bufferformaten en omrekenen van spanning naar sensorwaarde . Vergeleken met de eerste library die ik had gemaakt voor mijn DT9837 zijn dingen eenvoudiger, logischer en sneller geworden. Een flinke verbetering dus. Zo flink dat Claude 'm ook snapt, en na een middag viben kwam dit eruit:



Hier zie je een signaal generator die 150 hz genereert plus een 1 hz piloottoon. Die 150 Hz is gekozen om de driver lekker op te warmen (lage impedantie en kleine uitslag) en met de 1 Hz piloottoon wordt een schatting gemaakt van de DC weerstand van de spreekspoel. Je ziet duidelijk hoe die, bij het opdraaien van het volume, oploopt van zo'n 6 Ohm naar 9 Ohm (temperatuurverhoging van zo'n 127 graden!) en dat er dus aardig wat powercompressie optreedt. Ik had het hele proces al eens uitgeprobeerd (zie hier: viewtopic.php?p=2114988#p2114988) maar zo mooi "live" was het nog niet te volgen. Omdat het signaal en het volume van de generator ook on the fly zijn aan te passen, kan ik op deze manier continu in de gaten houden of de drie belangrijkste limieten van de driver (ingangsvermogen, uitslag en temperatuur van de spreekspoel) binnen veilige grenzen blijven en de amplitude zo nodig aanpassen.

[Kappa7]

Mooi om te zien dat je zulke stappen gemaakt hebt.
Zit aardig wat programmeer werk aan zo te zien.

[timpert]

Met deze laatste slag heb ik veel aan https://claude.ai gehad, vooral rond zaken zoals gebruik van de diverse Python pakketten (matplotlib, numpy, pythonnet etc) kan het je heel veel uitzoekwerk uit handen nemen. Het hele animatieverhaal van de grafieken dat je ziet is 1:1 copy-paste na een welgemikte prompt.

Daar staat tegenover dat je scherp moet blijven dat de geproduceerde code wel blijft kloppen. Zo wil Claude hardnekkig het RMS vermogen berekenen als:

CODE: Selecteer alles

rms_power = np.sqrt(np.mean(np.array(power_buffer) ** 2))

En dat is uiteraard niet correct: het vermogen moet je "gewoon" middelen over tijd, alleen van de spanning of van de stroom bepaal je de RMS waarde. Maar omdat iedereen babbelt over "RMS vermogen" neemt AI die slordigheid in het taalgebruik voor waar aan. En zo zijn er nog wat dingen, het is beslist geen vervanger voor weten wat je wil en doet. Maar het voelt wel alsof ik vanaf een zandpad zo de snelweg op gereden ben.

[timpert]

Ik heb net even gekeken in hoeverre mate de Rdc meting die de opstelling nu doet overeenkomt met de vierdraadsmeting van mijn tafelmultimeter, en ze zijn het binnen 0,2% met elkaar eens. Eerst mat ik de Rdc door een gecontroleerde stroom van 100 mA door de spreekspoel te sturen en die om te polen, maar de meting bij 1 Hz waarbij ik corrigeer voor de inductiespanning door het bewegen van de spreekspoel werkt klaarblijkelijk net zo goed. En dat is goed nieuws, want zo kan er weer een apparaat uit de opstelling gehaald worden zonder verlies van functionaliteit of nauwkeurigheid. Ik heb het ook nog even gecontroleerd aan de hand van een weerstand, en dat liet hetzelfde resultaat zien.

Trillingen van buitenaf en temperatuurfluctuaties introduceren een veel grotere fout, en ook als je de driver hebt vastgehouden zie je de weerstand variëren. De temperatuurcoëfficiënt van koper is 0,393% per graad, dus de nauwkeurigheid is veel beter dan je in de praktijk ooit nodig zal hebben. Fijne bevinding zo op de maandagavond.

[timpert]

Ik was al langer aan het nadenken over een goede werkwijze van meten en opslaan van meetdata. Het probleem is namelijk dat elke meting een los scriptje is, en de parameters van de meting en processing deels via "input" statements werden gevraagd, en deels hardcoded in het script zaten. De meetresultaten werden vervolgens in een array gestopt en via pickle weggeschreven naar disk zodat ik ze later met een ander scriptje kon analyseren. Dat is leuk als je aan het experimenteren bent, maar het wordt al snel een ratjetoe en het is waardeloos als je een meting doet, en die wil bewaren inclusief metadata (instellingen van de opstelling, identificatie van DUT en dat soort werk). Dat schreeuwt om een database waar ik alles in kan stoppen. Mijn eisen daaraan zijn:

• Per geteste driver één file waar alles in staat: ruwe meetdata, alle relevante metadata, datasheet eigenschappen van de driver, analyse resultaten enzovoorts.
• Datasheet object, waar je alles wat je vooraf van de driver weet kan invullen, zodat je dat niet steeds opnieuw hoeft te doen.

Nu had ik al eerder in een andere toepassing met SQLite gespeeld, dus daar begon ik mee, ook omdat het een standaard library in Python is. Je hoeft dus niks te installeren om er meteen mee aan de slag te kunnen. Probleem is echter: SQLite kan veel, maar heeft moeite met grote datareeksen zoals een tweedimensionale Numpy array met miljoenen elementen. Dat liep dus al snel spaak. Gelukkig fluisterde iemand die hier eindeloos veel meer verstand van heeft me het woord "DuckDB" in. Proudly made in Holland, lichtgewicht en supersnel, en het kan in de vorm van een Parquet file arbitrair grote arrays opslaan. Top, dat wordt 'm!

Toch was ik benieuwd naar het file format van een Klippel database. Openen met Notepad++ levert op:

SQLite3! Goh, wie had dat nou gedacht. Maar dat verklaart ook meteen waarom er geen ruwe data door Klippel in de database geplaatst wordt: het is technisch gewoon niet mogelijk zodra de datareeksen een beetje groter worden. En dat is jammer als je ook aan postprocessing wil doen.

Volgende stap: nette applicatie timmeren. De opzet is: een eenvoudig main window met daarin de knoppen om een database te laden (of een nieuwe aan te maken), de opstelling te initialiseren en configureren, en voor elke meting een knopje. De details vul je dan in bij de subvensters die openen. Tot zo ver heb ik een applicatie kunnen maken die een database opent of aanmaakt, daarin een datasheet object plaats, de opstelling configureert en een kleinsignaal meting uitvoert. Het hoofdvenster ziet er zo uit:

Duidelijk op de groei gedimensioneerd. In het venster voor de kleinsignaal meting is alle kennis die tot nu toe in losse scripts zat ondergebracht. Dat ziet er, na het doen van een meting, zo uit:

Nog te doen: modelfit om de T/S parameters uit de meting te destilleren, maar ik ben erg tevreden met hoe het tot nu toe vordert. Het geheim van de smid? Claude Code. Ik heb voor de gelegenheid een maandje Claude Pro genomen, en dat is waanzinnig. Al het geneuzel om een nette QT5 applicatie en het afhandelen van de database kan ik aan de agent uitbesteden, zodat ik me kan concentreren op de signaalverwerking en modellering (die ik al grotendeels klaar heb). Het gaat ineens keihard op deze manier! Wel een oppassertje: van signaalverwerking heeft Claude geen kaas gegeten, alleen weet 'ie dat zelf niet. Dus op het gebied van QT5 programmeren heeft hij aan een half woord genoeg om puik werk te leveren, maar bij de data- en signaalverwerking moet je 'm heel strak houden. Wordt vervolgd...

[satefan]

Offtopic: Wij hebben (op de zaak) in ons low-code platform een plugin gemaakt voor Claude Sonet (Gemini was al beschikbaar) . De developer heeft een permanente assistent in het platform die en de applicatie opzet, de code maakt en tegelijk ook de complete documentatie van de applicatie bijhoud. De resultaten zijn krankzinnig. De kosten lopen overigens ook aardig op.

[timpert]

Ik gebruik nu Claude Pro, dat is voor hobbygebruik prima te doen en al heel nuttig met Claude Code. Maar inderdaad, wanneer je met APIs aan de slag gaat en per zoveel tokens gaat betalen, dan kan het hard gaan. En dan heb je nog niet eens naar Opus durven wijzen.

Als je kijkt wat ik in een weekend en een paar avonden als amateur al voor elkaar heb gekregen met Claude Code (een agent die rondwaart in je projectdirectory en alle source files kan lezen waar je 'm toegang toe verschaft), dan vind ik die 21,78 euro die ik er nu aan heb uitgegeven eigenlijk peanuts voor wat het me heeft gebracht.

[satefan]

De productiviteitswinst staat buiten kijf.

[timpert]

Absoluut! Ik heb nu net alle drie de kleinsignaalfits kunnen maken: het "standaard" model (Re, Le, BL, Mms, Cms, Rms), het "advanced" model (standaard plus L2//R2) en het model met kruip in de ophanging zoals hier wordt gegeven in het Standard Linear Solid model. De ophanging wordt hier gegeven door een veer die beneden een bepaalde grensfrequentie slapper wordt:

Het resultaat mag er zijn. Het feit dat je geen stippellijn ziet van de modelfit t.o.v. de metingen rond de resonantie betekent dat de fit en de meting vrijwel perfect samenvallen:

En dat terwijl ik eigenlijk iets heel anders zou moeten doen...

[timpert]

Na de rioolperikelen verder met het volgende hoofdstuk, iets wat ik tot dusverre nog niet gedaan heb: preconditioneren, oftewel inspelen. De diverse standaarden vragen allemaal een preconditioneerfase. Meestal is dat een uur herrie maken gevolgd door minstens een uur afkoelen. Fabrikanten hebben er ook zo hun eigen ideeën over, dus ik heb geprobeerd het preconditioneren zo flexibel mogelijk te maken, met dit als resultaat:

Er zijn vier modi:

1 - Fixed frequency. Hierbij wordt een vaste frequentie aangeboden en wordt de amplitude opgedraaid tot één van de limieten bereikt (uitwijking, vermogen of temperatuur) wordt. Je kan bijvoorbeeld de uitslag op een percentage van x_max zetten (ook > 100% als je de boel flink wil oprekken) en daar wordt de geleverde amplitude continu op afgestemd. Wannere je bij lage frequentie inspeelt dan komen vermogens- en temperatuurlimiet niet in de buurt, maar je kan ook op f>>fs gaan zitten om zo met opzet de boel lekker warm te stoken.

2- Resonance search. Eigenlijk als hierboven, maar dan wordt ook de frequentie getuned zodat de driver continu in resonantie blijft. Zo kan je de mechanische belasting regelen terwijl de temperatuur zo laag mogelijk blijft. Je kan de frequentie uiteraard niet instellen, het startpunt wordt gehaald uit de ingestelde datasheet waarde of uit de kleinsignaal meting.

3- AES noise. Dit is gefilterde (hoog- en laagdoorlaat, beide 2e orde Butterworth) en geclipte roze ruis zodat de crestfactor van het signaal op 2 uitkomt. De amplitude wordt opgedraaid tot één van de limieten bereikt wordt. In de praktijk klinkt het alsof ik een straalmotor aan het proefdraaien ben in de kelder, dus dat doe ik alleen als er niemand anders in huis is.

4- Sound file. Sommige fabrikanten staan erop dat je niet met ruis of een gegenereerd signaal inspeelt, dus daarom heb ik de mogelijkheid ingebouwd om een mp3/flac/wav op repeat te gebruiken. Het signaal wordt verder hetzelfde behandeld als ruis, en de limieten worden continu bewaakt.

Dit gaf nog wat uitdagingen. Het bewaken van de limieten zonder GUI ging prima, maar met GUI ging het steeds mis door queue starvation en meer van dergelijke ellende. Ook merkte ik (wederom) dat Claude van QT5 zeer veel kaas heeft gegeten, maar van data acquisitie en signaalverwerking toch wat minder. Dus als ik een functionaliteit van de gebruikersinterface specificeer in een prompt, dan is het resultaat altijd precies zoals ik het hebben wil. Maar het gaat mis als ik Claude dezelfde vrijheid geef in het signaalverwerkingsgedeelte, daar is het steeds een geval van kleine stapjes maken, controleren en testen. Maar gelukkig heb ik op dat laatste gebied al veel voorwerk gedaan, dus uiteindelijk gaat ook dat best rap!

Wat je hier ziet is 5 minuten preconditioneren met AES ruis gevolgd door 5 minuten afkoeltijd van het Kartesian SUB120_VHP woofertje. De asymmetrie van de uitslag is goed te zien en ook is te zien hoe de spreekspoel best wel flink opwarmt, en vervolgens net niet terug afkoelt tot de starttemperatuur, omdat de magneet langzaam ook mee opwarmt. Overigens is het bewonderenswaardig wat dit woofertje al aan mishandeling heeft overleefd, zoals de volle toorn (550 W) van de eindversterker bij 20 Hz, en dat het nog steeds goed blijft functioneren.

Nog twee hoofdstukken: grootsignaal karakterisatie en thermische karakterisatie. Het lijkt zowaar een keer richting "klaar" te gaan!