Can somebody help explain what is going on in this simulation. Here is the deal, when S5 is equal to or less than 1091.14cm^2 the phase looks like the light gray trace. If S5 is made to be 1091.15cm^2 or greater, the phase looks like the dark trace. How can 0.01cm^2 make that much difference in the phase response?
Attachments
Hi JLH,
If the delay for the S5 = 1091.14 example is manually changed from the default value of 10.4 msec to 8.9 msec (the same as for the S5 = 1091.15 example) then the corrected phase response results become almost identical - see attached screenprint.
Without going into the specific details of the delay algorithm, the default delay values for the two examples are different because of the way that the -12 dB delimited SPL bandwidth, which is used in the calculation of the delay, is determined.
The following computations using actual Hornresp values illustrate how the difference arises even though the values of SPL1 and SPL2 for Case 1 are very similar to those for Case 2.
Limit = 20 * Log10(4) = 12.041200 dB
CASE 1:
S5 = 1091.14 cm^2
Freq1 = 172.196708 Hz
SPL1 = 104.758278 dB
Freq2 = 198.671992 Hz
SPL2 = 92.717041 dB
(SPL1 - SPL2) - Limit = (104.758278 - 92.717041) - 12.041200 = 0.000037 dB
CASE 2:
S5 = 1091.15 cm^2
Freq1 = 172.196708 Hz
SPL1 = 104.758271 dB
Freq2 = 198.671992 Hz
SPL2 = 92.717093 dB
(SPL1 - SPL2) - Limit = (104.758271 - 92.717093) - 12.041200 = -0.000022 dB
*** Note that [(SPL1 - SPL2) – Limit] is positive for Case 1 and negative for Case 2. ***
Although not obvious from the information given, this is essentially the reason why the default offset delay corrections are ultimately calculated to be so different.
Kind regards,
David
Attachments
?
Where shout I check that Sabbelbacke.
I run window virtual on my macbook. I know virtual box has all kind of installation possibilities.
But that isn't what you where thinking of I know, only say this to keep in mind maybe it plays a role.
Attachments
Last edited:
Hi Helmuth,
Are you using the latest release - Product Number 3240-130929, and are the Hornresp.exe, Hornresp.hlp and Msvbvm60.dll files located in the C:\Hornresp folder?
If so, then try moving your existing Hornresp.dat data file from the C:\Hornresp\Data folder to some other backup location, and run Hornresp. This should generate a new data file containing just the default record.
Does this work? If so, then it would seem that your original data file has been corrupted in some way. If you care to send me a copy, I can have a look and see if I can fix the problem for you. My email address is given on the Hornresp download web page (click on my name).
Kind regards,
David
Try backing up your old hornresp installation (ZIP it, or move the folder, rename it...), then do a quick fresh install. Does this work?
Hi David,
Removing the .dat file (who had 0 bites) solved the error. Thanks david.
So I lost my saved simulations due a corrupt file.
I have version 28.80
Attachments
Last edited:
Hi Helmuth,
This is very strange indeed. I have no idea how Hornresp could have corrupted your data so that it resulted in a zero-byte file. At the very least, the .dat file should always contain the default record, which is re-generated and re-stored each time the program is opened.
In my experience, since Version 19.10 was released (which prevented multiple sessions of Hornresp from being run simultaneously) the data file has proved to be remarkably resilient. During ongoing testing I have tried everything I can think of to deliberately corrupt the file using Hornresp, but without success.
Incidentally - I strongly recommend that you update to the latest Hornresp release, as a number of new features have been added since Version 28.80.
-------------------------
If anyone else has experienced similar problems with data loss and zero-byte files, could they please let me know - thanks.
Kind regards,
David
Hi Helmuth,
Further to my post above, I have just noticed that your screenprint attachment shows file Vbrun300.dll in the same folder as Hornresp.exe.
Vbrun300.dll is the application extension file for a program written in Microsoft Visual Basic 3. As from Version 20.00, Hornresp was converted to Visual Basic 6.
The Vbrun300.dll file should be deleted and replaced by Msvbm60.dll, if not already in the folder, supplied as part of the Setup.exe Hornresp download package.
Kind regards,
David
Further to my post above, I have just noticed that your screenprint attachment shows file Vbrun300.dll in the same folder as Hornresp.exe.
Vbrun300.dll is the application extension file for a program written in Microsoft Visual Basic 3. As from Version 20.00, Hornresp was converted to Visual Basic 6.
The Vbrun300.dll file should be deleted and replaced by Msvbm60.dll, if not already in the folder, supplied as part of the Setup.exe Hornresp download package.
Kind regards,
David
Atc question
Hello,
I am currently having trouble understanding the Atc and Vtc values when using two drivers in a push-push arrangement like the one pictured. What exactly is Atc? Is it simply the same value as S1? Is Vtc correctly sketched out in the drawing?
OR: Is the pictured arrangement really an "offset driver" horn in hornresp?
Thanks so much for the help!
Hello,
I am currently having trouble understanding the Atc and Vtc values when using two drivers in a push-push arrangement like the one pictured. What exactly is Atc? Is it simply the same value as S1? Is Vtc correctly sketched out in the drawing?
OR: Is the pictured arrangement really an "offset driver" horn in hornresp?
Thanks so much for the help!
Attachments
Last edited:
.Hi meko,
Your understanding is correct.
Don't worry too much about the value of Atc as it is really only required to find the length of the throat chamber (Ltc = Vtc / Atc) which in turn determines any throat chamber resonances - which may or may not appear in the overall SPL response depending upon the chamber length. With the 'chamber resonances masked' option selected, Atc is not used in the calculations at all.
For the purposes of the simulation, set Atc = S1. Using a different value for Atc probably won't make any appreciable difference to the results - try checking this for yourself.
Vtc (and Vrc) are as shown in your diagram.
Model the arrangement as a conventional front-loaded horn, rather than as an offset driver horn.
Kind regards,
David
Hi david,
I did play with the directivity tools they are great, what i would like to know with HF horn simulations when a round horn is formed like the line array horn. What directivity does.
The 15 degrees directivity above 10kHz bothers me.
What directivity does, I do not know how difficult it would be to make a tool like that.
Or to see how much directivity improves when flatten the round horn to a ellipse.
You probably already had ideas for that design feature.
I did play with the directivity tools they are great, what i would like to know with HF horn simulations when a round horn is formed like the line array horn. What directivity does.
The 15 degrees directivity above 10kHz bothers me.
What directivity does, I do not know how difficult it would be to make a tool like that.
Or to see how much directivity improves when flatten the round horn to a ellipse.
You probably already had ideas for that design feature.
Last edited: