Deftige meetopstelling voor luisprekerparameters

[timpert]

@hidjedewitje: als je wat meer wil lezen over de modelaanpak, dan staat het een en ander in deze post en de daaropvolgende. Voor het bepalen van Sd gebruik ik vooralsnog gewoon een plastic liniaal (niet magnetisch, erg belangrijk als je geen gat in de conus wil) en kwartpiedeekwadraat.

Verder: ik heb tijdreeksen voor u, i en x en ik zie vooralsnog niet hoe ik daaraan het luidsprekermodel kan fitten zonder i een keer en x twee keer te differentiëren: voor de tweede wet van Newton heb je immers de versnelling nodig. Met een Gaussische smoothing gecombineerd met differentiëren met een Savitzky-Golay filter gaat differentiëren in aanwezigheid van ruis best aardig. Ik heb momenteel twee routes van modelleren verkend, een is het voorspellen van de spanning en de stroom en die vergelijken met de daadwerkelijke waarden, en de andere komt uit de realisatie dat de elektrische arbeid die op de tegen-EMF van de spreekspoel wordt uitgeoefend gelijk moet zijn aan de mechanische arbeid die de spreekspoel levert. Verder pas ik wat regularization toe om te voorkomen dat de modelcomponenten exploderen. Of ik ze nu optimaal heb opgesteld voor Pytorch om mee te werken weet ik nog niet, vandaar dat ik het nog even als "highly experimental and subject to change at any whim" bestempel.

[timpert]

Do you need an additional reference object?
From my experiments with the DATS-LA, I have one Visaton AL-130 measured with Klippel by Andreas Dausend.
Regards Heinrich

That is a very nice offer! In this stage I will limit testing to drivers that are my own because, as you might have read, last week I gave one of them a near-dead-experience. I am currently working on a way to observe power, excursion and temperature limits while the test is running. Once that is working robustly, I can be a bit more confident in using other people's drivers again, especially considering that the AL series from Visaton appear somewhat delicate to me. But I would love to test it when I have my driver protection working.
Cheers, Jurgen

[Pjotr]

Eigenlijk zou je voor beveiliging een puur mechanisch device moeten hebben wat onafhankelijk de X-max in de gaten houdt. Kun je daarvoor niet je huidige laser afstandsmeter gebruiken? In het verleden heb ik daarvoor zelf lineaire PSD's (Position sensitive detectors) gebruikt van Hamamatsu. Zijn op zich hele simpele optische dingen die heel snel zijn en een analoge spanning afgeven. Zelf wel eens overwogen voor MFB maar daarvoor heb je versnelling als grootheid nodig en geen afstand. Dat gaat niet werken.

[timpert]

De displacement sensor is na de test digitaal uit te lezen, maar de analoge uitgang zit aan de DAQ dus die is ook tijdens de test beschikbaar. Beveiligen zonder extra hardware kan gewoon met de spullen zoals ze nu zijn. Het probleem zit 'm in de Python driver die ik voor de DAQ had gemaakt, tussentijds uitlezen van de data kon tot voor kort niet. Pas na afloop van de ingestelde meettijd kwam de data beschikbaar. Ik heb afgelopen weekend de driver aangepast zodat elke keer dat er een buffertje gevuld is met data een functie wordt aangeroepen. Die kan ik gebruiken om de inhoud van dat buffertje te analyseren en te gebruiken om de maximale uitslag en het gemiddelde vermogen te bepalen en weer te geven alvorens het weer op de queue van de DAQ te plaatsen voor de continumeting.

Probleem was nog het bepalen van de temperatuur van de spreekspoel. Ik heb een extra toon toegevoegd aan het testsignaal van 1 Hz (dat bleek nog prima door mijn versterker te komen) en aan de hand daarvan Re bepaald. Gisteravond kon ik de test niet meer doen omdat er al mensen in huis sliepen, maar zonet wel & het werkte zowaar! Bij interesse post ik de wiskunde wel, nu direct door naar het resultaat.

