(12/4/07)

TLineSim Frequently Asked Questions (FAQs):           

 

General

 

Technical

 

 

 

Answers:

 

 

The TLinesim.com web site was started as a project to see whether 2-port simulations could be done as a web site using a standard web server. Since most RF transmission line problems can be reduced to a single signal path, the initial engine was designs to work with 2 port device models (no differential or coupled paths) so the calculations can be very fast.  The application uses standard HTML format for all of its input and output, requiring only a web browser and internet connection to access it.  This simulation tool is free to use and does not require any login information. The target application is for educational purposes; however the powerful features and simple user interface allow the user to do much more.

 

 

 

      There is no individual tracking occurring anywhere in the web site.  No cookies are placed on the user’s computer, and all simulation activity done by the user is erased from memory when the user’s session times out.  The only tracking that is done is on a general scale.  A small bit of JavaScript is placed on each page that reports if a particular page is being used or not. Also, some technical information (like IP address, browser type, operating system, etc.) is stored to get information about where users are coming from and what browsers are most popular.  For example, here are some recent statistics from the TLineSim.com web site (November 2007):

 

Browser Types:

 

     

 

       

 

 

Operating Systems:

 

   

 

 

Top Locations for users:

 

        

 

 

Monitor Resolution:

 

         

 

 

 

      TLineSim is an experiment to see if RF and SI engineers will actually use simulation tools on the web.  As more people have internet access readily available, the software becomes easier to use from anywhere in the world.  The long term goal is to integrate the tool into the Gore.com web site under the electronic products section.  The hope is that more traffic to the web site will bring a greater awareness of Gore’s broad capabilities and world class products (no bias here).  The main motivator to continue work on the project will be user feedback.  If lots of folks use the application and provide feedback (good or bad), the project will continue.  If no one uses the application and does not provide feedback, then it will most likely not continue.

 

 

 

