Sorry, in the image the first graph is made with a valor of 16w in amplifier, but with the same input level the graphs are almost identical
Owen,
Thanks for your kind words. I'm glad you like the software. I have done a update with regards to your comments. This can be installed by opening the about window (Help -> About). This will check for updates and you can click the Install button to install them.
I need to add some more stuff here to make it more intuitive and maybe some more views etc.
Thanks for your kind words. I'm glad you like the software. I have done a update with regards to your comments. This can be installed by opening the about window (Help -> About). This will check for updates and you can click the Install button to install them.
Thanks, I have fixed this and it now appears once the main window has loaded.1. On startup the "Make a directory" box appears behind the splash screen and makes it look like the program has frozen. It wasn't until I clicked on the program's tab on the windows bar that the GUI for directory selection appeared.
Thanks. This was a bug where it tries to load a non-existent driver. Now fixed.2. After entering a driver's parameters in the driver window, I clicked save and everything worked perfectly, but clicking in the white "Driver Library" box caused a recoverable crash.
I'm still undecided on this. I know it is typical to quote inductance in mH but I am a warrior for SI units! 😉 I have added a warning so if you enter anything higher than 0.002mH it remind you that its in H, not mH.3. Lvc is in Henries, which caught me out the first time through. After looking more closely, I notice that all your units are consistent, but this one might be best left in mH since every datasheet I've ever seem gives Lvc in this format. I had initially put in 1.35H and all the graphs were nonsense, it wasn't until closer inspection that I found my error and re-entered as 0.00135H
I need to do some work on this, but it does essentially do nothing. There is a window called Geometry Viewer. This gives you a 2D view of your enclosure, the width value is used here. I divide the area by the width in order to show you a 2D view.4. I'm still wondering what "Enclosure Width" does since it didn't appear to change anything on the graphs.
I need to add some more stuff here to make it more intuitive and maybe some more views etc.
Hi, I like your program. I haven't had time to test it much yet but I've been telling lots of people about it.
Would it be possible to allow for a rear chamber? If so, front loaded horns could also be simulated.
It would also be neat if you could seal the tl terminus so you could simulate sealed boxes.
I realize that both these requests are outside the scope of a transmission line simulator, I'm just hoping this can evolve into a general 1/4 wave simulator.
Would it be possible to allow for a rear chamber? If so, front loaded horns could also be simulated.
It would also be neat if you could seal the tl terminus so you could simulate sealed boxes.
I realize that both these requests are outside the scope of a transmission line simulator, I'm just hoping this can evolve into a general 1/4 wave simulator.
Hi, I like your program. I haven't had time to test it much yet but I've been telling lots of people about it.
Would it be possible to allow for a rear chamber? If so, front loaded horns could also be simulated.
It would also be neat if you could seal the tl terminus so you could simulate sealed boxes.
I realize that both these requests are outside the scope of a transmission line simulator, I'm just hoping this can evolve into a general 1/4 wave simulator.
I have no experience with horns. Do you mean a rear chamber as well as a 'front pipe'? I would have to done some research to understand the best way of doing this. I will certainly keep it in mind.
With regards to sealing the terminus. In the enclosure window you can select 'Closed End' and you can indeed model sealed boxes.
On that note. You can model vented (reflex) enclosures by having a box and then adding an element that is the size of the port.
Since this has come up again, I'll point out that every value conversion by the user is an opportunity for error. Especially when decimals and lots of zeroes are involved. 😀I'm still undecided on this. I know it is typical to quote inductance in mH but I am a warrior for SI units! 😉
Myself, I'm a warrior for useability, though when I was programming back in the days of DEC PDP 11s, you'd have been hard pressed to get me to waste any processor time on the input. Or use a variable name with more than three letters. 😉 These days, things have changed, of course, and I have to tip my hat to the inputs in WinISD - being able to cycle through a choice of units (with conversion on-the-fly) is actually very useful.
The lack of standard units is annoying, but I think you'll make more friends by helping with the problem, rather than adding to it. (and that's my geezer lecture for today)
Do you mean a rear chamber as well as a 'front pipe'?
Yes.
Front loaded horns also sometimes have a defined front chamber as well, but that's easily defined by one or more of the initial segments, so no need to worry about a front chamber.
With regards to sealing the terminus. In the enclosure window you can select 'Closed End' and you can indeed model sealed boxes.
I didn't see that. Great!
On that note. You can model vented (reflex) enclosures by having a box and then adding an element that is the size of the port.
I realize that. It would be nice if you could also choose the port location, same as you choose the driver location. Then you could model all manner of mltl.
Hi schmeet,I need to do some work on this, but it does essentially do nothing. There is a window called Geometry Viewer. This gives you a 2D view of your enclosure, the width value is used here. I divide the area by the width in order to show you a 2D view.
What expansion/flare do you use? If you intend your software to design enclosures of constant width you'll want to use a parabolic expansion as opposed.
Hi
First impression is that input fields could be more userfriendly, liter instead of m3, cm instead of meters, cm2 instead of m3. Stuffing value etc.
I find it hard to actually see what I have entered for the Enclosure using several sections: Which Elements are to the Closed End, which Elements are to the Open End.
It would also be nice if the GeometryDisplay had measurements (cm) to ensure the Enclosure data had been entered correctly.
(I use simulation of stuffing distribution a lot.)
What I find very nice in "Easy Quarter-Wave" is the near real time result of the changes, and how easy it is "to move the driver" up and down in the line.
When I have some more time, I will compare to MJK models.
Hi from
Bjorn
First impression is that input fields could be more userfriendly, liter instead of m3, cm instead of meters, cm2 instead of m3. Stuffing value etc.
I find it hard to actually see what I have entered for the Enclosure using several sections: Which Elements are to the Closed End, which Elements are to the Open End.
It would also be nice if the GeometryDisplay had measurements (cm) to ensure the Enclosure data had been entered correctly.
(I use simulation of stuffing distribution a lot.)
What I find very nice in "Easy Quarter-Wave" is the near real time result of the changes, and how easy it is "to move the driver" up and down in the line.
When I have some more time, I will compare to MJK models.
Hi from
Bjorn
I find it hard to actually see what I have entered for the Enclosure using several sections: Which Elements are to the Closed End, which Elements are to the Open End.
Sorry, my mistake. I now see what Closed and Open means by reading the latest replies.
Hi from
Wonderful Copenhagen
I almost forgot, one last suggestion. Things would go a lot smoother if things just updated automatically without the having to click the "update" button every time you make a change.
I must defer. WinISD works like that, and I keep getting annoying error messages when I typo. 😱I almost forgot, one last suggestion. Things would go a lot smoother if things just updated automatically without the having to click the "update" button every time you make a change.
I think it may be even less apropos in a TL program where it's not uncommon to change several entries at once.
While it is possible to do that in code, it can be quite painful to implement. I go through stages where I try to do changes on the fly and other times I prefer to use a update button. The problem with real time changes is you have to spend a lot more time trying to catch errors.
For example deleting all of the data out of a box in real time will throw up one type of exception, type a letter where a number should be will throw up another, where as you use an update button it can check all of the data in one go and tell you if you have it right or wrong before it crashes anything.
Edit:
Forgot it has to check for double decimal points etc (while a decimal point is a valid entry and therefore you can't exclude it from acceptable characters, you only want the one), I have written code to check for all these things, and it can be quite handy for an application like this where you are dealing with a lot of decimal placed numbers, as you can use the same bit of code for numerous boxes.
For example deleting all of the data out of a box in real time will throw up one type of exception, type a letter where a number should be will throw up another, where as you use an update button it can check all of the data in one go and tell you if you have it right or wrong before it crashes anything.
Edit:
Forgot it has to check for double decimal points etc (while a decimal point is a valid entry and therefore you can't exclude it from acceptable characters, you only want the one), I have written code to check for all these things, and it can be quite handy for an application like this where you are dealing with a lot of decimal placed numbers, as you can use the same bit of code for numerous boxes.
Last edited:
Not sure if you plan to offer imperial conversion to those that don't speak native metric.... but here is a bit of code I wrote that works quite well for a two way conversion, you are most welcome to use it in your app.
Imports System.Math
Public Class Conversion
Dim Position As Integer
Dim FirstPart As Integer
Dim SecondPart As Integer
Dim ThirdPart As Integer
Const checkString As String = ".0123456789"
Public Function UnitConversion(ByRef ConvertMe As String, ByRef Metric As Boolean) As String
Dim charArray() As Char = ConvertMe.ToCharArray
Dim aBool As Boolean = False
For i = 0 To charArray.Length - 1
If CBool(InStr(checkString, charArray(i).ToString)) = False Then
If charArray(i).ToString = "/" Then
SecondPart = CInt(ConvertMe.Substring(Position, (ConvertMe.IndexOf("/") - Position)))
Position = ConvertMe.IndexOf("/") + 1
Else
FirstPart = CInt(ConvertMe.Substring(0, ConvertMe.IndexOf(charArray(i).ToString)))
Position = ConvertMe.IndexOf(charArray(i).ToString) + 1
End If
aBool = True
End If
Next
If aBool Then
Metric = False
ThirdPart = CInt(ConvertMe.Substring(Position, ConvertMe.Length - Position))
ConvertMe = CStr(Round((FirstPart + (SecondPart / ThirdPart)) * 25.4, 4))
Position = 0
FirstPart = 0
SecondPart = 0
ThirdPart = 0
Else
Metric = True
Dim Reducer As Double = CDbl(ConvertMe)
Dim Inches As Integer = CInt(Int(Reducer / 25.4)) 'Find the number of inches
Reducer -= Round(Inches * 25.4, 7) 'Subtract off the inches (out to 7 decimal points of accuracy)
Dim SixtyFourths As Integer = CInt(Int(Reducer / 0.396875)) 'Calculate the number of 64ths
Reducer -= Round(SixtyFourths * 0.396875, 7) 'Subract off the 64ths calculated
If Reducer > (0.396875 / 2) Then SixtyFourths += 1
Dim denom As Integer = 64 'The denominator starts off at 64
If CBool(SixtyFourths) Then 'If the number of 64ths is not 0 {even inches}
Do While (SixtyFourths And 1) = 0 'Do while number of SixtyFourths is even
SixtyFourths >>= 1 'Divide SixtyFourths by 2 (shift one bit to the right)
denom >>= 1 'Divide the denominator by 2
Loop
If CBool(Inches) Then
ConvertMe = String.Format("{0}-{1}/{2}", Inches, SixtyFourths, denom) 'Format inches and fraction
Else
ConvertMe = String.Format("{0}/{1}", SixtyFourths, denom) 'Format the fraction
End If
Else
ConvertMe = String.Format("{0}", Inches) 'Format inches only
End If
If Reducer <> 0 Then ConvertMe = "~" + ConvertMe
End If
Return (ConvertMe)
End Function
End Class
Imports System.Math
Public Class Conversion
Dim Position As Integer
Dim FirstPart As Integer
Dim SecondPart As Integer
Dim ThirdPart As Integer
Const checkString As String = ".0123456789"
Public Function UnitConversion(ByRef ConvertMe As String, ByRef Metric As Boolean) As String
Dim charArray() As Char = ConvertMe.ToCharArray
Dim aBool As Boolean = False
For i = 0 To charArray.Length - 1
If CBool(InStr(checkString, charArray(i).ToString)) = False Then
If charArray(i).ToString = "/" Then
SecondPart = CInt(ConvertMe.Substring(Position, (ConvertMe.IndexOf("/") - Position)))
Position = ConvertMe.IndexOf("/") + 1
Else
FirstPart = CInt(ConvertMe.Substring(0, ConvertMe.IndexOf(charArray(i).ToString)))
Position = ConvertMe.IndexOf(charArray(i).ToString) + 1
End If
aBool = True
End If
Next
If aBool Then
Metric = False
ThirdPart = CInt(ConvertMe.Substring(Position, ConvertMe.Length - Position))
ConvertMe = CStr(Round((FirstPart + (SecondPart / ThirdPart)) * 25.4, 4))
Position = 0
FirstPart = 0
SecondPart = 0
ThirdPart = 0
Else
Metric = True
Dim Reducer As Double = CDbl(ConvertMe)
Dim Inches As Integer = CInt(Int(Reducer / 25.4)) 'Find the number of inches
Reducer -= Round(Inches * 25.4, 7) 'Subtract off the inches (out to 7 decimal points of accuracy)
Dim SixtyFourths As Integer = CInt(Int(Reducer / 0.396875)) 'Calculate the number of 64ths
Reducer -= Round(SixtyFourths * 0.396875, 7) 'Subract off the 64ths calculated
If Reducer > (0.396875 / 2) Then SixtyFourths += 1
Dim denom As Integer = 64 'The denominator starts off at 64
If CBool(SixtyFourths) Then 'If the number of 64ths is not 0 {even inches}
Do While (SixtyFourths And 1) = 0 'Do while number of SixtyFourths is even
SixtyFourths >>= 1 'Divide SixtyFourths by 2 (shift one bit to the right)
denom >>= 1 'Divide the denominator by 2
Loop
If CBool(Inches) Then
ConvertMe = String.Format("{0}-{1}/{2}", Inches, SixtyFourths, denom) 'Format inches and fraction
Else
ConvertMe = String.Format("{0}/{1}", SixtyFourths, denom) 'Format the fraction
End If
Else
ConvertMe = String.Format("{0}", Inches) 'Format inches only
End If
If Reducer <> 0 Then ConvertMe = "~" + ConvertMe
End If
Return (ConvertMe)
End Function
End Class
I must defer. WinISD works like that, and I keep getting annoying error messages when I typo. 😱
I think it may be even less apropos in a TL program where it's not uncommon to change several entries at once.
Ok, I see what you mean, it probably shouldn't auto update every single time you type a character. But if the program auto updates every time you leave an input box, that's what I"d like to see. For example, the program could just assume that every time you leave an input box and click somewhere else, you'd like the program to click "update" for you, I don't see any need or advantage to do this manually.
When you are going through several iterations of a design trying to perfect it, just making single, small changes each time, that update button is going to get very annoying. Certainly not unmanageable but annoying nonetheless.
Last edited:
That's doable through something like "lose focus" you click away and it performs the check / update. But whether you do it in real time or after you leave the box it still needs to check the validity of the value, and have some means of fixing the value should you have it wrong.
I must defer. WinISD works like that, and I keep getting annoying error messages when I typo. 😱
I think it may be even less apropos in a TL program where it's not uncommon to change several entries at once.
I'll second this... It think it's perfect just the way it is. I probably ran close to 1000 variations on two designs today, and I didn't find the button cumbersome at all.
Quite the opposite in fact... if you're making small changes, having the "Apply" button allows you to focus on the graphs and the way they change as you click the button. If it just updated after text entry you might constantly be wondering if it changed, or by how much.
Add to this the incredibly obnoxious tendency of programs like winISD to throw errors when you delete the value in a box, and I think it's not worth the trouble. My vote would be for the button to stay.
By the way, I checked a ported enclosure simulated in winISD and this program, and they agreed nicely with the same parameters in both programs. Not a guarantee, but it's a good thing.
Cheers,
Owen
... if you're making small changes, having the "Apply" button allows you to focus on the graphs and the way they change as you click the button. If it just updated after text entry you might constantly be wondering if it changed, or by how much.
Cheers,
Owen
If you can focus on the graph while you click "update" you should be able to focus on the graph as you click ANYWHERE except the active input box (which would have the same effect, as I proposed). The only difference is it would be much easier and faster with no "update" button.
Maybe we aren't picturing the same thing, there also wouldn't be any error when you clear an input box, no changes would be applied until you left that input box.
- Home
- Design & Build
- Software Tools
- Transmission Line Modelling Software