Ik heb een ander multitone signaal gebruikt dat zo'n 18 Watt in de spreekspoel verstookt zonder xmax te overschrijden. Dit signaal heeft de meeste energie tussen 125 Hz en 500 Hz zitten, want je moet natuurlijk wel wat zien gebeuren met de temperatuur. Om de temperatuur nog wat verder omhoog te krijgen heb ik een föhn op de magneet gericht en een kwartiertje laten blazen arm ding. De test zag er toen zo uit (PAS OP MET JE VOLUME, want het is echt een hele nare taffesherrie):



Duidelijk zie je dat de 1 Hz testtoon nog wel wat minder had gekund in amplitude, dat is een makkelijk door te voeren verfijning dus dat staat nog op mijn to-do lijstje. Omdat elk buffertje 2 seconden signaal bevat, worden de uitslag, vermogen en temperatuur elke 2 seconden ververst. De temperatuur wordt berekend aan de hand van de temperatuurcoëfficiënt van koper (0,00393 per graad) en de geschatte Re. Op het scherm ziet de output er nu zo uit:



De gemeten temperatuur fluctueert wat in een band van 5 graden, maar voor beveiliging tegen oververhitten is dit goed genoeg. Maar dat roept wel de vraag op: klopt er nou iets van? Met de thermische camera heb ik een filmpje gemaakt waarop de 1 hz beweging en de spreekspoel duidelijk te zien zijn:



Hier is goed te zien hoe de spreekspoel een stuk warmer is dan de omgeving. Met ThermoTools (het überChinese programma dat bij mijn thermische camera hoort) kan ik het heetste punt in videostills bepalen wanneer de spreekspoel het verst naar buiten steekt.

Daar doe ik het voor. Het doel hiervan is niet om op drie cijfers achter de komma de temperatuur te bepalen (dat is sowieso onzin, want de spoel is waarschijnlijk niet eens homogeen van temperatuur), maar om te bepalen of er veilige limieten worden overschreden en het signaal terug te draaien of uit te schakelen voordat er dingen kapot gaan. Nu dat werkt kan ik dit een vast plekje geven in het programma, en daarmee de boel weer een stukje veiliger maken voor het DUT.

[Pjotr]

Ah, zie je wel! Dacht al, kan toch niet zo moeilijk zijn met de spullen die al hebt. Hooguit monnikenwerk Top!

[hidjedewitje]

@hidjedewitje: als je wat meer wil lezen over de modelaanpak, dan staat het een en ander in deze post en de daaropvolgende. Voor het bepalen van Sd gebruik ik vooralsnog gewoon een plastic liniaal (niet magnetisch, erg belangrijk als je geen gat in de conus wil) en kwartpiedeekwadraat.

Ik zie dat dat wel een andere aanpak is dan ik doe. Het staat ook niet in de standaard state-space form: dxdt = Ax+Bu, y = Cx+Du. Of in een nonlinear geval dxdt = f(x,u), y = g(x,u). Je hebt immers 3 vergelijkingen voor state-space en jij gebruikt er maar 2 (voor zover ik kan zien).

Zelf vind ik de methode van Antoine Falaize (wiens naam ik al eerder voorbij zag komen in deze thread) erg elegant: https://doi.org/10.1051/aacus/2019001
Dan behoud je ook het energetisch inzicht en krijg je sommige effecten, zoals de reluctance force, er gratis en voor niks bij. Temperatuur in zo'n model krijgen is overigens wel echt een draak (maar is me wel gelukt ).

Als je het in een state-space vorm kan zetten, dan wordt de "forward(...)" functie in je PyTorch model je state-space vergelijkingen. Zo'n simulatie kan je gebruiken in je simulatie door je predictie error te minimaliseren: MSE(y_measured, y_predicted(theta)), waar theta is de lijst met optimialisatie parameters. die MSE functie zit standaard in PyTorch overigens.

Dan kan je later eens simulatie draaien op basis van een nieuwe input dataset om te kijken of je je model echt gefit hebt en niet de meetruis.

Op deze manier heb je enkel inputdata (je spanning signaal) en outputdata (stroom en displacement) nodig en een initiele conditie (voor gemak is dat even 0). Je hebt geen acceleratie meting nodig omdat die inherent gekoppeld zit aan je displacement.

[timpert]

Daar moet ik even voor gaan zitten

