Oops, I forgot to set axial driving on the LF source. Simply add "Direction=z" to the driving group (solving.txt), that's it:
When doing real world measurements, each source would be measured on its radiation axis. How should we proceede in ath? Mesh.VerticalOffset set at between the center of both sources and then, add the respective vertical offset to the polar data in VCad?
If you set the observation axis at the intended design listening axis there would be no need to set any offsets in Vituix as the Data already contains them.
There was the discussion in @hifijim's thread where he tested the propper integration in VCAD and I mean his result was to measure each driver on its respective axis and then enter offsets in VCad.
I don't know the design axis atm, I will just set it in the middle for now and use vertical offsets in VCad.
I don't know the design axis atm, I will just set it in the middle for now and use vertical offsets in VCad.
Last edited:
It would be important to have the rotation axis for both the same plane, or close enough within few cm. Both drivers could be measured on axis, or from single position with some error, quote from measurement manual:
"
Elevation of mic is at the center point of driver under test i.e. mic and driver have the same Y-coordinate in mm. Turn speaker back/front if front baffle is tilted. Tilt turning table front with ground plane measurement to aim driver’s axis towards the mic while hor 0 deg measurement. Exception: Mid and tweeter can be measured at common mic elevation = average Y of center points if drivers are small and close to each other, baffle is straight (non-stepped) and vertical plane is not measured i.e. drivers are circular and hor/ver difference in baffle diffraction is ignored on purpose
"
https://kimmosaunisto.net/
The accurate way to do the measurements is tedious in real world and hence some shortcuts can be done in real world, but no point with sims as it is equally fast to do few angles than all, and move the DUT in front of the mic 🙂 Although, perhaps there are some errors in sims as well, in comparison to eventual real world build so some small errors expected. Perhaps it is all fine as long as nothing silly happens like micing/observing too close.
It is very very cool to be able to simulate a whole system and even process the results further in other software, hats off! Thanks mabat!
"
Elevation of mic is at the center point of driver under test i.e. mic and driver have the same Y-coordinate in mm. Turn speaker back/front if front baffle is tilted. Tilt turning table front with ground plane measurement to aim driver’s axis towards the mic while hor 0 deg measurement. Exception: Mid and tweeter can be measured at common mic elevation = average Y of center points if drivers are small and close to each other, baffle is straight (non-stepped) and vertical plane is not measured i.e. drivers are circular and hor/ver difference in baffle diffraction is ignored on purpose
"
https://kimmosaunisto.net/
The accurate way to do the measurements is tedious in real world and hence some shortcuts can be done in real world, but no point with sims as it is equally fast to do few angles than all, and move the DUT in front of the mic 🙂 Although, perhaps there are some errors in sims as well, in comparison to eventual real world build so some small errors expected. Perhaps it is all fine as long as nothing silly happens like micing/observing too close.
It is very very cool to be able to simulate a whole system and even process the results further in other software, hats off! Thanks mabat!
Common rotation axis is automatically set to depth of waveguide source, I have not tried the offset parameter, it should work too.
Ouch, nothing of this holds up for my case. Well, its solving now.
Ouch, nothing of this holds up for my case. Well, its solving now.
Last edited:
That is an issue of combining real measurements with synthetic baffle diffraction. You can get most of the answer from moving the Y coordinates in Vituix. If the baffle remains the same size and shape the difference will be very small. If the size and shape of the baffle changes due to the position of the drivers then a new 3D simulation is the better choice.
When a finished speaker is measured in an anechoic chamber they are not measuring it separately on each axis. The ABEC simulation is mimicking this same approach.
Small feedback: ath only outputs the first of two/several BEM data groups and I get the following print:
error: polar map 'SPL' not found in the BEM data
The data of vertical is quite corrupted but this might well be my fault, idk.
error: polar map 'SPL' not found in the BEM data
The data of vertical is quite corrupted but this might well be my fault, idk.
Exactly. There's no reason to do it any other way. As it is, it's already prepared to be used in a crossover simulator without setting any source offsets, etc. We have all we need (and all that's there) in the data already. I thought we cleared that up in the previous discussion. You only have to select the origin for rotations - the same way as you would do it for a finished speaker, it's really up to you and shouldn't matter much as long as we are observing it at far enough distance. I would keep it as it's shown above.
You are attempting to use a polar map which was not defined - most probably in the report.
As the documentation says:
The report will use SPL data from the polar map specified by its tag (see ABEC.Polars). The default tag is "SPL".
So for the report, specify the right polar map with the PolarData item.
Last edited:
I don't understand what you mean. Doesn't it work?
In ABEC you can't calculate the spectra of all the individual sources at once (you could but that's not what you want). So you have to do it in parts, manually "connecting" and "disconnecting" the sources, and repeating the spectra calculation and the data export for each part separately. I don't know of a simpler way. It's good that you have to solve it only once.
Last edited:
Hi,
It seems to work:
Although I did not use the ATh report feature
LF part:
HF part:
Edit:
FRD export seems to work too (did not open in other SW though)
It seems to work:
Although I did not use the ATh report feature
LF part:
HF part:
Edit:
FRD export seems to work too (did not open in other SW though)
Last edited:
You can have two separate drive groups and assign one to each graph so they are processed as if they are separate like below. The drive groups just need to be established and assigned to the correct mesh files in the solving.txt file.
Code:
Driving_Values
DrvType=Acceleration; Value=1.0
401 DrvGroup=1101 Weight=1.0 Delay=0.0
402 DrvGroup=1102 Weight=1.0 Delay=0.0
File="spl_nodes.txt"
// horizontal spectra
BE_Spectrum
PlotType=Polar; GraphHeader="PolarMap_H_Mid"
PolarRange=0,180,37
Farfield=true; BasePlane=zx
Offset=20mm; NormalizingAngle=0
501 Inclination=0.0 DrvGroups=1101 ID=5001
BE_Spectrum
PlotType=Polar; GraphHeader="PolarMap_H_Woofer"
PolarRange=0,180,37
Farfield=true; BasePlane=zx
Offset=20mm; NormalizingAngle=0
521 Inclination=0.0 DrvGroups=1102 ID=5201Great! I didn't realize that before. So then you already should have all you need to do it in one go, including the FRD export.
- Just use NamePrefix in the FRDExport sections to distinguish what is what - these prefixes become parts of the exported file names.
- Just use NamePrefix in the FRDExport sections to distinguish what is what - these prefixes become parts of the exported file names.
I tried to modify the box shape:
I have no error but the LF unit is not generated.
How declare teh LF source correctly?
Code:
box = {
point P0 100 0 8
point P1 140 20 16
point P2 100 250 16
point PB 0 250 20
bezier P0 P1 P2 PB
}
Mesh.Enclosure = {
Plan = box
Spacing = 20,20,20,200 ; first value is ignored in 1/4 sym, Spacing = <left, top, right, bottom>
LFSource.Below = {
Spacing = 10
Radius = 75
DrivingWeight = 1
}
}I have no error but the LF unit is not generated.
How declare teh LF source correctly?
Probably I haven't yet implemented the LF source functionality into the user plan.
The 4.8.3b2 is not yet fully functioning.
The 4.8.3b2 is not yet fully functioning.
It's not ignored because of the symmetry but because in this case this coordinate is explicitely stated in the ground plan.
Last edited:
Nuh, it didn’t, they where defined as in your example but there was no output for horizontal plane. Could be however that I was handling something wrong.
I had define values as -180,180,37, to include asymmetric vertical behaviour, could there be a problem with wanting to extract a full 360 degree like this? (except that ,37 gave odd values)
I understand that now. Is any center of rotation more correct than another, for CEA-2034A ? I would next time define baffle plane.
I think that for the full circle you should use 36 values, not 37, to get data every 10deg - it's a special case described in the ABEC documentation.
I'm not aware of any recommendation regarding the rotation centre. It can have some effect on the total power calculated from a limited set of data - that's about the only impact I can think of. I would put it close to the overall apparent acoustic centre of the system at the crossover frequency - if there's something like that at all. To be the most accurate we would have to sample the whole spherical surface around the loudspeaker properly. With only two orbits, there will be almost always some error.
I'm not aware of any recommendation regarding the rotation centre. It can have some effect on the total power calculated from a limited set of data - that's about the only impact I can think of. I would put it close to the overall apparent acoustic centre of the system at the crossover frequency - if there's something like that at all. To be the most accurate we would have to sample the whole spherical surface around the loudspeaker properly. With only two orbits, there will be almost always some error.
Yes, CTA2034 and VituixCAD manual recommends the baffle plane as rotation axis for measurements, for whatever reason. To me it makes sense to use same convention with simulations for consistency even though there wasn't any particular reason why. At least eventual measurements of the build would align those from the simulation. And perhaps more importantly workflow and mental set would be roughly the same reducing human error.
In Ath script you can use Offset in polar definition together with Mesh.VerticalOffset (this one is new) to place the rotation origin anywhere you want. I don't consider this as critical.
Last edited: