Re: Deftige meetopstelling voor luisprekerparameters
Geplaatst: di 05 nov 2024, 20:31
Tuurlijk, Mario heeft het niet voor niks zo mooi in orde gemaakt 
Hét forum voor en door zelfbouwers.
https://zelfbouwaudio.nl/forum/
De simulatoren waar T&S mee werkten waren heel primitief, SPICE 1 kwam pas twee jaar uit na het paper van deze heren. In 1971 kon een compu nog niet zo gek veel, dus componenten schrappen en samenrapen was wat je moest doen om (dure!) CPU tijd uit te sparen.timpert schreef: ↑di 05 nov 2024, 18:47Deze aanpak heeft een belangrijk voordeel: je kan op deze manier de frequentierespons doorrekenen met elektrische filtertheorie, en voorspellen met (de toen nog in de kinderschoenen staande) circuitsimulators op de computer in gevallen waarbij een exacte analytische oplossing niet te vinden is.
Dat vind ik wel wat simpel gesteld.
Dat lijkt mij nogal vanzelfsprekend, anders waren het ook geen LINEAIRE modellen!!
Ik heb je post gelezen, en hoewel ik begrijp wat je schrijft had ik gisteravond wat moeite om er de boodschap uit te destilleren. Ik denk dat de meesten van ons zich wel beseffen dat een complexe en veranderlijke werkelijkheid zich niet volledig laat vatten in een paar statische vergelijkingen.
Misschien ligt het aan mijn achtergrond, maar in de studie natuurkunde worden begrippen als orde van grootte en significantie er vanaf dag 1 met de paplepel in geramd.JanRSmit schreef: ↑za 09 nov 2024, 9:46Kan je uitgebreide post goed begrijpen. Doet me denken aan wat de mensheid door de eeuwen heen deden en doen om op zee te navigeren. Dat heet gegist bestek. Dat werd wel naukeurig uitgevoerd met alle correctie tabellen erbij, maaar er was altijd een afwijking. Op de zeekaarten aangegeven met een punt met daaromheen een cirkeltje. In het Engels heet dat "dead reckoning", oftewel een "exact uitgevoerde veronderstelling". Kort samengevat dus het gevaar van een getal te geloven zonder de bijbehorende veronderstelling te weten.
Ik denk persoonlijk dat dit dus juist niet helemaal de goede benadering is.
Lees de rest van de paragraaf ook even waar je nu de eerste zin van citeert, want die geeft weer hoe ik daar in sta. Ik koester niet de illusie de absolute werkelijkheid met deze meting te kunnen achterhalen, wel hoop ik het inzicht in de kwaliteiten van de verschillende drivers te verbeteren ten opzichte van wat nu in de hobbywereld de stand van zaken is.
Is dat niet precies wat ik gedaan heb? Beginnen met de "big three" en van daaruit verder kijken naar wat haalbaar en nuttig is.OWC schreef: ↑di 12 nov 2024, 0:27Het lijkt mij veel zinniger om iets te creëren dat een stuk beter te behappen is.
Op dit manier kun je alsnog verschillende drivers goed met elkaar vergelijken.
Dat is nu namelijk het essentiële dat nu mist.
Iets als een relatieve BL vs excursion curve zegt al boekdelen over hoe een driver presteert tov een andere driver.
Dat maakt het ook meer behapbaar voor jezelf.
Mijn foutinschatting is nu niet meer dan [LaTeX]\pi \cdot duim[/LaTeX] maar op dit moment ga ik die niet verbeteren. De grote onzekerheid is vooral op [LaTeX]K_m(x)[/LaTeX] van toepassing en komt doordat die meting met mijn huidige aanpak het afvoerputje is geworden waarin alle meetonzekerheid bij elkaar komt. Met een beter meetsignaal (multitone, ruis, muziek) nemen mijn mogelijkheden voor modelfit ook toe, en kan ik de oorzaak van de grote meetfout wegnemen. Een beetje net als met een lekke band: je kan bepalen hoe snel je band leegloopt om te kijken hoe vaak je moet pompen, maar je kan ook gewoon besluiten de band te gaan plakken.
Zeker weten doe ik het niet, maar ik vermoed dat hij aardig met de make-up kwast tekeer gaat. Het valt me namelijk op dat alle metingen bij groot signaal bij [LaTeX]x=0[/LaTeX] en/of [LaTeX]i=0[/LaTeX] exact (maar dan ook echt exact) overeenkomen moet de kleinsignaal metingen. Kijk je naar de werkwijze, dan doet Klippel eerst een kleinsignaal meting, en dan moet je de resultaten van die meting copy-pasten in de setup voor groot signaal. Daarom vermoed ik dat de grafieken/resultaten voor groot signaal geschaald worden zodat ze overeenkomen bij [LaTeX]x=0[/LaTeX] en/of [LaTeX]i=0[/LaTeX]. Als ik mijn resultaten op die manier oppoets, dan ziet het totaalplaatje er ongetwijfeld al een stuk beter uit. Maar dat wil ik nu niet doen, omdat ik dan al in de ontwikkelfase problemen wegmoffel en zo mezelf voor de gek houd.
Novak heeft inderdaad wat goede inzichten, en daar kijk ik nu ook zeker naar. Ik heb hem nog niet kunnen betrappen op het oppoetsen van resultaten, maar wellicht is dat ook omdat hij geen kant-en-klare systemen verkoopt die mooie plaatjes moeten produceren. Het artikel dat je hier hebt gedeeld is wat dat betreft ook erg interessant, want het benadert het probleem de andere kant op: hoe moet ik een signaal voor-vervormen om de luidspreker een zuivere output te laten produceren. Het plotje wat in paragraaf 4.1 wordt gegeven (driving force vs. displacement) moet in een avondje code kloppen wel te maken zijn. Je kan dan meteen zien welke speakers mooie rondjes blijven produceren, en welke aardappelen geven.
Dat kon nog niet toen ik de ingebouwde signaalgenerator van mijn DAQ gebruikte, maar nu ik mijn functiegenerator heb gesynchroniseerd behoort dat ook tot de mogelijkheden.
Dat had ik al gedaan, en dat heet miscommunicatie
Je bent je er van bewust dat de stijfheid sowieso afhankelijk is van wat voor signaal er wordt gebruikt alsmede de cone excursion?timpert schreef: ↑di 12 nov 2024, 9:08De grote onzekerheid is vooral op van toepassing en komt doordat die meting met mijn huidige aanpak het afvoerputje is geworden waarin alle meetonzekerheid bij elkaar komt. Met een beter meetsignaal (multitone, ruis, muziek) nemen mijn mogelijkheden voor modelfit ook toe, en kan ik de oorzaak van de grote meetfout wegnemen. Een beetje net als met een lekke band: je kan bepalen hoe snel je band leegloopt om te kijken hoe vaak je moet pompen, maar je kan ook gewoon besluiten de band te gaan plakken.
Sja, ik snap wat je bedoelt, maar we komen dan in een soort kip-ei discussie terecht.timpert schreef: ↑di 12 nov 2024, 9:08Zeker weten doe ik het niet, maar ik vermoed dat hij aardig met de make-up kwast tekeer gaat. Het valt me namelijk op dat alle metingen bij groot signaal bij en/of exact (maar dan ook echt exact) overeenkomen moet de kleinsignaal metingen. Kijk je naar de werkwijze, dan doet Klippel eerst een kleinsignaal meting, en dan moet je de resultaten van die meting copy-pasten in de setup voor groot signaal. Daarom vermoed ik dat de grafieken/resultaten voor groot signaal geschaald worden zodat ze overeenkomen bij en/of . Als ik mijn resultaten op die manier oppoets, dan ziet het totaalplaatje er ongetwijfeld al een stuk beter uit. Maar dat wil ik nu niet doen, omdat ik dan al in de ontwikkelfase problemen wegmoffel en zo mezelf voor de gek houd.
In principe kan dit ook al met een simpele audio interface.
Ik zal later deze week eens een plaatje maken waarin de amplitude- en frequentieafhankelijkheid te zien zijn, want de grafiek is nogal veranderlijk als je aan één van die twee draait, maar die verwachting heb ik inderdaad al op pagina 1 van deze thread uitgesproken. Daarom vermoed ik ook dat Klippel de [LaTeX]K_m(x)[/LaTeX] uit een meting haalt, en vervolgens zodanig schaalt dat [LaTeX]K_m(0)[/LaTeX] samenvalt met de kleinsignaal meting.
Je bent nogal dol op pluimvee
De aansturing van een audio interface is wat brak vanuit Python, en dat geldt dubbel voor mijn Focusrite met ASIO. Dus die laat ik hier maar even op de plank liggen. Wat betreft die geluidsdruk: ik heb de opstelling in de kelder staan, dus met de welbekende groene oorkappen of een remote desktop sessie is het probleem opgelost. En dat is wel fijn, want vooral een "sparse multitone"is echt een enorme takkeherrie als je ernaast staat.
Ik moet zeggen dat ik niet helemaal snap wat Klippel hier doet.
Sterker nog, die is volgens mij is die IEC door Klippel zelf bedacht
Is misschien quasi dynamic niet een optie hier?
Extra dummy speaker erbij enkel in tegenfase helpttimpert schreef: ↑di 12 nov 2024, 20:03at betreft die geluidsdruk: ik heb de opstelling in de kelder staan, dus met de welbekende groene oorkappen of een remote desktop sessie is het probleem opgelost. En dat is wel fijn, want vooral een "sparse multitone"is echt een enorme takkeherrie als je ernaast staat.
Ja mooi zo