Antoine Falaize is nieuw voor me, ik denk dat je de naam verwart met Antonin Novak, die naam is hier vaker gevallen. Een paar van zijn experimenten heb ik hier ook gedaan, zie bijvoorbeeld hier en hier. Maar ik ga Falaize's artikel zeker tot me nemen, waarbij ik wel moet toegeven dat ik daarvoor wat oude kennis moet afstoffen. Maar goed, dat heb ik in het kader van dit project wel vaker moeten doen

[timpert]

@hidjedewitje: ik ben langzaam maar zeker door het artikel van Falaize aan het raken, en ik moet zeggen dat ik erg gecharmeerd ben van deze aanpak. Ik ben nog niet helemaal klaar met de theorie, maar als ik er nog een paar avonden aan zit denk ik wel dat het goed komt. Ook leuk dat Falaize zijn Python PHS verrichtingen op Github heeft gezet: https://github.com/pyphs/pyphs

Uiteindelijk is dit toch de heilige graal waar ik op wil uitkomen:

Ik weet niet of ik dat in (quasi) real time kan doen op de PC die ik gebruik bij mijn meetopstelling, maar zelfs als ik achteraf met een arbitrair signaal parameters kan bepalen door op deze manier de fout te minimaliseren dan ben ik al heel blij.

Ik zal binnenkort ook eens uitschrijven wat ik nu doe in Pytorch. Dat is nog heel ruw (ook omdat ik nog maar sinds kort met Pytorch werk en er dus nog niet zo bedreven in ben, de aanpak is dus gegarandeerd suboptimaal), maar het geeft resultaten die niet meteen onzinnig aandoen en dat is bemoedigend.

[hidjedewitje]

