Liebe Mitleserinnen, Mitleser, Foristinnen und Foristen,
wer sich von Euch in letzter Zeit mit dem Gedanken getragen hat, Mitglied unseres wunderbaren IGDH-Forums zu werden und die vorher an dieser Stelle beschriebene Prozedur dafür auf sich genommen hat, musste oftmals enttäuscht feststellen, dass von unserer Seite keine angemessene Reaktion erfolgte.
Dafür entschuldige ich mich im Namen des Vereins!
Es gibt massive technische Probleme mit der veralteten und mittlerweile sehr wackeligen Foren-Software und die Freischaltung neuer User ist deshalb momentan nicht mit angemessenem administrativem Aufwand möglich.
Wir arbeiten mit Hochdruck daran, das Forum neu aufzusetzen und es sieht alles sehr vielversprechend aus.
Sobald es dies bezüglich Neuigkeiten, respektive einen Zeitplan gibt, lasse ich es Euch hier wissen.
Das wird auch für alle hier schon registrierten User wichtig sein, weil wir dann mit Euch den Umzug auf das neue Forum abstimmen werden.
Wir freuen uns sehr, wenn sich die geneigten Mitleserinnen und Mitleser, die sich bisher vergeblich um eine Freischaltung bemüht haben, nach der Neuaufsetzung abermals ein Herz fassen wollen und wir sie dann im neuen Forum willkommen heißen können.
Herzliche Grüße von Eurem ersten Vorsitzenden der IGDH
über Ostern wollte ich mal was anderes machen und motiviert durch die Hornbastelei mit Onnos 2344-Clon habe ich mich an den Feiertagen mal in ABEC tiefer eingearbeitet. Natürlich will ich dann auch schnell verschiedene Schallführungsformen ausprobieren, aber da war ich dann schnell davon genervt, daß ich die Geometrie immer per Hand eintippen sollen. Und der Weg über Fusion->Gmesh->ABEC nervt auf Dauer auch ganz schön bzw. ist zeitraubend. Also habe ich mich gefragt, ob das nicht auch anders geht. Da ich beruflich bedingt, in der Karwoche Python gelernt habe, habe ich damit auch gleich ein kleines Skript geschrieben, dass mir die Sache erleichtert.
Derzeit macht dieses Skript erstmal nichts weiter als ein rotationssymmetrisches, konisches Horn zu parametrisieren. Es kann der Öffnunswinkel und die Grenzfrequenz festgelegt werden, optional kann der Hornmund mit einem frei wählbaren Radius und frei wählbarer Tiefe verrundet werden. Somit kann ich schonmal verschiedene Geometrieen zügig ausprobieren.
Das Skript möchte ich Euch nicht vorenthalten und habe es hier angehängt. Einfach das Projektarchiv entpacken, in den Projekt per Kommandozeile wechseln und python yawt.py aufrufen. Das ist alles noch sehr rudimentär, Parameter müssen noch mit einem Texteditor im Skript selber geändert werden.
Ich möchte in den kommenden Wochen sporadische weitere Geometrieen hinzufügen und auch andere Formen als Rotationssymmetrie sollen dazu kommen (deswegen ja ABEC und nicht AxiDriver). Trotzdem wäre es cool, wenn der eine oder andere mal draufschaut, ob die Ergebnisse plausibel sind.
Raphael
Geändert von rkv (07.04.2021 um 17:55 Uhr)
Grund: Autokorrektur überlistet
Der weisse Prototyp hat durchaus Ähnlichkeit zu den Waveguides in den JBL Synthesis Wandlautsprechern, wen wundert es bei den Eigentumsverhältnissen...
Danke. In dem Paper geht es ja hauptsächlich um Optimierungsstrategien, und da bietet sich ein WG auf Basis von WG-Kurven wunderbar an, weil man über mehrere freie Parameter verfügt, die Kurve aber immer "glatt" bleibt, und eigentlich jedes CAD-Programm solche Kurven bzw. Flächen unterstützt (NURBSe basieren darauf).
Mit solchen WGs habe ich auch schon gearbeitet und u. a. auch in dem verlinkten Thread erwähnt: https://www.diy-hifi-forum.eu/forum/...l=1#post183275
Der allereinfachste Ansatz (aus CAD-Sicht) ist:
- Hornhalsdurchmesser definieren
- Hornmund definieren (gerne auch elliptisch oder rechteckig oder was überlagertes)
- Horntiefe definieren
- Randbedingungen definieren => am Hals senkrechter (bei Kalotten, bei HT-Treibern anders), am Mund tangentialer Abschluss
- Das CAD-Programm eine NURBS-Fläche einzeichnen lassen.
Man hat dann zwei freie Parameter (Tiefe und Mund, Hals ist ja meistens durch den Treiber bestimmt) über die man untere Grenzfrequenz und Abstrahlcharakteristik bestimmen kann. Klappt super mit SolidEdger (und wahrscheinlich mit allen anderen Parasolid-Modellern auch).
Wobei genau diese iterative Optimierung in dem Paper ja das eigentlich spannende ist. Wenn Comsol nicht so schweineteuer wäre...
Ich meine gelesen zu haben, dass ein Iterationsschritt oft schon reichen würde. Das deckt sich auch mit meinen manuellen Erfahrungen. Entscheidend sind halt die Anfangswerte. Wenn man da einfach nur ins Blaue hinein schießt, dann braucht man halt mehr Iterationen.
Z. B. das oben beschriebene NURBS-WG. Freie Parameter sind Tiefe und Mund. Dann gilt grob folgendes:
- Tiefe größer => untere Grenzfrequenz runter und mehr Gain*, dafür stärkeres Einschnüren
- Mund größer => weniger Gain, dafür breitbandiger und weniger starkes Einschnüren
Wenn man sich das Ziel vorher passend definiert kommt man dann mit einem oder zwei Iterationsschritten klar.
* Untenrum verhält sich so ein WG fast wie eine Transmissionline, mit maximalem Gain ungefähr bei lambda/4
Ich meine gelesen zu haben, dass ein Iterationsschritt oft schon reichen würde. Das deckt sich auch mit meinen manuellen Erfahrungen. Entscheidend sind halt die Anfangswerte. Wenn man da einfach nur ins Blaue hinein schießt, dann braucht man halt mehr Iterationen.
Dann habe ich mich wohl bei meinen bisherigen Versuchen wohl zu dösig angestellt...
Ich habe früher immer den Fehler gemacht, zu viel im Klein-Klein zu verbessern, und nochmal und nochmal weiter zu optimieren. Inzwischen bin ich eher bei "ist gut genug jetzt". Klar, man kann auch noch das letzte herausholen, aber der Aufwand rechtfertigt meistens nicht das Ergebnis.
Außerdem: wenn das Gelumpe verkauft, muss man sich Raum für Verbesserungen lassen, so von wegen "Jetzt neu: verbesserte Rezeptur". Ich frage mich dann immer: "ja wie, war vorher scheiße, oder was?"
Ich habe früher immer den Fehler gemacht, zu viel im Klein-Klein zu verbessern, und nochmal und nochmal weiter zu optimieren. Inzwischen bin ich eher bei "ist gut genug jetzt". Klar, man kann auch noch das letzte herausholen, aber der Aufwand rechtfertigt meistens nicht das Ergebnis.
Außerdem: wenn das Gelumpe verkauft, muss man sich Raum für Verbesserungen lassen, so von wegen "Jetzt neu: verbesserte Rezeptur". Ich frage mich dann immer: "ja wie, war vorher scheiße, oder was?"
Alles Trottel und Anfänger.
Wie gut, dass ich da nichts verkaufen muss sondern einfach fröhlich vor mich hinbasteln kann.
Außerdem: wenn das Gelumpe verkauft, muss man sich Raum für Verbesserungen lassen, so von wegen "Jetzt neu: verbesserte Rezeptur". Ich frage mich dann immer: "ja wie, war vorher scheiße, oder was?"
Muss halt leider doch zum Rest des Marketings passen...
Ich muss die Tage dringend noch mal mit ABEC und den Python Skripten herumprobieren, das klingt wirklich spannend. Der komplizierte Workflow hat mich bisher auch wirksam daran gehindert, hier großartig Zeit zu investieren. Ein großes Dankeschön an Raphael!
Jo, mach das mal, ich bin gerade dabei, eine Funktion zu ergänzen, die auch gleich die ABEC-Projektdatei und die Observations-Skripte baut, damit man die sich nicht von woanders noch her kopieren muss.