It may have some (unknown) limitations at the moment but in general it seems to work: https://at-horns.eu/ext/ath-4.9.0-pre-230109.zip
Simply define a line like the following one in your script (file path can be relative to the ATH directory or absolute).
Profile = D:\temp\coords.txt
The file should contain a space-separated pair of X Y coordinates per line ([mm]).
Last edited:
You can provide a coordinates fileIs there the new back side definition functionality on this pre release?
The drawing/model itself doesn't seem to be wrong. It uses the "mathematical" back side (Mesh.RearShape=2) which is a possible trick how to avoid modeling the whole back. I used that occasionally but it's not as accurate as a full model. (I only don't see the source elements (?)).
I have this as coords.txt:
and I get lots of:
Do I need to enter just e.g. the R-OSSE coordinates, or do I also have to provide the back side of the shape?
Code:
0.000000 12.700000
7.623634 15.777872
15.121538 19.658011
22.489087 24.025319
29.721288 28.706582
36.812750 33.609098
43.757652 38.682485
50.549708 43.898674
57.182131 49.241595
63.647598 54.701697
...and I get lots of:
Code:
Warning : Start point 2 and end point 10 of GEO line 3 are closer than the geometrical tolerance, at position (0, 0, 0)
Warning : Start point 2 and end point 3 of GEO line 4 are closer than the geometrical tolerance, at position (0, 0, 0)
Warning : Start point 3 and end point 11 of GEO line 5 are closer than the geometrical tolerance, at position (0, 0, 0)
Warning : Start point 3 and end point 4 of GEO line 6 are closer than the geometrical tolerance, at position (0, 0, 0)
Warning : Start point 4 and end point 12 of GEO line 7 are closer than the geometrical tolerance, at position (-0, 0, 0)
....Do I need to enter just e.g. the R-OSSE coordinates, or do I also have to provide the back side of the shape?
Just the profile curve (as you see e.g. in Desmos). The back side and everything else is then calculated/processed as usual. That's the idea.
Which means you should not create a closed surface yet, like a sphere. That will require some additional logic in the software. Keep it open at the back (curiously, it also seems to solve better that way).
Success!
Rollback so the edge faces the backside of the waveguide.
Not too shabby!
edit:
Without rollback:
Last edited:
I mixed thinks up a bit. Ath seems to chose spherical/flat wavefront on its own. That does alter the peak >15kHz. It also seems to introduce the anomaly at lower frequency and higher angles.
So, does that mean that the bump is dependent on the wavefront type (spherical/flat)? I don't know what my driver has.
p.s. Changed k from 1.2984 to 1 also in this graph, but have seen it happen without also.
So, does that mean that the bump is dependent on the wavefront type (spherical/flat)? I don't know what my driver has.
I can hear it already!- Let us know then at what SPL you hear a difference
p.s. Changed k from 1.2984 to 1 also in this graph, but have seen it happen without also.
That's hard to believe but maybe you have something in your script that mixes that up. The on-axis hole definitely emerges with a flat wavefront as the source.
Yea, I get the same DI bump around 500 Hz when I define the arc termination with arcterm=270. The overall shape looks quite the same to what you have but obviously something is different. The value of t at the junction (max curvature) in my case is ~0.922 and the arc radius is 30.3 mm with the center at [107.73; 194.56]. I used k=1.2984.
Last edited:
Yeah that low frequency DI hump is sound around the device, clearly visible now when diffraction backwave is eliminated with the midsized roundover on the lip. To get rid of this the roundover needs to be big like demonstrated earlier, it has to increase path length around the whole device. The whole thing needs to be shaped closer to a sphere than a mushroom to get rid of it.
The other option is to make smaller roundover on the lip to cure only the HF diffraction and leave LF main diffraction backwave be, which balances out this LF DI hump which is on passband because path length around the device at 500Hz is too short, the device is too small (depthwise)
The other option is to make smaller roundover on the lip to cure only the HF diffraction and leave LF main diffraction backwave be, which balances out this LF DI hump which is on passband because path length around the device at 500Hz is too short, the device is too small (depthwise)
No, I don't think that's related.
Nobody knows what their driver has. Probably the best what you can hope for is a spherical wave corresponding to the exit angle (i.e. set Source.Shape = 1).