Ja hij gebruikt een erg academische aanpak die erg goed werkt. Ik vind de notatie die ze gebruiken voor PHS systemen alleen verschrikkelijk. Ik heb liever dxdt = [J(x)-R(x)\gradH(x) + B(x)u, waar R(x)gradH identiek is aan hun dissipation law. Maar goed ieder zijn ding. Het framework is overigens een nederlandse uitvinding!

Wat klippel doet is voor zover ik weet op basis van 1-step ahead prediction methoden. Hetzelfde als dat ik voorstelde. Dat kan prima in een pytorch implementatie (sterker nog, het is er zelfs erg geschikt voor).
Real time wordt wel een uitdaging. Zoals je zelf waarschijnlijk al ondervonden hebt duurt het trainen van zo'n model wel eventjes.

Ik ben benieuw naar je resultaten & implementatie uit PyTorch!

[Pjotr]

Real time wordt wel een uitdaging. Zoals je zelf waarschijnlijk al ondervonden hebt duurt het trainen van zo'n model wel eventjes.

De hele exercitie zoals aangegeven in het blokschemaatje van Jurgen is toch ook niet meer dan een search naar de numerieke waarden van het model? Dat is een forse rekenpartij. Waarom zou je dat real time willen?

[timpert]

Waarom zou je dat real time willen?

Daar is inderdaad geen goede reden voor te geven, anders dan dat het er wel leuk uitziet. Analyse achteraf is een stuk efficiënter, en het geeft je ook geen hoofdpijn over concurrency van processen. Met name het tussentijds uitlezen van de DAQ is daar gevoelig voor: je moet een buffer uitlezen en die op tijd "teruggeven" aan de DAQ driver zodat die opnieuw gevuld kan worden. Als je daar te lang mee wacht dan stopt de driver met een exception. Dus in de functie die wordt aangeroepen als de buffer beschikbaar is moet je 'm snel kopiëren en weer teruggeven, om vervolgens in een ander, niet-tijdkritisch proces de analyse uit te voeren. Als je dan een beetje achter raakt met de analyse is dat niet zo'n probleem, want de acquisitie marcheert ongestoord door. En dat heb ik ook al werkend gekregen, maar het voegt wel weer een laag complicatie toe. Vandaar dat ik het liever simpel houd.

Wat ik wel (quasi) real time wil is het bewaken van veilige limieten. Als een test langer duurt (om een beeld te krijgen van de praktische belastbaarheid moet je toch naar 15 tot 30 minuten) dan wil je van de opstelling weg kunnen lopen en erop kunnen vertrouwen dat de driver heel blijft. Ook is het handig om naast de reeksen voor u, i en x een reeks voor T te hebben.

Ik vind de notatie die ze gebruiken voor PHS systemen alleen verschrikkelijk

+1. Ik heb daardoor echt meer moeite om door het artikel te komen. Maar goed, even doorkauwen maar. Ik heb als voorbereiding uiteraard ook het werk van Arjan van der Schaft tot me genomen. Leuk om in dit wereldje wat meer Nederlandse namen tegen te komen.

[Pjotr]

Voor de beveiliging heb je begrijp ik de real time analoge meetwaarden tot je beschikking. Is het dan niet slimmer om dat met een aparte processor/miniPC te gaan doen als fail-safe bewaker? Ontlast je je analyse van een hoop real time gedoe en de beveiliging kan veel sneller reageren. Je zou dat zelfs met simpele hardware kunnen doen die grenswaarden bewaakt.

[timpert]

Dat zou kunnen, maar ik vind de huidige opstelling al complex genoeg. En we werken met macroscopische fenomenen, bijvoorbeeld de thermische tijdsconstante is > 1 seconde, dus heel snel hoeft het niet te zijn. Ook is de manier waarop je het signaal opbouwt van belang: als je begint met een zwak signaal en dat rustig opdraait totdat je ziet dat een van de limieten in zicht komt dan blijf je uit de gevarenzone.

Daarna is het een kwestie van constant monitoren: in de eerste 10 seconden warmt de spreekspoel snel op, maar daarna volgt de temperatuur die van de magneet met een min of meer vast temperatuurverschil en loopt de temperatuur verder langzaam op. Ik overweeg nog om een temperatuursensor op de magneet te plaatsen, als ik de accelerometer niet gebruik heb ik een kanaal over op de DAQ. Dat zou wel weer een leuk uitstapje zijn, een IEPE powered temperatuursensor. Hmmm...

[Pjotr]

Ja linksom of rechtom. Wel een erg mooi project. Ook nog een soort van pad zoeken door de tijd. Dit is geen hobbyen meer maar niveau een dissertatie Vind je methode van de temperatuur bewaking middels R_dc van de spreekspoel wel erg elegant Moet je alleen nog aangeven of het Cu is of CCA. Die is wel essentieel i.v.m. met de temperatuurbestendigheid van de lijm e.d.

[hidjedewitje]

Dat zou kunnen, maar ik vind de huidige opstelling al complex genoeg. En we werken met macroscopische fenomenen, bijvoorbeeld de thermische tijdsconstante is > 1 seconde, dus heel snel hoeft het niet te zijn.

Welke parameters hoop je te kunnen meten? Om temperatuur in te schatten zal je dat ook in je model moeten proppen en dat is niet zo eenvoudig. Klippel zijn methode heeft ook flink wat afwijking bij hoge temperatuur verschillen. Bij temperatuur metingen zal je inderdaad redelijk lang moeten meten. Met name door de magneet op te laten warmen duurt lang. De spreek spoel kan al in enkele seconden bij grote ingangsignalen.

Als je geen temperatuur effecten mee neemt dan heb je aan enkele seconden ZEKER voldoende omdat alle tijdconstanten kleiner zijn dan 10 tallen ms.

a linksom of rechtom. Wel een erg mooi project. Ook nog een soort van pad zoeken door de tijd. Dit is geen hobbyen meer maar niveau een dissertatie

Eens! Het nonlineair modelleren en identificieren van luidsprekers is toevallig het onderwerp van mijn MSc thesis haha.

[timpert]

Ik zou nog even laten weten hoe mijn huidige Pytorch model in elkaar zit. Komt 'ie:

Beginnen met de lineaire situatie, voor klein signaal. Het uitgangspunt is het volgende stel vergelijkingen:

[LaTeX]
\begin{cases}
BL\cdot i(t)=K_m x+R_m\dot{x}+M_m\ddot{x} \\
u(t)=R_e i+L_e\frac{di(t)}{dt}+BL\dot{x}
\end{cases}
[/LaTeX]

Bovenaan staat de mechanische krachtenbalans, onderaan staat Kirchhoff en [LaTeX]\dot{x}=\frac{dx}{dt}[/LaTeX], [LaTeX]\ddot{x}=\frac{d^2 x}{dt^2}[/LaTeX]. Als je de bovenste deelt door [LaTeX]BL[/LaTeX] dan krijg je een uitdrukking voor de stroom en voor de spanning, en die heb ik beschikbaar als metingen. Ik moet nog de eerste afgeleide van de stroom en de eerste en tweede afgeleiden van de uitslag bepalen en dan kan ik in principe gaan fitten. Om dat soepel te laten lopen met Gradient Descent moet ik eerst de signalen normaliseren:

[LaTeX]
\begin{align}
&\tilde{x}=\frac{x}{max \vert x \vert} \\
&\tilde{\dot{x}} =\frac{\dot{x}}{max\vert \dot{x} \vert}\\
&\tilde{\ddot{x}} =\frac{\ddot{x}}{max\vert \ddot{x} \vert}\\
&\end{align}
[/LaTeX]

Spanning en stroom [LaTeX]i[/LaTeX] krijgen uiteraard dezelfde behandeling. Op deze manier worden alle signalen genormaliseerd binnen een interval van [LaTeX][-1, 1][/LaTeX].

Onderstaand had ik in eerste instantie verkeerd gedaan. Hierbij de gecorrigeerde voorspelling voor de genormaliseerde spanning en stroom [LaTeX]\tilde{u}[/LaTeX] en [LaTeX]\tilde{i}[/LaTeX], de forward functie:

[LaTeX]
\begin{cases}
\tilde{i_p} = \frac{s_\dot{x}}{Fs_u} (A\cdot\tilde{x} + B\cdot\tilde{\dot{x}} + B\cdot\tilde{\ddot{x}}) \\
\tilde{u_p} = D\cdot\tilde{i} + E\cdot\tilde{\dot{i}} + F\cdot \tilde{\dot{x}}
\end{cases}
[/LaTeX]

Hierin zijn [LaTeX]A[/LaTeX] t&m [LaTeX]F[/LaTeX] de te bepalen modelparameters die representatief zijn voor respectievelijk [LaTeX]K_m[/LaTeX], [LaTeX]R_m[/LaTeX], [LaTeX]M_m[/LaTeX], [LaTeX]R_e[/LaTeX], [LaTeX]L_e[/LaTeX] en [LaTeX]Bl[/LaTeX]. Factoren [LaTeX]s_u[/LaTeX] en [LaTeX]s_\dot{x}[/LaTeX] zijn de normalisatiefactoren voor spanning en snelheid zodat [LaTeX]u=\tilde{u}s_u[/LaTeX] enzovoorts. De loss is nu:

[LaTeX]
Loss = MSE(\tilde{i_p}, \tilde{i}) + MSE(\tilde{u_p},\tilde{u})
[/LaTeX]

Daarna Pytorch z'n dingetje laten doen levert resultaat. Het is vrij makkelijk om in deze opzet variabelen zoals [LaTeX]BL[/LaTeX], [LaTeX]K_m[/LaTeX], [LaTeX]R_m[/LaTeX] en [LaTeX]L_e[/LaTeX] afhankelijk te maken van [LaTeX]x[/LaTeX], maar dat ga ik nu niet uitschrijven want deze post is al lang genoeg. Als de parameters [LaTeX]A[/LaTeX] t&m [LaTeX]F[/LaTeX] gevonden zijn is het eenvoudig om daar vervolgens de fysische parameters uit terug te rekenen:

[LaTeX]
\begin{align}
&K_m = A\frac{s_i}{s_x} \\
&R_m = B\frac{s_i}{s_\dot{x}}\\
&M_m = C\frac{s_i}{s_\ddot{x}}\\
&R_e = D\frac{s_u}{s_i}\\
&L_e = E\frac{s_u}{s_\dot{i}}\\
&Bl = F\frac{s_u}{s_\dot{x}}\\
&\end{align}
[/LaTeX]

Ik heb slechts twee vergelijkingen en niet drie, want de Hamiltoniaanse aanpak ruilt een afgeleide-orde in voor een vergelijking. De tijdsafgeleiden van [LaTeX]x[/LaTeX] blijken erg ruisgevoelig te zijn, dus ik pas eerst een Gaussische smoothing toe en daarna bepaal ik met een Savitzky Golay filter de afgeleiden.

[timpert]

Nog even een run gedaan met dit herziene model, en ik moet zeggen, het eerste resultaat is niet onaardig.

Allereerst heb ik de kleinsignaal parameters bepaald met de IEC methode zoals hier beschreven (en een bonnetje uitgeprint uiteraard), vervolgens heb ik het zelfde multitone signaal gepakt en dat met een RMS spanning van 1V, 5V en 10V op de speaker gezet om het resultaat met Pytorch te kunnen analyseren. De bijna-dood meting zit hier niet bij, omdat die een heel vertekend beeld geeft. Dit is het resultaat voor de parameters bij x=0 van de vier verschillende metingen:

Duidelijk is te zien hoe de ophanging gemiddeld slapper wordt als de uitslag groter wordt. De niet-lineaire parameters zijn met een 10de orde polynoom gefit om de GPU iets te doen te geven. Gegeven de grote verschillen tussen de methoden (IEC gooit alle vervormingsproducten weg, de Torch fit neemt ze wel mee) vind ik de resultaten aardig dicht bij elkaar liggen. En ook: het zaakje convergeert uiteindelijk binnen een paar seconden. Omdat het signaalreeksen zijn van 10 seconden denk ik dat zelfs quasi realtime fitten gewoon tot de mogelijkheden behoort: met een of twee seconden signaalreeksen moet het nog sneller convergeren.

Wordt vervolgd.

[Pjotr]

Dat is een mooi resultaat Maar wat doet die ophanging slapper worden bij grote uitslagen? Beetje tegen de verwachting in. Of is dat bekend van het DUT? Is dat een momentaan, dus niet lineair effect? Of is dat een hysterese-achtig effect t.g.v. veelvuldig flexen? Hoe ga je dat uit elkaar houden?

[timpert]

Deze getallen gelden rond het nulpunt van de uitslag. Het is zeker niet de eerste keer dat ik dat gezien heb, zie bijvoorbeeld ook hier voor een meting aan de Reckhorn sub die Bart me ter beschikking had gesteld. Daar zie je ook dat naarmate de uitslag groter wordt de stijfheid in de rustpositie omlaag gaat alsof het materiaal van de ophanging tijdelijk wat losgetrokken wordt. De ophanging is als geheel nog steeds progressief.

Je gaat het inderdaad niet uit elkaar houden, want de "standaard" voorstelling van Bl(x), Km(x), Le(x) gaan er vanuit dat de curves onveranderlijk zijn, maar dat is duidelijk niet het geval.

[Pjotr]

Ik zie i.i.g. bij veel T/S metingen, zo niet de meeste, dat een kwartiertje los wapperen sowieso de Fs doet dalen, soms wel 10%. Om dan na een uurtje of dag weer aardig gestegen te zijn. Dat is dus een wat langdurig aanhoudend lostrek effect lijkt het. Maar ik kan mij wel goed voorstellen dat dat ook momentaan met een kleine tijdconstante op zou kunnen treden.

[hidjedewitje]

Ik heb slechts twee vergelijkingen en niet drie, want de Hamiltoniaanse aanpak ruilt een afgeleide-orde in voor een vergelijking. De tijdsafgeleiden van blijken erg ruisgevoelig te zijn, dus ik pas eerst een Gaussische smoothing toe en daarna bepaal ik met een Savitzky Golay filter de afgeleiden.

Je hoeft niet alle states te meten om alle vergelijkingen te kunnen identificeren. Er is namelijk een impliciete koppeling tussen velocity en acceleration.
State-space modellen bestaan ook uit TWEE vergelijkingen, de state equation en de output equation:
[LaTeX]\dot{x} = f(x,u), \; y = g(x,u)[/LaTeX]
Je hoeft niet alle states op de output te hebben. Sterker nog, dat maakt het in de praktijk vaak erg lastig, omdat je simpel weg niet alles kan meten (velocity meten is bijvoorbeeld erg irritant).
Als je dan MSE(Y-Y_predicted) neemt krijg je dezelfde loss function als die je nu gebruikt


De normalisatie die je doet is wel slim.

Deze getallen gelden rond het nulpunt van de uitslag. Het is zeker niet de eerste keer dat ik dat gezien heb, zie bijvoorbeeld ook hier voor een meting aan de Reckhorn sub die Bart me ter beschikking had gesteld. Daar zie je ook dat naarmate de uitslag groter wordt de stijfheid in de rustpositie omlaag gaat alsof het materiaal van de ophanging tijdelijk wat losgetrokken wordt. De ophanging is als geheel nog steeds progressief.

Ben je toevallig bewust van de achterliggende oorzaak van dit fenomeen? Ik heb het zelf ook vaker gezien, maar heb hier nooit een oorzaak voor gevonden.

Het zou een creep achtig fenomeen kunnen zijn. Dan zou je het, tot zekere hoogte, met extra Cms/R termen kunnen afvangen (vergelijkbaar met het LR_i model voor lossy inductance). Deze thesis is daar redelijk duidelijk in: https://download.spsc.tugraz.at/thesis/TIP_Brosch.pdf
en deze papers ook:
https://aes2.org/publications/elibrary-page/?id=15639
https://aes2.org/publications/elibrary-page/?id=14713
De achterliggende mechanismen daarvan worden beschreven met een PDE, dus je zal die phenomenen moeten schatten met een eindig hoeveelheid lumped elements. Als het daadwerkelijk een creep effect is dan zal het minder opvallen als je voor korte perioden meet.

Hysteresis kan ook, maar dat is echt veel lastiger om dat fysisch correct te beschrijven. Deze beschrijft hoe je dat in het eerder genoemde hamiltoniaanse framework kan proppen (en tevens temperatuur): https://doi.org/10.1016/j.ifacol.2018.06.005 (niet eenvoudig overigens).

Ik zou alleen uberhaupt niet weten of het een van deze twee fenomenen is...

Ik zou ook niet weten of voor nu wel de juiste richting is om op te gaan met het project. We weten namelijk nog niet of het model wat we nu hebben afgeschat ook daadwerkelijk overeenkomt met de data die we gemeten hebben. Wat er voor zo ver ik weet nu is een een deftige meetopstelling. Een manier om de parameters af te schatten en te plotten, maar nog geen tool om te checken of de geschatte parameters kloppen.

Wat je kan doen is een tweede signaal maken, daar een meting mee doen en met datzelfde ingangssignaal een simulatie doen en kijken in hoe verre ze overeenkomen! Welke criteria je dan gebruikt om te vergelijken laat ik dan nog even in het midden. Klippel zelf geeft verscheidene methoden aan. Ik zelf gebruik de Peak,RMS en NRMSE voor displacement en current (los van elkaar) en een best-fit ratio van het totaal plaatje.

[timpert]

Ben je toevallig bewust van de achterliggende oorzaak van dit fenomeen?

Niet exact, maar ik vermoed dat het iets te maken heeft met het vezelachtige/geweven zijn van de spider, als je ze strak trekt worden ze wat dunner en gaan ze daardoor wat makkelijker langs elkaar wrijven. Maar verder dan dit beeld reikt mijn idee ook niet.

Ik ben nog niet verder gegaan met modelleren, dus ik kan er nog niet veel meer over zeggen. Wel heb ik geprobeerd of ik met piloottoon plus een arbitrair signaal een meting kan doen met de Pytorch fit. Het signaal is nu geen multisine meer waarvan de amplitudes en fasen bekend zijn, maar een willekeurig "program representative signal" waar ik verder geen analyse op heb gedaan. Dat signaal heb ik in kanaal 1 van de functiegenerator gezet, en dat kanaal staat op "burst" met een software trigger. De generator begint het dus pas af te spelen als het programma de trigger geeft. Zo kan je ook inslingerverschijnselen meenemen.

Op kanaal 2 staat de piloottoon, door de generator op "combine" te zetten kan ik beide signalen bij elkaar optellen en op uitgang 1 naar buiten brengen. De piloottoon staat er al op voordat het arbitraire signaal begint. In de video hieronder is het duidelijk te zien dat de conus al licht beweegt op de piloottoon, nadat de acquisitie is gestart triggert ook het programmasignaal:



Ook is te zien hoe de temperatuur van de spreekspoel vrij snel oploopt naar zo'n 30 graden en dan constant blijft. Het totale vermogen is nog niet eens 8 Watt, maar toch is zo'n beetje alle uitsturingsruimte van de versterker benut. Ik moet dus een grotere versterker gaan zoeken...

Uiteraard heb ik ook even geprobeerd of er geloofwaardige T&S parameters uitkomen, hier een ongeformatteerd screenshot:

Screenshot 2025-09-14 155604.png (10.75 KiB) 442 keer bekeken

Even door de miljoenmiljard cijfers achter de komma heen kijken, maar die resultaten wijken niet eens zo veel af van de multisine resultaten. Zeker als je je bedekt dat het signaal rond de resonantiefrequentie (ca. 45 Hz) waarschijnlijk weinig energie bevat. Tot slot nog het obligatoire Bl(x) plaatje uit de polynoomfit:

En dat ziet er ook niet onaardig uit hoewel het toch een beetje afwijkt van eerdere resultaten. Dus waardoor dat komt? Wie het weet mag het zeggen.

maar goed, dit is dus wel heel dicht bij "full dynamic" meten, waarbij je aan de hand van een arbitrair signaal de parameters achterhaalt. Dat signaal is geen speciaal ontworpen meetsignaal, maar een gebruiksrepresentatief signaal: muziek dus. Het live bewaken van temperatuur, vermogen en uitslag tijdens de meting werkt naar behoren, hoewel de aanwezigheid van de piloottoon me nog wel wat stoort. Eens kijken of het ook zonder kan.

Voor de komende tijd staat op de agenda:

• Het opsplitsen van het programma in een acquisitie- en modelleergedeelte
• Het acquisitiegedeelte een nette grafische interface geven
• Een dikkere versterker scoren
• Een nieuwe spanningsprobe maken (de huidige heeft een te klein bereik)
• Een temperatuurprobe maken (optioneel)
• Me ingraven in de modellering wanneer de acquisitie helemaal naar mijn zin is

Maar nu is het tijd voor

[hidjedewitje]

En dat ziet er ook niet onaardig uit hoewel het toch een beetje afwijkt van eerdere resultaten. Dus waardoor dat komt? Wie het weet mag het zeggen.

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.

Ook is te zien hoe de temperatuur van de spreekspoel vrij snel oploopt naar zo'n 30 graden en dan constant blijft. Het totale vermogen is nog niet eens 8 Watt, maar toch is zo'n beetje alle uitsturingsruimte van de versterker benut. Ik moet dus een grotere versterker gaan zoeken...

Grappig, ik heb toevallig van het weekend een meting van 1u gedaan van temperatuur van een custom driver. Daar zag ik dat de temperatuur in het begin erg snel stijgt (voice-coil), maar niet settled. Pas na 40-45min was het echt gesettled!
Mijn verwachting is dat de tijdconstante van de magneet veel groter is dan de vc tijdconstante en dat het daarom langer duurt.

Mocht je hulp nodig hebben met validatie/modelleren, vanaf volgende week heb ik wat meer tijd om te hobbyen .

[Shadow]

Hangt er ook vanaf wat je meet qua temperatuur, de spreekspoel is een stuk sneller in thermisch evenwicht bij continu belasting dan de magneet lijkt me?

[hidjedewitje]

Hangt er ook vanaf wat je meet qua temperatuur, de spreekspoel is een stuk sneller in thermisch evenwicht bij continu belasting dan de magneet lijkt me?

In mijn geval maakte ik een video met thermische camera.De spreekspoel wordt inderdaad veel sneller warm, maar raakt niet zo snel in equilibrium. Pas als de magneet een bepaalde temperatuur bereikt eindig je in equilibrium. Waarschijnlijk omdat er "thermische conductie" is tussen de spoel en de magneet.

Excitatie was ~23W_rms (displacement limited) van 128 sines beginnent op 50Hz tot 2k. Driver betreft een custom 4" driver met Fs =~ 100Hz.