For most of 2009 the TILE! support team has been taking part in a development project that will improve some of the usability of the software.  Most of these enhancements will be in the immunity area.  I will save the details for when we get closer to releasing it.  Again we have brought the core of the software up to date so that we can take advantage of more third party plug-ins if we want to. 

This release will most likely be version 4.5.  You will be able to import profiles from v4.0 and 4.1 but you will have some more settings to consider in some of the actions.  If you leave it alone you will most likely get the correct results, but to take advantage of new features you may want to re-configure some of the actions.

We are still using drivers built in C++, not LabView.  However, if we find it advantageous to do that we can.  As most of you know, the driver is mostly a list of commands.  If an action wants a device to do something like change the center frequency, it will make a call for that change along with the value (frequency).  Since TILE! supports so many devices this simple call can be complicated.  To simplify it, TILE! combines action requests with known drivers responses.  So if you want to change the center frequency the action and driver must be able to speak the same language.  LabView drivers only know the command set that the device owners gave it. Therefore, TILE! would still have to have a translator to talk to that driver.  So for now we think we can do what is needed  with the current methodology.  That said, we are still going to improve the process for altering instrument behavior based on customer requests.

Dr. Gemei Yang, our senior software engineer has submitted a paper to the IEEE EMC committee that describes an evolutionary concept for EMC test software that describes where we expect to be in the next iteration of the software.  I will post a link when that paper is published.

Once my software engineers read this they may want to contribute to this post to point out my misunderstandings, so if there are no posts from them then I guess I got it right!

I will post more information in 2010 on our progress.  Meanwhile please post comments here or use the support link at the top of the page to communicate with us.

Happy New Year 2010!

Joe Tannehill

For the most part you can figure out the driver by the alpha prefix, such as hp, ag, rs…and the numeric or alpha body; 8546, esu, esci, 2022.  Yes there is some duplication of hp and ag drivers and some rs drivers simply have the unit name such as esi_rx.  We have kept it that way for now to reduce confusion and keep continuity from older versions.

Most drivers work well within its own family since the venders try to keep the code as universal as possible.  That is why we suggest that you try different drivers if the one you have is not working. 

As you can tell multi role instruments have multiple drivers, such as sa and rx.  But those are easy…

Some have an _3, _4_5 this  usually refers to a firmware version and some have 1000, 4000, 8000 that refer to points used.

Now I am asking your help.  I do not know what some of these driver suffix mean.  Through a by chance meeting I found out that the hp8563e/a_bfg stands for B.F. Goodrich.  This was a driver that would set bandwidths for pulse measurements. 

What are _spc, spc2, spc3′s and _ro?

If you have any insights to any of these names please add them here by commenting or send us a note on the ‘Support’ page.

Thanks!

Joe