No.  The intent for the software is to be web-based (as described earlier).  To make a stand alone version would be pretty straight forward, but would go against the original intent:  To have a web-based tool that engineers use for educational purposes, or to perform “What-If?” simulations concerning transmission line behavior.  This way, the user can access it from home or any public library, coffee shop, university or business that has web access.

 

 

 

      Yes.  The examples are simply simulation files (.sim) that have been saved to the web server.  There is an optional .htm file that can go along with each one which provides some simple information about the example.  If you have some good ideas for an example, I would be happy to hear about it.  Just send me an email to the address on the Startup page.

 

 

 

      Throughout the application, there are places to enter information via text boxes, drop-down list boxes, check boxes and radio buttons.  Each time the user makes a change to one of these objects, the web page is “posted back” to the server so that everything can be computed and updated.  This “post-back” makes the screen flash.  In the past, I use to do this by way of an “Update button” that would update all of the changes to that particular screen.  The problem with this was users were hitting the “Back” button on their browser before changes were updated.  Having the tools auto post-back is a solution to this.  If this approach is too obnoxious, I would consider going back to the old way.  Give me your thoughts on this and I’ll collect the various opinions.

 

 

 

      Not at this time.  The hope was that the user interface would be intuitive enough for the user to hack their way through it.  Then, with the use of “Help” buttons,  pop-up windows would provide the extra help needed.  If you feel a tutorial or manual (or even a webinar) would be helpful, or if you identify certain areas that need more pop-up help options, please send me an email.

 

 

 

      The application was written in Visual Basic .NET using an ASP.net web server.  This makes it very easy to put together a web interface that is compatible with Microsoft Internet Explorer, but not necessarily with other browsers.  I have been able to fix most of the problems by changing the style sheet or outright changing some text to .gif images.  There still may be some anomalies here and there.  Based on the information above, about 19% of the users have Mozilla based browsers.

 

 

 

      The best thing to do is the send me an email with the .sim file attached.  Include your questions and details about the simulation. You can save the .sim file locally from the “Test Bench” screen.  You can send that to: tclupper@wlgore.com.

 

 

 

      The elements chosen should cover most transmission line problems (I am always interested in suggestions for other element types). They are:

 

 

 

 

      There are three different sources: A vector network analyzer, or VNA (which also acts as the test instrument), a bit-pattern generator, and a waveform generator.  The test instruments are: The VNA, an oscilloscope, and a spectrum analyzer.  I am considering adding an “Arbitrary waveform generator” define by a piecewise linear source (see comments on SPICE below).

 

 

 

     As was mentioned before, the initial computational engine was designed to handle 2-port linear devices and data (e.g. 2-port S-parameters).  Certain differential transmission line effects can be simulated if one reduces the 4-port S-parameters to differential S-parameters (Sdd).  This way, the differential mode loss characteristics can be treated as a single signal path.  The engine could be extended to handle 4-port cascaded matrices, but the models would have to support it.  If the software really takes off in popularity, it will be something to consider adding in.

 

 

 

      The computational engine is written Visual Basic .NET (2005) and is really broken down into 3 parts.  First, when a simulation is performed, all of the element models are reduced to 2-port S-parameter matrices.  Then, they are cascaded to form one S-parameter matrix.  Second, the arbitrary sources are created in the time domain and transformed (using FFT) to the frequency domain. Third, the sources, S-parameter matrix, and load characteristics are combined (along with the necessary windows) to compute the desired output parameter.

 

      The basic limitation is the fact that the FFT is computed over a fixed (and repeating) length in time.  Therefore, sources that have behavior over long periods in time (like Bit-patterns or Steps) can be tricky to deal with.  The Bit-pattern and Waveform generator sources do calculate the proper Frequency and Time domain start, stop, and number of point conditions for most applications.  However, the user needs to be aware of the total length of their device under test (DUT) and its electrical length.  This way, the FFT won’t wrap around (or alias) before the source pattern has completely gone through the DUT.  This is even more complicated when dealing with reflection type parameters, since they make the DUT seem twice as long as it really is.

 

      If you have any questions regarding the computational engine and the results you are getting from the simulation, it is best to send me your question by email and attach the .sim file along with it.

 

 

 

      Since the information needed to compute a simulation is fairly small, the corresponding .sim file is also small.  Therefore, I went with a standard flat text file format, with the data being comma delimited.  I may (at some time) release the meaning behind all of the numbers, but I don’t think it is really necessary right now.  I have even toyed with the idea of making the file format compatible with an XML format.  If you have any thoughts on this, I would love to hear them.

 

 

 

      As mentioned before, the computational engine uses FFTs to integrated arbitrary sources with S-parameter data.  Depending on the source characteristics it will need certain start and stop frequencies and number of points to match up with the simulation.  At some time in the future, I will integrate in a feature that will perform some “re-mapping” of the frequency data to match the needed start, stop, and number of points requirements.  For now, the plan is to have the user go to a VNA and measure his or her DUT with this frequency setup up, or have them do the re-mapping off-line before bringing the data into TLineSim.

 

 

 

      The models are parametric-based and were developed using information found in the general literature.  The approach to creating a model is to obtain the R, L_external, L_internal, G, and C from the formulas and than calculate the S-parameters for that transmission line segment.  For coax and waveguide, it is pretty straight forward, but for microstrip and stripline, it is more difficult.  I have put together a document that describes the formulas used to generate the models and where they came from.

 

 

 

      One individual asked about IBIS models.  Although I am not that familiar with them, I will look into the possibility of incorporating IBIS source and receiver models into the application.  The trick will be that the simulation engine can only handle linear characteristics, so the models will have to be approximated by a linear source and source impedance.  If I come up with something, I will post it on the web site.  A SPICE piecewise linear source could be incorporated fairly easily, because the source characteristics are arbitrary to begin with.  If this is of interest, please send me an email.

 

 

 

No. The cables are shown as a “virtual” connection between the source and the DUT on one side, and the DUT and test equipment on the other.  The measurement “reference planes” are always going to be exactly at the beginning and end of the DUT.